[opnfv-tech-discuss] [vsperf] Agenda for VSPERF weekly meeting - 18 Oct 2017 (ww42)

[Cooper, Trevor]

Proposed agenda topics:


1.   PTL handover plan
2.   Euphrates release

*   October 18 - MS9 - finalize documentation (documentation compliance 
page)
* October 19 - MS10 - JIRA cleanup

*   All unresolved issues should either be closed or the "fix version" 
field should be updated to a future release
*   No unresolved issue should have the "fix version" field as "none" 
or set to an old release.
* October 20 - MS11 - tag repos

*   tagging 
instructions
* October 24 (tentative) - download page goes live
3.   Summary of Fraser release plan MS1 (11/03) 
https://wiki.opnfv.org/display/SWREL/Summary+of+Release+Plans+for+Fraser
4.   TREX multi-stream status
5.   Status of tuning CI configuration
6.   Sandbox 2 progress
7.   Recap of discussion last week on CSIT test report  
https://docs.fd.io/csit/rls1707/report/vpp_performance_tests/index.html#



Meeting minutes
* ww41 
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-vswitchperf/2017/opnfv-vswitchperf.2017-10-11-15.01.html
* ww40 
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-vswitchperf/2017/opnfv-vswitchperf.2017-10-04-14.49.html
* ww39 
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-vswitchperf/2017/opnfv-vswitchperf.2017-09-27-15.01.html



Time: Wednesday UTC 15h00, Ireland (UTC/GMT +1) 16h00, PDT 8h00 (UTC/GMT -7) 
... Currently observing daylight saving

IRC: freenode https://freenode.net/ channel: #opnfv-vswitchperf 
http://webchat.freenode.net/?channels=opnfv-vswitchperf

Audio: https://global.gotomeeting.com/join/391235029
You can also dial in using your phone.  United States: +1 (571) 317-3116  
Access Code: 391-235-029
Phone numbers from other countries are here ... 
https://wiki.opnfv.org/display/meetings

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

[opnfv-tech-discuss] [Bottlenecks] Minutes for Weekly Call 20171018

[Yuyang (Gabriel)]

Minutes of Bottlenecks Discussion on Oct. 18th, 2017

  *   Date and Time
 *   Thursday at 
0300-0400
 UTC, Oct. 18th, 2017
 *   Thursday at 1100-1200 Beijing, Oct. 18th, 2017
 *   Wednesday at 0800-0900 PDT, Oct. 18th, 2017
  *   Minutes
 *   Yang Yu
  *   Participants (6 peoples):
 *   Ace Lee
 *   Rutuja
 *   Shubham
 *   Manoj
 *   Ross
Agenda:

  *   Intern Reports
  *   Yarkstick Cooperation on Scale up/out
  *   Stress Testing Discuss & Release Discuss
  *   Action Items Review
Discussion & Action Item

1.  IRC Minutes

  *   
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-bottlenecks/2017/opnfv-bottlenecks.2017-10-11-03.01.html

2.  Action Items

  *   Rutuja documents her plan in JIRA
  *   Ace will install openstack for Shubham
  *   Ace will debug the environment config.

3.  Work Plan Review

  *   https://wiki.opnfv.org/display/bottlenecks/Release+Plan
  Euphrates:

  *   How to use Quota - Prakash
 *   Reliability project in Openstack - Prakash
 *   WIKI page restructured for closely updating project details @done 
(17-05-11 09:20)
 *   Testing framework
*   General env pre commond for all test cases? Maybe different test 
cases call diffrent functions?
  *   Requirments investigation of DPDK and SR-IOV in Bottlenecks
 *   Which categories we should put them in?
 *   What the structure of their report?
 *   Is there any existing implementation we could use?
 *   Do we need to separate the env pre and test executing operations?
  *   Test report
 *   (Automatically) Test result report to MongoDB
 *   Landing page (on-going, in plan)
  *   Stress testing
 *   Implementing the rest stress test cases discussed during Danube
 *   Collect stress test case
 *   Request/maintaining long duration pod
 *   Work with VSPERF & StorPerf
 *   Scale Up/Out cooperation with Yardstick
  *   Initiate Tuning Test
 *   Ceph Tuning ( installer deployment tuning?)
 *   Comparison results
  *   Initiate Container Testing
 *   K8S, OpenRetriever,  unicore
 *   Work with installers team for Kola deployment testing
 *   Prakash to check OpenStack for Kola testing
  *   Testing Framework Refactoring
 *   Overall framework design
 *   Determine requirements & Initiate the overall framework design
 *   Unified entrance/top logic for system limit/tuning test
 *   Initiate top logic design & investigation
 *   Separated monitoring module
*   Work with StorPerf & VSPERF adding monitoring function
*   Monitoring using yardstick? Barometer?
 *   Stand-alone & offline
  *   More Contributors in Bottlenecks
 *   Intern projects
 *   Integrate upstream
 *   More contributors in project




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

Re: [opnfv-tech-discuss] [opnfv-tsc][Compass]Nomination of Committer promotion for Yifei Xue

[Chenshuai]

+1


在 2017/10/17 15:47, Chigang (Justin) 写道:


*I would like to nominate Yifei Xue as committer to Compass4nfv Project.*

The motivation for nominating Yifei to committer on Compass4nfv 
project is due to his commitment of providing value to the project 
through consistent high quality and valuable contributions.


His active participation through patch submissions and code reviews 
for Compass4nfv project SDN features integration (such as 
OpenDaylight, ONOS, etc) has been invaluable.


