|
Sorry, I was sick last week and just getting caught up on my
email. The PDF does have IPMI log in information. There was some
concerns with this so Aric is working on a way to secure the log
in details. See patch https://gerrit.opnfv.org/gerrit/#/c/44389/
On 10/13/2017 12:15 AM, Jose Lausuch
wrote:
Hi,
When it comes to log collection, I strongly believe
it should be done post-job in our CI pipeline, not as part of
the test case. Users can always collect logs manually regardless
of the installer tools they use…
And regarding making it automated in OPNFV after
Functest/Yardstick execution, would it make sense to re-use the
PDF (Pod Descriptor File)? Otherwise, we are duplicating config
files like pod.yaml or new files with information about the
servers…
@Jack: is there a possibility to include login
information in the PDF (user, password, path to private key, …)
of the nodes already deployed?
Hi Srikanth,
I have one question. Are the
paths of all these log files constant for different
environment (Apex, Fuel and commercial deployments)?
If all paths for different
deployments are the same, then using config file to
login and getting files can work.
If not, there will be some
errors even though it can login with the config
file.
One more question, what logs
do SDNVPN get from all nodes? Are they useful for
users? If not, can we have an option to disable it?
Thanks
Dan Xu
Hi Srikanth,
Yardstick can use a global pod.yaml for
test cases.
Since each test case default use the “pod.yaml” located in “/etc/yardstick/pod.yaml”. so if you put “pod.yaml” here, it
can apply to each test case.
The picture you show below is how
yardstick test suite customize the input parameters,
so it also support each test case with different “pod.yaml”
if you give each test case different “pod.yaml”
BR,
Rex
+-------------------------------------------------------------------------------------------+
<image001.png>
+ Mingjiang Li (Rex) Mobile:
+86 13761275017
+ Shanghai Institute,
Huawei
+ No. 2222,
Xinjinqiao Road, Pudong, Shanghai, 201206,
P.R.China
+-------------------------------------------------------------------------------------------+
Thanks everyone for your
inputs.
So if Yardstick based approach
is the preferred one, then I am thinking of
extending the existing Deployment Factory class with
a new generic INSTALLER type (something like
“config-file” or so) which will provide the same
interface as other adapters (ApexAdapter,
FuelAdapter…etc), but instead reads from the a
configured pod.yaml file to provide Node
information. Plz let me know if you see any issues
with this approach.
One quick question on
Yardstick: Looks like Yardstick accepts the custom
pod.yaml file on a per test case basis as shown in
the below example. Can it also accept a global
pod.yaml file that can be applied to all or a group
of test cases.
-
file_name: opnfv_yardstick_tc043.yaml
constraint:
installer: xxx
pod: xxx-pod1
task_args:
xxx-pod1: '{"pod_info":
"etc/yardstick/.../pod.yaml",
"host": "node1.LF","target": "node2.LF"}'
Thanks
Srikanth
Hi,
I would vote for having
something similar to Yardstick [1] but centralized
in Releng with an easy python lib that enables
functions like SCP things to/from the deployed
nodes.
Just to highlight this, from
a Dovetail/CVP perspective, the important
aspect is that there are no dependencies
on OPNFV-specific resources/lib in order
to be able to run test cases against
commercial non-OPNFV deployments.
Having to write an adapter
for a particular commercial deployment
before you can run Dovetail is obviously
not really an option. So, for tests which
require SSH/SCP access, we need to think
about...
- If the adapter can be
parameterized, so that we can make it a
configuration option, e.g., specifying
login credentials, source and target
directories, etc., similarly to Yardstick.
- Reuse what Yardstick is
using?
- If the test case be
parameterized such that it does not
attempt to gather logs if used for
certification? (limited use, of course)
- …
With regards
to Functest, you can run it on any
OpenStack deployment as long as
you provide a proper RC file and
meet the requirements on the
jumphost (docker, connectivity to
the deployment, …).
However, in
some cases, some test cases from
feature projects require SSH
access to the deployment and to
make things centralized, the
deployment handler was created
[1]. This is a library that allows
users to get the number of nodes
from the deployment, functions to
SCP things from the nodes and some
other utils. The bad part of it is
that it only supports Apex, Fuel
and OSA for now… unless someones
volunteers to write the other
adapters for joid, mcp, compass
osa.. This library might be used
to extract the desired logs after
Functest/Yardstick runs in CI to
place them in artifact repo and
post-analize.
StorPerf very much
relies on
knowledge of
the installer
to gather
information
about the
block storage
underlay. For
example, the
number of Ceph
nodes, or even
Ceph vs. LVM,
is very
relevant to
the final
report. I
also wish
there were an
installer
agnostic
method of
collecting
this
information as
right now I
keep that code
in the
ci/daily.sh
and other
scripts.
With the new releng
repository
being created,
perhaps it is
time to start
moving some of
the installer
specific code
there? I also
see that being
of benefit
when adding
XCI support,
as technically
that would be
yet another
type of
installer.
SW System Sr Principal
Engineer
Dell EMC |
Office of the
CTO
As I know,
some Yardstick test
cases also need to login
nodes. Yardstick uses a
file providing all the
login information.
So,
the jira ticket proposes
to accept all the needed
information about the
OpenStack controllers,
compute nodes and the
associated username,
keys…etc. in a file
format such that these
tests can also be run on
OPNFV based commercial
products deployed with
their custom deployment
tools.
So
in general, in the test
tools, is there any need
to have awareness of
what installers being
used when we all care
about the target
OpenStack node IPs,
associated attributes
and jumphost IP (in some
cases)?
I
would like to get the
community opinion here.
Appreciate your inputs.
_______________________________________________
opnfv-tech-discuss
mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
--
Jack Morgan
OPNFV Pharos Intel Lab
|
