Re: [opnfv-tech-discuss] Anyone working with Clearwater-docker ?

[Srikanth Vavilapalli]

Hi Brian

I also observed the same issue while building Ellis docker image:

Step 4/12 : RUN /etc/init.d/mysql start && apt-get update && 
DEBIAN_FRONTEND=noninteractive apt-get install -y --force-yes ellis
---> Running in ec6a9983baae
* Starting MySQL database server mysqld
   ...fail!
The command '/bin/sh -c /etc/init.d/mysql start && apt-get update && 
DEBIAN_FRONTEND=noninteractive apt-get install -y --force-yes ellis' returned a 
non-zero code: 1

I tried to use some pre-built ellis image from dockerhub (kubeguide/ellis), but 
it is throwing up some exceptions internally when trying to create a private 
identity, so seems this is also not a viable solution.

Thanks
Srikanth

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of SULLIVAN, 
BRYAN L (BRYAN L)
Sent: Friday, November 10, 2017 6:59 AM
To: 'opnfv-tech-discuss@lists.opnfv.org' 
Subject: [opnfv-tech-discuss] Anyone working with Clearwater-docker ?

Hi all,

This goes out to anyone who is experimenting with Metaswitch clearwater-docker, 
or who might have an idea what's going on with an error I am having when trying 
to build it. I'm doing this as part of the Models project development of 
cloud-native stacks (https://github.com/opnfv/models/tree/master/tools) and 
will be using Cloudify with the k8s plugin. See 
https://github.com/opnfv/models/tree/master/tools/kubernetes for the working 
scripts that I use to deploy the stack 
(k8s+Helm+ceph-docker+Prometheus+Cloudify)
 and a hello world demo app. Other than trying to expand to deployment of real 
VNFs, I'm also working on VES integration using the latest Barometer VES plugin.

The issue I am having is with building the Ellis image, and is the same as 
https://github.com/Metaswitch/clearwater-docker/issues/74. You can see my 
environment in the note I added to that issue thread.

Any advice is appreciated.

Thanks,
Bryan Sullivan | AT

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [availability]High Availability Project meeting on Oct. 18

[Srikanth Vavilapalli]

Thanks Kubi. Yes, we can discuss this further in this week’s HA meeting 
(Nov-1st).

Thanks
Srikanth

From: Georg Kunz
Sent: Sunday, October 29, 2017 12:29 PM
To: Gaoliang (kubi) <jean.gaoli...@huawei.com>; Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com>
Cc: 'juan_qiu' <juan_...@tongji.edu.cn>; 'Yue Yuan' <yuan@zte.com.cn>; 
'opnfv-tech-discuss' <opnfv-tech-discuss@lists.opnfv.org>; Fu Qiao 
<fuq...@chinamobile.com>; 'Fan Yamei' <fanya...@chinamobile.com>; 'Tony Yin' 
<14_...@tongji.edu.cn>; 'lansizhong' <lansizh...@chinamobile.com>; 'wucaifu' 
<wuca...@chinamobile.com>; 'likaiyjy' <likai...@chinamobile.com>; 'wangxuyjy' 
<wangxu...@chinamobile.com>
Subject: RE: [opnfv-tech-discuss] [availability]High Availability Project 
meeting on Oct. 18

Hi Kubi,

Thank you very much for creating the slide deck. This is very helpful.

Regards
Georg


From: Gaoliang (kubi) [mailto:jean.gaoli...@huawei.com]
Sent: Friday, October 27, 2017 8:35 AM
To: Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>>
Cc: 'juan_qiu' <juan_...@tongji.edu.cn<mailto:juan_...@tongji.edu.cn>>; 'Yue 
Yuan' <yuan@zte.com.cn<mailto:yuan@zte.com.cn>>; 'opnfv-tech-discuss' 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>;
 Georg Kunz <georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>; Fu Qiao 
<fuq...@chinamobile.com<mailto:fuq...@chinamobile.com>>; 'Fan Yamei' 
<fanya...@chinamobile.com<mailto:fanya...@chinamobile.com>>; 'Tony Yin' 
<14_...@tongji.edu.cn<mailto:14_...@tongji.edu.cn>>; 'lansizhong' 
<lansizh...@chinamobile.com<mailto:lansizh...@chinamobile.com>>; 'wucaifu' 
<wuca...@chinamobile.com<mailto:wuca...@chinamobile.com>>; 'likaiyjy' 
<likai...@chinamobile.com<mailto:likai...@chinamobile.com>>; 'wangxuyjy' 
<wangxu...@chinamobile.com<mailto:wangxu...@chinamobile.com>>
Subject: RE: [opnfv-tech-discuss] [availability]High Availability Project 
meeting on Oct. 18

Hi Srikanth,

Thanks for your email

I went through the etherpad page of HA test case Fraser Planning,  It looks 
good.  Yardstick Fraser planning[3] is also on going. We already plan to sync 
the requirement from HA Team.  I would like to join the next HA meeting to 
discuss more detail about further HA test cases.

What I did is to following the action point of Test WG weekly meeting[1], I 
briefly summarized the existing HA test cases in Yardstick repo and make a 
slide[2] to  introduce HA testing to Openstack QA team, because they also would 
like to do some “ destructive testing” in Openstack community.  I guess Georg 
is the key person to connected with Openstack QA team.

[1] 
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2017/opnfv-testperf.2017-09-28-15.00.html
[2] 
https://wiki.opnfv.org/pages/viewpage.action?pageId=5734608=/5734608/13206674/HA%20testing%20in%20Yardstick%20v0.6.pdf
[3] https://etherpad.opnfv.org/p/yardstick_release_f

Regards,
Kubi
发件人: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com]
发送时间: 2017年10月27日 2:49
收件人: Georg Kunz <georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>; Fu 
Qiao <fuq...@chinamobile.com<mailto:fuq...@chinamobile.com>>; 'Fan Yamei' 
<fanya...@chinamobile.com<mailto:fanya...@chinamobile.com>>; 'Tony Yin' 
<14_...@tongji.edu.cn<mailto:14_...@tongji.edu.cn>>; 'lansizhong' 
<lansizh...@chinamobile.com<mailto:lansizh...@chinamobile.com>>; 'wucaifu' 
<wuca...@chinamobile.com<mailto:wuca...@chinamobile.com>>; 'likaiyjy' 
<likai...@chinamobile.com<mailto:likai...@chinamobile.com>>; 'wangxuyjy' 
<wangxu...@chinamobile.com<mailto:wangxu...@chinamobile.com>>; Gaoliang (kubi) 
<jean.gaoli...@huawei.com<mailto:jean.gaoli...@huawei.com>>
抄送: 'juan_qiu' <juan_...@tongji.edu.cn<mailto:juan_...@tongji.edu.cn>>; 'Yue 
Yuan' <yuan@zte.com.cn<mailto:yuan@zte.com.cn>>; 'opnfv-tech-discuss' 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
主题: RE: 答复: [opnfv-tech-discuss] [availability]High Availability Project 
meeting on Oct. 18

+kubi

Hi Kubi

I am referring to this e-mail thread in today’s test-wg call and here is the 
link to etherpad: https://etherpad.opnfv.org/p/HA_Testcases_F_Release where we 
are collating the High Availability test scenarios that we wanted to target for 
F release. As I understood from today’s call that you are also doing the 
similar exercise (by collecting inputs from OpenStack QA project and other 
sources) and it would be good if we can combine all these findings into the 
above etherpad.

Thanks
Srikanth

From: Georg Kunz
Sent: Wednesday, October 25, 2017 2:40 AM
To: Fu Qiao <

Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Srikanth Vavilapalli]

Hi Jose

Yes, the cleaner solution is to move the log collection or any deployer 
specific actions to outside of test frameworks such that they can be run 
against any OPNFV compliant platforms. We need to brainstorm in some forum on 
the best way to achieve this. David, plz help us.

For the immediate need, we can add a fix in sdnvpn project such that  
sdnvpn.lib.utils.get_nodes() returns an empty list of nodes rather than 
throwing exception if the INSTALLER_TYPE is set to anything else other than 
“apex” and “fuel”. So this is kind of disabling the sdnvpn LOG collection in 
other installer types.

Plz let me know any comments or inputs…

Thanks
Srikanth



From: Jose Lausuch [mailto:jalaus...@suse.com]
Sent: Tuesday, October 17, 2017 8:18 AM
To: David McBride <dmcbr...@linuxfoundation.org>; Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com>
Cc: Tim Irnich <tim.irn...@ericsson.com>; Tim Rozet <tro...@redhat.com>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

IMO, the log collection topic is a CI/Releng function rather than the test 
framework’s responsibility,  we should not discuss it only during the Functest 
weekly since we would lose audience.
@David, will you bring this discussion to the infra or technical weekly meeting?

Thanks,
Jose




On 17 Oct 2017, at 00:32, Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>> 
wrote:

Hi

Can we have a quick discussion in any weekly meeting (sdnvpn, functest?) on 
this topic to pick the best approach to move forward? Also Xu Dan has raised 
few other concerns on the location of log files and option for disabling the 
gathering logs…etc.