Please provide a +1/-1 vote before the end of next week, Oct 29.

Regards

Justin



华为技术有限公司Huawei Technologies Co., Ltd.

Company_logo

手　　机：13472817001
电子邮件：chig...@huawei.com



本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from 
HUAWEI, which
is intended only for the person or entity whose address is listed 
above. Any use of the
information contained herein in any way (including, but not limited 
to, total or partial
disclosure, reproduction, or dissemination) by persons other than the 
intended
recipient(s) is prohibited. If you receive this e-mail in error, 
please notify the sender by

phone or email immediately and delete it!



___
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

[opnfv-tech-discuss] Poll for Stor4NFV weekly meeting

[Wang, Shane]

Hi

Stor4NFV project (https://wiki.opnfv.org/display/Stor) is about to set up 
regular weekly meetings, for those who are interested in that project and are 
willing to contribute to the project, please look at 
https://doodle.com/poll/dg4tz7ekh2bn737e, and give a vote for your preference 
by this Friday. I'm going to set up them according to the polling result.

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

[opnfv-tech-discuss] 答复: Re: [Doctor][Functest] about doctor verify job using 'functest-suite-builder'

[dong.wenjuan]

Hi Jose,






Thanks for the fix~   :-)


I'll check after these patches were merged.






BR,


dwj




















原始邮件



发件人： ;
收件人：董文娟00101742;
抄送人： ; ; 
; ;
日 期 ：2017年10月17日 22:56
主 题 ：Re: [opnfv-tech-discuss] [Doctor][Functest] about doctor verify job using 
'functest-suite-builder'






Hi,


There was a problem with functest-suite and exporting the environment variables 
in the shell scripts we were running within the jenkins builders. This patch 
should fix that issue:

https://gerrit.opnfv.org/gerrit/#/c/45301/



and this one should fix the TESTCASE_OPTIONS issue and also the error you get 
in the jenkins output when trying to push the results to the DB:

https://gerrit.opnfv.org/gerrit/#/c/45349/



Once the second one is merged, please try again to run the doctor job.





Regards,

Jose




 

On 17 Oct 2017, at 04:01, dong.wenj...@zte.com.cn wrote:






Hi All,





As doctor verify job using the 'functest-suite-builder' to test, I found that 
many parameters are not passed to start functest docker container.


Such as {sshkey_vol}, {TESTCASE_OPTIONS}, you can see the log from[1]





[1] 
https://build.opnfv.org/ci/job/doctor-python-verify-apex-sample-master/121/console


This part:

docker run --privileged=true -e INSTALLER_TYPE=apex -e INSTALLER_IP=192.168.X.X 
-e NODE_NAME=zte-virtual3 -e DEPLOY_SCENARIO=os-nosdn-nofeature-ha -e 
BUILD_TAG=jenkins-doctor-python-verify-apex-sample-master-121 -e 
DEPLOY_TYPE=baremetal -v 
/home/jenkins/opnfv/functest/images:/home/opnfv/functest/images -v 
/home/jenkins/opnfv/functest/results/master:/home/opnfv/functest/results -v 
/home/jenkins/opnfv-openrc.sh:/home/opnfv/functest/conf/openstack.creds 
opnfv/functest-features:latest /bin/bash -c 'prepare_env start && run_tests -r 
-t doctor-notification'



You can see that  {sshkey_vol}, {TESTCASE_OPTIONS} are missing and 
'INSTALLER_IP' is wrong.


I remember that using 'export XXX=XXX' in different builders are not effective, 
they have different workspace.


Not sure about that. Do you have any ideas? Can you help to fix it? Thanks~








BR,


dwj___
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

[Jose Lausuch]

Hi,

We don´t need IPMI info, but access info (user, IPs, location of private key, 
..) Something similar to what Yardstick is using:
https://github.com/opnfv/yardstick/blob/master/etc/yardstick/nodes/pod.yaml.sample
 


Not sure if that fits to the PDF...

Regards,
Jose

> On 18 Oct 2017, at 00:14, Jack Morgan  wrote:
> 
> 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?
>> 
>> Regards,
>> Jose
>> 
>> 
>> 
>> 
>> 
>>> On 12 Oct 2017, at 03:50, xudan (N) >> > 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 
>>> ] On Behalf Of 
>>> limingjiang
>>> Sent: Thursday, October 12, 2017 9:24 AM
>>> To: Srikanth Vavilapalli
>>> Cc: 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
>>> +---+
>>>  
>>> 发件人: 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 
>>> 
>>> 主题: 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:
>>> 
>>>   

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

[Jack Morgan]

  
  
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?
  
  
  

  

  Regards,
  Jose
  
  


  
  
  



  
On 12 Oct 2017, at 03:50, xudan (N)  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] On Behalf Of limingjiang
Sent: Thursday,
October 12, 2017 9:24 AM
To: Srikanth
Vavilapalli
Cc: 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
  +---+

 

  
发件人: 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
主题: 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,

Re: [opnfv-tech-discuss] [release][euphrates] release next week - Oct 20, 2017

[David McBride]

Reminder...

Tomorrow, *October 18, please finalized your documentation for Euphrates
5.0.*  Please remember to update the documentation compliance page

so
that I can verify project compliance.  Thanks.

David

On Thu, Oct 12, 2017 at 11:40 AM, David McBride <
dmcbr...@linuxfoundation.org> wrote:

> Team,
>
> Just a reminder that, per the revised schedule approved by the TSC on Oct
> 10, Euphrates 5.0 will be released next Friday, October 20.
>
>- October 17 - MS8 - end of formal testing
>- October 18 - MS9 - finalize documentation
>   - please update the documentation compliance page
>   
>  
> under
>   "Milestone 9 (final)"
>- October 19 - MS10 - JIRA cleanup
>   - All unresolved issues should either be closed or the "fix
>   version" field should be updated to a future release
>   - No unresolved issue should have the "fix version" field as "none"
>   or set to an old release.
>- October 20 - MS11 - tag repos
>   - tagging insructions
>   
> 
>- October 24 (tentative) - download page goes live
>
> Let me know if you have any questions.
>
> David
>
> --
> *David McBride*
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>



-- 
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Auto] Re: All pods are pending when setting up kubernetes

[Michael O'Brien]

Tina, Harry,
   It looks like your kubernetes pods under rancher are not up – they are all 
0/1 or 0/3 – in the instructions after setting up your kube client run
Kubectl cluster-info
– you should see all 7 green lines – errors usually means there are issues 
either with your file system or dns – are you running collocated (server/client 
on same machine – I think so right?)
  Also I need to update the meeting minutes with the demo video – I’ll post the 
time where I checked this during the demo.

For any image issues - could you verify that you ran the prepull_docker sh 
script from the page
https://wiki.onap.org/display/DW/ONAP+on+Kubernetes#ONAPonKubernetes-QuickstartInstallation

https://jira.onap.org/secure/attachment/10501/prepull_docker.sh

[https://jira.onap.org/images/icons/issuetypes/story.svg]OOM-328
 - Preload docker images script before createAll.sh will allow 7 min startup IN 
PROGRESS
curl https://jira.onap.org/secure/attachment/10501/prepull_docker.sh > 
prepull_docker.sh
chmod 777 prepull_docker.sh
nohup ./prepull_docker.sh > prepull.log &


Then do the following to verify that at least all the docker images were pulled.
Docker images

After that try bringing up an independent component like onap-robot – this does 
not need anything else and can be used to verify your install

./createAll.bash –n onap –a onap-robot

/michael



From: Tina Tsou [mailto:tina.t...@arm.com]
Sent: Tuesday, October 17, 2017 13:21
To: huangxiangyu ; lylav...@iol.unh.edu; 
pberber...@iol.unh.edu
Cc: Michael O'Brien ; 
opnfv-tech-discuss@lists.opnfv.org
Subject: [Auto] Re: All pods are pending when setting up kubernetes

Include UNH Lab...


Thank you,
Tina

On Oct 16, 2017, at 11:33 PM, huangxiangyu 
mailto:huangxiang...@huawei.com>> wrote:
HI Michael

Currently I manage to bring up onap pods in our local lab and most of them are 
in running state. But there seem to be a rancher bug that block me in UNH lab.  
Everything seems fine and throws no error when I created rancher-agent. Somehow 
pods in kube-system just keep getting stuck in pending state. I check the 
docker images and even images for these pods are not pulled.
[root@pod1 ~]# kubectl get pods --all-namespaces -a
NAMESPACE NAME   READY STATUS
RESTARTS   AGE
kube-system   heapster-4285517626-8r16j  0/1   Pending   0  
20h
kube-system   kube-dns-638003847-hkn34   0/3   Pending   0  
20h
kube-system   kubernetes-dashboard-716739405-n7x9l   0/1   Pending   0  
20h
kube-system   monitoring-grafana-2360823841-bfd5b0/1   Pending   0  
1d
kube-system   monitoring-influxdb-2323019309-mgnb5   0/1   Pending   0  
1d
kube-system   tiller-deploy-737598192-dq0pm  0/1   Pending   0  
1d

This new pod should be powerful enough but still installed centos. I used to 
have no problem when setting up undercloud in previous pod which is also a 
centos pod. Have you ever met this problem ? or maybe we should ask UNH lab to 
reinstall a Ubuntu OS.

Thanks
Harry Huang

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

Re: [opnfv-tech-discuss] [Auto] Re: All pods are pending when setting up kubernetes

[Parker Berberian]

Hi Harry Huang,

I can help you with whatever you need us at UNH to do.

I just want to clarify: Is this a connection issue you are having with our
vpn and network? Or are you having trouble with pod1 itself?

I can install Ubuntu for you, or try to troubleshoot the freezing issue.
Let me know what you need.

Thank you,
Parker Berberian

On Tue, Oct 17, 2017 at 1:21 PM, Tina Tsou  wrote:

> Include UNH Lab...
>
>
> Thank you,
> Tina
>
> On Oct 16, 2017, at 11:33 PM, huangxiangyu 
> wrote:
>
> HI Michael
>
>
>
> Currently I manage to bring up onap pods in our local lab and most of them
> are in running state. But there seem to be a rancher bug that block me in
> UNH lab.  Everything seems fine and throws no error when I created
> rancher-agent. Somehow pods in kube-system just keep getting stuck in
> pending state. I check the docker images and even images for these pods are
> not pulled.
>
> [root@pod1 ~]# kubectl get pods --all-namespaces -a
>
> NAMESPACE NAME   READY STATUS
> RESTARTS   AGE
>
> kube-system   heapster-4285517626-8r16j  0/1   Pending
>  0  20h
>
> kube-system   kube-dns-638003847-hkn34   0/3   Pending
>  0  20h
>
> kube-system   kubernetes-dashboard-716739405-n7x9l   0/1   Pending
>  0  20h
>
> kube-system   monitoring-grafana-2360823841-bfd5b0/1   Pending
>  0  1d
>
> kube-system   monitoring-influxdb-2323019309-mgnb5   0/1   Pending
>  0  1d
>
> kube-system   tiller-deploy-737598192-dq0pm  0/1   Pending
>  0  1d
>
>
>
> This new pod should be powerful enough but still installed centos. I used
> to have no problem when setting up undercloud in previous pod which is also
> a centos pod. Have you ever met this problem ? or maybe we should ask UNH
> lab to reinstall a Ubuntu OS.
>
>
>
> Thanks
>
> Harry Huang
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [release][euphrates] recommended list of scenarios for release in Euphrates 5.0

[David McBride]

Team,

Based on scenario owner intent-to-participate, as well as a review of
deploy results, I'm recommending that the following scenarios be released
for Euphrates 5.0:

*Scenario* *Installer*
os-nosdn-nofeature-ha Apex
os-nosdn-calipso-noha Apex
os-nosdn-nofeature-noha Apex
os-odl-nofeature-ha Apex
os-odl-nofeature-noha Apex
os-nosdn-ovs_dpdk-ha Apex
os-nosdn-ovs_dpdk-noha Apex
os-odl-fdio-noha Apex
os-odl-fdio-ha Apex
os-odl-fdio_dvr-noha Apex
os-nosdn-fdio-noha Apex
os-nosdn-fdio-ha Apex
os-nosdn-kvm_ovs_dpdk-ha Apex
os-nosdn-kvm_ovs_dpdk-noha Apex
os-nosdn-bar-ha Apex
os-nosdn-bar-noha Apex
os-odl-bgpvpn-ha Apex
os-odl-bgpvpn-noha Apex
os-odl-sfc-noha Apex
os-ovn-nofeature-noha  Apex
os-odl_l2-moon-ha Compass
os-odl_l2-moon-noha Compass
os-nosdn-nofeature-ha Compass4NFV
os-nosdn-nofeature-noha Compass4NFV
os-odl-sfc-ha Compass4NFV
os-odl-sfc-noha Compass4NFV
k8s-nosdn-nofeature-ha Compass4NFV
os-nosdn-nofeature-ha Daisy
os-odl-nofeature-ha  Daisy
os-nosdn-nofeature-noha Fuel/MCP
os-nosdn-nofeature-ha Fuel/MCP
os-nosdn-ovs-noha Fuel/MCP
os-nosdn-ovs-ha Fuel/MCP
os-odl-nofeature-noha Fuel/MCP
os-odl-nofeature-ha Fuel/MCP
k8-nosdn-lb-noha JOID
os-nosdn-nofeature-ha JOID
os-nosdn-lxd-ha JOID
os-nosdn-lxd-noha JOID
os-nosdn-nofeature-noha JOID
os-ocl-nofeature-ha JOID
os-ocl-nofeature-noha JOID
os-nosdn-openbaton-ha JOID
k8-ovn-lb-noha JOID
os-nosdn-nofeature-ha Fuel/MCP (aarch64)
os-odl-nofeature-ha Fuel/MCP (aarch64)

-- 
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [Auto] Auto Project Meeting 10/23/2017 - Auto - OPNFV Wiki

[Tina Tsou]

Dear all,

Auto meeting agenda 10/23 next Monday 6am PT is posted at the wiki page.

https://wiki.opnfv.org/pages/viewpage.action?pageId=13206149

Talk to you at the meeting and the mailing list.


Thank you,
Tina
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - Oct. 9th

[HU, BIN]

Morgan,

Sure. I added this agenda item after Clover.

Thanks
Bin

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jack Morgan
Sent: Tuesday, October 17, 2017 9:56 AM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - 
Oct. 9th


Bin,

Can we add this topic to the Tech Discuss meeting this week? Perhaps, after the 
Clover topic? thanks

Topic is IDF definitions and details (others feel free to add/adjust)

On 10/16/2017 06:49 AM, Julien wrote:
Hi David,

I agree your comments about net_config in [2]. Before my holiday maybe I make a 
mistake that I think IDF is used for infrastructure network descriptor.
For Jobs naming, I think in Kubernetes, we still need to resolve the usage of 
network and storage, while these features are not well supported in the 
Kubernetes community. Control is equivalent to Master, and Minion is  
equivalent to Minion. It is difficult to define one set of names to meet all 
the requirement. If someday VMware or HyperV is introduced into the community 
as VIM, the names are meaningful to the new VIMs?


mailto:david.blaisonn...@orange.com>>于2017年10月16日周一
 下午4:26写道：

Hi everyone,

I agree that the PDF/IDF definitions must be fixed ASAP.

  *   About net_config in IDF: I think it is a bad idea. As i answer in the 
patch #42233 [2], if the L3 network is configured in the infra (firewall, 
router, ...), and not configurable by the installer, it must stay in the PDF. 
If the PDF leaves an empty L3 network section, it could be fixed by the 
installer, and configured in the IDF.
  *   About net_config as proposed by Guillermo Herrero in #42893 [1]: +1 with 
an official naming less openstack 'like'. For a better understanding and 
writing by infra ops, can we authorize comments describing what is this network 
in simple name (and openstack 'like' naming if the author like it)? We must 
consider that ops may not use the same convention in the data center, and pdf 
writting must not be painful.
  *   Jobs naming: Today, jobs in IDF are also openstack centric and can only 
describe a ha or noha mode, but not both, I propose in #42233[2] that we use 
'infra', 'worker' and 'infra_or_worker' as naming for main node's job. This 
will let SDF file describing what is the mapping  to openstack, k8s or any 
other vim naming.
  *   storage definition in shared IDF part [3]: Julien propose to add the 
storage definition in IDF, I agree, but it must be consolidated. I will comment 
in the patch
BR

David

[1] 
https://gerrit.opnfv.org/gerrit/#/c/42893
[2]
 
https://gerrit.opnfv.org/gerrit/#/c/42233

[3] https://gerrit.opnfv.org/gerrit/#/c/44603/1/labs/att/idf-pod1.yaml




--

David BLAISONNEAU

NFV platforms DevOPS - OPNFV contributor

Orange - IMT / OLN / CNC / NCA / SINA



tel: +33 (0)2 96 07 27 93

email: david.blaisonn...@orange.com

2, avenue Pierre Marzin 22307 LANNION Cedex - France
Le 16/10/2017 à 02:25, Julien a écrit :
Hi Alex,

It's a great news.
2 PODs in our lab reserved for MCP are blocked to deploy in master branch. Can 
you give me a PDF/IDF link which are used now, then we will submit PDF/IDF 
patches according to your version.

For **net_config**, I personally suggest to move it to IDF and get the 
template/format approved ASSP, for it is really important to us.

BR/Julien

Alexandru Avadanii 
mailto:alexandru.avada...@enea.com>>于2017年10月15日周日 
下午9:44写道：
Hi,
Fuel has been using PDF and IDF for weeks now.
We still rely on net_config, which is out of spec, to map between PDF networks 
and the network role within the installer.
Apart from net_config, we still need to sort out the mapping between interfaces 
indexes in PDF and the interface names inside OS (e.g. iface 0 = eno1, iface 2 
= enp1s0f1).

For net_config, Guillermo proposed an alternative as a comment in [1], which 
imo is closer to the hardware view of the setup (e

[opnfv-tech-discuss] [Auto] Re: All pods are pending when setting up kubernetes

[Tina Tsou]

Include UNH Lab...


Thank you,
Tina

On Oct 16, 2017, at 11:33 PM, huangxiangyu 
mailto:huangxiang...@huawei.com>> wrote:

HI Michael

Currently I manage to bring up onap pods in our local lab and most of them are 
in running state. But there seem to be a rancher bug that block me in UNH lab.  
Everything seems fine and throws no error when I created rancher-agent. Somehow 
pods in kube-system just keep getting stuck in pending state. I check the 
docker images and even images for these pods are not pulled.
[root@pod1 ~]# kubectl get pods --all-namespaces -a
NAMESPACE NAME   READY STATUS
RESTARTS   AGE
kube-system   heapster-4285517626-8r16j  0/1   Pending   0  
20h
kube-system   kube-dns-638003847-hkn34   0/3   Pending   0  
20h
kube-system   kubernetes-dashboard-716739405-n7x9l   0/1   Pending   0  
20h
kube-system   monitoring-grafana-2360823841-bfd5b0/1   Pending   0  
1d
kube-system   monitoring-influxdb-2323019309-mgnb5   0/1   Pending   0  
1d
kube-system   tiller-deploy-737598192-dq0pm  0/1   Pending   0  
1d

This new pod should be powerful enough but still installed centos. I used to 
have no problem when setting up undercloud in previous pod which is also a 
centos pod. Have you ever met this problem ? or maybe we should ask UNH lab to 
reinstall a Ubuntu OS.

Thanks
Harry Huang

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - Oct. 9th

[Bryan Sullivan]

The "network" (as it's called in my alternate proposal for IDF at 
https://gerrit.opnfv.org/gerrit/#/c/44603/ is important in the IDF as some 
constructs (e.g. bonds) may vary and are not part of the physical 
infrastructure (though certainly discoverable, they would have to be discovered 
through the installer process). The IDF as I see it is an important 
intersection between the PDF and SDF, and should enable the installer to apply 
largely scenario-independent generic constructs/roles as needed for the 
particular deployment.

Thanks,
Bryan Sullivan

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
 on behalf of Alexandru Avadanii 

Sent: Sunday, October 15, 2017 6:44 AM
To: Julien; Jack Morgan; opnfv-tech-discuss
Cc: Guillermo Herrero
Subject: Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - 
Oct. 9th

Hi,
Fuel has been using PDF and IDF for weeks now.
We still rely on net_config, which is out of spec, to map between PDF networks 
and the network role within the installer.
Apart from net_config, we still need to sort out the mapping between interfaces 
indexes in PDF and the interface names inside OS (e.g. iface 0 = eno1, iface 2 
= enp1s0f1).

For net_config, Guillermo proposed an alternative as a comment in [1], which 
imo is closer to the hardware view of the setup (especially the port_matrix 
part).
For iface name mapping, we will probably add it to IDF as a Fuel-specific 
section for now (no PoC proposed yet).

BR,
Alex

[1] https://gerrit.opnfv.org/gerrit/#/c/42893/6/labs/lf/pod4.yaml


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Julien
Sent: Sunday, October 15, 2017 12:38 PM
To: Jack Morgan; opnfv-tech-discuss
Subject: Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - 
Oct. 9th

Hi Jack and Infra team:

This week I have a chance to directly discuss with installer team: Apex and 
Compass. I still can not contact Joid.

This is the status of PDF in each installer:

Apex: Not started, won't support in E release, and I have submitted a Jira 
ticket in Apex.
Compass: Not started, and plan to support in F release
Daisy: PDF is supported and used in CI PODs for deployment, while IDF is not 
used for now
Fuel: Started, not finished yet
Joid: No response in email and IRC(#opnfv-joid)

I would like to suggest to clear PDF/IDF patches in gerrit, let's make an 
acceptable template and update them in the future, then the lab owners can 
submit their PDF/IDF and used for deployment.

BR/Julien
Jack Morgan mailto:jack.mor...@intel.com>>于2017年10月10日周二 
上午12:38写道：
October 9th

Agenda:
1.Status update on PDF
・ complete discussion from last week as this is a deliverable for 
Euphrates release
2.LaaS and Dashboard integration Lincoln 
Lavoie
3.Infra documentation on RTD - patch 
40329
 merged, what else?
a. Discussion of Infra documentation
4.Zuul v3, Fatih 
Degirmenci
 .  possibility to start a prototype?
5.Follow up on security audit job logs  
[https://jira.opnfv.org/secure/viewavatar?size=xsmall&avatarId=10303&avatarType=issuetype]
 
RELENG-272

Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - Oct. 9th

[Jack Morgan]

  
  
Bin,
Can we add this topic to the Tech Discuss meeting this week?
Perhaps, after the Clover topic? thanks
Topic is IDF definitions and details (others feel free to add/adjust)


On 10/16/2017 06:49 AM, Julien wrote:


  
  Hi David,


I agree your comments about net_config in [2]. Before my
  holiday maybe I make a mistake that I think IDF is used for
  infrastructure network descriptor.
For Jobs naming, I think in Kubernetes, we still need to
  resolve the usage of network and storage, while these features
  are not well supported in the Kubernetes community. Control is
  equivalent to Master, and Minion is  equivalent to Minion. It
  is difficult to define one set of names to meet all the
  requirement. If someday VMware or HyperV is introduced into
  the community as VIM, the names are meaningful to the new
  VIMs?




  于2017年10月16日周一
下午4:26写道：
  
  

  Hi everyone,
  I agree that the PDF/IDF definitions must be fixed
ASAP.
  
About net_config in IDF: I think it is a bad
  idea. As i answer in the patch #42233 [2], if the L3
  network is configured in the infra (firewall, router,
  ...), and not configurable by the installer, it must
  stay in the PDF. If the PDF leaves an empty L3 network
  section, it could be fixed by the installer, and
  configured in the IDF. 

About net_config as proposed by Guillermo
Herrero in #42893 [1]: +1 with an official
  naming less openstack 'like'. For a better
  understanding and writing by infra ops, can we
  authorize comments describing what is this network in
  simple name (and openstack 'like' naming if the author
  like it)? We must consider that ops may not use the
  same convention in the data center, and pdf writting
  must not be painful.
Jobs naming: Today, jobs in IDF are also
  openstack centric and can only describe a ha or noha
  mode, but not both, I propose in #42233[2] that we use
  'infra', 'worker' and 'infra_or_worker' as naming for
  main node's job. This will let SDF file describing
  what is the mapping  to openstack, k8s or any other
  vim naming.
storage definition in shared IDF part [3]:
  Julien propose to add the storage definition in IDF, I
  agree, but it must be consolidated. I will comment in
  the patch

  
  BR
  
  David
  [1]
https://gerrit.opnfv.org/gerrit/#/c/42893
[2]
https://gerrit.opnfv.org/gerrit/#/c/42233
  [3]
https://gerrit.opnfv.org/gerrit/#/c/44603/1/labs/att/idf-pod1.yaml
  
  
  
  -- 
David BLAISONNEAU
NFV platforms DevOPS - OPNFV contributor
Orange - IMT / OLN / CNC / NCA / SINA

tel: +33 (0)2 96 07 27 93
email: david.blaisonn...@orange.com
2, avenue Pierre Marzin 22307 LANNION Cedex - France 


  Le
16/10/2017 à 02:25, Julien a écrit :
  
  
Hi Alex,
  
  
  It's a great news.
  2 PODs in our lab reserved for MCP are blocked to
deploy in master branch. Can you give me a PDF/IDF
link which are used now, then we will submit PDF/IDF
patches according to your version.
  
  
  For **net_config**, I personally suggest to move
it to IDF and get the template/format approved ASSP,
for it is really important to us.
  
  
  BR/Julien



  Alexandru Avadanii 于2017年10月15日周日
下午9:44写道：
  
  

  
Hi,
Fuel
has been using PDF and IDF for weeks now.
We
still rely on net_config, which is out of
spec, to map between PDF networks and the
network role within the 

[opnfv-tech-discuss] [Update] [barometer] Weekly Call

[aasmith]

Apologies, cancelling meeting for this week.  Didn't get the ducks aligned.

You have been invited to the following event.

Title: [opnfv-tech-discuss] [barometer] Weekly Call
Hi Folks

Let’s kick off a weekly call on Tuesdays to cover project updates.  This  
first week we will start 30 minutes later than usual.


Barometer JIRA:  
https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=57&projectKey=BAROMETER


Aaron


When: Tue Oct 17, 2017 12:30pm – 1pm Eastern Time
Where: https://global.gotomeeting.com/join/819733085
Who:
* aasm...@redhat.com - organizer
* andrew.duig...@intel.com
* ola.liljed...@arm.com
* romanx.korynkev...@intel.com
* ning@intel.com
* kand...@us.ibm.com
* ab...@redhat.com
* opnfv-tech-discuss@lists.opnfv.org
* bs3...@att.com
* scott.mansfi...@ericsson.com
* acmor...@att.com
* pavan.gu...@calsoftinc.com
* manish.ja...@cavium.com
* Srinivas Chaganti
* emma.l.fo...@intel.com
* mario.rodrig...@arm.com
* aput...@redhat.com
* Javier Arauz
* krishna.j.mur...@intel.com
* serkant.ulude...@argela.com.tr
* yangya...@chinamobile.com
* raghuveer.re...@intel.com
* daniel.par...@intel.com
* damien.po...@intel.com
* tony.b.mcma...@intel.com
* wesley.campb...@intel.com
* calin.gher...@intel.com
* tarasx.chor...@intel.com
* bj@intel.com
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [Update] [barometer] Weekly Call

[aasmith]

Need to delay start of meeting until 12:30 today.  It will be a quick  
meeting.


You have been invited to the following event.

Title: [opnfv-tech-discuss] [barometer] Weekly Call
Updated the goto meeting


When: Tue Oct 24, 2017 12pm – 1pm Eastern Time
Where: https://global.gotomeeting.com/join/819733085
Who:
* aasm...@redhat.com - organizer
* bj@intel.com
* tony.b.mcma...@intel.com
* emma.l.fo...@intel.com
* scott.mansfi...@ericsson.com
* mario.rodrig...@arm.com
* aput...@redhat.com
* calin.gher...@intel.com
* bs3...@att.com
* romanx.korynkev...@intel.com
* manish.ja...@cavium.com
* pavan.gu...@calsoftinc.com
* damien.po...@intel.com
* kand...@us.ibm.com
* wesley.campb...@intel.com
* Javier Arauz
* ning@intel.com
* ab...@redhat.com
* tarasx.chor...@intel.com
* ola.liljed...@arm.com
* raghuveer.re...@intel.com
* yangya...@chinamobile.com
* serkant.ulude...@argela.com.tr
* krishna.j.mur...@intel.com
* opnfv-tech-discuss@lists.opnfv.org
* andrew.duig...@intel.com
* Srinivas Chaganti
* acmor...@att.com
___
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

[Jose Lausuch]

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 
>  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] On Behalf Of Jose Lausuch
> Sent: Friday, October 13, 2017 4:28 AM
> To: Tim Irnich 
> 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  > 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 
> ] On Behalf Of Jose Lausuch
> Sent: Friday, October 13, 2017 09:16
> To: xudan (N) mailto:xuda...@huawei.com>>; Morgan, Jack 
> mailto:jack.mor...@intel.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,
>  
> 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)  > 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 
> ] On Behalf Of limingjiang
> Sent: Thursday, October 12, 2017 9:24 AM
> To: Srikanth Vavilapalli
> Cc: 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”

Re: [opnfv-tech-discuss] [Doctor][Functest] about doctor verify job using 'functest-suite-builder'

[Jose Lausuch]

Hi,

There was a problem with functest-suite and exporting the environment variables 
in the shell scripts we were running within the jenkins builders. This patch 
should fix that issue:
https://gerrit.opnfv.org/gerrit/#/c/45301/ 


and this one should fix the TESTCASE_OPTIONS issue and also the error you get 
in the jenkins output when trying to push the results to the DB:
https://gerrit.opnfv.org/gerrit/#/c/45349/ 


Once the second one is merged, please try again to run the doctor job.

Regards,
Jose





> On 17 Oct 2017, at 04:01, dong.wenj...@zte.com.cn wrote:
> 
> 
> 
> Hi All,
> 
> 
> 
> As doctor verify job using the 'functest-suite-builder' to test, I found that 
> many parameters are not passed to start functest docker container.
> 
> Such as {sshkey_vol}, {TESTCASE_OPTIONS}, you can see the log from[1]
> 
> 
> 
> [1] 
> https://build.opnfv.org/ci/job/doctor-python-verify-apex-sample-master/121/console
>  
> 
> This part:
> 
> docker run --privileged=true -e INSTALLER_TYPE=apex -e 
> INSTALLER_IP=192.168.X.X -e NODE_NAME=zte-virtual3 -e 
> DEPLOY_SCENARIO=os-nosdn-nofeature-ha -e 
> BUILD_TAG=jenkins-doctor-python-verify-apex-sample-master-121 -e 
> DEPLOY_TYPE=baremetal -v 
> /home/jenkins/opnfv/functest/images:/home/opnfv/functest/images -v 
> /home/jenkins/opnfv/functest/results/master:/home/opnfv/functest/results  -v 
> /home/jenkins/opnfv-openrc.sh:/home/opnfv/functest/conf/openstack.creds  
> opnfv/functest-features:latest /bin/bash -c 'prepare_env start && run_tests 
> -r -t doctor-notification'
> 
> 
> You can see that  {sshkey_vol}, {TESTCASE_OPTIONS} are missing and 
> 'INSTALLER_IP' is wrong.
> 
> I remember that using 'export XXX=XXX' in different builders are not 
> effective, they have different workspace.
> 
> Not sure about that. Do you have any ideas? Can you help to fix it? Thanks~
> 
> 
> 
> 
> 
> BR,
> 
> dwj
> 
> 
> 
> 
> 

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

[opnfv-tech-discuss] [Bottlenecks] Weekly Call

[Yuyang (Gabriel)]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Australia Standard Time
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Yuyang (Gabriel):MAILTO:gabriel.yuy...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -discuss:MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Brattain,
  Ross B'":MAILTO:ross.b.bratt...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'S, Deepak
 '":MAILTO:deepa...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Rutuja Su
 rve':MAILTO:rutuja.r.su...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=AMIT KUMAR
  JAISWAL:MAILTO:amitkumarj...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Manuel Reb
 ellon:MAILTO:mrebel...@sandvine.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=wangyaogua
 ng (A):MAILTO:sunshine.w...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Liyin (Ace
 ):MAILTO:liyi...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Manoj Nir
 ania':MAILTO:manojnira...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Shubham A
 garwal':MAILTO:shubham.agarwal.co...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=limingjian
 g:MAILTO:limingji...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=chenjianku
 n:MAILTO:chenjiank...@huawei.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Canio Cil
 lis':MAILTO:canio.cil...@de.ibm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'GUPTA, AL
 OK'":MAILTO:ag1...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Maria Toe
 roe':MAILTO:maria.toe...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Bernier, 
 Daniel'":MAILTO:daniel.bern...@bell.ca
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Kedalagud
 de, Meghashree Dattatri'":MAILTO:meghashree.dattatri.kedalagu...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Jose Ange
 l Lausuch':MAILTO:jalaus...@suse.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anubhav G
 uleria':MAILTO:anugule...@grads.cds.iisc.ac.in
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ray Wong'
 :MAILTO:ray.w...@deltaww.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Nicolas B
 outhors':MAILTO:nicolas.bouth...@enea.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Sun, Jimi
 ng'":MAILTO:jiming@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Cooper, T
 revor'":MAILTO:trevor.coo...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Carlos Br
 avo':MAILTO:carlos.br...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Andrew Ve
 itch':MAILTO:andrew.vei...@netcracker.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Vul, Alex
 '":MAILTO:alex@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Ramia, Ka
 nnan Babu'":MAILTO:kannan.babu.ra...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Alan McNa
 mee':MAILTO:alan...@openet.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Wang, Sha
 ne'":MAILTO:shane.w...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Tim Irnic
 h':MAILTO:tim.irn...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ken Gray 
 (kegray)':MAILTO:keg...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Seiler, G
 lenn'":MAILTO:glenn.sei...@windriver.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Perala, T
 imo (Nokia - FI/Espoo)'":MAILTO:timo.per...@nokia.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ahmed Elb
 ornou (amaged)':MAILTO:ama...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Piyush Sa
 rwal':MAILTO:psar...@us.ibm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Reddy, Rag
 huveer":MAILTO:raghuveer.re...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=최강일:
 MAILTO:forerun...@etri.re.kr
DESCRIPTION;LANGUAGE=zh-CN:Hi\,\n\nThe Bottlenecks weekly meeting will be h
 eld at 3:00-4:00 UTC\, Wednesday\, 11:00-12:00 Beijing Time\, Wednesday\, 
 PDT 8:00-9:00 Tuesday.\nWelcome to join our discussion. Details of this me
 eting are shown below.\nAgenda:\n   1.   Intern Reports\na
 ) Monitoring Stress tests

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