Thanks
Srikanth



From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Friday, October 13, 2017 4:28 AM
To: Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi Tim,

My only concern is that by implementing this function inside the test case, we 
might run into exceptions raised if there is a problem with SSH keys or 
whatever other problem accessing the nodes.

Collecting logs when the test fails makes sense, but it doesn’t harm if we 
collect it when it passes as well. Anyway, if we do it only when having 
failures, I imagine that logic could also be implemented post-job by checking 
the "criteria": “FAIL" value on the DB and executing some j-job to collect the 
logs. This logs could be uploaded to artifact repo for further analysis as we 
do for the Functest logs.

Regards,
Jose




On 13 Oct 2017, at 09:27, Tim Irnich 
<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>> wrote:

Jose,

I see the point of avoiding log collection in the code for test execution to 
avoid false negatives in case something with the log collection itself goes 
wrong (although I’m wondering a bit if that cannot also be handled by carefully 
implementing the test pass/fail criteria).

There are however cases where we’ll want to collect logs only if a test fails, 
in order to enable a first tier of offline troubleshooting. You’ll remember the 
gather_logs function Niko implemented for the bgpvpn tests – that is one 
example. Can that effectively be handled if we separate things as you suggest?

Regards, Tim


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Friday, October 13, 2017 09:16
To: xudan (N) <xuda...@huawei.com<mailto:xuda...@huawei.com>>; Morgan, Jack 
<jack.mor...@intel.com<mailto:jack.mor...@intel.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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?

Regards,
Jose




On 

Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Srikanth Vavilapalli]

Hi

Can we have a quick discussion in any weekly meeting (sdnvpn, functest?) on 
this topic to pick the best approach to move forward? Also Xu Dan has raised 
few other concerns on the location of log files and option for disabling the 
gathering logs…etc.

Thanks
Srikanth



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Friday, October 13, 2017 4:28 AM
To: Tim Irnich <tim.irn...@ericsson.com>
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi Tim,

My only concern is that by implementing this function inside the test case, we 
might run into exceptions raised if there is a problem with SSH keys or 
whatever other problem accessing the nodes.

Collecting logs when the test fails makes sense, but it doesn’t harm if we 
collect it when it passes as well. Anyway, if we do it only when having 
failures, I imagine that logic could also be implemented post-job by checking 
the "criteria": “FAIL" value on the DB and executing some j-job to collect the 
logs. This logs could be uploaded to artifact repo for further analysis as we 
do for the Functest logs.

Regards,
Jose




On 13 Oct 2017, at 09:27, Tim Irnich 
<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>> wrote:

Jose,

I see the point of avoiding log collection in the code for test execution to 
avoid false negatives in case something with the log collection itself goes 
wrong (although I’m wondering a bit if that cannot also be handled by carefully 
implementing the test pass/fail criteria).

There are however cases where we’ll want to collect logs only if a test fails, 
in order to enable a first tier of offline troubleshooting. You’ll remember the 
gather_logs function Niko implemented for the bgpvpn tests – that is one 
example. Can that effectively be handled if we separate things as you suggest?

Regards, Tim


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Friday, October 13, 2017 09:16
To: xudan (N) <xuda...@huawei.com<mailto:xuda...@huawei.com>>; Morgan, Jack 
<jack.mor...@intel.com<mailto:jack.mor...@intel.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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?

Regards,
Jose




On 12 Oct 2017, at 03:50, xudan (N) 
<xuda...@huawei.com<mailto:xuda...@huawei.com>> wrote:

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

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of limingjiang
Sent: Thursday, October 12, 2017 9:24 AM
To: Srikanth Vavilapalli
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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

+---+

+ Mingjiang Li (Rex) Mobile: +86 13761275017
+ Shanghai Institute, Huawei
+ No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
+---

Re: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Srikanth Vavilapalli]

Hi Dan

I think you raised a valid point for which I am not sure if the log file paths 
across all deployments stays remain same (in some case, there may be no local 
logging configured)

Seems like the gather_logs() routine in sdnvpn is assuming certain log file 
locations. It is collecting the logs from the following locations on the 
openstack nodes:

  1.  OpenStack
 *   /var/log/nova/
 *   /var/log/neutron/
  2.  OpenDaylight sdnvpn related Karaf logs (If running)
 *   /opt/opendaylight/data/log/
  3.  OVS (Logs for port,flows,groups dump)
 *   /var/log/openvswitch/

I believe these logs are more for debugging purposes rather than for end user 
consumption, but I may be wrong here.

Thanks
Srikanth

From: xudan (N) [mailto:xuda...@huawei.com]
Sent: Wednesday, October 11, 2017 6:50 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of limingjiang
Sent: Thursday, October 12, 2017 9:24 AM
To: Srikanth Vavilapalli
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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

+---+
[cid:image001.png@01D0A50A.DD5A8F20]
+ Mingjiang Li (Rex) Mobile: +86 13761275017
+ Shanghai Institute, Huawei
+ No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
+---+

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Srikanth Vavilapalli
发送时间: 2017年10月12日 9:03
收件人: Jose Lausuch; Georg Kunz
抄送: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Wednesday, October 11, 2017 10:45 AM
To: Georg Kunz <georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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.

For 

Re: [opnfv-tech-discuss] [xci] xci - aio installation failed on a ubuntu 16.04 VM

[Srikanth Vavilapalli]

Thanks Mark

I recreated my VM with 8GB RAM and 8 vCPUs as recommended in the wiki, but I 
still hit the same issue. I will try to increase the RAM further and try, but 
in the meantime if there are anything else I could try, plz let me know...

vagrant@xci:~/releng-xci/xci$ sudo virsh start opnfv
error: Failed to start domain opnfv
error: internal error: early end of file from monitor, possible problem: 
2017-10-16T22:14:57.110918Z qemu-system-x86_64: cannot set up guest memory 
'pc.ram': Cannot allocate memory

vagrant@xci:~/releng-xci/xci$ free -m
  totalusedfree  shared  buff/cache   available
Mem:   7982 8974226  1228596738
Swap:   511   0 511
vagrant@xci:~/releng-xci/xci$


Thanks
Srikanth

-Original Message-
From: Markos Chandras [mailto:mchand...@suse.de] 
Sent: Friday, October 13, 2017 1:17 AM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [xci] xci - aio installation failed on a 
ubuntu 16.04 VM

On 12/10/17 19:33, Srikanth Vavilapalli wrote:
> Hi Markos
> 
> The following is the error I get when I start the opnfv domain. It says 
> "cannot allocate memory". I have 4GB RAM assigned to my vagrant VM where I am 
> bringing up the XCI. May I know what are minimum RAM needs fro XCI AIO flavor?
> 
> vagrant@xci:~$ sudo virsh start opnfv
> error: Failed to start domain opnfv
> error: internal error: early end of file from monitor, possible 
> problem: 2017-10-12T18:29:50.649458Z qemu-system-x86_64: cannot set up 
> guest memory 'pc.ram': Cannot allocate memory
> 
> vagrant@xci:~$ free -m
>   totalusedfree  shared  buff/cache   
> available
> Mem:   3951 6561853  361441
> 2958
> Swap:   511  19 492
> vagrant@xci:~$

The AIO requirements are listed here

https://git.opnfv.org/releng-xci/tree/xci/config/aio-vars

The opnfv VM will need 8G of RAM so your vagrant box has to have more than that.

--
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 
(AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Srikanth Vavilapalli]

Thanks Rex for the clarification.

From: limingjiang [mailto:limingji...@huawei.com]
Sent: Wednesday, October 11, 2017 6:24 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>
Cc: opnfv-tech-discuss@lists.opnfv.org; Jose Lausuch <jalaus...@suse.com>; 
Georg Kunz <georg.k...@ericsson.com>
Subject: 答复: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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

+---+
[cid:image001.png@01D0A50A.DD5A8F20]
+ Mingjiang Li (Rex) Mobile: +86 13761275017
+ Shanghai Institute, Huawei
+ No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
+---+

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Srikanth Vavilapalli
发送时间: 2017年10月12日 9:03
收件人: Jose Lausuch; Georg Kunz
抄送: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Wednesday, October 11, 2017 10:45 AM
To: Georg Kunz <georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

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.

For your third point, log collection shouldn’t be done at test case level. It 
should be performed by CI after running the test tools, otherwise you can a 
false negative when running those test on non-OPNFV installers.

Regards,
Jose

[1] 
https://raw.githubusercontent.com/opnfv/yardstick/master/etc/yardstick/nodes/fuel_virtual/pod.yaml


On 11 Oct 2017, at 18:08, Georg Kunz 
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>> wrote:

Hi,

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)
  *   …

Cheers
Georg

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Wednesday, October 11, 2017 4:40 PM
To: Beierl, Mark <mark.bei...@dell.com<mailto:mark.bei...

Re: [opnfv-tech-discuss] [xci] xci - aio installation failed on a ubuntu 16.04 VM

[Srikanth Vavilapalli]

Hi Markos

The following is the error I get when I start the opnfv domain. It says "cannot 
allocate memory". I have 4GB RAM assigned to my vagrant VM where I am bringing 
up the XCI. May I know what are minimum RAM needs fro XCI AIO flavor?

vagrant@xci:~$ sudo virsh start opnfv
error: Failed to start domain opnfv
error: internal error: early end of file from monitor, possible problem: 
2017-10-12T18:29:50.649458Z qemu-system-x86_64: cannot set up guest memory 
'pc.ram': Cannot allocate memory

vagrant@xci:~$ free -m
  totalusedfree  shared  buff/cache   available
Mem:   3951 6561853  3614412958
Swap:   511  19 492
vagrant@xci:~$


Thanks
Srikanth

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Markos Chandras
Sent: Thursday, October 12, 2017 12:38 AM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [xci] xci - aio installation failed on a 
ubuntu 16.04 VM

On 11/10/17 23:17, Srikanth Vavilapalli wrote:
> Hi
> 
>  
> 
> I am trying to run XCI inside a ubuntu 16.04 VM and in the mid-way the 
> script stopped with the following error (The log is available at 
> https://hastebin.com/maqepiwoyi.md). Can any one plz help me to 
> resolve this issue? The environment I have is a vagrant VM with ubuntu 16.04 
> loaded.
> 
>  
> 
> TASK [ironic-inspect-node : Sending dnsmasq HUP]
> *
> 
> skipping: [opnfv]
> 
>  
> 
> TASK [ironic-inspect-node : Execute node introspection - noauth_mode]
> 
> 
> fatal: [opnfv]: FAILED! => {"changed": false, "failed": true, "msg":
> "Inspection of node 93494378-56ee-5e22-b6f0-e3be3a9ebdf1 failed, last
> error: timeout reached while inspecting the node"}
>  

Hello,

Can you do a 'sudo virsh list --all' and then start the opfnv VM (assuming 
there is one) using 'sudo virsh stsart opnfv'? You may get some useful errors 
on why your VM is not starting

--
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 
(AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg 
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Srikanth Vavilapalli]

lly that would be yet another type 
of installer.

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Oct 11, 2017, at 02:25, xudan (N) 
<xuda...@huawei.com<mailto:xuda...@huawei.com>> wrote:

Hi Srikanth,

As I know, some Yardstick test cases also need to login nodes. Yardstick uses a 
file providing all the login information.
You can refer to 
https://github.com/opnfv/yardstick/tree/master/etc/yardstick/nodes which gives 
some examples.
Hope this will help you.

BR
Dan Xu

From: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com]
Sent: Wednesday, October 11, 2017 12:28 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Tim Irnich; xudan (N)
Subject: [functest] [sdnvpn] Proposal for removing installer dependent 
information in the test tools

Hi

I am looking into Jira ticket 
“SDNVPN-181<https://jira.opnfv.org/browse/SDNVPN-181>: Function "gather_logs" 
restricts to Apex and Fuel”, which raises concerns on having installer 
dependent logic in the sdnvpn repo. The issue is, at the end of the sdnvpn test 
execution, we are invoking gather_logs() utility which internally tries to 
gather the information about all the OpenStack nodes based on the configured 
INSTALLER_TYPE in order to run the fetch_logs.sh script on the target OpenStack 
nodes 
(https://gerrit.opnfv.org/gerrit/gitweb?p=sdnvpn.git;a=blob;f=sdnvpn/lib/utils.py;h=ad0714ea9dd40ee8305cd17e42695f0176e88328;hb=HEAD#l215)

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.

Thanks
Srikanth

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [xci] xci - aio installation failed on a ubuntu 16.04 VM

[Srikanth Vavilapalli]

Hi

I am trying to run XCI inside a ubuntu 16.04 VM and in the mid-way the script 
stopped with the following error (The log is available at 
https://hastebin.com/maqepiwoyi.md). Can any one plz help me to resolve this 
issue? The environment I have is a vagrant VM with ubuntu 16.04 loaded.

TASK [ironic-inspect-node : Sending dnsmasq HUP] ***
skipping: [opnfv]

TASK [ironic-inspect-node : Execute node introspection - noauth_mode] **
fatal: [opnfv]: FAILED! => {"changed": false, "failed": true, "msg": 
"Inspection of node 93494378-56ee-5e22-b6f0-e3be3a9ebdf1 failed, last error: 
timeout reached while inspecting the node"}

NO MORE HOSTS LEFT *
to retry, use: --limit 
@/tmp/.xci-deploy-env/bifrost/playbooks/opnfv-virtual.retry

PLAY RECAP *
127.0.0.1  : ok=127  changed=78   unreachable=0failed=0
opnfv  : ok=6changed=1unreachable=0failed=1
Making logs directory and collecting logs.


Thanks
Srikanth

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Srikanth Vavilapalli]

Hi

I am looking into Jira ticket 
"SDNVPN-181: Function "gather_logs" 
restricts to Apex and Fuel", which raises concerns on having installer 
dependent logic in the sdnvpn repo. The issue is, at the end of the sdnvpn test 
execution, we are invoking gather_logs() utility which internally tries to 
gather the information about all the OpenStack nodes based on the configured 
INSTALLER_TYPE in order to run the fetch_logs.sh script on the target OpenStack 
nodes 
(https://gerrit.opnfv.org/gerrit/gitweb?p=sdnvpn.git;a=blob;f=sdnvpn/lib/utils.py;h=ad0714ea9dd40ee8305cd17e42695f0176e88328;hb=HEAD#l215)

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.

Thanks
Srikanth

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Functest] Installing and Running Functest in Transparent Proxy with Whitelists environment

[Srikanth Vavilapalli]

Thanks Linda and Steve

I have not yet got the access to that host/server to install Functest on it, so 
I am currently analyzing the potential challenges we may encounter once we take 
the Functest into that restricted environment.

So, from your response, once I have the docker engine installed and pulled 
functest container (latest alpine based) from docker hub,  if I add those image 
download URLs to the whitelist, I should see the “functest env prepare” step go 
through without many issues. Is this correct understanding?

From Steve’s response, seems like internet connectivity is also needed during 
some test execution of SNAPS-OO based tests. Steve, can you plz clarify why we 
need HTTP/HTTPS proxy settings for SNAPS-OO and are there any specific list of 
URLs that SNAPS-OO based tests would pull from internet during test execution?

Thanks much for your help
Srikanth



From: wangwulin [mailto:wangwu...@huawei.com]
Sent: Wednesday, September 13, 2017 7:46 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: 答复: [opnfv-tech-discuss] [Functest] Installing and Running Functest in 
Transparent Proxy with Whitelists environment

Hi Srikanth,

I am wondering if you have succeeded launching functest container, and have 
trouble with functest env preparation. And which version of functest image did 
you use?


1)  If there is no trouble with docker engine installation for you, the two 
documentation links you mentioned are a little bit outdated.
Now offline is fully supported by functest master, so there is no need to 
access any URLs for the step “functest env prepare”.


2)  To enable run functest test cases, all the images required by tests should 
be downloaded beforehand via a shell file named download_images.sh [1] provided 
by functest. Please make sure these images URLs are included in your whitelist 
and put all the downloaded images in the dir /home/opnfv/functest/images inside 
functest container.


3)  Meanwhile, we are switching to the new Alpine images, please refer to [2] 
for detailed info.



[1]: https://git.opnfv.org/functest/tree/functest/ci/download_images.sh
[2]: https://wiki.opnfv.org/display/functest/Run+Alpine+Functest+containers


Best Regards,
Linda

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Srikanth Vavilapalli
发送时间: 2017年9月14日 2:33
收件人: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: [opnfv-tech-discuss] [Functest] Installing and Running Functest in 
Transparent Proxy with Whitelists environment

Hi

I am looking for some information in bringing up OPNFV Functest in a corporate 
proxy environment, where the proxy provides restricted internet connectivity 
based on the configured whitelist URLs.

I have looked at the Functest documentation wiki links [1] and [2], but they 
are not covering the above scenario.

In order to make the Functest work in the Proxy environment with whitelist, we 
need to know about the list of various domains or URLs that Functest would 
access during the installation and ENV prepare stages, such that we can 
configure upfront the Proxy with same list of URLs.

Can anyone plz let me know if this information is maintained in any functest 
wiki pages or appreciate if anyone from the community can share this 
information if they have tried Functest in such restricted environments in 
their own labs?


Thanks for your help.
Srikanth

[1] 
http://docs.opnfv.org/en/stable-danube/submodules/functest/docs/testing/user/configguide/index.html#proxy-support
[2] 
http://docs.opnfv.org/en/stable-danube/submodules/functest/docs/testing/user/configguide/index.html#docker-installation-on-centos-behind-http-proxy

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [Functest] Installing and Running Functest in Transparent Proxy with Whitelists environment

[Srikanth Vavilapalli]

Hi

I am looking for some information in bringing up OPNFV Functest in a corporate 
proxy environment, where the proxy provides restricted internet connectivity 
based on the configured whitelist URLs.

I have looked at the Functest documentation wiki links [1] and [2], but they 
are not covering the above scenario.