[Markos Chandras]

On 16/10/17 23:22, Srikanth Vavilapalli wrote:
> 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  122859
> 6738
> Swap:   511   0 511
> vagrant@xci:~/releng-xci/xci$
> 
> 
Hello,

As I said in my previous e-mail, the AIO VM needs 8GB of ram so your
host (ie your vagrant VM) will need to have more than that. The AIO VM
will be created inside the vagrant VM so you will end up with nested
virtualization. If you are using virtualbox then it does not support
nested KVM virtualization which means your AIO VM will need to use the
Qemu emulator which will be terribly slow. It's probably best to create
a big (>=12G of RAM, >=120G ofr disk, >=8vcpus) KVM virtual machine
(with libvirt, virt-manager or something else) and then execute
./xci-deploy.sh inside of it.

-- 
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] [opnfv-tsc][Compass]Nomination of Committer promotion for Xinhui Hu

[Chigang (Justin)]

I would like to nominate Xinhui Hu as committer to Compass4nfv Project.

The motivation for nominating Xinhui Hu to committer on Compass4nfv project is 
due to his commitment of providing value to the project through consistent high 
quality and valuable contributions.
He is a senior architect for Cloud Computing in Fiberhome, more than 7 years’ 
development experience in Cloud, familiar with Vmware, OpenStack, Kubernetes 
high availability cluster building.
His active participation through patch submissions and code reviews for 
contributing K8s integration in Euphrates has been invaluable.

Please provide a +1/-1 vote before the end of next week, Oct 29.

Regards
Justin


华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
手　　机：13472817001
电子邮件：chig...@huawei.com

 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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

[opnfv-tech-discuss] [opnfv-tsc][Compass]Nomination of Committer promotion for Yifei Xue

[Chigang (Justin)]

I would like to nominate Yifei Xue as committer to Compass4nfv Project.

The motivation for nominating Yifei to committer on Compass4nfv project is due 
to his commitment of providing value to the project through consistent high 
quality and valuable contributions.
His active participation through patch submissions and code reviews for 
Compass4nfv project SDN features integration (such as OpenDaylight, ONOS, etc) 
has been invaluable.

Please provide a +1/-1 vote before the end of next week, Oct 29.

Regards
Justin


华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
手　　机：13472817001
电子邮件：chig...@huawei.com

 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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