In order to make the Functest work in the Proxy environment with whitelist, we 
need to know about the list of various domains or URLs that Functest would 
access during the installation and ENV prepare stages, such that we can 
configure upfront the Proxy with same list of URLs.

Can anyone plz let me know if this information is maintained in any functest 
wiki pages or appreciate if anyone from the community can share this 
information if they have tried Functest in such restricted environments in 
their own labs?


Thanks for your help.
Srikanth

[1] 
http://docs.opnfv.org/en/stable-danube/submodules/functest/docs/testing/user/configguide/index.html#proxy-support
[2] 
http://docs.opnfv.org/en/stable-danube/submodules/functest/docs/testing/user/configguide/index.html#docker-installation-on-centos-behind-http-proxy

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [dovetail] Request for a slot in tomorrow's weekly call

[Srikanth Vavilapalli]

Hi

Attached the slide deck…

Thanks
Srikanth

From: Zenghui Shi [mailto:z...@redhat.com]
Sent: Sunday, July 30, 2017 7:31 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>
Cc: Wenjing Chu <wenjing@huawei.com>; Tianhongbo 
<hongbo.tianhon...@huawei.com>; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [dovetail] Request for a slot in tomorrow's 
weekly call

Hi Srikanth & Tim,

Thanks for sharing the findings on test gaps in weekly dovetail meeting!
Is it possible the slides can be shared so that anyone who's interested in can 
get to understand and follow-up on some of the test items?

Regards,
zenghui

On Thu, Jul 27, 2017 at 11:18 PM, Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>> 
wrote:
Hi

In tomorrow’s weekly call, Tim and myself (from Ericsson) wanted to share our 
findings on test gaps in basic cloud capability, security and High availability 
areas.

Can you plz add to the agenda if we can get some time for this?

Thanks
Srikanth




___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss



OPNFV Dovetail.pptx
Description: OPNFV Dovetail.pptx
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [dovetail] Request for a slot in tomorrow's weekly call

[Srikanth Vavilapalli]

Hi

In tomorrow's weekly call, Tim and myself (from Ericsson) wanted to share our 
findings on test gaps in basic cloud capability, security and High availability 
areas.

Can you plz add to the agenda if we can get some time for this?

Thanks
Srikanth



___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with dovetail.cvp.0.1.0 throw an error

[Srikanth Vavilapalli]

Thanks Dan Xu for detailed response.

I changed the pod.xml as u suggested and ran the ha test suite. I also enabled 
debug option while running the tests and noticed the outage times getting 
logged in the dovetail.log file.

Thanks
Srikanth

From: xudan (N) [mailto:xuda...@huawei.com]
Sent: Thursday, July 06, 2017 11:55 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Srikanth,


  1.  About the pod.yaml file

  1.  Think it’s wrong. Switch to user “stack” first, then source under cloud 
rc file(named stackrc in my env), command “openstack server list” will show the 
platform nodes, mine is
+---+--+---+-+---+
| ID
| Name | Status | Networks | Image 
Name |
+---+--+---+-+---+
| 8e4380ea-b348-49b7-a5e4-39dc18e8994b | compute-0   | ACTIVE   | 
ctlplane=192.0.2.15  | overcloud-full   |
| 49a5f4f6-6b84-4ce3-9a69-654618511dfb| controller-2  | ACTIVE   | 
ctlplane=192.0.2.10  | overcloud-full   |
| adcef3e3-f456-4c01-987a-1d72182b3f00| compute-1   | ACTIVE   | 
ctlplane=192.0.2.17  | overcloud-full   |
| f41552b9-a4e4-4445-bd07-e8b025bec9b6 | controller-0  | ACTIVE   | 
ctlplane=192.0.2.14  | overcloud-full   |
| f622a698-5fa0-41ff-a0e9-566e3a5e45b7| controller-1  | ACTIVE   | 
ctlplane=192.0.2.13  | overcloud-full   |
+---+--+---+-+---+


  1.  Set the ${DOVETAIL_HOME}/pre_config/pod.yaml as follows

nodes:
-
name: node1
role: Controller
ip: 192.0.2.14——> node IP
user: heat-admin  ———> node login user
key_filename: /root/.ssh/id_rsa  ——> ssh key file
-
name: node2
role: Controller
ip: 192.0.2.13
user: heat-admin
key_filename: /root/.ssh/id_rsa
-
name: node3
role: Compute
ip: 192.0.2.15
user: heat-admin
key_filename: /root/.ssh/id_rsa

The user “heat-admin” above is obtained from the installation guide document. 
You can check it according to your platform installation documents. I can “ssh 
heat-admin@192.0.2.14<mailto:heat-admin@192.0.2.14>” to verify that.
If deployed in HA mode, since only process HA (no node HA) are tested for the 
current tests, you can only write one Controller “node1” information in the 
pod.yaml , it will work, i.e., if I delete node2 node3 info in the above file, 
it will also work.


  1.  Copy the user “stack” private key (the path usually is 
/home/stack/.ssh/id_rsa) to  $DOVETAIL_HOME/pre_config/id_rsa



  1.  About the results data

  1.  In the result file, if the value of “sla_pass”  is 1, the test passes, 
otherwise fails.

Under linux vim env, suggest to use “:$!python -m json.tool” to transfer the 
result file into json to see more clearly.


  1.  For the outage time, it is not shown in the dovetail.ha.tc***.out file 
now.

If you run “dovetail run --testsuite  proposed_tests --testarea ha -d” (“-d” 
added for showing debug logs), you can find in results/dovetail.log, such as


2017-07-06 20:17:22,211 - container.Container - DEBUG - 2017-07-06 20:17:22,211 
yardstick.benchmark.scenarios.availability.monitor.basemonitor 
basemonitor.py:155 DEBUG the monitor result:{'total_time': 10.886008977890015, 
'outage_time': 1.1303958892822266, 'outage_count': 1, 'last_outage': 
1499372232.053993, 'first_outage': 1499372230.923597, 'total_count': 8}

Regards,
Dan Xu

发件人: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com]
发送时间: 2017年7月7日 2:48
收件人: Srikanth Vavilapalli; xudan (N); 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: RE: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi

Just continuing my dovetail testing with HA test suite and have few questions:


  1.  I created the pod.yaml file as shown below. Are these correct settings 
for an apex based OPNFV deployment?

root@r720-003 ~/dovetail/results $ cat ../pre_config/pod.yaml
nodes:
-
name: node1
role: Controller
ip: 192.168.122.140  <- apex undercloud IP
user: stack  <- apex undercloud login user
key_filename: /root/.ssh/id_rsa  <- apex undercloud ssh key file


  1.  The test run has generated output files for each test case. What is the 
way to interpret this output? Which fields in that log indicate the outage time 
and recovery time? I expecting some outage for these tests because my backend 
opnfv deployment is running in non-HA mode.

ro

Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with dovetail.cvp.0.1.0 throw an error

[Srikanth Vavilapalli]

Hi

Just continuing my dovetail testing with HA test suite and have few questions:


  1.  I created the pod.yaml file as shown below. Are these correct settings 
for an apex based OPNFV deployment?

root@r720-003 ~/dovetail/results $ cat ../pre_config/pod.yaml
nodes:
-
name: node1
role: Controller
ip: 192.168.122.140  <- apex undercloud IP
user: stack  <- apex undercloud login user
key_filename: /root/.ssh/id_rsa  <- apex undercloud ssh key file


  1.  The test run has generated output files for each test case. What is the 
way to interpret this output? Which fields in that log indicate the outage time 
and recovery time? I expecting some outage for these tests because my backend 
opnfv deployment is running in non-HA mode.

root@r720-003 ~/dovetail/results $ cat dovetail.ha.tc001.out
{"status": 1, "result": [{"context_cfg": {"nodes": {"node1": {"ip": 
"192.168.122.140", "key_filename": "/root/.ssh/id_rsa", "role": "Controller", 
"name": "node1.LF-785e43fe", "user": "stack"}}}, "scenario_cfg": {"task_id": 
"785e43fe-9ef0-4a0f-a6e2-f813a468915f", "runner": {"object": 
"yardstick.benchmark.scenarios.availability.serviceha.ServiceHA", "type": 
"Iteration", "output_filename": 
"/home/opnfv/yardstick/results/dovetail.ha.tc001.out", "iterations": 1, 
"runner_id": 55}, "tc": "opnfv_yardstick_tc019", "options": {"wait_time": 10, 
"attackers": [{"fault_type": "kill-process", "host": "node1", "process_name": 
"nova-api"}], "monitors": [{"monitor_number": 3, "monitor_time": 10, 
"command_name": "openstack server list", "monitor_type": "openstack-cmd", 
"sla": {"max_outage_time": 5}}, {"process_name": "nova-api", "monitor_type": 
"process", "monitor_number": 3, "host": "node1", "monitor_time": 20, "sla": 
{"max_recover_time": 20}}]}, "nodes": {"node1": "node1.LF-785e43fe"}, "type": 
"ServiceHA", "sla": {"outage_time": 5, "action": "monitor"}}, "runner_id": 55}, 
{"benchmark": {"timestamp": 1499367559.269849, "errors": "", "data": 
{"sla_pass": 1}, "sequence": 1}, "runner_id": 55}]}

root@r720-003 ~/dovetail/results $ cat dovetail.ha.tc002.out
{"status": 1, "result": [{"context_cfg": {"nodes": {"node1": {"ip": 
"192.168.122.140", "key_filename": "/root/.ssh/id_rsa", "role": "Controller", 
"name": "node1.LF-1271a70f", "user": "stack"}}}, "scenario_cfg": {"task_id": 
"1271a70f-aa8a-44a7-83b9-f59705000483", "runner": {"duration": 1, "object": 
"yardstick.benchmark.scenarios.availability.serviceha.ServiceHA", "type": 
"Duration", "output_filename": 
"/home/opnfv/yardstick/results/dovetail.ha.tc002.out", "runner_id": 55}, "tc": 
"opnfv_yardstick_tc045", "options": {"attackers": [{"fault_type": 
"kill-process", "host": "node1", "process_name": "neutron-server"}], 
"monitors": [{"monitor_number": 3, "monitor_time": 10, "command_name": 
"openstack router list", "monitor_type": "openstack-cmd", "sla": 
{"max_outage_time": 5}}, {"process_name": "neutron-server", "monitor_type": 
"process", "monitor_number": 3, "host": "node1", "monitor_time": 20, "sla": 
{"max_recover_time": 20}}]}, "nodes": {"node1": "node1.LF-1271a70f"}, "type": 
"ServiceHA", "sla": {"outage_time": 5, "action": "monitor"}}, "runner_id": 55}, 
{"benchmark": {"timestamp": 1499367597.087087, "errors": "", "data": 
{"sla_pass": 1}, "sequence": 1}, "runner_id": 55}]}

Thanks for your help.

Thanks
Srikanth


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Srikanth 
V

Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with dovetail.cvp.0.1.0 throw an error

[Srikanth Vavilapalli]

Hi hongbo

I am running these dovetail test suites in order to familiarize myself with 
dovetail framework, not very sure if these run results are suitable to be 
recorded in wiki. I am also not very sure what version of OPNFV I am running 
these tests against. I got this apex-OPNFV setup from one of my colleague with 
sdnvpn scenario loaded.

Thanks
Srikanth

From: Tianhongbo [mailto:hongbo.tianhon...@huawei.com]
Sent: Wednesday, July 05, 2017 5:52 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>; xudan (N) 
<xuda...@huawei.com>; opnfv-tech-discuss@lists.opnfv.org
Subject: 答复: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Srikanth：

Thanks for the interest in the testing.

The dovetail team has created the wiki page for the record of running history:

https://wiki.opnfv.org/display/dovetail/Running+history+for+the+dovetail+tool

If possible, please help to add your running test on that wiki page.

Best regards

hongbo


发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Srikanth Vavilapalli
发送时间: 2017年7月6日 7:34
收件人: xudan (N); 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Thanks Dan Xu.

I pulled cvp.0.2.0 version of dovetail and was able to verify the bgpvpn tests 
with this version.

Thanks
Srikanth

From: xudan (N) [mailto:xuda...@huawei.com]
Sent: Wednesday, July 05, 2017 12:51 AM
To: Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Jose Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Srikanth,

The Functest WARNING logs you have mentioned can all be ignored, because they 
don’t have any matter with the test case itself.
Dovetail passes “INSTALLER_TYPE=netvirt” and “DEPLOY_SCENARIO=bgpvpn” to 
Functest Container to ensure test case bgpvpn can be triggered.
However, “INSTALLER_IP” has nothing to do with the Functest test cases 
themselves. So Dovetail doesn’t pass it to Functest.

About the ERROR log “Unknown test case or tier 'bgpvpn', or not supported by 
the given scenario 'bgpvpn'”,
we also met this problem during the test and that’s because 
opnfv/functest:danube.2.0 used by dovetail:cvp.0.1.0 disables bgpvpn with the 
config file testcases.yaml.
Functest has tagged opnfv/functest:cvp.0.2.0 which has enabled bgpvpn and fixed 
some bugs about it. Following are related patches:
https://gerrit.opnfv.org/gerrit/#/c/35051/2
https://gerrit.opnfv.org/gerrit/#/c/36777/3
https://gerrit.opnfv.org/gerrit/#/c/36785/
Dovetail cvp.0.2.0 will be available soon which will use 
opnfv/functest:cvp.0.2.0 instead of opnfv/functest:danube.2.0. Then you can 
have a try with this new version.
You can go to the wiki page for the details about the version change logs: 
https://wiki.opnfv.org/display/dovetail/Running+history+for+the+dovetail+tool#Runninghistoryforthedovetailtool-5.Versionchangelogs

Please feel free to contact me if you have any questions.

Thanks,
Dan Xu


发件人: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com]
发送时间: 2017年7月5日 11:31
收件人: Jose Lausuch
抄送: xudan (N); 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: RE: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Jose

I have already tried setting these environment variables while launching 
dovetail docker container (as shown below), even then I have noticed these 
warning messages from functest. So looks like these env variables are not 
passed on to functest container.

docker run --privileged=true -it -e DOVETAIL_HOME=$DOVETAIL_HOME -e 
INSTALLER_TYPE=apex -e INSTALLER_IP=192.168.37.11 -v 
$DOVETAIL_HOME:$DOVETAIL_HOME -v /var/run/docker.sock:/var/run/docker.sock 
opnfv/dovetail:cvp.0.1.0 /bin/bash

Thanks
Srikanth

From: Jose Lausuch
Sent: Monday, July 03, 2017 2:14 PM
To: Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>>
Cc: xudan (N) <xuda...@huawei.com<mailto:xuda...@huawei.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Srikanth,

You should set INSTALLER_TYPE=apex and also set INSTALLER_IP to the undercloud 
VM. You also need to set the DEPLOY_SCENARIO to the corresponding scenario you 
are deploying. If it’s a bgpvpn deployment, you can set it to 
os-odl_l2-bgpvpn-ha.

That is at least from Functest side, not sure how

Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with dovetail.cvp.0.1.0 throw an error

[Srikanth Vavilapalli]

Thanks Dan Xu.

I pulled cvp.0.2.0 version of dovetail and was able to verify the bgpvpn tests 
with this version.

Thanks
Srikanth

From: xudan (N) [mailto:xuda...@huawei.com]
Sent: Wednesday, July 05, 2017 12:51 AM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>; 
opnfv-tech-discuss@lists.opnfv.org
Cc: Jose Lausuch <jose.laus...@ericsson.com>
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Srikanth,

The Functest WARNING logs you have mentioned can all be ignored, because they 
don’t have any matter with the test case itself.
Dovetail passes “INSTALLER_TYPE=netvirt” and “DEPLOY_SCENARIO=bgpvpn” to 
Functest Container to ensure test case bgpvpn can be triggered.
However, “INSTALLER_IP” has nothing to do with the Functest test cases 
themselves. So Dovetail doesn’t pass it to Functest.

About the ERROR log “Unknown test case or tier 'bgpvpn', or not supported by 
the given scenario 'bgpvpn'”,
we also met this problem during the test and that’s because 
opnfv/functest:danube.2.0 used by dovetail:cvp.0.1.0 disables bgpvpn with the 
config file testcases.yaml.
Functest has tagged opnfv/functest:cvp.0.2.0 which has enabled bgpvpn and fixed 
some bugs about it. Following are related patches:
https://gerrit.opnfv.org/gerrit/#/c/35051/2
https://gerrit.opnfv.org/gerrit/#/c/36777/3
https://gerrit.opnfv.org/gerrit/#/c/36785/
Dovetail cvp.0.2.0 will be available soon which will use 
opnfv/functest:cvp.0.2.0 instead of opnfv/functest:danube.2.0. Then you can 
have a try with this new version.
You can go to the wiki page for the details about the version change logs: 
https://wiki.opnfv.org/display/dovetail/Running+history+for+the+dovetail+tool#Runninghistoryforthedovetailtool-5.Versionchangelogs

Please feel free to contact me if you have any questions.

Thanks,
Dan Xu


发件人: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com]
发送时间: 2017年7月5日 11:31
收件人: Jose Lausuch
抄送: xudan (N); 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: RE: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Jose

I have already tried setting these environment variables while launching 
dovetail docker container (as shown below), even then I have noticed these 
warning messages from functest. So looks like these env variables are not 
passed on to functest container.

docker run --privileged=true -it -e DOVETAIL_HOME=$DOVETAIL_HOME -e 
INSTALLER_TYPE=apex -e INSTALLER_IP=192.168.37.11 -v 
$DOVETAIL_HOME:$DOVETAIL_HOME -v /var/run/docker.sock:/var/run/docker.sock 
opnfv/dovetail:cvp.0.1.0 /bin/bash

Thanks
Srikanth

From: Jose Lausuch
Sent: Monday, July 03, 2017 2:14 PM
To: Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>>
Cc: xudan (N) <xuda...@huawei.com<mailto:xuda...@huawei.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Srikanth,

You should set INSTALLER_TYPE=apex and also set INSTALLER_IP to the undercloud 
VM. You also need to set the DEPLOY_SCENARIO to the corresponding scenario you 
are deploying. If it’s a bgpvpn deployment, you can set it to 
os-odl_l2-bgpvpn-ha.

That is at least from Functest side, not sure how Dovetail passes those env 
variables to Functest.

Let me know if that fixes your problem.

Regards,
Jose


On 3 Jul 2017, at 20:45, Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>> 
wrote:

Thanks Dan Xu

After fixing the DOVETAIL_HOME issue, I see the below WARNING logs in functest 
log, when I ran `dovetail run --testsuite proposed_tests --testarea sdnvpn`. 
Can I ignore these warning messages? I tried to set these environment variables 
while launching the dovetail container and also in env_config.sh file, but 
still I see those errors.

2017-07-03 18:49:09,172 - functest.utils.functest_utils - DEBUG - Executing 
command: 'python /home/opnfv/repos/functest/functest/ci/prepare_env.py start'
2017-07-03 18:49:10,232 - functest.ci.prepare_env - INFO - # Preparing 
Functest environment #

2017-07-03 18:49:10,232 - functest.ci.prepare_env - INFO - 
==
2017-07-03 18:49:10,232 - functest.ci.prepare_env - INFO - Checking environment 
variables...
2017-07-03 18:49:10,232 - functest.ci.prepare_env - WARNING - 
INSTALLER_TYPE=netvirt is not a valid OPNFV installer. Available OPNFV 
Installers are : ['apex', 'fuel', 'compass', 'joid', 'daisy']. Setting 
INSTALLER_TYPE=undefined.
2017-07-03 18:49:10,233 - functest.ci.prepare_env - WARNING - The env variable 
'INSTALLER_IP' is not defined. It is needed to fetch the OpenStack credentials. 
If the credentials are not provided to the container as a volume, please add 
thi

Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with dovetail.cvp.0.1.0 throw an error

[Srikanth Vavilapalli]

Hi Jose

I have already tried setting these environment variables while launching 
dovetail docker container (as shown below), even then I have noticed these 
warning messages from functest. So looks like these env variables are not 
passed on to functest container.

docker run --privileged=true -it -e DOVETAIL_HOME=$DOVETAIL_HOME -e 
INSTALLER_TYPE=apex -e INSTALLER_IP=192.168.37.11 -v 
$DOVETAIL_HOME:$DOVETAIL_HOME -v /var/run/docker.sock:/var/run/docker.sock 
opnfv/dovetail:cvp.0.1.0 /bin/bash

Thanks
Srikanth

From: Jose Lausuch
Sent: Monday, July 03, 2017 2:14 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>
Cc: xudan (N) <xuda...@huawei.com>; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Srikanth,

You should set INSTALLER_TYPE=apex and also set INSTALLER_IP to the undercloud 
VM. You also need to set the DEPLOY_SCENARIO to the corresponding scenario you 
are deploying. If it’s a bgpvpn deployment, you can set it to 
os-odl_l2-bgpvpn-ha.

That is at least from Functest side, not sure how Dovetail passes those env 
variables to Functest.

Let me know if that fixes your problem.

Regards,
Jose


On 3 Jul 2017, at 20:45, Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>> 
wrote:

Thanks Dan Xu

After fixing the DOVETAIL_HOME issue, I see the below WARNING logs in functest 
log, when I ran `dovetail run --testsuite proposed_tests --testarea sdnvpn`. 
Can I ignore these warning messages? I tried to set these environment variables 
while launching the dovetail container and also in env_config.sh file, but 
still I see those errors.

2017-07-03 18:49:09,172 - functest.utils.functest_utils - DEBUG - Executing 
command: 'python /home/opnfv/repos/functest/functest/ci/prepare_env.py start'
2017-07-03 18:49:10,232 - functest.ci.prepare_env - INFO - # Preparing 
Functest environment #

2017-07-03 18:49:10,232 - functest.ci.prepare_env - INFO - 
==
2017-07-03 18:49:10,232 - functest.ci.prepare_env - INFO - Checking environment 
variables...
2017-07-03 18:49:10,232 - functest.ci.prepare_env - WARNING - 
INSTALLER_TYPE=netvirt is not a valid OPNFV installer. Available OPNFV 
Installers are : ['apex', 'fuel', 'compass', 'joid', 'daisy']. Setting 
INSTALLER_TYPE=undefined.
2017-07-03 18:49:10,233 - functest.ci.prepare_env - WARNING - The env variable 
'INSTALLER_IP' is not defined. It is needed to fetch the OpenStack credentials. 
If the credentials are not provided to the container as a volume, please add 
this env variable to the 'docker run' command.
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - 
DEPLOY_SCENARIO=bgpvpn
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - CI_DEBUG=true
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - NODE_NAME=master
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - 
BUILD_TAG=daily-master-a279734f-3d6f-4e7b-96f7-7e8e192471aa-dovetail.sdnvpn.tc001
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - IS_CI_RUN=True


Also I see that the tests are ending with a failure log saying “Unknown test 
case or tier 'bgpvpn', or not supported by the given scenario 'bgpvpn'”. 
Attached the logs. Do I need to enable any specific config in my deployment for 
the sdnvpn testcases to pass?

2017-07-03 19:03:53,274 - functest.ci.run_tests - DEBUG - Sourcing the 
OpenStack RC file...
2017-07-03 19:03:53,275 - functest.ci.run_tests - ERROR - Unknown test case or 
tier 'bgpvpn', or not supported by the given scenario 'bgpvpn'.
2017-07-03 19:03:53,275 - functest.ci.run_tests - DEBUG - Available tiers are:

Thanks for your help…


Thanks
Srikanth

From: xudan (N) [mailto:xuda...@huawei.com]
Sent: Friday, June 30, 2017 9:17 PM
To: Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Srikanth,

The first step:
Added ‘export DOVETAIL_HOME=$HOME/dovetail’ in 
~/dovetail/pre_config/env_config.sh

You need to replace $HOME with /root. Because in your host, $HOME is /root. But 
in Dovetail container $HOME is /home/opnfv.

Dovetail tool will source this env_config.sh at the running time in the 
container and then it will reset the DOVETAIL_HOME to be /home/opnfv/dovetail.
So then Dovetail tool will go to /home/opnfv/dovetail to look for all the files 
rather than /root/dovetail.

Sorry for the mistake in Dovetail testing user guide and we will amend it soon. 
Thank you for your feedback.

Thanks
Dan Xu

发件人: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com]
发送时间: 2017年7月1日 1:58
收件人: xudan (N); 
opnfv-tech-discuss@lists.opnfv.org<mail

Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with dovetail.cvp.0.1.0 throw an error

[Srikanth Vavilapalli]

Thanks Dan Xu

After fixing the DOVETAIL_HOME issue, I see the below WARNING logs in functest 
log, when I ran `dovetail run --testsuite proposed_tests --testarea sdnvpn`. 
Can I ignore these warning messages? I tried to set these environment variables 
while launching the dovetail container and also in env_config.sh file, but 
still I see those errors.

2017-07-03 18:49:09,172 - functest.utils.functest_utils - DEBUG - Executing 
command: 'python /home/opnfv/repos/functest/functest/ci/prepare_env.py start'
2017-07-03 18:49:10,232 - functest.ci.prepare_env - INFO - # Preparing 
Functest environment #

2017-07-03 18:49:10,232 - functest.ci.prepare_env - INFO - 
==
2017-07-03 18:49:10,232 - functest.ci.prepare_env - INFO - Checking environment 
variables...
2017-07-03 18:49:10,232 - functest.ci.prepare_env - WARNING - 
INSTALLER_TYPE=netvirt is not a valid OPNFV installer. Available OPNFV 
Installers are : ['apex', 'fuel', 'compass', 'joid', 'daisy']. Setting 
INSTALLER_TYPE=undefined.
2017-07-03 18:49:10,233 - functest.ci.prepare_env - WARNING - The env variable 
'INSTALLER_IP' is not defined. It is needed to fetch the OpenStack credentials. 
If the credentials are not provided to the container as a volume, please add 
this env variable to the 'docker run' command.
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - 
DEPLOY_SCENARIO=bgpvpn
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - CI_DEBUG=true
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - NODE_NAME=master
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - 
BUILD_TAG=daily-master-a279734f-3d6f-4e7b-96f7-7e8e192471aa-dovetail.sdnvpn.tc001
2017-07-03 18:49:10,233 - functest.ci.prepare_env - INFO - IS_CI_RUN=True


Also I see that the tests are ending with a failure log saying “Unknown test 
case or tier 'bgpvpn', or not supported by the given scenario 'bgpvpn'”. 
Attached the logs. Do I need to enable any specific config in my deployment for 
the sdnvpn testcases to pass?

2017-07-03 19:03:53,274 - functest.ci.run_tests - DEBUG - Sourcing the 
OpenStack RC file...
2017-07-03 19:03:53,275 - functest.ci.run_tests - ERROR - Unknown test case or 
tier 'bgpvpn', or not supported by the given scenario 'bgpvpn'.
2017-07-03 19:03:53,275 - functest.ci.run_tests - DEBUG - Available tiers are:

Thanks for your help…


Thanks
Srikanth

From: xudan (N) [mailto:xuda...@huawei.com]
Sent: Friday, June 30, 2017 9:17 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Srikanth,

The first step:
Added ‘export DOVETAIL_HOME=$HOME/dovetail’ in 
~/dovetail/pre_config/env_config.sh

You need to replace $HOME with /root. Because in your host, $HOME is /root. But 
in Dovetail container $HOME is /home/opnfv.

Dovetail tool will source this env_config.sh at the running time in the 
container and then it will reset the DOVETAIL_HOME to be /home/opnfv/dovetail.
So then Dovetail tool will go to /home/opnfv/dovetail to look for all the files 
rather than /root/dovetail.

Sorry for the mistake in Dovetail testing user guide and we will amend it soon. 
Thank you for your feedback.

Thanks
Dan Xu

发件人: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com]
发送时间: 2017年7月1日 1:58
收件人: xudan (N); 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: RE: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Dan Xu

Here is the command I have used to launch the dovetail container

  *   root@r720-003 ~ $ Added ‘export DOVETAIL_HOME=$HOME/dovetail’ in 
~/dovetail/pre_config/env_config.sh
  *   root@r720-003 ~ $ source $HOME/dovetail/pre_config/env_config.sh
  *   root@r720-003 ~ $ sudo docker run --privileged=true -it -e 
DOVETAIL_HOME=$DOVETAIL_HOME  -v $DOVETAIL_HOME:$DOVETAIL_HOME  -v 
/var/run/docker.sock:/var/run/docker.sock  opnfv/dovetail:cvp.0.1.0 /bin/bash

I followed the instructions at 
http://artifacts.opnfv.org/dovetail/review/34285/testing_user_userguide/index.html
 to bringup the dovetail container.

Thanks
Srikanth

From: xudan (N) [mailto:xuda...@huawei.com]
Sent: Thursday, June 29, 2017 6:29 PM
To: Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Srikanth,

We have tested dovetail:cvp.0.1.0 locally and have not found this ERROR. Maybe 
there are something wrong when you create the Dovetail container.

Can you show us the command. According to the log, the right command for you is:

 sudo docker run -it --privileged=true -e DOVETAIL_HOME=/root/dove

Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with dovetail.cvp.0.1.0 throw an error

[Srikanth Vavilapalli]

Hi Dan Xu

Here is the command I have used to launch the dovetail container

  *   root@r720-003 ~ $ Added ‘export DOVETAIL_HOME=$HOME/dovetail’ in 
~/dovetail/pre_config/env_config.sh
  *   root@r720-003 ~ $ source $HOME/dovetail/pre_config/env_config.sh
  *   root@r720-003 ~ $ sudo docker run --privileged=true -it -e 
DOVETAIL_HOME=$DOVETAIL_HOME  -v $DOVETAIL_HOME:$DOVETAIL_HOME  -v 
/var/run/docker.sock:/var/run/docker.sock  opnfv/dovetail:cvp.0.1.0 /bin/bash

I followed the instructions at 
http://artifacts.opnfv.org/dovetail/review/34285/testing_user_userguide/index.html
 to bringup the dovetail container.

Thanks
Srikanth

From: xudan (N) [mailto:xuda...@huawei.com]
Sent: Thursday, June 29, 2017 6:29 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with 
dovetail.cvp.0.1.0 throw an error

Hi Srikanth,

We have tested dovetail:cvp.0.1.0 locally and have not found this ERROR. Maybe 
there are something wrong when you create the Dovetail container.

Can you show us the command. According to the log, the right command for you is:

 sudo docker run -it --privileged=true -e DOVETAIL_HOME=/root/dovetail 
-v /root/dovetail: /root/dovetail -v /var/run/docker.sock:/var/run/docker.sock 
opnfv/dovetail:cvp.0.1.0 /bin/bash

Thanks
Dan Xu

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Srikanth Vavilapalli
发送时间: 2017年6月30日 7:03
收件人: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: [opnfv-tech-discuss] [Dovetail] sdnvpn test cases with dovetail.cvp.0.1.0 
throw an error

Hi

When I run the `sdnvpn’ dovetail test cases, I see the below error for each 
run. I have ensured that the ubuntu cloudimg is present under 
$(DOVETAIL_HOME)/pre_config folder on the host before executing these tests. 
The failure is happening when the dovetail container is trying to copy the file 
from one location to other location in the functest container & this folder 
/home/opnfv/userconfig/pre_config/ does not exist in the functest container. 
Can any one plz help me with this error?


root@98da04f3fb76:/usr/local/lib/python2.7/dist-packages/dovetail#<mailto:root@98da04f3fb76:/usr/local/lib/python2.7/dist-packages/dovetail>
 dovetail run --testsuite proposed_tests --testarea sdnvpn
2017-06-29 23:38:07,875 - run - INFO - 

2017-06-29 23:38:07,875 - run - INFO - Dovetail compliance: proposed_tests!
2017-06-29 23:38:07,875 - run - INFO - 

2017-06-29 23:38:07,875 - run - INFO - Build tag: 
daily-master-350ba85a-b2bf-4693-a107-ca25af60b925
2017-06-29 23:38:08,109 - run - INFO - >>[testcase]: dovetail.sdnvpn.tc001
2017-06-29 23:38:09,428 - container.Container - INFO - get hosts info
2017-06-29 23:38:09,947 - container.Container - ERROR - The command 'sudo 
docker exec 4e7f920152d3 /bin/bash -c "cp 
/home/opnfv/userconfig/pre_config/ubuntu-16.04-server-cloudimg-amd64-disk1.img 
/home/opnfv/functest/images"' failed.
2017-06-29 23:38:10,010 - container.Container - ERROR - The command 'sudo 
docker exec 4e7f920152d3 /bin/bash -c "cp 
/home/opnfv/userconfig/pre_config/sdnvpn_config_testcase1.yaml 
/home/opnfv/repos/sdnvpn/sdnvpn/test/functest/config.yaml"' failed.
2017-06-29 23:39:19,314 - run - ERROR - Fail to store results with file 
/root/dovetail/results/functest_results.txt.
2017-06-29 23:39:19,315 - report.FunctestCrawler - INFO - result file not 
found: /root/dovetail/results/functest_results.txt
2017-06-29 23:39:19,315 - run - INFO - >>[testcase]: dovetail.sdnvpn.tc002
2017-06-29 23:39:19,317 - container.Container - INFO - get hosts info
2017-06-29 23:39:19,788 - container.Container - ERROR - The command 'sudo 
docker exec 25805da3d12b /bin/bash -c "cp 
/home/opnfv/userconfig/pre_config/ubuntu-16.04-server-cloudimg-amd64-disk1.img 
/home/opnfv/functest/images"' failed.
….


root@98da04f3fb76:/usr/local/lib/python2.7/dist-packages/dovetail#<mailto:root@98da04f3fb76:/usr/local/lib/python2.7/dist-packages/dovetail>
 ls /root/dovetail/pre_config/
env_config.sh sdnvpn_config_testcase3.yaml
hosts.yamlsdnvpn_config_testcase4.yaml
pod.yaml.sample   sdnvpn_config_testcase8.yaml
sdnvpn_config_testcase1.yaml  ubuntu-16.04-server-cloudimg-amd64-disk1.img
sdnvpn_config_testcase2.yaml


Thanks
Srikanth
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [APEX] Apex virtual deployment install fails with error

[Srikanth Vavilapalli]

? (192.168.122.203) at  on virbr0
? (192.168.122.192) at  on virbr0


Thanks
Srikanth

From: Feng Pan [mailto:f...@redhat.com]
Sent: Tuesday, June 20, 2017 4:29 PM
To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [APEX] Apex virtual deployment install fails 
with error

Hi Srikanth,

The failure you see is caused by a syntax error in ovs-dpdk-preconfig.yaml that 
we use to configure ovs-dpdk. I submitted a patch to fix this: 
https://gerrit.opnfv.org/gerrit/#/c/36277/

You could either wait for this fix to be merged or apply and build this patch 
yourself.

Thanks
Feng

On Fri, Jun 16, 2017 at 1:37 AM, Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>> 
wrote:
Hi Feng

This time I tried with following danube daily rpms:
wget 
http://artifacts.opnfv.org/apex/danube/opnfv-apex-undercloud-4.0-20170613.noarch.rpm
wget 
http://artifacts.opnfv.org/apex/danube/opnfv-apex-common-4.0-20170613.noarch.rpm
wget http://artifacts.opnfv.org/apex/danube/opnfv-apex-4.0-20170613.noarch.rpm

I see the following errors with this install (attached full log). Seems some 
issues with OVS-DPDK deployment. Appreciate any pointers on what may be going 
wrong? Could this be because of any issue with my jumphost config? I am running 
this script on a 64GB RAM centos 7 VM.

2017-06-15 20:24:21Z [overcloud.Compute.0.ComputeExtraConfigPre]: CREATE_FAILED 
 Error: resources.ComputeExtraConfigPre.resources.OvsDpdkSetup: Deployment to 
server failed: deploy_status_code: Deployment exited with non-zero status code: 
1
2017-06-15 20:24:21Z [overcloud.Compute.0]: CREATE_FAILED  Resource CREATE 
failed: Error: resources.ComputeExtraConfigPre.resources.OvsDpdkSetup: 
Deployment to server failed: deploy_status_code: Deployment exited with 
non-zero status code: 1
2017-06-15 20:24:22Z [overcloud.Compute.0]: CREATE_FAILED  Error: 
resources[0].resources.ComputeExtraConfigPre.resources.OvsDpdkSetup: Deployment 
to server failed: deploy_status_code: Deployment exited with non-zero status 
code: 1
2017-06-15 20:24:22Z [overcloud.Compute]: CREATE_FAILED  Resource CREATE 
failed: Error: 
resources[0].resources.ComputeExtraConfigPre.resources.OvsDpdkSetup: Deployment 
to server failed: deploy_status_code: Deployment exited with non-zero status 
code: 1
2017-06-15 20:24:23Z [overcloud.Compute]: CREATE_FAILED  Error: 
resources.Compute.resources[0].resources.ComputeExtraConfigPre.resources.OvsDpdkSetup:
 Deployment to server failed: deploy_status_code: Deployment exited with 
non-zero status code: 1
2017-06-15 20:24:23Z [overcloud]: CREATE_FAILED  Resource CREATE failed: Error: 
resources.Compute.resources[0].resources.ComputeExtraConfigPre.resources.OvsDpdkSetup:
 Deployment to server failed: deploy_status_code: Deployment exited with 
non-zero status code: 1

Stack overcloud CREATE_FAILED


One other observation I can see all the three VMs (undercloud, baremetal0, 
baremetal1) are in running state. But I am unable to login to undercloud VM.

[vagrant@jumphost2 ~]$ sudo virsh list --all
IdName   State

1 undercloud running
4 baremetal0 running
5 baremetal1 running

[vagrant@jumphost2 ~]$ opnfv-util undercloud root
error: failed to get domain 'undercloud'
error: Domain not found: no domain with matching name 'undercloud'
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
ssh: Could not resolve hostname : Name or service not known



Thanks
Srikanth

From: Feng Pan [mailto:f...@redhat.com<mailto:f...@redhat.com>]
Sent: Wednesday, June 14, 2017 8:07 PM

To: Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [APEX] Apex virtual deployment install fails 
with error

Hi Srikanth,

You are getting this error because your jump host doesn't have internet 
connectivity during deploy process. Those dependencies should have been added 
to the latest daily rpms, can you try using those instead of Danube 2.0 release?

Thanks
Feng

On Wed, Jun 14, 2017 at 4:03 PM, Srikanth Vavilapalli 
<srikanth.vavilapa...@ericsson.com<mailto:srikanth.vavilapa...@ericsson.com>> 
wrote:
Thanks Feng

This time I tried with rpms from Danube branch on a fresh centos 7 VM but got 
different errors (below) while undercloud install… Plz find the attached full 
log.


I installed the following rpms:

sudo yum install 
https://repos.fedorapeople.org/repos/openstack/openstack-newton/rdo-release-newton-4.noarch.rpm
sudo yum install epel-release
sudo yum install 
http://artifacts.opnfv.org/apex/dependencies/python34-markupsafe-0.23-9.el7.centos.x86_64.rpm
sudo yum

[opnfv-tech-discuss] [APEX] Apex virtual deployment install fails with error

[Srikanth Vavilapalli]

Hi

I am trying to setup APEX virtual deployment on a centos7 VM by following the 
instructions from 
http://docs.opnfv.org/en/stable-danube/submodules/apex/docs/release/installation/virtualinstall.html.

At a high level:

  1.  Created a VM with Centos 7 on an ubuntu server
  2.  Installed RDO RPM: https://www.rdoproject.org/repos/rdo-release.rpm
  3.  Installed APEX RPMs (version 5.0-20170608) from opnfv artifacts
  4.  sudo opnfv-deploy -v --virtual-computes 1 -n 
/etc/opnfv-apex/network_settings.yaml -d /etc/opnfv-apex/os-odl-bgpvpn-noha.yaml

The opnfv-deploy script ran for nearly 90mins or so after which it returned the 
following error log (attached full log):

Configuring undercloud and discovering nodes
Waiting for messages on queue '18d292d8-e4c2-4bde-a6b0-88557f636f4e' with no 
timeout.
Waiting for messages on queue '18d292d8-e4c2-4bde-a6b0-88557f636f4e' with no 
timeout.
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: 
2f658b2a-29ea-4eb8-a877-86f19bebffa8
Successfully registered node UUID 121aaeca-ab9a-47cb-856b-d38521758e85
Successfully registered node UUID 0023532c-1548-44a9-9bc1-fcbf8be18513
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: 
12606ed5-5320-4571-890d-89570c7512d0
Successfully set all nodes to available.
Configuring nameserver on ctlplane network
Executing overcloud deployment, this could run for an extended period without 
output.
Error: The following files were not found: 
/usr/share/openstack-tripleo-heat-templates/environments/neutron-opendaylight-bgpvpn.yaml
ERROR: The Stack (overcloud) could not be found.
[vagrant@jumphost ~]$

Can anyone plz help me with this and point me if I am missing any step in the 
process?

Thanks
Srikanth

[vagrant@jumphost ~]$ sudo opnfv-deploy -v --virtual-computes 1 -n 
/etc/opnfv-apex/network_settings.yaml -d /etc/opnfv-apex/os-odl-bgpvpn-noha.yaml


This script is used to deploy the Apex Installer and Provision OPNFV Target 
System


Use -h to display help
Executing a Virtual Deployment
Virtual Compute nodes set to 1
Network Settings Configuration file: /etc/opnfv-apex/network_settings.yaml
Deployment Configuration file: /etc/opnfv-apex/os-odl-bgpvpn-noha.yaml
INFO: Parsing deploy settings file...
ha_enabled=False
deploy_options_array[odl_version]="carbon"
deploy_options_array[tacker]=False
deploy_options_array[dataplane]="ovs"
deploy_options_array[vpp]=False
deploy_options_array[sfc]=False
deploy_options_array[gluon]=False
deploy_options_array[sdn_controller]="opendaylight"
deploy_options_array[congress]=True
deploy_options_array[vpn]=True
deploy_options_array[rt_kvm]=False
deploy_options_array[ceph]=True
INFO: Parsing network settings file...
admin_cidr=192.0.2.0/24
admin_dhcp_range='192.0.2.2,192.0.2.10'
admin_installer_vm_vlan='native'
admin_installer_vm_members='em1'
admin_installer_vm_nic_type='interface'
admin_installer_vm_ip='192.0.2.1'
admin_introspection_range='192.0.2.100,192.0.2.120'
admin_enabled=True
admin_overcloud_ip_range='192.0.2.11,192.0.2.99'
admin_nic_mapping_compute_members='eth0'
admin_nic_mapping_compute_phys_type='interface'
admin_nic_mapping_controller_members='eth0'
admin_nic_mapping_controller_phys_type='interface'
admin_gateway='192.0.2.1'
tenant_cidr=11.0.0.0/24
tenant_overcloud_ip_range='11.0.0.21,11.0.0.234'
tenant_segmentation_type='vxlan'
tenant_enabled=True
tenant_nic_mapping_compute_uio_driver='uio_pci_generic'
tenant_nic_mapping_compute_vlan='native'
tenant_nic_mapping_compute_members='eth1'
tenant_nic_mapping_compute_phys_type='interface'
tenant_nic_mapping_controller_vlan='native'
tenant_nic_mapping_controller_members='eth1'
tenant_nic_mapping_controller_phys_type='interface'
tenant_overlay_id_range='2,65535'
tenant_mtu=1500
external_installer_vm_vlan='native'
external_installer_vm_members='em1'
external_installer_vm_nic_type='interface'
external_installer_vm_ip='192.168.37.1'
external_external_overlay_type='flat'
external_external_overlay_name='Public_internet'
external_external_overlay_gateway='192.168.37.1'
external_enabled=True
external_overcloud_ip_range='192.168.37.10,192.168.37.199'
external_gateway='192.168.37.1'
external_cidr=192.168.37.0/24
external_public=None
external_mtu=1500
external_floating_ip_range='192.168.37.200,192.168.37.220'
external_nic_mapping_compute_vlan='native'
external_nic_mapping_compute_members='eth2'
external_nic_mapping_compute_phys_type='interface'
external_nic_mapping_controller_vlan='native'
external_nic_mapping_controller_members='eth2'
external_nic_mapping_controller_phys_type='interface'
storage_enabled=True
storage_cidr=12.0.0.0/24
storage_overcloud_ip_range='12.0.0.21,12.0.0.234'
storage_nic_mapping_compute_vlan='native'
storage_nic_mapping_compute_members='eth3'
storage_nic_mapping_compute_phys_type='interface'
storage_nic_mapping_controller_vlan='native'
storage_nic_mapping_controller_members='eth3'
storage_nic_mapping_controller_phys_type='interface'
storage_mtu=1500
enabled_network_list='admin tenant