Re: [opnfv-tech-discuss] [RELENG] Vote to make Trevor a submitter on releng.

[Jose Lausuch]

+1

-Original Message-
From: Aric Gardner [mailto:agard...@linuxfoundation.org] 
Sent: Thursday, July 21, 2016 20:05 PM
To: OPNFV Tech
Cc: Fatih Degirmenci; Jose Lausuch; Meimei; RICHOMME Morgan IMT/OLN; Ryota 
Mibu; Tim Rozet
Subject: [opnfv-tech-discuss] [RELENG] Vote to make Trevor a submitter on 
releng.

Hi Releng committers,

Please vote on making Trevor (tbramw...@linuxfoundation.org) a releng committer.

Here's my +1

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

Re: [opnfv-tech-discuss] Do all OPNFV installers create an external net/subnet?

[Jose Lausuch]

Hi Bryan,

Yes, the 4 installers deploy an external network by default, we requested that 
already in Arno for Functest. We have a "utils" function that returns you the 
name of the external network, but it is written in Python and we can use it and 
pass the network name as a parameter when calling your Shell script. Is that ok?

Regarding our vPing tests, we do test the external connectivity as well making 
use of floating ips and ssh to the instances. Check this out for more info:
http://artifacts.opnfv.org/functest/docs/userguide/index.html#vping-ssh

Regards,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of SULLIVAN, 
BRYAN L
Sent: Wednesday, July 27, 2016 5:25 AM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] Do all OPNFV installers create an external 
net/subnet?

Hi all,

This question came up as I was debugging why in my NUC lab environment.  I was 
not able to ping or SSH to VMs. Turns out there was an external network and 
subnet that had been created by JOID as part of the install process (see 
https://git.opnfv.org/cgit/joid/plain/ci/openstack.sh). Creating a second 
external net/subnet as I do in my tests e.g. the smoke test 
(https://git.opnfv.org/cgit/copper/plain/tests/adhoc/smoke01.sh), prevents ping 
and SSH from working for some reason. So I had to change that script to find an 
existing external net/subnet if any, first.

This brings up the question: like JOID, do all other OPNFV installers create an 
external network as part of the install process?

If not, is there a recommended way for tests to determine what the parameters 
(e.g. gateway, allocation pools) of an external net/subnet should be?

BTW, the smoke01 script I developed goes beyond vPing, with tests of external 
network connectivity as well. Is that something we should add to vPing (I 
didn't see it in vPing)?

Thanks,
Bryan Sullivan | AT&T

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

[opnfv-tech-discuss] Functest feedback in Jenkins

[Jose Lausuch]

Hi,

In order to provide a better user experience and useful feedback from the daily 
runs in Jenkins, these features have been implemented in Functest recently:

"Blocking flag" for each test case:
For each test case executed in Functest, there is a flag called "blocking" that 
can be set to True or False. If the test fails and the flag is set 'true', 
Functest will stop the execution of the rest of the tests in the daily loop 
exiting with error. If the test fails but the flag is set to false, it will 
mark the Job as failed, but it will allow the execution of the remaining test 
cases.
https://git.opnfv.org/cgit/functest/tree/ci/testcases.yaml
The purpose of this is to allow the critical test cases like the 
healthcheck/vping be a "gate" or a filter i.e. if you can't create VMs, why 
should you bother in testing sfc or any other feature? Some other tests like 
Tempest, will allow the execution of the preceding tests even though if there 
is a failure.


Summary report:
Some of you gave us some feedback about the confusing output given by Functest 
in Jekins if a job has failed. This has been improved a lot, providing clear 
output messages to understand what is happening. But now you don't even need to 
go through all that output, you just need to scroll  down and at the bottom of 
the page you will see the "Functest report" to check what has worked/failed 
along with some other useful information.
Example here: 
https://build.opnfv.org/ci/job/functest-fuel-baremetal-daily-master/261/console


Black listing tests in Tempest:
If you know that in a certain scenario/installer, a tempest test case fails, 
you can now blacklist the test case in this yaml:
https://git.opnfv.org/cgit/functest/tree/testcases/OpenStack/tempest/custom_tests/blacklist.txt
For example, for bgpvpn we have deactivated the tests that deal with floating 
ips due to lacking support for floating IPs in ODL VPNService (which will be 
fixed in the future).
So, if you know that a known bug will make a test case fail, you can add the 
test in this list and it will be skipped.
NOTE: this is not meant to avoid running tests that fail without a reason. It 
should be justified (known bug, feature lack of support, ...).


You'll see a lot of red in Jenkins, and that's because Functest has become a 
bit more strict when giving the final status. It will only return blue if all 
the tests succeeded according to the defined success criteria, not only if the 
execution of the test script succeeded (even though the test failed).
For example:
https://build.opnfv.org/ci/job/functest-fuel-baremetal-daily-master/261/console
https://build.opnfv.org/ci/job/functest-fuel-baremetal-daily-master/260/console
The exit status is -1 because there was >0 failures in Tempest-smoke, and the 
success criteria for Tempest-smoke is 100%.

This strictness has been changed like this after some feedback collected from 
the community, in particular from the installer teams.



Thanks,

JOSE LAUSUCH
Senior Systems Designer
Ericsson

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

[opnfv-tech-discuss] [Functest] [Tempest] Current status for each installer

[Jose Lausuch]

Hi,

Please find attached a brief report of the Tempest test cases that are failing 
for each installer. I hope this helps as a feedback to the installer and 
feature owners to improve the quality of the deployments and reach the release 
date without errors. Now it's the time to solve as many bugs as we can.

Remember, if you know that a specific test case fails because of a known bug 
that can't be fixed before the Colorado release date, we can always add that 
test to the blacklist so that it's not executed.

@David: it would be nice to track the progress of this. We have a Dashboard 
where we show the status (weather icons) of the test cases per scenario and per 
installer.
http://testresults.opnfv.org/reporting/functest/release/master/index-status-compass.html
It's basically the same thing that I did in those txt's but in an automated 
manner.

Regards,
Jose
RALLY All scenarios: 
   Rally fails in heat, 75.00% success in that scenario
   
TEMPEST:
os-odl_l2-nofeature-ha, os-odl_l3-nofeature-ha, os-onos-sfc-ha

tempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_reboot_server_hard

tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops

tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops

tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern

tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern

odl-nosdn-nofeature-ha
timeout. Last test executed:

tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops

os-odl_l2-sfc-ha
Deployment failure?
No tests run lately

os-odl_l2-bgpvpn-ha
No failures, because the tests that normally fail are 
blacklisted due to lacking support for floating IP in VPN service in ODL.

RALLY All scenarios: 
83.89%  success: 0% in cinder, 75% heat, 80% nova

TEMPEST:
All scenarios:
setUpClass 
(tempest.api.volume.test_volumes_actions.VolumesV1ActionsTest)
setUpClass 
(tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest)

tempest.api.volume.test_volumes_get.VolumesV1GetTest.test_volume_create_get_update_delete

tempest.api.volume.test_volumes_get.VolumesV1GetTest.test_volume_create_get_update_delete_from_image

tempest.api.volume.test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete

tempest.api.volume.test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete_from_image
setUpClass 
(tempest.api.volume.test_volumes_list.VolumesV1ListTestJSON)
setUpClass 
(tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON)

tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern

tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern

os-onos-sfc-ha

tempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_reboot_server_hard

tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops

tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops
RALLY All scenarios: 
100% Success

TEMPEST:
os-nosdn-nofeature-ha, os-odl_l2-nofeature-ha

tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops

os-odl_l3-nofeature-ha

tempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_reboot_server_hard

tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops

tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops

tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern

tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern


os-odl_l2-bgpvpn-ha
no failures

os-odl_l2-sfc-ha
no failures

os-onos-nofeature-ha
No tests run --> Healthcheck fails: ERROR -  The instance 
opnfv-instance4 couldn't get an IP from the DHCP agent.

os-onos-sfc-ha

tempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_reboot_server_hard

tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops


RALLY: 
Not executed so far

TEMPEST:
os-odl_l2-nofeature-ha
   

Re: [opnfv-tech-discuss] Shout out: Julien Zhang

[Jose Lausuch]

+1 

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of DENG Hui
Sent: Thursday, August 18, 2016 10:09 AM
To: morgan.richo...@orange.com; 'Jack Morgan'; 'opnfv-tech-discuss'
Subject: Re: [opnfv-tech-discuss] Shout out: Julien Zhang

+1

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of 
morgan.richo...@orange.com
Sent: Thursday, August 18, 2016 3:47 PM
To: Jack Morgan; opnfv-tech-discuss
Subject: Re: [opnfv-tech-discuss] Shout out: Julien Zhang

+1
Le 18/08/2016 à 00:31, Jack Morgan a écrit :
> OPNFV,
>
> I would like to take a moment to recognize Julien Zhang for his hard 
> work and dedication during this Colorado release cycle. I really 
> appreciate his input even though I as the Pharos PTL didn't provide 
> much direction. Julien worked the JIRA issues in his name and created 
> new ones when needed. He tirelessly focused on getting things done 
> this cycle and even harassed me several times to approve his Gerrit 
> hanges. I hope to be more like him moving forward.
>
> Since Julien is currently a contributor to the Pharos project, I'm 
> going to recommend he be a committer via Gerrit. Please consider his 
> nomination and add your +1 in Gerrit.
>
>
> Thanks,
>


--
Morgan Richomme
Orange/ IMT/ OLN/ CNC/ NCA/ SINA 

Network architect for innovative services Future of the Network community 
member Open source Orange community manager


tel. +33 (0) 296 072 106
mob. +33 (0) 637 753 326
morgan.richo...@orange.com



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
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 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] Q2'2016 OPNFV Quarterly Award Winners

[Jose Lausuch]

Hi,

Thanks a lot for this recognition. I think many other contributors who have 
been working hard deserve this award as well. You are making OPNFV an exciting 
journey. It’s fun working with you!

Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Tuesday, August 23, 2016 23:02 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] Q2'2016 OPNFV Quarterly Award Winners

All,

Here are winners of the Q2'2016 Awards as was announced at the Hackfest earlier 
today.

•   Code Development: Jose Lausuch (repeat winner) & Ulas Kozat
•   Collaboration: Bryan Sullivan
•   Documentation & User Support: Mark Beierl (repeat winner)
•   Integration: Dan Radez & Hongbo Tian
•   Testing: Maryam Tahhan (repeat winner)

Thanks and congratulations to all the winners!

Ray
___
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] [functest] [D release]

[Jose Lausuch]

Hi,

I added a few things in the wiki. Feedback from the community would be great, 
but the Functest specific improvements could be discussed and accepted during 
the Functest face-to-face meetup in France as we did before Colorado. Of 
course, everyone is invited to attend via conference call.

Thanks,
Jose


-Original Message-
From: SULLIVAN, BRYAN L [mailto:bs3...@att.com] 
Sent: Friday, September 23, 2016 17:30 PM
To: morgan.richo...@orange.com; Jose Lausuch; serena feng; OLLIVIER Cédric 
IMT/OLN; Jose Lausuch; Tikkanen, Viktor (Nokia - FI/Espoo); Kosonen, Juha 
(Nokia - FI/Espoo); Gaynor, Colum (Nokia - FI/Espoo); Haapavirta, Juha (Nokia - 
FI/Espoo); Kamsali, Raghavendrachari; Meimei; valentin boucher
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [opnfv-tech-discuss] [OPNFV] [functest] [D release]

Morgan,

That's a big page so I'm not sure where to put this input, but here are some 
things in scope for Danube:

* Models: several new VNFs and VNFM tests, some already listed at 
https://wiki.opnfv.org/display/models/testing. Some of these will be used in 
the Colorado Plugfest - see the "VNF Portability" section on the page 
https://wiki.opnfv.org/display/EVNT/Colorado+Plugfest+Test+Cases. VNFMs will 
include Tacker, Cloudify, OpenBaton, etc. The tests will focus on simple to 
medium-complexity VNFs, specific TOSCA-based resource requirements as supported 
by those VNFMs, and YANG-based application control via ODL.

* VES: Deployment of a VES Hello World VNF, and reference (real) VNFs 
integrated with VES

* Copper: additional policy test cases

Thanks,
Bryan Sullivan | AT&T

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of 
morgan.richo...@orange.com
Sent: Friday, September 23, 2016 8:09 AM
To: Jose Lausuch ; serena feng 
; OLLIVIER Cédric IMT/OLN 
; Jose Lausuch ; 
Tikkanen, Viktor (Nokia - FI/Espoo) ; Kosonen, Juha 
(Nokia - FI/Espoo) ; Gaynor, Colum (Nokia - FI/Espoo) 
; Haapavirta, Juha (Nokia - FI/Espoo) 
; Kamsali, Raghavendrachari 
; Meimei ; valentin 
boucher 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [OPNFV] [functest] [D release]

Hi

based on the discussion initiated during last Functest weekly meeting, I 
created the Danube page for the project.

https://wiki.opnfv.org/display/functest/Functest+Danube

as mentioned in the beginning of the page, this page is a draft

The goal is to collect element to prepare the D release.

Functest evolutions are expected in

- the Functest framework (reflexion on the relations between the test projects 
(API), dockerization, CI evolution, reporting, dashboard)

- new tools and libs

- the new tests (unit, functional, VNF onboarding,...)

If you want to participate to Functest D release feel free to modify the page 
and/or create new pages referenced from this one

You can also obviously use the mailing list or meet us during the weekly 
meeting (Every Tuesday 8 AM UTC #opnfv-functest)

/Morgan


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
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 mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Functest] Project organization

[Jose Lausuch]

Hi,

I think it is a good idea, Morgan. 
Another way to do this would be to have elections after each release (6 month 
cadence) where the PTL can always be re-elected but never more than 2 times in 
a row.

For this election, I also nominate myself as a candidate for Functest PTL.

Thanks,
Jose



-Original Message-
From: morgan.richo...@orange.com [mailto:morgan.richo...@orange.com] 
Sent: Tuesday, September 20, 2016 15:10 PM
To: serena.feng@gmail.com; ollivier.ced...@gmail.com; Jose Lausuch; 
mei...@huawei.com; valentin.bouc...@orange.com; lanqingl...@huawei.com; 
viktor.tikka...@nokia.com; ";juha.kosonen"@nokia.com; zhanghao...@huawei.com; 
raghavendrachari.kams...@hpe.com; lixiaoguang (C)
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: [Functest] Project organization

Hi,

as discussed quickly this morning during our weekly meeting, I would like to 
plan the next Functest PTL election.

My idea for Functest is to call for PTL election every 2 releases.

The PTL will thus be legitimate by the core developpers, it should help 
reflecting the diversity within the project, ease the transition between PTL 
generations and bring new energy and creativity.

I think it makes also sense to put a limit in term of relections => 1 possible 
re-election =  2 mandates = 4 releases = 2 years max per PTL

If no objection from the core developers, I would like to plan the first 
election on the 11th of October 2016 correspoding to Colorado release.
The vote will be done by IRC durung the weekly meeting (8 UTC).
All Functest core devs can vote and if they cannot be present they can delegate 
their vote.

For this election I will be candidate to my reelection :) but other 
candidatures are more than welcome.

/Morgan


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
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] Jose Lausuch is the New Functest PTL

[Jose Lausuch]

Hi,

Thanks Morgan and thank the Functest committers for trusting me on having this 
role, which I am honored to take.

I will put all my energy and try to lead the project as good as Morgan has done 
so far to help it evolve and progress according to our expectative for the 
coming release. Danube is going to be an exciting journey full of new 
challenges with great solutions that will bring quality and maturity to OPNFV.

Best regards,
Jose


 

-Original Message-
From: morgan.richo...@orange.com [mailto:morgan.richo...@orange.com] 
Sent: Tuesday, October 11, 2016 14:01 PM
To: opnfv-...@lists.opnfv.org
Cc: Jose Lausuch; David McBride; opnfv-tech-discuss@lists.opnfv.org
Subject: Jose Lausuch is the New Functest PTL

Hi TSC,

I would like to inform that the Functest project elected this morning his new 
PTL.

We just applied the recommendations we voted in Functest
(https://wiki.opnfv.org/display/functest/Functest+admin)

Jose -  you all know him -  will take the lead of the project.

He has been very active in the project (and not only in Functest...) since Arno 
and has a perfect knowledge of the OPNFV ecosystem.

Eisenhower said "Leadership consists of nothing but taking responsibility for 
everything that goes wrong and giving your subordinates credit for everything 
that goes well."

@José: Do not worry, we already know that most of the things that go well in 
Functest are due to you, so I am sure you will be a great PTL!
And as Liverpool Footbal fans are used to sing: "You will never walk alone..."

I was very happy to PTLize Functest from Arno to Colorado. Still many rivers to 
cross...

I will keep on contributing in Functest in addition of my TSC/Testing 
group/EndUserGroup tasks.

vote is available here:
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-functest/2016/opnfv-functest.2016-10-11-08.01.html
(note I received 4 additional Yes proxies by mail) INFO file has been amended: 
https://gerrit.opnfv.org/gerrit/#/c/22969/
I will ask for the modification of the mailing list to include Jose in PTL 
mailing list (and remove myself)

/Morgan


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
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] CI evolution on impact on test projects

[Jose Lausuch]

Hi,

Although it took a while to go through all your slides and understand them all 
(the 2 big example slides helped a lot), I agree in general with what you 
explain. There are some confusing assumptions like   "if a case(weekly) fails 
=> still weekly loop but daily status" ... but the concept behind sounds like a 
good approach to follow.
We should definitively move to different keywords to latest/daily/weekly. 
Silver/Gold/Platinum sounds good enough, and congratulations for those 
scenarios that get the Platinum badge from Functest because it comprises a lot 
of long tests..

The promotions are performed in a logical way and everything is calculated and 
stored in the central DB. Just some concerns come to my mind:

   - if a couple scenarios (say 3 or 4) are promoted to "Gold", it means that 
they will be running all the tests (weekly loop) in CI (unless there is a 
regression on a daily test if I understand correctly)  ==> each Funtest weekly 
run might take 3-5 hours (say 8 hours for Deploy+Functest+Yardstick) ==> CI 
needs more time to complete an entire installer loop going through all the 
scenarios. Today, in some cases, a scenario takes ~2 days to run again in CI 
(with only daily Functest tests) and some scenarios could be considered 
nowadays as "Gold".. Are we prepared to run weekly tests on so many scenarios? 
Will we be able to do this the weeks before a release?

   - This new logic is very CI-oriented. We also need to bypass it for the case 
that an end user just wants to run all the tests the same way we do now (i.e. 
functest testcase run all). So, the logic has to be implemented in another 
layer on top, not in the test project framework as such. I can imagine a layer 
between CI (Jenkins) and the test project. This layer just tells Functest what 
to execute according to the info in the DB.

Regards,
Jose


-Original Message-
From: morgan.richo...@orange.com [mailto:morgan.richo...@orange.com] 
Sent: Thursday, October 13, 2016 17:12 PM
To: test...@lists.opnfv.org
Cc: Fatih Degirmenci; opnfv-tech-discuss@lists.opnfv.org; serena feng; 
yaohelan; Jose Lausuch
Subject: CI evolution on impact on test projects

Hi,

I took the action point to describe the possible consequences of CI evolution 
on test projects.

Please find attached a pdf detailing what I tried to explain yesterday :)

I will be off next Thursday and will not be able to detail it before Barcelona 
but if you have comments/remarks

I have also the odp and yed files if you want to edit anything

@Kubi could you check Yardstick status info?

If you prefer I can put that on the wiki, but as there are many things to agree 
first (to be sure we are sharing the same view), I prefer to initiate first 
exchanges by mail to converge to a first level of stability.

/Morgan



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
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] Kicking off nominations for Q3'2016 OPNFV Quarterly Awards

[Jose Lausuch]

+1 to all these nominations and I'd like to include Cedric Ollivier to the code 
development category for all the effort put in Functest to improve the quality 
of the code and the framework.

Fatih Degirmenci in the Collaboration category for his CI evolution proposal 
which is a real need in the community and will help us using the resources we 
have in a more efficient way. He is constantly collaborating with the installer 
and testing groups to make this happen.


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of 
morgan.richo...@orange.com
Sent: Friday, October 14, 2016 9:25 AM
To: Raymond Paik; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Kicking off nominations for Q3'2016 OPNFV 
Quarterly Awards

Hi,
·  Code development: Serena Feng (ZTE) for her work on the refactoring ot the 
test api. She consolidated the code, developped the swagger documentation part 
for Tornado (the python web server we are using), dockerize it, add function 
for upgrade of the mongo DB, backup, add unit tests. This API is used to store 
the results, build reporting. It was also used for the plugfest and thanks to 
the dockerization it is easy to deploy such framework on demand.


·  Collaboration (e.g. across different OPNFV projects or with other upstream 
communities): Cedric Ollivier (Orange) for his work on ODL test refactoring and 
his effort to upstream as much as possible. Working upstream is agreed by most 
of us but it is not always concretely easy to do. Cedric succeeded in moving 
code from OPNFV to ODL using it for the Functest ODL test suite. Moreover he 
contributed with josé to the git page in OPNFV to help newcomers and share best 
practice. he is an active, relevant and benevolent reviewer.


·  Documentation & User support: Colum Gaynor and Juha Haapavirta (Nokia), the 
quality of Functest documentation has been greatly improved thanks to them. 
They accepted to initiate documentation early in time and spent lots of time in 
order to reach a "Telco grade" quality


·  Integration: Alexandru Avadanii (ENEA) according to git and gerrit 
statistics one of the most active contributors (other ones got already 
awards...). ENEA is very active since Colorado on Armband but also on testing 
projects. Integration is challenging and they did a great job.


·  Testing: Valentin Boucher (Orange) - I wanted to nominate him last time but 
it was too late. Valentin is still a student but his work on automating a vIMS 
solution within Functest had a real influence on the community. His work was 
showed in OPNFV summit in Berlin and a presentation with Cloudify was also 
selected for openStack Summit Barcelona. His work was also reused by vendors 
for some demos during several summits and/or guidelines for vIMS deployments. 
According to the mailing list threads, vIMS test case was a driver for non 
OPNFV member to install OPNFV. New projects such as models also reused what he 
did. As he is still student, he clearly deserved a recognition.


e 14/10/2016 à 02:52, Raymond Paik a écrit :
All,

It's time for the Q3 Awards.  As a reminder, this is to recognize contributions 
from OPNFV community members in the following categories.
· Code development
· Collaboration (e.g. across different OPNFV projects or with other 
upstream communities)
· Documentation & User support
· Integration
· Testing
In order to give new people opportunities for recognition, the award winners 
from the previous quarter will not be eligible to win the same category 2 
quarters in a row. As a reminder, below are the winners from Q2'2016.
· Code development: Jose Lausuch & Ulas Kozat
· Collaboration: Bryan Sullivan
· Documentation & User Support: Mark Beierl
· Integration: Dan Radez & Hongbo Tian
· Testing: Maryam Tahhan
(So for example, Jose will not be eligible to win the Code development category 
again in Q3. However, he can be a winner for other categories)
If you'd like to nominate someone for any of the 5 areas above, please send me 
the following information by 5pm Pacific Time on October 21st (Friday).
· Name/Company
· Award category
· Brief description of her/his contribution
Once nomination statements are collected, voting will be done by TSC members 
(e.g. on SurveyMonkey). Thanks and let me know if you have any questions.
Ray




___

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




--

Morgan Richomme

Orange/ IMT/ OLN/ CNC/ NCA/ SINA



Network architect for innovative services

Future of the Network community member

Open source Orange community manager





tel. +33 (0) 296 072 106

mob. +33 (0) 637 753 326

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][danube] MS1 - Planning - October 25 (tomorrow)

[Jose Lausuch]

David,

I guess you meant this link for the template:
https://wiki.opnfv.org/display/SWREL/Summary+of+Project+Release+Plans+for+Danube

-Jose-

From: opnfv-project-leads-boun...@lists.opnfv.org 
[mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Monday, October 24, 2016 11:55 AM
To: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV
Cc: Tapio Tallgren
Subject: [opnfv-project-leads] [release][danube] MS1 - Planning - October 25 
(tomorrow)

Team,

Tomorrow (Oct 25) is our MS1 (planning) date for the Danube release.  Please 
complete the release plan for your respective projects.  Also, be sure to 
complete the new planning 
template.
  At this time, I'm still waiting to get the plans for about 1/3 of the 
projects.

Also, I have been neglecting to remind you that our planning milestone includes 
adding planned scenarios to the Danube scenario status 
page.

David

--
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] SFC failures in CI for Colorado 2.0

[Jose Lausuch]

Hi Tim,

Yes, lately sfc test case has been focusing on making the test work on Fuel and 
we might have missed Apex support in the latest patches (adding Manuel and 
Georgios who are doing a great work in that area). We'll work on making it 
installer agnostic for Colorado 3.0 if we can. If you want to save resources, 
the scenario can be deactivated for Apex until we fix that. Another solution is 
to disable the test case for that scenario.

Regards,
Jose


-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 25, 2016 16:10 PM
To: Jose Lausuch; morgan richomme
Cc: TECH-DISCUSS OPNFV
Subject: [functest][sfc][apex] SFC failures in CI for Colorado 2.0

Hi Jose, Morgan,

I see errors during the CI run (including a fuel command):

bash: fuel: command not found
Warning: Permanently added '192.168.122.150' (ECDSA) to the list of known hosts.
Warning: Permanently added '192.168.122.150' (ECDSA) to the list of known hosts.
cp: cannot stat ‘:/root/tackerc’: No such file or directory
2016-10-24 08:02:42,248 - ODL_SFC - INFO - The presetup of the server worked 
Traceback (most recent call last):
  File "/home/opnfv/repos/functest/testcases/features/sfc/prepare_odl_sfc.py", 
line 73, in 
output = stdout.readlines()
NameError: name 'stdout' is not defined
2016-10-24 08:02:44,702 - functest_utils - ERROR - The command 
'/home/opnfv/repos/functest/ci/exec_test.sh -t odl-sfc -r' failed.

It looks like in prepare_odl_sfc.py is only for Fuel to do some presetup.  Is 
that correct?

Tim Rozet
Red Hat SDN Team
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Functest Danube meeting at OpenStack summit

[Jose Lausuch]

Hi,

For those who will attend the Functest Danube release planning tomorrow 
(9-13h), we will be meeting at 9:00 at the OPNFV booth first and will head to 
the area behind the black curtains in the Marketplace hall.

-Jose-
___
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 Danube meeting at OpenStack summit

[Jose Lausuch]

We are meeting at the back of the cafeteria next to the market place at one of 
the round tables.
Jose

From: Jose Lausuch
Sent: Tuesday, October 25, 2016 23:58 PM
To: Morgan Richomme (morgan.richo...@orange.com); OLLIVIER Cédric IMT/OLN 
(cedric.olliv...@orange.com); BLAISONNEAU David RD-CORE-LAN 
(david.blaisonn...@orange.com); feng.xiao...@zte.com.cn; Kosonen, Juha (Nokia - 
FI/Espoo) (juha.koso...@nokia.com); 'yaohe...@huawei.com'
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Functest Danube meeting at OpenStack summit

Hi,

For those who will attend the Functest Danube release planning tomorrow 
(9-13h), we will be meeting at 9:00 at the OPNFV booth first and will head to 
the area behind the black curtains in the Marketplace hall.

-Jose-
___
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] scenarios and common config files

[Jose Lausuch]

Hi,

Both proposals are excellent and are a step forward to improve our CI and Infra.

I would like to propose the creation of a relational database for infra related 
topics to store this kind of information. This would allow us to interact with 
this data in many ways and create additional tools. Some ideas that come to my 
mind are for example:

-  Generate these yaml files out of the info stored in the DB

-  Create a REST API to interact with the DB --> projects can benefit 
of having this info in a central place callable from a rest api instead of 
parsing a yaml

-  Dynamic POD allocation tools can also consume this DB

-  Connect the booking dashboard tool to this Database

-  Create a portal for Pharos where we show the pods information in a 
nice way and lab owners can create/modify/remove anything. We already have a 
draft of this feature in the Pharos booking tool that Max is developing 
(examples below), and I’d like to avoid duplicating the information and 
maintain it in different places.
https://wiki.opnfv.org/display/INF/Dashboard+User+Guide?preview=/6823302/7769776/admin-resource.png
https://wiki.opnfv.org/display/INF/Dashboard+User+Guide?preview=/6823302/7769777/admin-server.png

Thanks,
Jose


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jack Morgan
Sent: Friday, October 28, 2016 6:17 AM
To: opnfv-tech-discuss
Cc: TSC OPNFV
Subject: [opnfv-tech-discuss] [Infra] scenarios and common config files

OPNFV,

The Infra WG had a working F2F meeting[0] at the OpenStack Summit yesterday. We 
specifically were looking to solve two main issues[1]. Once we get some 
feedback from the community on the proposals to solve these two problems, we 
will be asking the TSC to vote on the changes we propose below (the week of 
Nov. 8th).

Scenarios
The current naming strategy for scenarios is not able to scale as the number of 
scenarios grows. In addition, it doesn't include information such as operating 
system or scenario owner that are import. We came up with a scenario 
description yaml file that should be able to solve the limitations of our 
current naming strategy. The initial proposal has committed to the Pharos git 
tree (see gerrit commit below). We need as many as possible to review this file 
and provide feedback.

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


Common configuration files
Each installer has its own strategy for deploying OPNFV onto an OPNFV POD. 
There has been an effort to come up with a common configuration file that all 
installers use for deployments for more then 18 months. We came up with a 
proposal to define what should be included in this file based on the current 
files that installers use. Again, we need lots of feedback on our proposal (see 
gerrit commit below)

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


[0] 
https://wiki.opnfv.org/display/INF/OpenStack+Summit+2016+Barcelona+-+F2F+Session+Topics
[1[ https://etherpad.opnfv.org/p/barcelona-infra-f2f


The Infra WG PTLs,

Jack Morgan (pharos)
Fatih Degirmenci (releng)
Ulrich Kleber (octopus)
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Functest weekly sync meeting

[Jose Lausuch]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Romance Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Jose Lausuch:MAILTO:jose.laus...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=opnfv-tec
 h-disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
DESCRIPTION;LANGUAGE=en-US:Time: 8am UTC\, 9am(CET)\, 4pm(CST)\n\nOnly IRC\
 n\nAgenda: https://wiki.opnfv.org/display/functest/Functest+Meeting\n\n\n\n
RRULE:FREQ=WEEKLY;UNTIL=20170331T07Z;INTERVAL=1;BYDAY=TU;WKST=MO
SUMMARY;LANGUAGE=en-US:Functest weekly sync meeting
DTSTART;TZID=Romance Standard Time:20161108T09
DTEND;TZID=Romance Standard Time:20161108T10
UID:04008200E00074C5B7101A82E008A03F3701F532D201000
 01000E89D29AFEEC285499EACD620AF2D551D
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161030T204423Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:#opnfv-testperf
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:-618747936
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DISALLOW-COUNTER:TRUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
___
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] [yardstick] Client version can't support Newton

[Jose Lausuch]

Hi,

We are aware of that and are in the process of supporting Newton in Functest.
Related JIRA Epic:
https://jira.opnfv.org/browse/FUNCTEST-528

Basically, there are 2 actions the test projects need to do:

1)  Upgrade the OpenStack python clients (pip install --upgrade ...)

2)  Update the module version that is imported in the code (from 
neutronclient.v3_0 import client)

I have created a wiki collecting this information to align in what we are 
installing in our Docker image
https://wiki.opnfv.org/display/functest/OpenStack+python+clients
Feel free to provide feedback.


JOSE LAUSUCH
Senior Systems Designer
Ericsson



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Beierl, Mark
Sent: Friday, November 11, 2016 16:16 PM
To: liyuenan
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't 
support Newton

Hello,

This does raise an interesting dilemma: a project often will use the Python API 
directly, which means a change from v2 to v3 is a code change, not a runtime 
configuration change.  Therefore at the moment, this is not something that is 
selectable per installer.

I know for StorPerf, this is definitely the case, and I think I will need to 
propose a change where the client and API to use is dynamically selectable 
based on a configuration file.

Does any project have such code already?

Regards,
Mark

Mark Beierl
Advisory Solutions Architect
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Nov 11, 2016, at 02:58, liyuenan 
mailto:liyue...@huawei.com>> wrote:

Hi everyone!

Compass4nfv can deploy Newton now, but could not test it by yardstick or 
functest because of API version.
Newton deployed by compass4nfv use the API v3 to instead of API v2.0.

So I think yardstick and functest should update client version to support 
Newton.

Error log is in attachment. And you can deploy Newton by compass4nfv.

Best Regards!
Yuenan Li

___
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

Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't support Newton

[Jose Lausuch]

Hi,

That is something to be tested. I don’t know yet. We had some problems with 
version in the past, that’s why we hard-code some client versions in the import 
commands.

We created this task https://jira.opnfv.org/browse/FUNCTEST-529   to keep track 
of that upgrade. Helen Yao will be our hero for that activity.


JOSE LAUSUCH
Senior Systems Designer
Ericsson


From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Friday, November 11, 2016 16:32 PM
To: Jose Lausuch
Cc: liyuenan; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't 
support Newton

Hello, Jose.

Question - what about the transitional state where some installers are still on 
v2?  Will the v3 client still work?

Regards,
Mark

Mark Beierl
Advisory Solutions Architect
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Nov 11, 2016, at 10:26, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

Hi,

We are aware of that and are in the process of supporting Newton in Functest.
Related JIRA Epic:
https://jira.opnfv.org/browse/FUNCTEST-528

Basically, there are 2 actions the test projects need to do:
1)  Upgrade the OpenStack python clients (pip install --upgrade …)
2)  Update the module version that is imported in the code (from 
neutronclient.v3_0 import client)

I have created a wiki collecting this information to align in what we are 
installing in our Docker image
https://wiki.opnfv.org/display/functest/OpenStack+python+clients
Feel free to provide feedback.


JOSE LAUSUCH
Senior Systems Designer
Ericsson



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 Beierl, Mark
Sent: Friday, November 11, 2016 16:16 PM
To: liyuenan
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't 
support Newton

Hello,

This does raise an interesting dilemma: a project often will use the Python API 
directly, which means a change from v2 to v3 is a code change, not a runtime 
configuration change.  Therefore at the moment, this is not something that is 
selectable per installer.

I know for StorPerf, this is definitely the case, and I think I will need to 
propose a change where the client and API to use is dynamically selectable 
based on a configuration file.

Does any project have such code already?

Regards,
Mark

Mark Beierl
Advisory Solutions Architect
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Nov 11, 2016, at 02:58, liyuenan 
mailto:liyue...@huawei.com>> wrote:

Hi everyone!

Compass4nfv can deploy Newton now, but could not test it by yardstick or 
functest because of API version.
Newton deployed by compass4nfv use the API v3 to instead of API v2.0.

So I think yardstick and functest should update client version to support 
Newton.

Error log is in attachment. And you can deploy Newton by compass4nfv.

Best Regards!
Yuenan Li

___
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

Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't support Newton - solution proposal

[Jose Lausuch]

  Identify the all scenarios that we are leveraging clients
2.Test with OpenStackClient to make sure all scenarios can be fulfilled
Risks/Challenges
1. Functest and Yardstick are mainly using components including Nova, Keystone, 
Neutron, Heat, etc. OpenStackClient provides a shell.py to wrapping the call 
into CLI and it seems that this way provides almost every possible alternatives 
to our currently implementation. However, if we wants to import openstackclient 
as module in the code, heat might be lost and we have to implement the logic to 
support calling different version of heatclient.
2. The learning curve might be long as it requires developers to map all of 
current implementation to openstackclient.

Idea 2: Design the logic to handle different clients
Areas to investigate
1.Come up with the client list for different OpenStack version
2.Put the client requirements into separate configuration per OpenStack 
version
3.Dynamically decide which configuration to use
Risks/Challenges
1. A wise and general architecture is required as more OpenStack upgrades are 
expected

[1] https://github.com/openstack/python-openstackclient



发件人: Jose Lausuch [mailto:jose.laus...@ericsson.com]
发送时间: 2016年11月11日 23:43
收件人: Beierl, Mark mailto:mark.bei...@dell.com>>; yaohelan 
mailto:yaohe...@huawei.com>>
抄送: liyuenan mailto:liyue...@huawei.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: RE: [opnfv-tech-discuss] [functest] [yardstick] Client version can't 
support Newton

Hi,

That is something to be tested. I don’t know yet. We had some problems with 
version in the past, that’s why we hard-code some client versions in the import 
commands.

We created this task https://jira.opnfv.org/browse/FUNCTEST-529   to keep track 
of that upgrade. Helen Yao will be our hero for that activity.


JOSE LAUSUCH
Senior Systems Designer
Ericsson


From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Friday, November 11, 2016 16:32 PM
To: Jose Lausuch
Cc: liyuenan; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't 
support Newton

Hello, Jose.

Question - what about the transitional state where some installers are still on 
v2?  Will the v3 client still work?

Regards,
Mark

Mark Beierl
Advisory Solutions Architect
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Nov 11, 2016, at 10:26, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

Hi,

We are aware of that and are in the process of supporting Newton in Functest.
Related JIRA Epic:
https://jira.opnfv.org/browse/FUNCTEST-528

Basically, there are 2 actions the test projects need to do:
1)  Upgrade the OpenStack python clients (pip install --upgrade …)
2)  Update the module version that is imported in the code (from 
neutronclient.v3_0 import client)

I have created a wiki collecting this information to align in what we are 
installing in our Docker image
https://wiki.opnfv.org/display/functest/OpenStack+python+clients
Feel free to provide feedback.


JOSE LAUSUCH
Senior Systems Designer
Ericsson



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 Beierl, Mark
Sent: Friday, November 11, 2016 16:16 PM
To: liyuenan
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't 
support Newton

Hello,

This does raise an interesting dilemma: a project often will use the Python API 
directly, which means a change from v2 to v3 is a code change, not a runtime 
configuration change.  Therefore at the moment, this is not something that is 
selectable per installer.

I know for StorPerf, this is definitely the case, and I think I will need to 
propose a change where the client and API to use is dynamically selectable 
based on a configuration file.

Does any project have such code already?

Regards,
Mark

Mark Beierl
Advisory Solutions Architect
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Nov 11, 2016, at 02:58, liyuenan 
mailto:liyue...@huawei.com>> wrote:

Hi everyone!

Compass4nfv can deploy Newton now, but could not test it by yardstick or 
functest because of API version.
Newton deployed by compass4nfv use the API v3 to instead of API v2.0.

So I think yardstick and functest should update client version to support 
Newton.

Error log is in attachment. And you can deploy Newton by compass4nfv.

Best Regards!
Yuenan Li

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

Re: [opnfv-tech-discuss] one issue for kingbird functest Re: About kingbird OpenStack clients dependency ... RE: OpenStack python Clients in Functest

[Jose Lausuch]

Hi,

I would like to avoid modifying a requirements file in the Dockerfile. That is 
not self-maintainable… What we can do is to clone the right tag from the 
kingbird repository. Currently we are cloning KINGBIRD_TAG=0.2.2  , would it 
work if we clone an earlier version of it? Can you point me to the right one?

Regards,

JOSE LAUSUCH
Senior Systems Designer
Ericsson



From: joehuang [mailto:joehu...@huawei.com]
Sent: Friday, November 18, 2016 4:06 AM
To: Jose Lausuch; morgan.richo...@orange.com; cedric.olliv...@orange.com; 
yaohelan; feng.xiao...@zte.com.cn; Steven Pisarski; Dimitri Mazmanov; Ashish 
Singh
Cc: Manuel Buil; geo...@intracom-telecom.com; r...@intracom-telecom.com; 
opnfv-tech-discuss
Subject: RE: one issue for kingbird functest Re: About kingbird OpenStack 
clients dependency ... RE: OpenStack python Clients in Functest

Hello, Jose,

Consider that Functest is integrating Newton release of OpenStack, if the 
dockfile installs the latest master branch of Kingbird, obviously the client 
version will be conflict with each other, since the master branch of Kingbird 
will update the requirements to the latest client version constantly.

And I checked that Functest will support different release of client library 
with fixed version:

python-openstackclient==2.3.0   # Mitaka
python-keystoneclient==3.6.0# Ocata
python-neutronclient==4.1.1 # Mitaka
python-ceilometerclient==1.5.1  # Liberty

But non-tag or release of Kingbird have this odd client requirements. But it's 
possible to re-enable kingbird in functest like this:


git clone https://github.com/openstack/kingbird.git && cd kingbird/



then modify the requirements.txt in kingbird folder, update the requirements 
for the client to Fuctest's common requirements on client library.


After that, then run following command to install kingbird tempest plugin, and 
enable the test of kingbird.

RUN cd ${repos_dir}/kingbird && pip install -e .


---

On the other hand, I would suggest to use same release of OpenStack client, or 
install each functest modules like kingbird into separate venv.

Best Regards
Chaoyi Huang (joehuang)
________
From: Jose Lausuch [jose.laus...@ericsson.com]
Sent: 13 November 2016 20:21
To: joehuang; morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>; 
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; yaohelan; 
feng.xiao...@zte.com.cn<mailto:feng.xiao...@zte.com.cn>; Steven Pisarski; 
Dimitri Mazmanov; Ashish Singh
Cc: Manuel Buil; 
geo...@intracom-telecom.com<mailto:geo...@intracom-telecom.com>; 
r...@intracom-telecom.com<mailto:r...@intracom-telecom.com>
Subject: RE: one issue for kingbird functest Re: About kingbird OpenStack 
clients dependency ... RE: OpenStack python Clients in Functest
Hi,

Ok. We can re-enable kingbird installation in the container. Please point me to 
the right version we should fetch and I will include it again after doing local 
testing of the build process.

Thanks,


JOSE LAUSUCH
Senior Systems Designer
Ericsson



From: joehuang [mailto:joehu...@huawei.com]
Sent: Saturday, November 12, 2016 3:50 AM
To: Jose Lausuch; 
morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>; 
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; yaohelan; 
feng.xiao...@zte.com.cn<mailto:feng.xiao...@zte.com.cn>; Steven Pisarski; 
Dimitri Mazmanov; Ashish Singh
Cc: Manuel Buil; 
geo...@intracom-telecom.com<mailto:geo...@intracom-telecom.com>; 
r...@intracom-telecom.com<mailto:r...@intracom-telecom.com>
Subject: one issue for kingbird functest Re: About kingbird OpenStack clients 
dependency ... RE: OpenStack python Clients in Functest

I just noticed one issue will happen if the
kingbird install was removed in functest
container: the kingbird tempest plugin will
not be able to be discovered by tempest, so
the functest for kingbird will also not happen
again.

Sent from HUAWEI AnyOffice
发件人：黄朝意
收件人：Jose 
Lausuch,morgan.richo...@orange.com,cedric.olliv...@orange.com,yaohelan,feng.xiao...@zte.com.cn,Steven
 Pisarski,Dimitri Mazmanov,Ashish Singh,
抄送：Manuel Buil,Georgios Paraskevopoulos 
(geo...@intracom-telecom.com),Skiadas<mailto:geo...@intracom-telecom.com),Skiadas>
 Romanos (r...@intracom-telecom.com<mailto:r...@intracom-telecom.com>),
时间：2016-11-12 10:11:25
主题:About kingbird OpenStack clients dependency ... RE: OpenStack python Clients 
in Functest

Hello, Jose,

Currently, the master branch Functest of multisite CI job in OPNFV always get 
the latest version of Kingbird, and install regarding dependency, which means 
kingbird will install the ongoing developed Ocata openstack client dependency, 
and leads to break the other module's dependency if no Venv is used.

I think Kingbird stable Newton version can be used instead the in OPNFV 
functest, or install kingbird in Venv to avoid the dependency chao

Re: [opnfv-tech-discuss] [functest][netready] Gluon integration test strategy

[Jose Lausuch]

Hi Georg,

Thanks for the description, exactly what we were expecting :)

I created this JIRA ticket and assigned to you 
https://jira.opnfv.org/browse/FUNCTEST-578 just to help us tracking what it is 
going to be integrated in Functest from OPNFV feature projects.  If you have 
already a JIRA for this in the Netready project is also ok, it can be linked. 

Can I use the name "netready-vping" to create a new entry in our DataBase?


Regards,

JOSE LAUSUCH 
Senior Systems Designer 
Ericsson






-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Georg Kunz
Sent: Friday, November 18, 2016 9:53 AM
To: opnfv-tech-discuss@lists.opnfv.org
Cc: thomas.hamble...@nokia.com
Subject: [opnfv-tech-discuss] [functest][netready] Gluon integration test 
strategy

Dear NetReady folks,
dear Functest people,

I've created a wiki page with the test strategy planning for the Gluon 
integration for the Danube release. Please have a look and review:
https://wiki.opnfv.org/display/netready/Test+Strategy

Best regards
Georg
___
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 Addition for Barometer

[Jose Lausuch]

Hi Calin,

I think this is more than enough. It would be appreciated if you create a wiki 
page with this information, so that we can link it from JIRA/gerrit if needed.

About the procedure you have described, point 2 is not needed. We are trying to 
get rid of exec_tests.sh in Danube and use all python module calls. With 
regards to the High Level Testing Procedure, where is collected.conf located? 
In the controller nodes? Will the test case need to collect information 
directly from the deployment?

Thanks,
Jose




> On 22 Nov 2016, at 20:25, Gherghe, Calin  wrote:
> 
> Hi again Jose
> 
> Thanks so much for your help.  Please find attached the doc that describes 
> our proposal.  Essentially it's about a test-suite covering all the collectd 
> plugins related to the Barometer project.  Hoping this submission is timely 
> (per the milestones schedule) and the content is appropriate for MS2, but 
> we're looking forward for feedback from you and the tech group.  We'll 
> respond and/or adjust the doc as needed based on input received, and then 
> commit to follow the process further under your guidance.
> 
> Thanks again.  Calin
> 
> -Original Message-
> From: Jose Lausuch [mailto:jose.laus...@ericsson.com] 
> Sent: Thursday, October 20, 2016 5:25 AM
> To: Gherghe, Calin ; Morgan Richomme 
> 
> Cc: Tahhan, Maryam 
> Subject: RE: Functest Addition
> 
> Hi Calin,
> 
> New tests are welcome, especially if they are not "touching" an area we 
> haven't worked before as it is the case. 
> 
> Do you have a description about the test case? We are still on time to decide 
> what is going to be part of the release and we would like to have the 
> complete overview next week during the Functest meetup in Barcelona. If you 
> or any of your colleagues are attending the summit, we could have a talk 
> about this, but in principle I don't see any problem.
> 
> Timeline is dictated by the release milestones: 
> https://wiki.opnfv.org/display/SWREL/Danube+Milestone+Description
> And looking at the schedule, 
> https://wiki.opnfv.org/display/SWREL/Danube?preview=/6827418/7768700/OPNFV%20Release%20%2522D%2522%20r3.pdf
>  you have until 11/22/16 (MS21) to provide this information to us, so plenty 
> of time :)
> 
> The requirements are basically that you would have to adapt and use the tools 
> that libraries that the Functest framework provides. Of course we would be 
> happy to help and guide you through the process.
> 
> I can include this as an agenda topic for our weekly meeting in 2 weeks (next 
> week is cancelled due the summit). 
> 
> Thanks,
> 
> JOSE LAUSUCH
> Senior Systems Designer
> Ericsson
> 
> 
> 
> 
> 
> -Original Message-
> From: Gherghe, Calin [mailto:calin.gher...@intel.com] 
> Sent: Thursday, October 20, 2016 8:37 AM
> To: Jose Lausuch; Morgan Richomme
> Cc: Tahhan, Maryam
> Subject: Functest Addition
> 
> Hello Jose and Morgan
> 
> My name is Calin, engineer at Intel, working within a larger team lead by 
> Maryam (cc-ed), focused on the 'Collectd Ceilometer Plugin'.   We'd like to 
> introduce to you our intent of adding a Functest test-suite related to this 
> plugin into the OPNFV D Release. We think it will likely be a "Feature" test, 
> named FastPathMetrics.
> 
> Please advise about the process (steps, requirements, timeline, etc) to make 
> this happen.  Any pointers would be greatly appreciated.  Also willing to 
> join any support-group as you may recommend. 
> 
> Thank you in advance for your guidance.
> 
> Calin
> 

___
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] [Yardstick] Test Results API (testresults.opnfv.org/test/api) Documentation

[Jose Lausuch]

Hi Mark,

If you want to post results you need:

1) Project declarated in the DB. Done for Storperf: 
http://testresults.opnfv.org:80/test/api/v1/projects/storperf
2) Declare test cases under the project. Currently 1 test for Storperf: 
http://testresults.opnfv.org:80/test/api/v1/projects/storperf/cases

Once that is done, you need to do a call to the test api from your code. This 
is an example using python:
https://git.opnfv.org/functest/tree/functest/utils/functest_utils.py#n185


The api is on http://testresults.opnfv.org/test/api/v1 and this is the model 
schema you need to post a result:

{
  "project_name": "",
  "scenario": "",
  "stop_date": “",
  "case_name": "",
  "build_tag": "",
  "version": "",
  "pod_name": "",
  "criteria": "",
  "installer": "",
  "start_date": "",
  "details": ""
}

Serena can help out since she is in charge of the API/DB.

Regards,
Jose



> On 22 Nov 2016, at 22:36, Beierl, Mark  wrote:
> 
> Hello,
> 
> Sorry for misplacing the email, but I know someone sent out information on 
> the test results API being refactored quite a number of months ago.  Where 
> can I find the latest documentation on how to post results?
> 
> Regards,
> Mark
> 
> Mark Beierl
> Advisory Solutions Architect
> Dell EMC | Office of the CTO
> mobile +1 613 314 8106
> mark.bei...@dell.com
> 
> ___
> 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] [Yardstick] Test Results API (testresults.opnfv.org/test/api) Documentation

[Jose Lausuch]

Hi Mark,


As far as I can tell, intel-pod9 is declared.
http://testresults.opnfv.org:80/test/api/v1/pods/intel-pod9

It could be also that the test case name you are using is not declared. I see 
only a test case named "storperf" in the DB:
http://testresults.opnfv.org/test/api/v1/projects/storperf


Regards,
Jose


From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Wednesday, November 23, 2016 15:11 PM
To: RICHOMME Morgan IMT/OLN
Cc: Jose Lausuch; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Functest] [Yardstick] Test Results API 
(testresults.opnfv.org/test/api) Documentation

Thank you.  That is the document I was looking for.

>From that I found out that intel-pod9 is not registered as a pod, and that is 
>why I was getting the 404 when doing the HTTP POST.

Regards,
Mark

Mark Beierl
Advisory Solutions Architect
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Nov 23, 2016, at 01:49, 
morgan.richo...@orange.com<mailto:morgan.richo...@orange.com> wrote:

Do not hesitate to use the swagger interface described in 
http://artifacts.opnfv.org/functest/docs/devguide/index.html

There are discussions on the etherpad on the evolution of the data model, feel 
free to contribute

/Morgan



Envoyé de mon Galaxy Note 4 d'Orange


 Message d'origine 
De : Jose Lausuch mailto:jose.laus...@ericsson.com>>
Date : 22/11/2016 23:59 (GMT+01:00)
À : Mark Beierl mailto:mark.bei...@dell.com>>
Cc : 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Objet : Re: [opnfv-tech-discuss] [Functest] [Yardstick] Test Results API 
(testresults.opnfv.org/test/api<http://testresults.opnfv.org/test/api>) 
Documentation
Hi Mark,

If you want to post results you need:

1) Project declarated in the DB. Done for Storperf: 
http://testresults.opnfv.org:80/test/api/v1/projects/storperf<http://testresults.opnfv.org/test/api/v1/projects/storperf>
2) Declare test cases under the project. Currently 1 test for Storperf: 
http://testresults.opnfv.org:80/test/api/v1/projects/storperf/cases<http://testresults.opnfv.org/test/api/v1/projects/storperf/cases>

Once that is done, you need to do a call to the test api from your code. This 
is an example using python:
https://git.opnfv.org/functest/tree/functest/utils/functest_utils.py#n185


The api is on http://testresults.opnfv.org/test/api/v1 and this is the model 
schema you need to post a result:

{
  "project_name": "",
  "scenario": "",
  "stop_date": "",
  "case_name": "",
  "build_tag": "",
  "version": "",
  "pod_name": "",
  "criteria": "",
  "installer": "",
  "start_date": "",
  "details": ""
}

Serena can help out since she is in charge of the API/DB.

Regards,
Jose



> On 22 Nov 2016, at 22:36, Beierl, Mark 
> mailto:mark.bei...@dell.com>> wrote:
>
> Hello,
>
> Sorry for misplacing the email, but I know someone sent out information on 
> the test results API being refactored quite a number of months ago.  Where 
> can I find the latest documentation on how to post results?
>
> Regards,
> Mark
>
> Mark Beierl
> Advisory Solutions Architect
> Dell EMC | Office of the CTO
> mobile +1 613 314 8106
> mark.bei...@dell.com<mailto:mark.bei...@dell.com>
>
> ___
> 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

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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] [SFC] Meeting minutes, Nov 23, 2016

[Jose Lausuch]

Hi,

I would recommend following a similar approach to SDNVPN repo:
https://git.opnfv.org/sdnvpn/tree/test/functest

Where we define a config file testcases.yaml to define test-related parameters, 
a script run_tests.py that triggers the test cases and a different script for 
the each test case.

Once that is done, we will immediately merge this  
https://gerrit.opnfv.org/gerrit/#/c/24757/

One thing to take into consideration for this refactor is to implement all the 
pre-steps that are currently defined in exec_tests.sh 
https://gerrit.opnfv.org/gerrit/#/c/24757/6/functest/ci/exec_test.sh
Such as creating the security groups or running  prepare_odl_sfc.py


Thanks,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Vijayendra 
Radhakrishna
Sent: Wednesday, November 23, 2016 17:24 PM
To: Manuel Buil
Cc: OPNFV Tech
Subject: Re: [opnfv-tech-discuss] [SFC] Meeting minutes, Nov 23, 2016

SFC-54  Adapt to new way of calling tests in functest Task
I would like to work on above if Juan Vidal is fine with it. I can take SFC-55 
if not SFC-54

Regards,
VIjay

On Wed, Nov 23, 2016 at 9:43 PM, Manuel Buil 
mailto:manuel.b...@ericsson.com>> wrote:
Hi,

Here are the slides I showed:

https://docs.google.com/presentation/d/1Fgo0TBZD6scQg1RKbBCoYzVu_2bPqyjGM2y_ZpkVa6w/edit#slide=id.p

And here the EPIC in Jira:

https://jira.opnfv.org/browse/SFC-49

having the following tasks that we discussed today:

SFC-51  Document the test case  Task
SFC-52  Update the SFC repo Task
SFC-53  Implement the symmetry test case Task
SFC-54  Adapt to new way of calling tests in functest Task
SFC-55  Implement the two or more SF in different computes test caseTask

Who would like to help? I can already take SFC-51 as I can reuse the slides I 
created. I would also like to take either SFC-53 or SFC-55. @Juan Vidal: You 
wanted to take SFC-54 right?

Regards,
Manuel


-Original Message-
From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 On Behalf Of Brady Allen Johnson
Sent: Wednesday, November 23, 2016 4:51 PM
To: OPNFV Tech 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: [opnfv-tech-discuss] [SFC] Meeting minutes, Nov 23, 2016


http://ircbot.wl.linuxfoundation.org/meetings/opnfv-sfc/2016/opnfv-sfc.2016-11-23-15.00.html


___
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 mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [functest] Functest healthcheck error log

[Jose Lausuch]

Hi,

We are aware of it and we know the root cause. It's being addressed currently.
Thanks for the feedback.

Regards,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of liyuenan
Sent: Tuesday, December 06, 2016 19:23 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [functest] Functest healthcheck error log

Hi all

I found after 10:00 December 6, 2016(BeiJing time), functest can't run 
healthcheck. There is the error log.

By the way, when could functest support API v3?

Best Regards!
Yuenan Li

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

Re: [opnfv-tech-discuss] [SDNVPN test Case fail criteria

[Jose Lausuch]

+1 to disable (not remove) tests that don't work due to upstream missing 
functionality. The problem is: how do we show the upstream community that it 
fails and we would like to use that?

+1 to remove release criteria from all the test cases in sdnvpn, which is the 
same as requiring 100% success for all of them.

Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Skiadas Romanos
Sent: Monday, December 05, 2016 4:34 AM
To: Nikolas Hermanns; BV Guravareddy; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [SDNVPN test Case fail criteria

So make all test cases require 100% success and only do separation testing in a 
specific test that will be disabled?


From: Nikolas Hermanns [mailto:nikolas.herma...@ericsson.com]
Sent: Monday, December 05, 2016 10:49 AM
To: Skiadas Romanos; BV Guravareddy; 
opnfv-tech-discuss@lists.opnfv.org
Subject: [SDNVPN test Case fail criteria


1.   We need to change the 75% test criteria for all test. That just makes 
thing more complicated. Can we copy the tests we have an rewrite them so that 
we don't need the criteria? Then we disable the first test and run them when 
the bug is fixed upstream.

2.   I think we should add a small check in the meta data of the VM is it 
got a ip. Greping for it or something similar. Or checking if it has at least a 
route to send the ping on. If it doesn't then we fail in any case. For a /24 ip 
to ping it would be something like:

a.   [[ $(route -n|awk '{print $1}') == *"192.168.122.0"* ]];
BR Nikolas

From: Skiadas Romanos [mailto:r...@intracom-telecom.com]
Sent: Friday, December 02, 2016 4:04 PM
To: BV Guravareddy
Cc: Nikolas Hermanns
Subject: RE: test Case fail criteria

The problem is that a VM not getting IP is not our issue per se. It causes us 
problems, but what we test is VPN connectivity.
We could have an assertion before each test that all the VMs must get an IP and 
then fail all of them, but then we fail to check if the VMs that got IPs had 
the correct VPN connectivity.

We could fail all the tests the specific VM participates in.
Eg. Vm1 doesn't get an IP, we should fail:
- Vm1 can ping vm2
- Vm1 cannot ping vm2
But not vm2 can ping vm2.

I think the first would be the easiest thing to implement but I don't know 
which is the saner thing to do. I've cc'd Niko so he can have a say in this.

In most tests we have 75% success criteria because isolation doesn't work. So 
one flipped fail and one flipped pass would still give the same success %, 
causing the overall tests to pass.

BR,
Romanos
From: BV Guravareddy [mailto:bv.guravare...@ericsson.com]
Sent: Friday, December 02, 2016 1:43 PM
To: Skiadas Romanos
Subject: test Case fail criteria

Hi Rom,

I have seen that some test cases are not having proper check for pass/fail 
Criteria. Please see the examples below.


1.   DHCP is not working, so instances will not get an IP address.

2.   Ping of VM-1 to VM-2  will not be success.

3.   But scenario like VM-1 should not be ping-able from VM-2 will PASS. 
Without even having  an IP address.  My suggestion is to Fail ALL test cases if 
VM is not having an IP address.

I am sure, we have success criteria of 100%. So it should not be an issue. 
Please feel free to  suggest.

Thanks & Regards,
Venkata Guravareddy.

___
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][apex] New smoke tests in master verify

[Jose Lausuch]

Hi,

"master" tag is no longer used. I will remove that tag from Docker hub.

Now:
"latest" belongs to master branch, overwritten after each docker build.
"stable" belongs to the current stable branch, overwritten after each docker 
build.

The docker build jobs are triggered every 30 min window, and only if there are 
new changes in the repo.
https://git.opnfv.org/releng/tree/jjb/releng/opnfv-docker.yml#n85

Triggering a job directly after a merge could cause troubles. 30 minutes is 
quite fair considering that the build process takes ~15-20 min.

-Jose-


-Original Message-
From: morgan.richo...@orange.com [mailto:morgan.richo...@orange.com] 
Sent: Tuesday, December 13, 2016 11:13 AM
To: Tim Rozet
Cc: Jose Lausuch; OPNFV Tech Discussion; Steven Pisarski
Subject: Re: [functest][apex] New smoke tests in master verify

Le 13/12/2016 à 02:30, Tim Rozet a écrit :
> Hi Morgan,
> Thanks for the patch to move those tests.  Also it is great to see the 
> integration of Steve's framework!
>
> On our latest verify we see that it is still running those tests.  Is that 
> because we have to wait for a new functest container to be built?  If so, 
> when does that get built?
in theory some minutes after the merge...so it should be included now..
but we may have change the way we build the docker...(I can see onlu latest one 
day ago and master 15 days ago) Jose any idea?

strange in
https://build.opnfv.org/ci/job/functest-apex-apex-verify-master-suite-master/736/console
I can see that it is still run
however this run is post merge
https://build.opnfv.org/ci/job/functest-apex-apex-verify-master-suite-master/736/



>
> https://build.opnfv.org/ci/job/apex-verify-master/2033/
>
> Thanks,
>
> Tim Rozet
> Red Hat SDN Team
>
> - Original Message -
> From: "morgan richomme" 
> To: "Tim Rozet" , "Jose Lausuch" 
> 
> Cc: "OPNFV Tech Discussion" , 
> "Steven Pisarski" 
> Sent: Monday, December 12, 2016 4:07:59 AM
> Subject: Re: [functest][apex] New smoke tests in master verify
>
> Hi Tim,
>
> api_check is part of new SNAPS tests (framework developed by Steve and 
> integrated in Danube)
> - 2 in healthcheck: connection_check and api_check
> - 1 in smoke: snaps_smoke
> we integrated them end of next week, it seems that we need to 
> troubleshoot a little bit :) we had a discussion on the category 
> (healtcheck versus smoke)
>
> As the 2 first test suites were short - healthcheck is as you 
> mentioned mainly for gating so it should be reliable and not block 
> installer CI - we put them in healthcheck (they could eventually 
> replace the old one written in bash)
>
> but as you say, negative tests must not be in healthcheck (good point, 
> we should include that in our rule for category selection..), I move 
> api_check to smoke (as Tempest) patch => 
> https://gerrit.opnfv.org/gerrit/#/c/25783/1
>
> + Steve in copy
>
> /Morgan
>
> Le 12/12/2016 à 03:07, Tim Rozet a écrit :
>> Hi Jose, Morgan,
>> I noticed in our latest verifies there are some new test cases added called 
>> 'api_check' that are running as part of the healthcheck:
>>
>> https://build.opnfv.org/ci/job/functest-apex-apex-verify-master-suite
>> -master/734/console
>>
>> Most of these test cases pass, but the negative tests seem to fail like:
>> test_create_subnet_empty_cidr 
>> (snaps.openstack.utils.tests.neutron_utils_tests.NeutronUtilsSubnetTe
>> sts) ... FAIL test_create_subnet_empty_name 
>> (snaps.openstack.utils.tests.neutron_utils_tests.NeutronUtilsSubnetTe
>> sts) ... FAIL test_create_subnet_null_cidr 
>> (snaps.openstack.utils.tests.neutron_utils_tests.NeutronUtilsSubnetTe
>> sts) ... FAIL test_create_subnet_null_name 
>> (snaps.openstack.utils.tests.neutron_utils_tests.NeutronUtilsSubnetTe
>> sts) ... FAIL
>>
>> Should those be running as part of the healthcheck?  If so, can we remove 
>> the negative test cases?  I feel like the smoke tests should just be for 
>> valdidating basic functionality of what is deployed works, rather than 
>> negative tests.  We still need to figure out why these are failing, but I 
>> don't want it to block our verify CI (maybe turn on in daily?).
>>
>> There are a few positive tests that failed:
>> test_create_network 
>> (snaps.openstack.utils.tests.neutron_utils_tests.NeutronUtilsNetworkT
>> ests) ... FAIL test_create_subnet 
>> (snaps.openstack.utils.tests.neutron_utils_tests.NeutronUtilsSubnetTe
>> sts) ... FAIL test_create_port 
>> (snaps.openstack.utils.tests.neutron_utils_tests.NeutronUtilsRouterTe
>> sts) ... FAIL test_create_router_private_network 
>> (snaps

Re: [opnfv-tech-discuss] [test-wg] [all] TestPerf EcoSystem diagram now editable

[Jose Lausuch]

Hi Yujun,

That looks good. It’s a great idea to have diagrams and pictures editable so 
that we can change it when we see the need.
Maybe we should apply the same for the other pictures/graphs.

Thanks,
Jose

From: test-wg-boun...@lists.opnfv.org [mailto:test-wg-boun...@lists.opnfv.org] 
On Behalf Of Yujun Zhang
Sent: Thursday, December 15, 2016 14:05 PM
To: test-wg
Cc: TECH-DISCUSS OPNFV
Subject: [test-wg] [all] TestPerf EcoSystem diagram now editable

Hi testers,

I have replaced the previous image of TestPerf EcoSystem with an editable 
diagram in the overview section of testperf wiki page[1]. Please review and 
amend if something is missing.

https://wiki.opnfv.org/display/testing/TestPerf
___
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] Keystone error when getting nova client

[Jose Lausuch]

Hi Georgios,

I think it could be due to the last docker builds failed, so the docker image 
is outdated. There is a new successful build from today which includes the 
latest patches from Helen that tackle that problem about the OS clients.

Can you try the same with the latest functest image?

Thanks,
Jose


From: Paraskevopoulos Georgios [mailto:geo...@intracom-telecom.com]
Sent: Thursday, December 15, 2016 15:13 PM
To: OPNFV Tech
Cc: Jose Lausuch
Subject: [functest] Keystone error when getting nova client

Hi all,

In functest master when I'm trying to run get_nova_client() I'm getting the 
following exceptions: http://hastebin.com/lokuciquce.hs

I run git bisect with the following test: http://hastebin.com/asezuwawoh.js
Where test.py tries to get a nova client: http://hastebin.com/fidehufuju.cpp

And it shows [0] that the commit hash that introduced this error is 
703d4477d2385d3c654cdac549b936c08b9c5b31

[0] git bisect output: http://hastebin.com/zeralilemi.rb

I've created a Jira ticket for anyone who wishes to investigate further: 
https://jira.opnfv.org/browse/FUNCTEST-662

BR,
George Paraskevopoulos


George Paraskevopoulos
Software Engineer (SDN/NFV), INTRACOM-TELECOM

[https://newoldstamp.com/editor/images/phone_g.png] + 30 210 667 7689

[https://newoldstamp.com/editor/images/email_g.png] 
geo...@intracom-telecom.com<mailto:geo...@intracom-telecom.com>

[https://newoldstamp.com/editor/images/address_g.png] 19.7 km Markopoulou Ave 
19002 Peania, Athens, Greece



The information in this e-mail message and any attachments are intended only 
for the individual or entity to whom it is addressed and may be confidential. 
If you have received this transmission in error, and you are not an intended 
recipient, be aware that any copying, disclosure, distribution or use of this 
transmission or its contents is prohibited.  INTRACOM TELECOM and the sender 
accept no liability for any loss, disruption or damage to your data or computer 
system that may occur while using data contained in, or transmitted with, this 
email. Views or opinions expressed in this message may be those of the author 
and may not necessarily represent those of INTRACOM TELECOM.

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

Re: [opnfv-tech-discuss] Starting to clean-up meetings page on the wiki

[Jose Lausuch]

Hi Ray,

I’ve seen you have created https://wiki.opnfv.org/display/meetings/Functest  
which contains the same info as in the main page.
Shall I move all the content from 
https://wiki.opnfv.org/display/functest/Functest+Meeting to that one to avoid 
pointers to pointers?

Thanks,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Friday, December 16, 2016 5:36 AM
To: Aimee Ukasick
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Starting to clean-up meetings page on the wiki

I did find a few project meetings where the daughter page was missing the 
meeting logistics info, so I copied them from the main meetings page.  I will 
also be reaching out to a few PTLs where the meeting information is 
inconsistent...

Finally, if there are meetings that are no longer occurring could you let me 
know so that I can remove them from the meetings page?

Thanks,

Ray


On Thu, Dec 15, 2016 at 2:13 PM, Aimee Ukasick 
mailto:aimeeu.opensou...@gmail.com>> wrote:
VNF Event Streaming looks good.


On 12/15/2016 01:35 PM, Raymond Paik wrote:
> All,
>
> Following up on one of my action items from a few weeks ago  On
> the meetings wiki page
> (https://wiki.opnfv.org/display/meetings/Meetings), a relatively
> simple fix I mentioned was to eliminate the "Project Meetings" section
> from the main page and keep all the meetings detail on the daughter
> pages for each project teams.  Please see the attached screenshot.
> This will keep the main page short plus eliminate having to make
> meeting updates on two places on the wiki.
>
> There were 15 projects that did not have daughter pages, so I went
> ahead and created them and copied the information from the main page.
> The 15 projects were Apex, Barometer (I just renamed the SFQM page),
> Daisy4NFV, Domino, Fuel, Functest, HA, Models, ONOSFW, OVS4NFV, Qtip,
> Security, SFC, VES, and Yardstick.  Could I ask project team members
> from these 15 projects to verify that the information in the daughter
> pages are correct?  If I don't hear any feedback by January 3rd, I
> will go ahead and delete the project meeting details on the main page...
>
> Next step is to see if there's a way to streamline the meetings
> calendar on the upper right corner.  If anyone has good
> ideas/suggestions, please let me know.
>
> Thanks,
>
> Ray
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

--
Aimee Ukasick, AT&T Open Source

___
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] [Fuel] [Functest] Fuel10, Newton and v3 testing

[Jose Lausuch]

Hi,

Looking at the latest CI daily jobs for Fuel, Functest fails due to a failure 
while running the healthcheck test case:
https://build.opnfv.org/ci/view/functest/job/functest-fuel-baremetal-daily-master/1012/console
 
I have ran Functest on Fuel-10 on a local server and got better results after 
running some tests cases.


This output belongs to testing it with the ISO I got during the Plugfest: 
fuel-10.0-1060-2016-12-02_23-00-01.iso  --> http://pastebin.com/raw/uJ9R7mzT

and with the latest ISO built in CI:
http://artifacts.opnfv.org/fuel/opnfv-2016-12-21_16-00-14.iso --> 
http://pastebin.com/raw/S5RWcV8w


Both deployed virtual, NO-HA and without ODL.

So, I don't understand what happens in CI, which is related to Glance [1] but 
at least we don't have those v3 issues any more (thanks to Helen and Serena 
from Functest team for fixing that).


[1] 2016-12-21 21:58:33,734 - healtcheck - INFO -  Testing Glance API...
Error finding address for 
http://192.168.0.2:9292/v2/images/1a2969fc-5fb3-4d6b-bf3d-68fc889b0f41/file: 
Unable to establish connection to 
http://192.168.0.2:9292/v2/images/1a2969fc-5fb3-4d6b-bf3d-68fc889b0f41/file


Regards,
Jose
___
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]if the l3vpn feature is completed fully in C release

[Jose Lausuch]

Hi,

Adding Tim who is the PTL of the SDNVPN project. We had a discussion yesterday 
about it during the weekly team meeting. We would like to remark that the test 
cases were mature and gave success in Colorado release. However, there were 
some performance penalties in ODL when activating the bgpvpn plugin in Fuel. 
When doing so, some other test cases took longer execution time than in 
non-bgpvpn scenarios. This is being addressed for Danube. Apart from that, the 
test cases were stable enough to be considered as part of Dovetail test plan.

Regards,
Jose


On 17 Jan 2017, at 03:33, Tianhongbo 
mailto:hongbo.tianhon...@huawei.com>> wrote:

Hi Jose and Chris:

Could you please help me to check this action item?

Best regards

hongbo

发件人: Tianhongbo
发送时间: 2017年1月14日 15:32
收件人: Jose Lausuch
抄送: 'TECH-DISCUSS OPNFV'
主题: [dovetail]if the l3vpn feature is completed fully in C release

Hi Jose:

Last dovetail weekly meeting, we have reviewed dovetail test cases and 
requirements

Here is the action item from the last dovetail weekly meeting:

Vpn or l3vpn: unclear if the l3vpn feature is completed fully in C release 
(action: to collect definitive answer for next review). Commented that it 
should be excluded on the ground of not yet mature and have adoption (see test 
case reqs & cvp description).

Could you please help to get the feedback to the dovetail for the next review?
The minutes is attached by the end for email.

Best regards

hongbo

___
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]if the l3vpn feature is completed fully in C release

[Jose Lausuch]

Me neither. If that were the case, that feature Was tested only in Fuel during 
Colorado.

Let's follow up on Friday. 

- Jose - 


-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Wednesday, January 18, 2017 9:32 AM
To: Tapio Tallgren; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [dovetail]if the l3vpn feature is completed 
fully in C release

Hmm,

I was not aware that “all installers must support” a feature for there to be a 
dovetail suite to validate it.  
Maybe we should review the “qualification criteria” again on Friday’s call.

Completely agree that we need to do this in Gerrit.

/ chris

On 2017-01-18, 08:59, "Tapio Tallgren" 
 wrote:

On 01/18/2017 12:53 AM, Dave Neary wrote:
> Hi Hongbo, Jose,
>
> As I was saying on the Dovetail calls, I have some concerns about moving
> tests into the Dovetail test suite too early.
>
> In the Dovetail test requirements, we have:
>
> "* Test cases must pass on OPNFV reference deployments
>* Tests must not require a specific NFVi platform composition or
> installation tool
>* Tests must not require unmerged patches to the relevant upstream
> projects"
>
> And in the CVP requirements, we have the following section:
>
> "The overall CVP compliance verification scope tied to an OPNFV release
> is determined by the Committee. The OPNFV TSC defines and maintains the
> compliance verification procedures and associated tools. The scope is
> constrained to features, capabilities, components, and interfaces
> included in an OPNFV release that are generally available in the
> industry (e.g., through adoption by an upstream community)."
>
>
> I wonder if this functionality is sufficiently widely adopted in
> commercial NFVi and VIM solutions to pass this bar.
>
> Thanks,
> Dave.

I have no opinion about L3VPN as such, but I read this to mean that the 
code should be part of a released upstream projects and that OPNFV 
installers should all support it.

What would be the best way to discuss these? Currently, the test cases 
are on a wiki page which makes it a little difficult to comment them. 
Would it make sense to copy the whole test areas and test cases wiki 
page to an Etherpad? Or should the whole page be put to gerrit for 
commenting?

-Tapio

___
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 mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [dovetail]L3VPN for dovetail area

[Jose Lausuch]

Hi Hongbo,


Test cases must pass on OPNFV reference deployments
* Tests must not require a specific NFVi platform composition or 
installation tool

Can you please explain what this statement exactly means? By "installation 
tool" are we talking about the installers we have or a specific and different 
tool to install a certain feature?

Adding Tim, who is the SDNVPN PTL.

Thanks,
Jose

From: Tianhongbo [mailto:hongbo.tianhon...@huawei.com]
Sent: Wednesday, January 25, 2017 01:46 AM
To: Jose Lausuch
Cc: 'TECH-DISCUSS OPNFV'
Subject: [dovetail]L3VPN for dovetail area

Hi Jose:

As you mentioned, there will be discussion about the more detail of the L3VPN 
with L3VPN team to check if the L3VPN can be included in the dovetail area now.

There are some requirements from the dovetail wiki page: 
https://wiki.opnfv.org/display/dovetail/Dovetail+Test+Case+Requirements

Look forward to your reply.

Best regards

hongbo
___
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]L3VPN for dovetail area

[Jose Lausuch]

Thanks Chris, that makes things clearer. But still, it is a broad statement and 
difficult to measure. I guess and as you say, the TSC has the final word when 
approving features to be verified/certified in Dovetail with existing tests. 
From functional prospective, I can just provide and overview about how the 
tests were behaving when releasing Colorado.

Regards,
Jose


From: Christopher Price
Sent: Wednesday, January 25, 2017 14:17 PM
To: Jose Lausuch; Tianhongbo; Tim Irnich
Cc: 'TECH-DISCUSS OPNFV'
Subject: Re: [opnfv-tech-discuss] [dovetail]L3VPN for dovetail area

Hi Jose,

The intent of this statement is that we should not attempt to establish 
compliance tests on features or capabilities that are unique to a very specific 
configuration or composition of components. The statement is intended to mean 
that we should focus our efforts on compliance on “generally available” or 
“community relevant” use cases and features.

Again, I am not able to accurately articulate what that means or how to measure 
it, as such we have a somewhat obtuse statement in the documentation.

This should be seen as a guideline to be applied by the development, testing 
and dovetail teams around expectations for compliance testing.  It would be 
eventually ratified or judged by the TSC as they have the final say on the 
tests that are approved for compliance validation for a given dovetail release.

Does that help?
I do believe we should formalize and commit our governance into a repo and have 
the TSC cast an approving eye over it as well for good form.  Then, if nothing 
else, we would have a more consistent view of our intention and needed approach.

/ Chris

From: 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of Jose Angel Lausuch Sales 
mailto:jose.laus...@ericsson.com>>
Date: Wednesday, 25 January 2017 at 11:51
To: Tianhongbo 
mailto:hongbo.tianhon...@huawei.com>>, Tim Irnich 
mailto:tim.irn...@ericsson.com>>
Cc: TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] [dovetail]L3VPN for dovetail area

Hi Hongbo,


Test cases must pass on OPNFV reference deployments
• Tests must not require a specific NFVi platform composition or 
installation tool

Can you please explain what this statement exactly means? By “installation 
tool” are we talking about the installers we have or a specific and different 
tool to install a certain feature?

Adding Tim, who is the SDNVPN PTL.

Thanks,
Jose

From: Tianhongbo [mailto:hongbo.tianhon...@huawei.com]
Sent: Wednesday, January 25, 2017 01:46 AM
To: Jose Lausuch
Cc: 'TECH-DISCUSS OPNFV'
Subject: [dovetail]L3VPN for dovetail area

Hi Jose:

As you mentioned, there will be discussion about the more detail of the L3VPN 
with L3VPN team to check if the L3VPN can be included in the dovetail area now.

There are some requirements from the dovetail wiki page: 
https://wiki.opnfv.org/display/dovetail/Dovetail+Test+Case+Requirements

Look forward to your reply.

Best regards

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

Re: [opnfv-tech-discuss] [SFC] Using compressed sf_nsh_colorado.qcow2 VM image

[Jose Lausuch]

Juan, please ping me in IRC and I'll do it for you.
- Jose -


-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Manuel Buil
Sent: Wednesday, January 25, 2017 18:49 PM
To: Juan Vidal ALLENDE; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [SFC] Using compressed sf_nsh_colorado.qcow2 
VM image

Hello Juan,

Cool, sounds like a great idea!

Only contributors to infra project can upload images in the opnfv artifactory. 
You will need to contact them (e.g. fatih.degirme...@ericsson.com)

Regards,
Manuel




>>> Juan Vidal ALLENDE  01/25/17 4:19 PM >>>
 Hello guys,
 
 
 I used the virt-sparsify[0] command to compress the .qcow image 
sf_nsh_colorado.qcow2 that we are using for our OPNFV-SFC tests, and I reduced 
the size to almost 1/5 of the original one (559M vs. 2.4G previously). The 
small tests that I ran went well,  so I think that we could start using this VM 
image, which will reduce the time required to run the tests (download, upload 
to glance, etc. will benefit from smaller size). My suggestion is to upload it 
to artifacts.opnfv.org/sfc/demo/sf_nsh_danube_sparse.qcow2  or something like 
that, and start using it in master (this patch[1] would enable it.
 
 
 Does it look good to you? How can I upload that image to the opnfv public 
artifactory? I am currently hosting it on my google drive [2] 
 
 
 Regards,
 Juan
 
 
 [0] http://libguestfs.org/virt-sparsify.1.html
 [1] https://gerrit.opnfv.org/gerrit/#/c/27547/
 [2] 
https://drive.google.com/file/d/0BxsYX2Xl1MrSQ214Sk9sTEJBRDg/view?usp=sharing
 
 
 
 
   

___
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] [SDNVPN]{Fuel] Fuel virtual install

[Jose Lausuch]

Hi Bryan,

To deploy virtual FUEL, I use this every time I have a fresh Ubuntu 
installation :

sudo apt-get install -y\
 python-pip\
 python-dev\
 libffi-dev\
 libssl-dev\
 sshfs\
 fuseiso\
 isoinfo\
 genisoimage\
 sshpass\



sudo pip install --upgrade pip
sudo pip install pyyaml
sudo pip install netaddr
sudo pip install lxml
sudo pip install paramiko
sudo pip install scp

Not sure if I’m missing anything, but you can try and see. Fuel deploy script 
will complain if a library is missing.


Regards,
Jose





On 31 Jan 2017, at 19:54, SULLIVAN, BRYAN L 
mailto:bs3...@att.com>> wrote:

Next issue (note this also applies to the master doc: 
http://artifacts.opnfv.org/sdnvpn/docs/userguide/feature.userguide.html#preparing-the-host-to-install-fuel-by-script)

Re “Scenario Preparation”:
cp /deploy/config/labs/devel-pipeline/elx \
   /deploy/config/labs/devel-pipeline/
This should be “cp -r”

Thanks,
Bryan Sullivan | AT&T

From: SULLIVAN, BRYAN L
Sent: Tuesday, January 31, 2017 10:40 AM
To: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [SDNVPN]{Fuel] Fuel virtual install

Hi SDNVPN and Fuel teams,

I am trying to do a Fuel virtual install. This is not documented in the Fuel 
docs, but I was referred to the 
dochttp://artifacts.opnfv.org/sdnvpn/colorado/docs/userguide/feature.userguide.html#preparing-the-host-to-install-fuel-by-script
 by Jose.

I have some questions about the description in that doc:
Installation of required packages
The doc refers to the following packages being needed:
-  Which are essential?
-  What updates are needed for Danube (in which Ubuntu Xenial is the 
standard for jumphosts)? I got the following errors for example:

E: Unable to locate package libpq-dev
E: Package 'qemu-system' has no installation candidate
E: Unable to locate package tightvncserver
E: Unable to locate package virt-manager
E: Unable to locate package sshpass
E: Unable to locate package fuseiso
E: Unable to locate package genisoimage
E: Unable to locate package blackbox
E: Unable to locate package xterm
E: Unable to locate package python-git
E: Unable to locate package python-oslo.config
E: Couldn't find any package by glob 'python-oslo.config'
E: Couldn't find any package by regex 'python-oslo.config'
E: Unable to locate package libffi-dev
E: Unable to locate package libxml2-dev
E: Unable to locate package libxslt1-dev
E: Unable to locate package libffi-dev
E: Unable to locate package libxml2-dev
E: Unable to locate package libxslt1-dev
E: Unable to locate package expect
E: Unable to locate package python-netaddr
E: Unable to locate package p7zip-full

sudo apt-get install -y git make curl libvirt-bin libpq-dev qemu-kvm \
qemu-system tightvncserver virt-manager sshpass \
fuseiso genisoimage blackbox xterm python-pip \
python-git python-dev python-oslo.config \
python-pip python-dev libffi-dev libxml2-dev \
   libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \
   expect curl python-netaddr p7zip-full

sudo pip install GitPython pyyaml netaddr paramiko lxml scp \
 python-novaclient python-neutronclient python-glanceclient \
 python-keystoneclient debtcollector netifaces enum


Thanks,
Bryan Sullivan | AT&T

___
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][apex] functest container not updating

[Jose Lausuch]

Hi Tim,

I have observed something similar today. For some reason the build wasn't 
triggered.

Please try againwhen this job finished:
https://build.opnfv.org/ci/view/functest/job/functest-docker-build-push-master/888/

Apologies.

Jose



From: Tim Rozet 
Sent: Feb 3, 2017 17:22
To: Jose Lausuch; morgan richomme
Cc: OPNFV Tech Discussion
Subject: [functest][apex] functest container not updating

Hi Jose, Morgan,
I see in 
https://build.opnfv.org/ci/job/functest-apex-apex-daily-master-suite-master/3/console
that the patch to fix glance is not there, but in the job diff I see:

Changes:
 Migrates glance commands to OSCLI (detail)

Do we need to trigger the container to be rebuilt?

On the host:
[root@lf_pod1 ~]# docker ps
CONTAINER IDIMAGE   COMMAND CREATED 
STATUS  PORTS   NAMES
5081db2edcb7opnfv/functest:latest   "/bin/bash" 9 minutes ago   
Up 9 minutesdistracted_mestorf

[root@lf_pod1 ~]# docker images
REPOSITORY  TAG IMAGE IDCREATED 
SIZE
opnfv/functest  latest  d88385eb4340About an hour ago   
1.32 GB
opnfv/functesta1ca28f947472 days ago  
1.339 GB
opnfv/yardstick latest  98c6ec405cf08 days ago  
970.2 MB
hello-world latest  c54a2cc56cbb7 months ago
1.848 kB
tutum/influxdb  latest  5d606dc1468011 months ago   
275.2 MB


Thanks,

Tim Rozet
Red Hat SDN Team

___
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][apex] functest container not updating

[Jose Lausuch]

That is expected. Functest job always pulls the image first:
https://git.opnfv.org/releng/tree/jjb/functest/set-functest-env.sh#n75

-Jose-


From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Friday, February 03, 2017 18:11 PM
To: morgan.richo...@orange.com
Cc: Tim Rozet; Jose Lausuch; OPNFV Tech Discussion
Subject: Re: [opnfv-tech-discuss] [functest][apex] functest container not 
updating

For the StorPerf daily job, I found I had to do an explicit docker pull. Simply 
issuing docker run storperf/latest would not cause the latest to get pulled 
prior to running.

Regards,
Mark

Mark Beierl
Advisory Solutions Architect
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:john.gar...@dell.com>


On Feb 3, 2017, at 11:54, 
"morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>" 
mailto:morgan.richo...@orange.com>> wrote:
Hi Tim

in theory no...it is done automatically

the docker integrating your patch has been successfully produced
https://build.opnfv.org/ci/view/functest/job/functest-docker-build-push-master/883/

several latest Functest docker have been produced meanwhile
https://hub.docker.com/r/opnfv/functest/tags/ (last one 1 hour ago)

so the functest:latest shoudl include your patch...
I just pulled the last version, I can see that your patch is included in
healthcheck.sh

so it seems that the docker on LF POD1 is not up to date

Morgan



Le 03/02/2017 à 17:22, Tim Rozet a écrit :

Hi Jose, Morgan,
I see in 
https://build.opnfv.org/ci/job/functest-apex-apex-daily-master-suite-master/3/console
that the patch to fix glance is not there, but in the job diff I see:

Changes:
Migrates glance commands to OSCLI (detail)

Do we need to trigger the container to be rebuilt?

On the host:
[root@lf_pod1 ~]# docker ps
CONTAINER IDIMAGE   COMMAND CREATED 
STATUS  PORTS   NAMES
5081db2edcb7opnfv/functest:latest   "/bin/bash" 9 minutes ago   
Up 9 minutesdistracted_mestorf

[root@lf_pod1 ~]# docker images
REPOSITORY  TAG IMAGE IDCREATED 
SIZE
opnfv/functest  latest  d88385eb4340About an hour ago   
1.32 GB
opnfv/functesta1ca28f947472 days ago  
1.339 GB
opnfv/yardstick latest  98c6ec405cf08 days ago  
970.2 MB
hello-world latest  c54a2cc56cbb7 months ago
1.848 kB
tutum/influxdb  latest  5d606dc1468011 months ago   
275.2 MB


Thanks,

Tim Rozet
Red Hat SDN Team



--
Morgan Richomme
Orange/ IMT/ OLN/ CNC/ NCA/ SINA

Network architect for innovative services
Future of the Network community member
Open source Orange community manager


tel. +33 (0) 296 072 106
mob. +33 (0) 637 753 326
morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
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

Re: [opnfv-tech-discuss] [functest][apex] functest container not updating

[Jose Lausuch]

merged


-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Friday, February 03, 2017 19:55 PM
To: Jose Lausuch
Cc: Mark Beierl; morgan richomme; OPNFV Tech Discussion
Subject: Re: [opnfv-tech-discuss] [functest][apex] functest container not 
updating

OK it looks like we are hitting the glance image-list in another script: 
check_os.sh

I posted a fix here:
https://gerrit.opnfv.org/gerrit/#/c/28005/

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Jose Lausuch" 
To: "Mark Beierl" , "morgan richomme" 

Cc: "Tim Rozet" , "OPNFV Tech Discussion" 

Sent: Friday, February 3, 2017 12:18:05 PM
Subject: RE: [opnfv-tech-discuss] [functest][apex] functest container not   
updating

That is expected. Functest job always pulls the image first:
https://git.opnfv.org/releng/tree/jjb/functest/set-functest-env.sh#n75

-Jose-


From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Friday, February 03, 2017 18:11 PM
To: morgan.richo...@orange.com
Cc: Tim Rozet; Jose Lausuch; OPNFV Tech Discussion
Subject: Re: [opnfv-tech-discuss] [functest][apex] functest container not 
updating

For the StorPerf daily job, I found I had to do an explicit docker pull. Simply 
issuing docker run storperf/latest would not cause the latest to get pulled 
prior to running.

Regards,
Mark

Mark Beierl
Advisory Solutions Architect
Dell EMC | Office of the CTO
mobile +1 613 314 8106 
mark.bei...@dell.com<mailto:john.gar...@dell.com>


On Feb 3, 2017, at 11:54, 
"morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>" 
mailto:morgan.richo...@orange.com>> wrote:
Hi Tim

in theory no...it is done automatically

the docker integrating your patch has been successfully produced 
https://build.opnfv.org/ci/view/functest/job/functest-docker-build-push-master/883/

several latest Functest docker have been produced meanwhile 
https://hub.docker.com/r/opnfv/functest/tags/ (last one 1 hour ago)

so the functest:latest shoudl include your patch...
I just pulled the last version, I can see that your patch is included in 
healthcheck.sh

so it seems that the docker on LF POD1 is not up to date

Morgan



Le 03/02/2017 à 17:22, Tim Rozet a écrit :

Hi Jose, Morgan,
I see in 
https://build.opnfv.org/ci/job/functest-apex-apex-daily-master-suite-master/3/console
that the patch to fix glance is not there, but in the job diff I see:

Changes:
Migrates glance commands to OSCLI (detail)

Do we need to trigger the container to be rebuilt?

On the host:
[root@lf_pod1 ~]# docker ps
CONTAINER IDIMAGE   COMMAND CREATED 
STATUS  PORTS   NAMES
5081db2edcb7opnfv/functest:latest   "/bin/bash" 9 minutes ago   
Up 9 minutesdistracted_mestorf

[root@lf_pod1 ~]# docker images
REPOSITORY  TAG IMAGE IDCREATED 
SIZE
opnfv/functest  latest  d88385eb4340About an hour ago   
1.32 GB
opnfv/functesta1ca28f947472 days ago  
1.339 GB
opnfv/yardstick latest  98c6ec405cf08 days ago  
970.2 MB
hello-world latest  c54a2cc56cbb7 months ago
1.848 kB
tutum/influxdb  latest  5d606dc1468011 months ago   
275.2 MB


Thanks,

Tim Rozet
Red Hat SDN Team



--
Morgan Richomme
Orange/ IMT/ OLN/ CNC/ NCA/ SINA

Network architect for innovative services Future of the Network community 
member Open source Orange community manager


tel. +33 (0) 296 072 106
mob. +33 (0) 637 753 326
morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
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-t

Re: [opnfv-tech-discuss] Functest ODL-SFC

[Jose Lausuch]

Hi,

The SFC test case was only supported by Fuel installer in the Colorado Release.

+Manuel and Georgios who can give you more details about it.

-Jose-

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of KA PDE
Sent: Monday, February 13, 2017 04:22 AM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] Functest ODL-SFC

Hi,

I was giving Functest a try and I'm getting the following error:

/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122:
 InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause certain SSL 
connections to fail. You can upgrade to a newer version of Python to solve 
this. For more information, see 
https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Warning: Permanently added '10.20.0.2' (ECDSA) to the list of known hosts.
Warning: Permanently added '10.20.0.2' (ECDSA) to the list of known hosts.
Warning: Permanently added '10.20.0.2' (ECDSA) to the list of known hosts.
Warning: Permanently added '10.20.0.5' (ECDSA) to the list of known hosts.
Warning: Permanently added '10.20.0.2' (ECDSA) to the list of known hosts.
2017-02-13 03:15:28,500 - ODL_SFC - INFO - The presetup of the server worked
2017-02-13 03:15:28,689 - ODL_SFC - INFO - Executing ssh to collect the compute 
IPs
Warning: Permanently added '10.20.0.2' (ECDSA) to the list of known hosts
(...)
Warning: Permanently added '10.20.0.6' (ECDSA) to the list of known hosts.
2017-02-13 03:15:37,096 - ODL_SFC - ERROR - Currently supported only Fuel 
Installer type

^^

Could someone provide any hint?

Thanks and best regards,

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

Re: [opnfv-tech-discuss] [SFC] Collecting current issues

[Jose Lausuch]

Hi,

Currently there is a bigger problem which happens in CI:
https://build.opnfv.org/ci/view/functest/job/functest-fuel-baremetal-daily-master/1112/console

The instances can’t get an IP from the dhcp agent.

Adding Michail, who together with me has seen that issue before on fuel and 
sometimes was due to bad POD configuration.

Thanks,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Juan Vidal 
ALLENDE
Sent: Wednesday, February 15, 2017 17:03 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [SFC] Collecting current issues

Hello,

As we talked in the weekly meeting, let's compile the current issues that we 
are facing, and try to focus on fixing them to stabilize the test cases. We can 
then add them to JIRA and assign them.

I am currently facing two issues:

1) Floating IPs are not working sometimes. I don't know why this happens, 
because manually I can spawn a VM and manually asign IP to it and works fine 
with the admin user, but I seem to have more problems when using the 'tacker' 
user.

2) Wait for ovs configuration goes too fast. After testing 'ssh blocked' 
subtest, 'http works' subtest usually fails. I noticed that if I add a delay of 
10 seconds after 'wait_for_configuration_changes' function, it works. 
Apparently  it takes some time for the rules to be correctly installed.

Are you guys seeing these bugs as well? Do you have some others?

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

Re: [opnfv-tech-discuss] [Announce] OPNFV E-release naming

[Jose Lausuch]

Evans (Australia) https://en.wikipedia.org/wiki/Evans_River_(New_South_Wales)

Not so many rivers in Africa starting with E… 
https://en.wikipedia.org/wiki/List_of_rivers_of_Africa


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Wednesday, February 15, 2017 22:50 PM
To: opnfv-tech-discuss@lists.opnfv.org; opnfv-...@lists.opnfv.org
Subject: [opnfv-tech-discuss] [Announce] OPNFV E-release naming

All,

As discussed on the last TSC call, I'd like to get the process started for the 
E-release naming.

A quick reminder that we have a river theme for OPNFV releases and our first 4 
release names are Arno (Europe), Brahmaputra (Asia), Colorado (Americas), and 
Danube (Europe).  Let's continue the tradition of rotating through 
continents/geographies, so we could venture into Africa/Oceania for the first 
time or return to Asia...

Can you send me your top 2-3 nominations (at most) in the following format by 
5pm Pacific Time on February 24th?  After I collect all the nominations, I'll 
send out a SurveyMonkey poll so the community can pick the winner.

Format: River name (locations)
For example,
·  Esk (Australia)
·  Euphrates (Asia)
·  etc.

Thanks,

Ray
___
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] vnf test case failed

[Jose Lausuch]

JIRA created : https://jira.opnfv.org/browse/FUNCTEST-734

Valentin is working on it.


Thanks,
Jose

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of liyuenan
Sent: Thursday, February 16, 2017 09:25 AM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [functest] vnf test case failed

Hi

I found that functest add vnf test case in 
https://gerrit.opnfv.org/gerrit/#/c/28597/ . but it failed in compass4nfv, did 
it stable?
There is the error log:

2017-02-16 05:23:45,152 - run_tests - INFO - 

2017-02-16 05:23:45,152 - run_tests - INFO - Running test case 'cloudify_ims'...
2017-02-16 05:23:45,152 - run_tests - INFO - 

2017-02-16 05:23:45,153 - openstack_snapshot - INFO - Generating OpenStack 
snapshot...
2017-02-16 05:23:45,160 - openstack_utils - INFO - OS_IDENTITY_API_VERSION is 
set in env as '3'
2017-02-16 05:23:46,633 - functest.core.vnf_base - WARNING - No tenant image 
defined for this VNF
2017-02-16 05:23:46,677 - vIMS - INFO - Images needed for vIMS: {'centos_7': 
'http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1510.qcow2',
 'ubuntu_14.04': 
'http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img'}
2017-02-16 05:23:46,678 - vIMS - INFO - Cloudify IMS VNF onboarding test 
starting
2017-02-16 05:23:46,678 - vIMS - INFO - Create VNF Onboarding environment
2017-02-16 05:23:46,680 - openstack_utils - INFO - OS_IDENTITY_API_VERSION is 
set in env as '3'
2017-02-16 05:23:46,836 - vIMS - INFO - Prepare OpenStack plateform(create 
tenant and user)
2017-02-16 05:23:47,374 - vIMS - INFO - Update OpenStack creds informations
2017-02-16 05:23:47,379 - vIMS - INFO - Deploy orchestrator (if necessary)
2017-02-16 05:23:47,379 - vIMS - INFO - Additional pre-configuration steps
2017-02-16 05:23:47,383 - openstack_utils - INFO - OS_IMAGE_API_VERSION is set 
in env as '2'
2017-02-16 05:23:47,385 - openstack_utils - INFO - OS_IDENTITY_API_VERSION is 
set in env as '3'
2017-02-16 05:23:47,557 - vIMS - WARNING - Problem with the Orchestrator
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/functest/core/vnf_base.py", line 
61, in execute
res_orchestrator = self.deploy_orchestrator()
  File 
"/usr/local/lib/python2.7/dist-packages/functest/opnfv_tests/vnf/ims/cloudify_ims.py",
 line 73, in deploy_orchestrator
self.keystone_client = os_utils.get_keystone_client(self.creds)
  File 
"/usr/local/lib/python2.7/dist-packages/functest/utils/openstack_utils.py", 
line 186, in get_keystone_client
return keystoneclient.Client(get_keystone_client_version(), session=sess)
  File "/usr/local/lib/python2.7/dist-packages/keystoneclient/client.py", line 
62, in Client
d = discover.Discover(session=session, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/positional/__init__.py", line 
101, in inner
return wrapped(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/keystoneclient/discover.py", 
line 185, in __init__
authenticated=authenticated)
  File "/usr/local/lib/python2.7/dist-packages/positional/__init__.py", line 
101, in inner
return wrapped(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/keystoneclient/_discover.py", 
line 147, in __init__
authenticated=authenticated)
  File "/usr/local/lib/python2.7/dist-packages/positional/__init__.py", line 
101, in inner
return wrapped(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/keystoneclient/_discover.py", 
line 41, in get_version_data
resp = session.get(url, headers=headers, authenticated=authenticated)
  File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py", line 
758, in get
return self.request(url, 'GET', **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/positional/__init__.py", line 
101, in inner
return wrapped(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py", line 
491, in request
auth_headers = self.get_auth_headers(auth)
  File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py", line 
818, in get_auth_headers
return auth.get_headers(self, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/plugin.py", line 
90, in get_headers
token = self.get_token(session)
  File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/identity/base.py", 
line 90, in get_token
return self.get_access(session).auth_token
  File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/identity/base.py", 
line 136, in get_access
self.auth_ref = self.get_auth_ref(session)
  File 
"/usr/local/lib/python2.7/dist-packages/keystoneauth1/identity/generic/base.py",
 line 198, in get_auth_ref
return self._plugin.get_auth_ref(session, **kwargs)
  File 
"/usr/local/lib/python2.7/dist-packages/keystoneauth1/identity/v3/base.py", 
line 167, in

Re: [opnfv-tech-discuss] [SFC] Collecting current issues

[Jose Lausuch]

+Manuel, George


From: Michael Polenchuk [mailto:mpolenc...@mirantis.com]
Sent: Thursday, February 16, 2017 13:58 PM
To: Jose Lausuch
Cc: Juan Vidal ALLENDE; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [SFC] Collecting current issues

I've got only the following flows on the compute node (all instance(s) packets 
is being dropped):

# ovs-ofctl dump-flows -OOpenFlow13 br-int
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x0, duration=36399.647s, table=0, n_packets=0, n_bytes=0, 
dl_type=0x88cc actions=CONTROLLER:65535
 cookie=0x0, duration=36399.647s, table=0, n_packets=180, n_bytes=27686, 
priority=6 actions=goto_table:1
 cookie=0x0, duration=36399.648s, table=1, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:11
 cookie=0x0, duration=36399.656s, table=11, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:21
 cookie=0x0, duration=36399.652s, table=21, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:31
 cookie=0x0, duration=36399.648s, table=31, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:41
 cookie=0x0, duration=36399.659s, table=41, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:51
 cookie=0x0, duration=36399.653s, table=51, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:61
 cookie=0x0, duration=36399.650s, table=61, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:71
 cookie=0x0, duration=36399.660s, table=71, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:81
 cookie=0x0, duration=36399.654s, table=81, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:91
 cookie=0x0, duration=36399.651s, table=91, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:101
 cookie=0x0, duration=36399.660s, table=101, n_packets=180, n_bytes=27686, 
priority=0 actions=goto_table:111
 cookie=0x0, duration=36399.655s, table=111, n_packets=180, n_bytes=27686, 
priority=0 actions=drop

On Thu, Feb 16, 2017 at 12:53 PM, Michael Polenchuk 
mailto:mpolenc...@mirantis.com>> wrote:
Hi,
Definitely need to debug it in details,
but I believe this issue relates to ovs+nsh chains/flows since other scenarios 
pass this test.

On Wed, Feb 15, 2017 at 10:10 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi,

Currently there is a bigger problem which happens in CI:
https://build.opnfv.org/ci/view/functest/job/functest-fuel-baremetal-daily-master/1112/console

The instances can’t get an IP from the dhcp agent.

Adding Michail, who together with me has seen that issue before on fuel and 
sometimes was due to bad POD configuration.

Thanks,
Jose


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto: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 Juan Vidal ALLENDE
Sent: Wednesday, February 15, 2017 17:03 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] [SFC] Collecting current issues

Hello,

As we talked in the weekly meeting, let's compile the current issues that we 
are facing, and try to focus on fixing them to stabilize the test cases. We can 
then add them to JIRA and assign them.

I am currently facing two issues:

1) Floating IPs are not working sometimes. I don't know why this happens, 
because manually I can spawn a VM and manually asign IP to it and works fine 
with the admin user, but I seem to have more problems when using the 'tacker' 
user.

2) Wait for ovs configuration goes too fast. After testing 'ssh blocked' 
subtest, 'http works' subtest usually fails. I noticed that if I add a delay of 
10 seconds after 'wait_for_configuration_changes' function, it works. 
Apparently  it takes some time for the rules to be correctly installed.

Are you guys seeing these bugs as well? Do you have some others?

Regards,
Juan


--
  Michael Polenchuk
  Private Cloud / Mirantis Inc.



--
  Michael Polenchuk
  Private Cloud / Mirantis Inc.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] MS6 Functest

[Jose Lausuch]

Hi David,

This is the status of MS6 for Functest.


-  New internal test cases:

o   snaps_healthcheck: https://gerrit.opnfv.org/gerrit/#/c/28011/

o   api_check: https://gerrit.opnfv.org/gerrit/#/c/25443/

o   connection_check: https://gerrit.opnfv.org/gerrit/#/c/25443/

o   snaps_smoke: https://gerrit.opnfv.org/gerrit/#/c/25443/

o   vRouter: https://gerrit.opnfv.org/gerrit/#/c/28619/

o   Cloudify_ims fixes: https://gerrit.opnfv.org/gerrit/#/c/28371/



-  Integration of new Feature projects:

o   Netready [WIP]: https://gerrit.opnfv.org/gerrit/#/c/28615/

o   Barometer [WIP]: https://gerrit.opnfv.org/gerrit/#/c/28609/

o   FastDataStacks [WIP]: https://gerrit.opnfv.org/gerrit/#/c/28883/

o   Orchestra [WIP]: https://gerrit.opnfv.org/gerrit/#/c/28587/

o   Multisite fixes: https://gerrit.opnfv.org/gerrit/#/c/28687/

o   Security_scan test moved from Functest to security_scan repo: 
https://gerrit.opnfv.org/gerrit/#/c/28019/

As for documentation:

-  updated Developer guide: https://gerrit.opnfv.org/gerrit/#/c/27665/

-  updated User guide: https://gerrit.opnfv.org/gerrit/#/c/27385/

-  updated Configuration guide: 
https://gerrit.opnfv.org/gerrit/#/c/27247/



Thanks,

JOSE LAUSUCH
Senior Systems Designer
Ericsson | Germany
jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>


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

[opnfv-tech-discuss] Functest-suite job returns always 0

[Jose Lausuch]

Hi,

The reason why Functest-suite job is giving false positives in CI is because of 
the Functest CLI. This job is mainly used by verify gates and other 3rd party 
jobs like ODL-Netvirt, ODL-CSIT, and will be more often used.

This only happens with the 'suite' job and not with 'daily' jobs, since we call 
the 'run_tests.py' script directly instead of the CLI.

https://gerrit.opnfv.org/gerrit/gitweb?p=releng.git;a=blob;f=jjb/functest/functest-suite.sh;h=f28d3d0377fcc40f30c41f64a1f2619ff4648e1d;hb=2b72e01a433d886999f2159e996a65fb7d855706#l10
Looking at this line, we use the CLI command (functest testcase run ...) in our 
Functest-suite job, so that you can run a single test case or a given list of 
test cases.

Functest CLI is based on click http://click.pocoo.org/5/. The way it works is 
that the functions that are called from the CLI are not "functions" any more, 
they become a CLI program, then it will always return 0 if the command 
execution is OK, regardless of what the implemented function returns. Thus, the 
command "functest testcase run" will return always 0 whatever test result we 
have.
Example of a failed test execution here: http://pastebin.com/raw/97uUkeYj

We have some options to solve this:

1)  Swap the Functest-suite command to use the python script run_tests.py 
instead of the CLI command. Problem --> cannot run more than 1 test case at a 
time. With the CLI you can do things like: "functest testcase run healtcheck, 
vping, tempest" but with run_tests.py you can only call 1 test case at a time, 
i.e. 'run_tests.py -t vping.'

2)  Parse the testcase name in the Jenkins Job and if it is a list 
separated by comas, we call run_tests.py as many times as needed. --> too much 
logic in the Jenkins job

3)  Raise an exception in the CLI if the test case fails --> effective but 
ugly http://pastebin.com/raw/MEvpbm3c

What are your preferences?

Thanks,
Jose



___
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]dovetail weekly meeting 2/24

[Jose Lausuch]

Hi,

During the first 2 days at the PTG, I have been talking to the Interop WG and 
to the RefStack PTL to grab as much info as I could about how they are doing 
certification and what tools they use. They are excited about this 
collaboration and willing to work with us on this initiative but need our help.

Please let me expose during the call the feedback I got, open questions and the 
action points for us. Then, we can think about a plan and how to start 
executing things as soon as possible.

Thanks,
Jose


From: Tianhongbo [mailto:hongbo.tianhon...@huawei.com]
Sent: Wednesday, February 22, 2017 05:42 AM
To: Christopher Price; 'TECH-DISCUSS OPNFV'
Cc: Jose Lausuch
Subject: 答复: [dovetail]dovetail weekly meeting 2/24

Hi Chris:

Ok, I will put these as the first point on the agenda.

Yes, that is true that before the dovetail wok, we need to get the clear 
strategy from the CVP. Last week, wenjing shared the feedback from board.
We can discuss and get the consensus on that. It will make the dovetail go to 
right direction.

Thank you for participating the joint discussion for the interp WG and OPNFV. I 
will put that on the agenda to see how the dovetail and interop WG can 
cooperate.

For the test case results and tool, we have discussed several times in the test 
group. We have the consensus that the dovetail will use as much as possible 
from the test group.
I will put this on the agenda, let us make this more clear.

Best regards

hongbo


发件人: Christopher Price [mailto:christopher.pr...@ericsson.com]
发送时间: 2017年2月22日 17:50
收件人: Tianhongbo; 'TECH-DISCUSS OPNFV'
抄送: Jose Lausuch
主题: Re: [dovetail]dovetail weekly meeting 2/24

Hi Hongbo,

I would like to ensure we are discussing the CVP test strategy document as a 
priority point on the agenda.  My recollection of the discussion from last week 
was that our Jira planning, utilization and structure would be best done in 
conjunction with the document of how we will test and structure our work. This 
may be best to try and achieve consensus on before we start to dig into Jira 
task tracking directly to ensure everyone has a chance to understand what is 
being discussed.  Given the strategy document has been clearly identified as a 
pre-requisite to our program it feels like something we should prioritize.

As the PTG was this week and we had a number of people there discussing an NFV 
compliance suite with the interop WG to discuss integration with OPNFV testing 
WG activities I think we should likely include a readout of that as a topic 
point.

For the test case results, could we have a discussion around how we might use 
(or clone) the existing test result collection and reporting mechanisms we use 
for our testing projects.  I do not recall if there were any specific 
requirements from the CVP that prohibit us from using those, or adding any 
missing capabilities.  But it would be worth discussing that I think.  
Leveraging our upstream communities and mechanisms will require us to have a 
clear structure and process for result handling that likely should not be 
handled in the execution processes but rather a specific server based solution.

/ Chris


From: Tianhongbo 
mailto:hongbo.tianhon...@huawei.com>>
Date: Wednesday, 22 February 2017 at 06:07
To: TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>,
 Christopher Price 
mailto:christopher.pr...@ericsson.com>>, Dave 
Neary mailto:dne...@redhat.com>>, 
"'marko.a.kui...@nokia.com'" 
mailto:marko.a.kui...@nokia.com>>, "'Rautakumpu, Mika 
(Nokia - FI/Espoo)'" 
mailto:mika.rautaku...@nokia.com>>, 
"'sheng-ann...@ericsson.com'" 
mailto:sheng-ann...@ericsson.com>>, 
"'yangjian...@chinamobile.com'" 
mailto:yangjian...@chinamobile.com>>, 
"'zhang.ju...@zte.com.cn'" 
mailto:zhang.ju...@zte.com.cn>>, "'HU, BIN'" 
mailto:bh5...@att.com>>, "'l...@biigroup.cn'" 
mailto:l...@biigroup.cn>>, 'Tetsuya Nakamura' 
mailto:t.nakam...@cablelabs.com>>, Wenjing Chu 
mailto:wenjing@huawei.com>>, "Christopher Donley 
(Chris)" mailto:christopher.don...@huawei.com>>, 
Jose Angel Lausuch Sales 
mailto:jose.laus...@ericsson.com>>, "Lijun 
(Matthew)" mailto:matthew.li...@huawei.com>>
Subject: [dovetail]dovetail weekly meeting 2/24

时间: 2017年2月24日星期五 22:00-23:00(UTC+08:00)北京，重庆，香港特别行政区，乌鲁木齐。
注意: 以上 GMT 时差并不反映夏令时调整。
*~*~*~*~*~*~*~*~*~*
Hi all:
Last week, we have hot topic for the discussion on the dovetail plan. Let us 
continue and have efficient plan for dovetail.
The agenda for this week:
1）dovetail development plan（ milestone and schedule）,jira consensus and 
approach-wenjing, bryan and Lincoln Lavoie
2）Test case run results history info gathering and display - Matthew
3）update of authentication for dovetail to

Re: [opnfv-tech-discuss] [functest]multisite test executed, but test cases not being execeuted

[Jose Lausuch]

It looks like the function that configures tempest for multisite is wrong since 
it doesn't run any test at all. Juha, can you please have a quick look?



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of joehuang
Sent: Thursday, February 23, 2017 04:51 AM
To: opnfv-tech-discuss
Subject: [opnfv-tech-discuss] [functest]multisite test executed, but test cases 
not being execeuted


After kingbird installation in Functest was restored, the multisite test was 
executed, but test cases not being execeuted





https://build.opnfv.org/ci/view/multisite/job/functest-fuel-virtual-suite-master/259/console





2017-02-23 03:07:39,016 - Tempest - INFO - Tempest multisite success_rate is 
0%, is marked as FAIL

2017-02-23 03:07:39,016 - openstack_clean - INFO - Cleaning OpenStack 
resources...

2017-02-23 03:07:39,023 - openstack_utils - INFO - OS_IDENTITY_API_VERSION is 
set in env as '3'

2017-02-23 03:07:47,835 - openstack_utils - ERROR - Error 
[remove_gateway_router(neutron_client, 
'90f89c6f-46f2-46d7-8725-1be7e9630bd0')]: Request Failed: internal server error 
while processing your request.

Neutron server returns request_ids: ['req-4838f98a-5e9d-47ed-ba94-4c957843ed76']

2017-02-23 03:07:47,835 - openstack_clean - ERROR - There has been a problem 
removing the gateway...

2017-02-23 03:07:54,525 - run_tests - INFO - Test execution time: 00:41

2017-02-23 03:07:54,525 - run_tests - ERROR - The test case 'multisite' failed.

2017-02-23 03:07:54,525 - run_tests - INFO - Execution exit value: 
Result.EX_ERROR

2017-02-23 03:07:54,584 - functest_utils - ERROR - The command 'python 
/home/opnfv/repos/functest/functest/ci/run_tests.py  -t 'multisite'' failed

But the tempest test cases for kingbird could be discovered in Functest 
container:

root@d6b3b8fd39e8:~/repos/tempest# testr list-tests | grep kingbird
scenario.quota_management.client_tests.test_quota_management_api.KingbirdQMTestJSON.test_kingbird_delete_all_method
scenario.quota_management.client_tests.test_quota_management_api.KingbirdQMTestJSON.test_kingbird_delete_method
scenario.quota_management.client_tests.test_quota_management_api.KingbirdQMTestJSON.test_kingbird_get_default_method_after_delete
scenario.quota_management.client_tests.test_quota_management_api.KingbirdQMTestJSON.test_kingbird_get_default_method_after_update
scenario.quota_management.client_tests.test_quota_management_api.KingbirdQMTestJSON.test_kingbird_get_method
scenario.quota_management.client_tests.test_quota_management_api.KingbirdQMTestJSON.test_kingbird_put_method
scenario.quota_management.client_tests.test_quota_management_api.KingbirdQMTestJSON.test_kingbird_put_method_wrong_token

It worked before the kingbird installation was commented in Functest image 
build scripts.

Best Regards
Chaoyi Huang (joehuang)
___
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] [Danube] [Documentation] Organization of testing section

[Jose Lausuch]

Hi,

Functest already following this approach: 
https://gerrit.opnfv.org/gerrit/#/c/29151/

Thanks,
Jose

From: Sofia Wallin
Sent: Wednesday, March 01, 2017 14:11 PM
To: morgan.richo...@orange.com; David McBride
Cc: opnfv-tech-discuss@lists.opnfv.org; Yujun Zhang; mark.bei...@emc.com; Jose 
Lausuch; Cooper, Trevor; Yuyang (Gabriel); Gaoliang (D)
Subject: RE: [OPNFV] [Danube] [Documentation] Organization of testing section

Hi Morgan,
Yes – This is consistent with what we decided yesterday.

Thank you,
Sofia

From: morgan.richo...@orange.com<mailto:morgan.richo...@orange.com> 
[mailto:morgan.richo...@orange.com]
Sent: den 1 mars 2017 08:27
To: Sofia Wallin mailto:sofia.wal...@ericsson.com>>; 
David McBride 
mailto:dmcbr...@linuxfoundation.org>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
Yujun Zhang mailto:zhangyujun+...@gmail.com>>; 
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch 
mailto:jose.laus...@ericsson.com>>; Cooper, Trevor 
mailto:trevor.coo...@intel.com>>; Yuyang (Gabriel) 
mailto:gabriel.yuy...@huawei.com>>; Gaoliang (D) 
mailto:jean.gaoli...@huawei.com>>
Subject: [OPNFV] [Danube] [Documentation] Organization of testing section


Hi,

during the last release meeting we had a discussion on the structure of the 
testing documentation for Danube

we suggest to adopt the following approach for the test projects
/docs
|_ release
...
   |_ release-notes // release note of the projects involved in the release
 reference http://testresults.opnfv.org/reporting 
snapshot of the status at the release date
...
|_ testing
testing overview // umbrella document => figure, description of the testing 
ecosystem, pointers to project documentation
|__ user // will collect the documentation of the test projects 
allowing the end user to perform testing towards a OPNFV SUT
 e.g. Functest/Yardstick/Vsperf/Storperf/Bottlenecks/Qtip 
installation/config & user guides
|__ developer// will collect documentation to explain how to create 
your own test case and leverage existing testing frameworks
 e.g. devloper guides


the umbrella testing documentation "testing overview" is under opnfvdocs => 
will be put into /testing

the other documents are in the project repos under
/docs
/installation guide
/config guide
/user guide
/release note
/development
/development guide
/ interships

--
|  Test Project Repo   |   Target in docs.opnfv.org  |
--
| installation, config, user guide|  testing/user  |
| development guide |  testing/developer |
| release note|  release-notes/testing   |
--

@Sofia, David: is it OK for you?

Morgan

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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] FW: Functest weekly sync meeting

[Jose Lausuch]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Customized Time Zone
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Jose Lausuch;SENT-BY="MAILTO:bob.monk...@arm.com":MAILTO:jose.la
 us...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=opnfv-tec
 h-disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTACH:CID:02951B6FFB8AFC419EDD8AECD19AEF36@eurprd08.prod.outlook.com
DESCRIPTION;LANGUAGE=en-US:\n\n\n\n
 \nFrom: Jose Lausuch\nSent: Sunday\, October 30\, 2016 8:44:42 PM UTC\nTo:
  Jose Lausuch\; opnfv-tech-discuss@lists.opnfv.org\nSubject: [opnfv-tech-d
 iscuss] Functest weekly sync meeting\nWhen: Tuesday\, March 7\, 2017 8:00 
 AM-9:00 AM.\nWhere: #opnfv-testperf\n\nTime: 8am UTC\, 9am(CET)\, 4pm(CST)
 \n\nOnly IRC\n\nAgenda: https://wiki.opnfv.org/display/functest/Functest+M
 eeting\n\n\n\nIMPORTANT 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 pur
 pose\, or store or copy the information in any medium. Thank you.\n
UID:04008200E00074C5B7101A82E008A03F3701F532D201000
 01000E89D29AFEEC285499EACD620AF2D551D
RECURRENCE-ID;TZID=Customized Time Zone:20170307T09
SUMMARY;LANGUAGE=en-US:FW: Functest weekly sync meeting
DTSTART;TZID=Customized Time Zone:20170307T09
DTEND;TZID=Customized Time Zone:20170307T10
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161030T204423Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:#opnfv-testperf
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:-618747936
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-DISALLOW-COUNTER:TRUE
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
___
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] [release][danube] K8 scenario testing on Joid

[Jose Lausuch]

Hi,

I tend to agree about running the same set of test cases to all scenarios. But 
if the test frameworks are not prepared for a certain technology (like in this 
case K8), it doesn’t make sense to execute them. It’s a waste of time and we 
know beforehand that it will fail systematically.

We probably need to treat this case as an isolated scenario and define a 
different release criteria for it.

For Euphrates, we can think of adding support in Functest/Yardstick for 
containers (VIM abstraction layer or similar) but today we don’t have it.

Regards,
Jose



From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Tuesday, March 21, 2017 19:59 PM
To: Narinder Gupta; Fatih Degirmenci
Cc: TECH-DISCUSS OPNFV; Heather Kirksey; Tapio Tallgren; Morgan Richomme 
(morgan.richo...@orange.com); Gaoliang (kubi); Jose Lausuch; Raymond Paik
Subject: [release][danube] K8 scenario testing on Joid

This is a follow-up to a conversation on IRC (opnfv-release) earlier today.

When asked about disabling Functest and Yardstick for the new K8 scenarios on 
Joid, I agreed.  My reasoning was that I didn't want to delay release of new 
and potentially interesting scenarios.  I also know that functest and yardstick 
testing is not always applicable to every feature or configuration.  In 
addition, I was aware that the K8 scenarios had project-specific testing.

My initial thought was that the disabled tests would be documented in the 
release notes and that the project would be required to contribute tests to 
functest and yardstick for the following release.

Subsequently, after some discussion, I realized that I had made a mistake and 
that this is something that the test working group should weigh in on, at a 
minimum.

Therefore, please disregard my earlier direction about disabling the tests.  
The tests are still required for all scenarios until the test working group 
and/or the TSC indicate otherwise.

Let me know if you have any questions. Sorry for the confusion.

David

--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto: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] [release][danube] K8 scenario testing on Joid

[Jose Lausuch]

Hi,

Agreed. “Releasing” something that has not been –properly– tested is not a good 
practice. By “properly” I mean following the same procedures we use to verify 
all the other scenarios.

We need to emphasize that manual testing or “I run my own tests and it works” 
is not sufficient. Testing results must be shown and verified on CI following 
the OPNFV test mechanisms in order to consider it as a release candidate. Maybe 
we are too late to apply this to the k8 scenario which could be released as 
“Experimental”, as you suggest.

Regards,
Jose


From: Heather Kirksey [mailto:hkirk...@linuxfoundation.org]
Sent: Thursday, March 23, 2017 06:40 AM
To: Jose Lausuch
Cc: David McBride; Narinder Gupta; Fatih Degirmenci; TECH-DISCUSS OPNFV; Tapio 
Tallgren; Morgan Richomme (morgan.richo...@orange.com); Gaoliang (kubi); 
Raymond Paik
Subject: Re: [release][danube] K8 scenario testing on Joid

Hi all --

So first of all kudos to the JOID team for introducing this new technology -- 
it's an important step forward.

Secondly, obviously it doesn't make sense to run OpenStack tests against 
something that doesn't implement OpenStack.

I'm really worried, however, about "releasing" something that hasn't been 
tested at all. I know that often we document upstream bugs when tests aren't 
passing, etc., but not testing at all doesn't seem to be meeting a basic bar we 
should probably hold ourselves to for scenarios. Perhaps we can call this 
scenario something like "Experimental" or really point out that it's early 
days. Or we can continue to work this and put it out in Euphrates. I'd love to 
talk about this to the media, obviously, but I also want to feel comfortable 
that we're on solid footing and not overselling.

For my own edification, and apologies if this is a naive question, but how does 
this relate to the OpenRetriever project, which if I understood correctly, is 
the OPNFV project approved to focus on K8S and container requirements?

Cheers,
Heather





On Wed, Mar 22, 2017 at 6:14 AM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi,

I tend to agree about running the same set of test cases to all scenarios. But 
if the test frameworks are not prepared for a certain technology (like in this 
case K8), it doesn’t make sense to execute them. It’s a waste of time and we 
know beforehand that it will fail systematically.

We probably need to treat this case as an isolated scenario and define a 
different release criteria for it.

For Euphrates, we can think of adding support in Functest/Yardstick for 
containers (VIM abstraction layer or similar) but today we don’t have it.

Regards,
Jose



From: David McBride 
[mailto:dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>]
Sent: Tuesday, March 21, 2017 19:59 PM
To: Narinder Gupta; Fatih Degirmenci
Cc: TECH-DISCUSS OPNFV; Heather Kirksey; Tapio Tallgren; Morgan Richomme 
(morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>); Gaoliang 
(kubi); Jose Lausuch; Raymond Paik
Subject: [release][danube] K8 scenario testing on Joid

This is a follow-up to a conversation on IRC (opnfv-release) earlier today.

When asked about disabling Functest and Yardstick for the new K8 scenarios on 
Joid, I agreed.  My reasoning was that I didn't want to delay release of new 
and potentially interesting scenarios.  I also know that functest and yardstick 
testing is not always applicable to every feature or configuration.  In 
addition, I was aware that the K8 scenarios had project-specific testing.

My initial thought was that the disabled tests would be documented in the 
release notes and that the project would be required to contribute tests to 
functest and yardstick for the following release.

Subsequently, after some discussion, I realized that I had made a mistake and 
that this is something that the test working group should weigh in on, at a 
minimum.

Therefore, please disregard my earlier direction about disabling the tests.  
The tests are still required for all scenarios until the test working group 
and/or the TSC indicate otherwise.

Let me know if you have any questions. Sorry for the confusion.

David

--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride



--
Heather Kirksey
Director, OPNFV
Mobile: +1.512.917.7938
Email/Google Talk: 
hkirk...@linuxfoundation.org<mailto:hkirk...@linuxfoundation.org>
Skype: HeatherReneeKirksey
IRC: HKirksey

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

[opnfv-tech-discuss] [Functest] Tagging and docker build completed for Danube.1.0

[Jose Lausuch]

Hi,

Functest repo ready with tags:
danube.1.0 : 
https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.0
danube.1.RC1: 
https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.RC1

Docker image built with tag "danube.1.0"
https://hub.docker.com/r/opnfv/functest/tags/


Thanks,
Jose
___
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] Tagging and docker build completed for Danube.1.0

[Jose Lausuch]

Hi,

I did it manually from the latest built “stable” image when I tagged the repo. 
The Jenkins job we have allows you to do that automatically specifying the tag 
in the RELEASE_VERSION field (see below).

You might need rights in Jenkins to run this job. If you have problems let me 
know and I can trigger the build for you.


[cid:image001.png@01D2AA58.4D0DA6F0]


From: Yujun Zhang (ZTE) [mailto:zhangyujun+...@gmail.com]
Sent: Friday, March 31, 2017 17:22 PM
To: Jose Lausuch; TECH-DISCUSS OPNFV
Subject: Re: [opnfv-tech-discuss] [Functest] Tagging and docker build completed 
for Danube.1.0

Hi, Jose,

When will the docker build with tag be triggered?

Besides tagging in git, is there anything else  required to make it happen?

On Fri, Mar 31, 2017 at 10:44 PM Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi,

Functest repo ready with tags:
danube.1.0 : 
https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.0
danube.1.RC1: 
https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.RC1

Docker image built with tag “danube.1.0”
https://hub.docker.com/r/opnfv/functest/tags/


Thanks,
Jose
___
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
--
Yujun Zhang
___
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] Tagging and docker build completed for Danube.1.0

[Jose Lausuch]

Yes, sorry about that. I forgot we already use the branch name for that field 
by default. Thanks Kubi for pointing that out.
Jose

From: Gaoliang (kubi) [mailto:jean.gaoli...@huawei.com]
Sent: Saturday, April 01, 2017 03:22 AM
To: Yujun Zhang; Jose Lausuch; Soni, Anand Kumar via opnfv-tech-discuss
Subject: Re: [opnfv-tech-discuss] [Functest] Tagging and docker build completed 
for Danube.1.0

It should be "1.0".  I tried with "danube1.0",  the result was 
"danube.danube<http://danube.danube>.1.0"

regards
kubi

Sent from HUAWEI AnyOffice
发件人：Yujun Zhang
收件人：Jose Lausuch,Soni, Anand Kumar via opnfv-tech-discuss,
时间：2017-04-01 08:55:09
主题:Re: [opnfv-tech-discuss] [Functest] Tagging and docker build completed for 
Danube.1.0

Hi, Jose

Thanks for the hint. Should RELEASE_VERSION be `1.0` or `danube.1.0`. It seems 
the release name is automatically prefixed in jjb.


# Get tag version
echo "Current branch: $BRANCH"

if [[ "$BRANCH" == "master" ]]; then
DOCKER_TAG="latest"
else
if [[ -n "${RELEASE_VERSION-}" ]]; then
release=${BRANCH##*/}
DOCKER_TAG=${release}.${RELEASE_VERSION}
# e.g. colorado.1.0, colorado.2.0, colorado.3.0
else
DOCKER_TAG="stable"
fi
fi

On Sat, Apr 1, 2017 at 1:52 AM Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi,

I did it manually from the latest built “stable” image when I tagged the repo. 
The Jenkins job we have allows you to do that automatically specifying the tag 
in the RELEASE_VERSION field (see below).

You might need rights in Jenkins to run this job. If you have problems let me 
know and I can trigger the build for you.


[cid:image001.png@01D2AA58.4D0DA6F0]


From: Yujun Zhang (ZTE) 
[mailto:zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>]
Sent: Friday, March 31, 2017 17:22 PM
To: Jose Lausuch; TECH-DISCUSS OPNFV
Subject: Re: [opnfv-tech-discuss] [Functest] Tagging and docker build completed 
for Danube.1.0

Hi, Jose,

When will the docker build with tag be triggered?

Besides tagging in git, is there anything else  required to make it happen?

On Fri, Mar 31, 2017 at 10:44 PM Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi,

Functest repo ready with tags:
danube.1.0 : 
https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.0
danube.1.RC1: 
https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.RC1

Docker image built with tag “danube.1.0”
https://hub.docker.com/r/opnfv/functest/tags/


Thanks,
Jose
___
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
--
Yujun Zhang
--
Yujun Zhang
___
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] Security Scanning

[Jose Lausuch]

Hi Luke,

We should of course keep your test case and if you had time or anyone who wants 
to take it, we could try to make it run on other installers as well. We have 
now an abstraction layer to connect to the deployed nodes regardless of the 
installer, we could probably adapt the code to use it and make it “installer 
agnostic”.  There are also a few things I’d like to expect from the test case 
as Functest has evolved, it would be great that the test case adapts to it.

How will be your availability for Euphrates? If you don’t have much time maybe 
we could propose it as an intern project.

Regards,
Jose



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Luke Hinds
Sent: Monday, April 03, 2017 09:36 AM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [functest] Security Scanning

Hi Functest'ers,

I am aware I have not been as active on security scanning as I originally 
hoped, largely due to being v-busy working on upstream. I have also not seen 
much uptake in contributions from others or any requests for support or 
enhancements to make from operators / users of OPNFV.

With the above snippet in mind, would you like to revisit the projects use in 
functest? I am not saying I wish to decommission, as I put quite a good number 
of hours into the code, but at the same time I am aware my contributions have 
not been very active and I am not sure if that will change in the foreseeable 
future. You might see otherwise and like to enhance it further, so it seems a 
discussion could be worthwhile.

If you would like we could have this as a topic on a functest meeting or 
alternately I will be at the plugfest too.

Cheers,

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

Re: [opnfv-tech-discuss] [Pharos] Bandwidth expectations for OPNFV Pharos labs

[Jose Lausuch]

Hi Bryan,

I'm afraid we don't have those numbers. As far as Functest is concerned, it 
only needs to download the latest Docker image before running the container 
(<1GB) and when it's running the test cases, it doesn't need to pull many 
things from the internet, maybe a small image or some packages. Functest is 
mostly about API calls towards the deployed system, so don't expect high load 
during its execution.

I would say something similar happens with the installers, you will need to 
pull the corresponding ISO from artifacts repo, which could take around 3-4GB.

Regards,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of SULLIVAN, 
BRYAN L
Sent: Wednesday, April 12, 2017 22:47 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [Pharos] Bandwidth expectations for OPNFV Pharos 
labs

Hi all,

We are building out our own Pharos labs (finally!) and need to know what the 
typical expectations are for the load that the external gateway will experience 
during the CI/CD phase, in which a lot of packages etc may be pulled from the 
net, or during Functest in which other things may be pulled. Do we capture any 
stats on network usage during CI/CD/Functest runs? This info would be very 
valuable to document if not.

Also, to reduce the bandwidth, are there are specific recommendations/guides as 
to how to setup a local package proxy/cache? If possible, we would prefer to be 
able to do this without reconfiguring how it works for the different OPNFV 
installers.

Thanks,
Bryan Sullivan | AT&T

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

Re: [opnfv-tech-discuss] [test-wg] Notes from OPNFV Plugfest meeting - "Testing group Euphrates collaborative work"

[Jose Lausuch]

Hi,

The Functest team is going to work on providing OpenID authentication to the 
TEST API and also the functionality of uploading a json file using the API with 
results to be pushed to the DB. We commit to have it ready 1-2 weeks before the 
OPNFV summit. We would like to implement this functions besides Dovetail 
decision of using Refstack toolchain or not, we want to provide this 
functionality to the community anyway, which could be used also in further 
plugfests.

Regards,
Jose



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Wenjing Chu
Sent: Tuesday, May 02, 2017 01:16 AM
To: Cooper, Trevor; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [test-wg] Notes from OPNFV Plugfest meeting - 
"Testing group Euphrates collaborative work"

I have a question that we didn’t have a chance to loop back while we were in 
the plugfest.
Did the discussion on test API’s extension on login with credentials reached a 
conclusion that can be implemented in time for CVP?
Jose, Serena, can you give an update?

Thanks.
Wenjing

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Cooper, Trevor
Sent: Friday, April 28, 2017 7:36 AM
To: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [test-wg] Notes from OPNFV Plugfest meeting - 
"Testing group Euphrates collaborative work"

Status of Danube and what improved

1. landing page
- 
http://testresults.opnfv.org/reporting2/reporting/index.html
- 
http://testresults.opnfv.org/reporting2/reporting/index.html#!/landingpage/table
§ Meaning of info displayed? Test ran, test 
passed … agree for consistency … TBD

2. catalogue - diagram with roll-over
- 
http://testresults.opnfv.org/reporting2/reporting/index.html#!/select/visual
- All PTLs to review if test cases are valid and if not 
remove
- Add short description that is human readable (add API 
field)
○ Define test domain categories - start by using labels 
on test ecosystem diagram

3. Stress tests - video of presentation is available - simultaneous 
vPING which increases until system fails

4. Documentation
○ Ecosystem diagram
○ Testing guide
○ Add agenda item to TWG in June (2 sessions on how to 
improve)
○ New test projects … add to common docs
○ Developer guide - move to docs

5. Reporting status / dashboard
○ Bottlenecks TBD?

6. Bitergia
○ Morgan meeting 10th May
○ 
https://wiki.opnfv.org/display/testing/Result+alignment+for+ELK+post-processing
○ Add to TWG agenda next week to revisit

Wish list for Infra group

- One POD dedicated to long duration tests (with reservation 
mechanism)

- Per installer
○ Stable of previous release
○ Master

- OPNFV POD on demand for tester (before merging)
○ Per installer if possible
○ Infra group working on it
○ Today can fill a ticket to ask if there is a free 
resource

Micro services
- Deploy VNF
○ Retrieve image
○ Deploy
○ Prebuild image with tools - standardise on a framework
○ Take image and copy over tools - Ansible (infra doing 
this with Open Stack Ansible)
○ Catalog of roles for Ansible?
§ Ansible Galaxy is a tool for deploying 
and managing roles
□ e.g. Install TREX TG
□ Turn on live migration in Nova

- Test generator?

- Collect / display results
○ Test API and DB
○ Reuse collectd lib for VNF KPIs

- Analytics of results

- What APIs to expose to other test projects?
○ Functest
§ Deploy orchestrator VNF
§ Use Traffic gen and generate load


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

Re: [opnfv-tech-discuss] [Danube][Functest][Apex][Nosdn-nofeature-ha] Functest docker fails

[Jose Lausuch]

Hi Tuan,

Are you using latest tag of the docker image? We are currently working on 
refactoring some code at the moment, so we can take action to solve that. Could 
you provide more console logs?

In the meantime, you can use danube.1.0 instead of latest.

Thanks,
Jose



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of luong h?u tu?n
Sent: Saturday, May 06, 2017 16:34 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [Danube][Functest][Apex][Nosdn-nofeature-ha] 
Functest docker fails

Hi,

When i run "functest prepare env" , it raises an error:

The request you have made requires authentication. (HTTP 401)

I source the $cred before that. Does any one know about this problem in 
functest.

Br,

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

Re: [opnfv-tech-discuss] [Danube][Functest][Apex][Nosdn-nofeature-ha] Functest docker fails

[Jose Lausuch]

Hi,

+Juha (Nokia)

Sure, please provide that info and make sure you have connectivity from the 
jumphost to the admin (api) network of your Apex deployment.

Thanks,
Jose


From: lương hữu tuấn 
Sent: May 7, 2017 15:20
To: Jose Lausuch
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Danube][Functest][Apex][Nosdn-nofeature-ha] 
Functest docker fails

Hi Jose,

I will access to the lab tomorrow for more information, e.g. docker image tag, 
log file, etc.

 As i remember well, the error happens when running check_os.sh. I use the 
creds of overcloud, all the checks before check_os run well. It seemed like it 
failed when trying to authenticate with keystone through auth_url that is 
provided within overcloud creds.

Br,

Tuan/Nokia

On Sun, May 7, 2017 at 1:02 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi Tuan,

Are you using latest tag of the docker image? We are currently working on 
refactoring some code at the moment, so we can take action to solve that. Could 
you provide more console logs?

In the meantime, you can use danube.1.0 instead of latest.

Thanks,
Jose



From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto: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 luong h?u tu?n
Sent: Saturday, May 06, 2017 16:34 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] [Danube][Functest][Apex][Nosdn-nofeature-ha] 
Functest docker fails

Hi,

When i run "functest prepare env" , it raises an error:

The request you have made requires authentication. (HTTP 401)

I source the $cred before that. Does any one know about this problem in 
functest.

Br,

Tuan/Nokia

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

Re: [opnfv-tech-discuss] 答复: [Danube][Functest][Apex][Nosdn-nofeature-ha] Functest docker fails

[Jose Lausuch]

Hi,

It seems that your “old” credentials file had a problem in the AUTH_URL and 
check_os failed to parse the IP and Port. We are working on making that 
connectivity check more robust for the coming release.

Thanks,
Jose

From: lương hữu tuấn [mailto:tuantulu...@gmail.com]
Sent: Monday, May 08, 2017 06:28 AM
To: wangwulin
Cc: Jose Lausuch; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: 答复: [opnfv-tech-discuss] 
[Danube][Functest][Apex][Nosdn-nofeature-ha] Functest docker fails

Hi Wang,

Thank you for instruction. It works now for me after deleting the creds file. 
Could you provide more information about the scenario of this fail when 
sourcing openstack.creds on docker container? Why after sourcing that file and 
env fails when preparing?

Br,

Tuan/Nokia

On Mon, May 8, 2017 at 11:37 AM, wangwulin 
mailto:wangwu...@huawei.com>> wrote:
Hi Tuan,

1) The step of “source $creds” is not essential for cli “functest env prepare”, 
because “functest env prepare” will try to fetch the overcloudrc automatically 
and source it before running check_os.sh.

2) Could you please delete the file “openstack.creds” first, and then rerun the 
cli “functest env prepare”.

Please have a try and tell me if it still does not work.

Thank you.
Linda Wang


发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>]
 代表 l??ng h?u tu?n
发送时间: 2017年5月8日 15:59
收件人: Jose Lausuch
抄送: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: Re: [opnfv-tech-discuss] [Danube][Functest][Apex][Nosdn-nofeature-ha] 
Functest docker fails

Hi Jose,

Here is the error:

Unauthorized: The request you have made requires authentication. (HTTP 401) 
(Request-ID: req-135151d0-41e3-4f07-94b7-3e527b2de64c)

It happens when functest tries to prepare env and then verify OpenStack 
services:

2017-05-08 07:46:10,415 - prepare_env - INFO - 
==
2017-05-08 07:46:10,415 - prepare_env - INFO - Verifying OpenStack services...
2017-05-08 07:46:10,425 - prepare_env - INFO - Checking OpenStack endpoints:
The request you have made requires authentication. (HTTP 401) (Request-ID: 
req-99814475-3ca8-4c7e-a926-a5cc36ccb9b3)
2017-05-08 07:46:11,851 - prepare_env - INFO - >>Verifying connectivity to the 
public endpoint :...
2017-05-08 07:46:21,886 - prepare_env - ERROR - ERROR: Cannot talk to the 
public endpoint : .
2017-05-08 07:46:21,886 - prepare_env - ERROR - Problem while running 
'check_os.sh'.


Some other information:

- Version: Danube 1.0
- INSTALLER_IP: 
- INSTALLER_TYPE: apex
- This test is run on docker that is running on Jumphost.

Br,

Tuan



On Sun, May 7, 2017 at 3:32 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi,

+Juha (Nokia)

Sure, please provide that info and make sure you have connectivity from the 
jumphost to the admin (api) network of your Apex deployment.

Thanks,
Jose

From: lương hữu tuấn mailto:tuantulu...@gmail.com>>
Sent: May 7, 2017 15:20
To: Jose Lausuch
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [Danube][Functest][Apex][Nosdn-nofeature-ha] 
Functest docker fails

Hi Jose,

I will access to the lab tomorrow for more information, e.g. docker image tag, 
log file, etc.

 As i remember well, the error happens when running check_os.sh. I use the 
creds of overcloud, all the checks before check_os run well. It seemed like it 
failed when trying to authenticate with keystone through auth_url that is 
provided within overcloud creds.

Br,

Tuan/Nokia

On Sun, May 7, 2017 at 1:02 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi Tuan,

Are you using latest tag of the docker image? We are currently working on 
refactoring some code at the moment, so we can take action to solve that. Could 
you provide more console logs?

In the meantime, you can use danube.1.0 instead of latest.

Thanks,
Jose



From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto: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 luong h?u tu?n
Sent: Saturday, May 06, 2017 16:34 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] [Danube][Functest][Apex][Nosdn-nofeature-ha] 
Functest docker fails

Hi,

When i run "functest prepare env" , it raises an error:

The request you have made requires authentication. (HTTP 401)

I source the $cred before that. Does any one know about this problem in 
functest.

Br,

Tuan/Nokia



___
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-project-leads] [release][euphrates] Milestone 2 - test case documentation - May 22

[Jose Lausuch]

Hi,

Due to some major changes in Functest, we have DISABLED ALL the test cases 
belonging to FEATURE projects in MASTER jobs for the moment. Only Functest 
smoke test cases are running in CI (for now).

The reasoning behind is:

-  Functest team is working hard to make the framework more robust and 
reliable.

-  Housekeeping. Only the projects that need to see their test on CI 
will have to enable it.

-  To speed up the process of installer development as the CI loops 
will be faster.


It is possible to enable your test case again by following the procedure 
described here:
https://wiki.opnfv.org/pages/viewpage.action?pageId=8685677

In short, removing the flag “enabled: false” in testcases.yaml

The PTLs from the feature projects will be responsible for enabling the test 
cases, so please be aware of this. You just need to commit a patch in Functest 
repo to enable the test, but please do it when you think it makes sense to run 
it in CI (e.g. you are working on improving the test case or creating new ones).

IMPORTANT: It is mandatory that the test case returns the appropriate return 
value (==0 if success, !=0 if failure). This is the way to capture the failed 
tests in Functest.

Thanks,
Jose




From: opnfv-project-leads-boun...@lists.opnfv.org 
[mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Monday, May 15, 2017 20:00 PM
To: TECH-DISCUSS OPNFV; opnfv-project-leads
Subject: [opnfv-project-leads] [release][euphrates] Milestone 2 - test case 
documentation - May 22

OPNFV Feature Project Owners,

Test case documentation (MS2) is due in 1 week (May 
22).
  Please register your project with functest and document your test cases in 
the test case database, as described 
here.

In order to verify compliance, please respond to this email with a link to your 
test case documentation (e.g., for 
FDS).  
Note:  please send the link even if you are not changing your test cases from 
the previous release.

David

--
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] [Functest] Glance images from feature projects

[Jose Lausuch]

Hi,

This is addressed to all the feature projects that integrate tests in Functest.

The team is working on a mechanism to pre-download the needed images for all 
the test cases instead of downloading them while running the tests. This may 
potentially speed up the testing process and could help reusing what it is 
already available.

We would like to know what Glance images you will be using during your testing. 
Can you please fill this table with that information?
https://wiki.opnfv.org/display/functest/Glance+images+from+tests

Thanks,
Jose


___
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][doctor][releng] how to run experimental jobs

[Jose Lausuch]

Hi,

Your case is a good example of continuous development of your test cases. You 
need Functest support in CI and it makes sense to re-enable doctor-notification 
now. As I asked in my email to the tech-discuss, the PTLs are free to do that 
as soon as they need it. Please go ahead and remove the flag "enabled: false" 
in testcases.yaml.

For  [1], please note that the link is pointing to the latest job and the 
problem is different but I found what you mean in 
https://build.opnfv.org/ci/job/doctor-verify-apex-sample-master/230/console


For experimental jobs, you can overwrite testcases.yaml and 
config_functest.yaml by creating docker volumes pointing to the corresponding 
paths in the container.
If you want to add a new test case you can follow this guide:
https://wiki.opnfv.org/pages/viewpage.action?pageId=8685677


# Could we merge contents of testcases_yaml into 'config_functest.yaml'?
No. They have different purposes. The first defines the test cases and comply 
with a certain structure that the framework uses. The second is a bunch of 
parameters for common or specific configurations.


Thanks,
Jose



-Original Message-
From: Ryota Mibu [mailto:r-m...@cq.jp.nec.com] 
Sent: Wednesday, May 17, 2017 13:46 PM
To: Jose Lausuch
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: [functest][doctor][releng] how to run experimental jobs

Hi Jose and Functest team,


I'm wondering how we can run experimental jobs with functest in OPNFV CI 
pipeline. Could you help me figure out a solution?


There are two problems sharing the same root issue;

  1) Current Doctor verify jobs are failing due to "not supported" [1], after 
[2] got merged. I understand that all feature testcases, including doctor, are 
not tested in new OPNFV deployment (with OpenStack Ocata) yet, so cannot be 
enabled in daily CI jobs.

  2) We can run experimental tests (e.g. expand scenario support) by changing 
testcase_yaml for functest in local env. But, we don't know a programmatic way 
to having such experimental testing jobs in OPNFV CI.


The second one is the question I already asked in the last plugfest. I cannot 
fully understand your suggestion at the venue yet, and maybe the situation has 
been changed already... If I remember correctly, you suggested to use env 
parameter to update valuable. The logic can be found 
'functest/utils/constants.py'. However, seeing 'TierBuilder' class, it seems 
available for parameters in 'config_functest.yaml', but doesn't work for 
parameters in testcases_yaml. Should I have new testcase_yaml and run functest 
with 'functest_testcases_yaml='?

This approach provide us full flexibility of changing testcases_yaml, but also 
requires the pre-script for specific jobs in order to generate updated 
testcases_yaml by copying from original and changing specific parameter.

# Could we merge contents of testcases_yaml into 'config_functest.yaml'?


[FYI] The brief description of the current CI flow for doctor verify job is;

0. [gerrit/jenkins] patch uploaded, then Jenkins start the doctor verify job

1. [releng] in the job, 'functest-suite-builder' will be triggered with 
FUNCTEST_SUITE_NAME=

2. [releng] in this builder, "(...)/functest/ci/run_tests.py -t 
doctor-notification" will be executed in functest container

3. [functest] in the container, doctor test script is triggered after env 
setup

4. [doctor] execute testing scenario, while logs and exit status will be 
captured by functest


[1] 
https://build.opnfv.org/ci/job/doctor-verify-apex-sample-master/lastBuild/console
[2] https://gerrit.opnfv.org/gerrit/#/c/34833/


BR,
Ryota


___
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-tech-discuss Digest, Vol 34, Issue 11

[Jose Lausuch]

Hi Leopoldo,

The SFC test case needs to access the deployment to perform some actions. Do 
you have access to Fuel VM from your container? We use 10.20.0.2 by default. If 
you use a different IP you will need to specify it along with the password in 
the configuration.

Regards,
Jose


On 13 Jun 2017, at 23:15, Leopoldo Mauricio 
mailto:leomauri...@gmail.com>> wrote:

Hi Morgan and Manuel,

I've got the same error that Sanz has informed using both danube.1.0 and stable 
docker images.



When I do "python run_tests.py"

root@476c23c24e90:~# cd /home/opnfv/repos/sfc/sfc/tests/functest/
root@476c23c24e90:~/repos/sfc/sfc/tests/functest# python run_tests.py

I have the following error, which can also be found inside the logs

root@476c23c24e90:~# cat /home/opnfv/functest/results/sfc.log

2017-06-13 14:56:34,607 - paramiko.transport - ERROR - Secsh channel 1 open 
FAILED: No route to host: Connect failed
2017-06-13 14:56:34,610 - SSH utils - ERROR - (2, 'Connect failed')
Traceback (most recent call last):
  File "./run_tests.py", line 189, in 
main(report=args.report)
  File "./run_tests.py", line 81, in main
installer_pwd=COMMON_CONFIG.installer_password)
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/factory.py", line 42, 
in get_handler
installer_pwd=installer_pwd)
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/fuel/adapter.py", 
line 26, in __init__
pkey_file=None)
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/manager.py", line 
327, in __init__
self.nodes = self.get_nodes()
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/fuel/adapter.py", 
line 159, in get_nodes
id, ip, name, status, roles, ssh_client, dict)
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/manager.py", line 
136, in __init__
sys_info = self.get_system_info()
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/manager.py", line 
246, in get_system_info
memory = self.run_cmd(cmd).partition('MemTotal:')[-1].strip().encode()
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/manager.py", line 
182, in run_cmd
_, stdout, stderr = (self.ssh_client.exec_command(cmd))
  File "/usr/local/lib/python2.7/dist-packages/paramiko/client.py", line 435, 
in exec_command
chan = self._transport.open_session(timeout=timeout)
AttributeError: 'NoneType' object has no attribute 'open_session'


Thanks for your support,

Leopoldo Mauricio


On Sun, Jun 11, 2017 at 9:00 AM, 
mailto:opnfv-tech-discuss-requ...@lists.opnfv.org>>
 wrote:
Send opnfv-tech-discuss mailing list submissions to

opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
or, via email, send a message with subject or body 'help' to

opnfv-tech-discuss-requ...@lists.opnfv.org<mailto:opnfv-tech-discuss-requ...@lists.opnfv.org>

You can reach the person managing the list at

opnfv-tech-discuss-ow...@lists.opnfv.org<mailto:opnfv-tech-discuss-ow...@lists.opnfv.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of opnfv-tech-discuss digest..."


Today's Topics:

   1. Re: SFC functionality test (Manuel Buil)
   2. RE :  SFC functionality test 
(morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>)
   3. Details for Summit registration etc (SULLIVAN, BRYAN L)


------

Message: 1
Date: Sat, 10 Jun 2017 17:41:10 +0200
From: Manuel Buil mailto:mb...@suse.com>>
To: Igor Jochem Sanz mailto:s...@gta.ufrj.br>>, Jose Lausuch
mailto:jose.laus...@ericsson.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] SFC functionality test
Message-ID: 
<1497109270.2763.4.ca...@suse.com<mailto:1497109270.2763.4.ca...@suse.com>>
Content-Type: text/plain; charset="UTF-8"

HI Igor,

That is strange. @Jose: Do you know what might be happening?

Could you check if you have the variable $creds? If you do "source
$creds", what do you get?

I will be busy this week in the OPNFV summit but could you try to
execute the test directly without functest?

To do so, inside the functest container, go to:

/home/opnfv/repos/sfc/sfc/tests/functest

And there, execute:

source $cerds
python?run_tests.py

That should execute the SFC tests

Regards,
Manuel

On Fri, 2017-06-09 at 15:28 -0300, Igor Jochem Sanz wrote:
> Hi Manuel.
>
> We ran everything as instructed, solved some issues but then we
> stumbled?
> upon the messages below. It looks like we nee

Re: [opnfv-tech-discuss] opnfv-tech-discuss Digest, Vol 34, Issue 11

[Jose Lausuch]

S val 37907480 ecr 952286334], length 0
17:27:48.454912 IP 10.20.0.8.35022 > 10.20.0.2.22: Flags [F.], seq 1817, ack 
4088, win 305, options [nop,nop,TS val 37907495 ecr 952286293], length 0
17:27:48.458424 IP 10.20.0.2.22 > 10.20.0.8.35022: Flags [F.], seq 4088, ack 
1818, win 247, options [nop,nop,TS val 952286397 ecr 37907495], length 0
17:27:48.458654 IP 10.20.0.8.35022 > 10.20.0.2.22: Flags [.], ack 4089, win 
305, options [nop,nop,TS val 37907496 ecr 952286397], length 0



Thanks for your support,

Leopoldo Mauricio


On Tue, Jun 13, 2017 at 12:42 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi Leopoldo,

The SFC test case needs to access the deployment to perform some actions. Do 
you have access to Fuel VM from your container? We use 10.20.0.2 by default. If 
you use a different IP you will need to specify it along with the password in 
the configuration.

Regards,
Jose



On 13 Jun 2017, at 23:15, Leopoldo Mauricio 
mailto:leomauri...@gmail.com>> wrote:

Hi Morgan and Manuel,

I've got the same error that Sanz has informed using both danube.1.0 and stable 
docker images.



When I do "python run_tests.py"

root@476c23c24e90:~# cd /home/opnfv/repos/sfc/sfc/tests/functest/
root@476c23c24e90:~/repos/sfc/sfc/tests/functest# python run_tests.py

I have the following error, which can also be found inside the logs

root@476c23c24e90:~# cat /home/opnfv/functest/results/sfc.log

2017-06-13 14:56:34,607 - paramiko.transport - ERROR - Secsh channel 1 open 
FAILED: No route to host: Connect failed
2017-06-13 14:56:34,610 - SSH utils - ERROR - (2, 'Connect failed')
Traceback (most recent call last):
  File "./run_tests.py", line 189, in 
main(report=args.report)
  File "./run_tests.py", line 81, in main
installer_pwd=COMMON_CONFIG.installer_password)
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/factory.py", line 42, 
in get_handler
installer_pwd=installer_pwd)
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/fuel/adapter.py", 
line 26, in __init__
pkey_file=None)
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/manager.py", line 
327, in __init__
self.nodes = self.get_nodes()
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/fuel/adapter.py", 
line 159, in get_nodes
id, ip, name, status, roles, ssh_client, dict)
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/manager.py", line 
136, in __init__
sys_info = self.get_system_info()
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/manager.py", line 
246, in get_system_info
memory = self.run_cmd(cmd).partition('MemTotal:')[-1].strip().encode()
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/manager.py", line 
182, in run_cmd
_, stdout, stderr = (self.ssh_client.exec_command(cmd))
  File "/usr/local/lib/python2.7/dist-packages/paramiko/client.py", line 435, 
in exec_command
chan = self._transport.open_session(timeout=timeout)
AttributeError: 'NoneType' object has no attribute 'open_session'


Thanks for your support,

Leopoldo Mauricio


On Sun, Jun 11, 2017 at 9:00 AM, 
mailto:opnfv-tech-discuss-requ...@lists.opnfv.org>>
 wrote:
Send opnfv-tech-discuss mailing list submissions to

opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
or, via email, send a message with subject or body 'help' to

opnfv-tech-discuss-requ...@lists.opnfv.org<mailto:opnfv-tech-discuss-requ...@lists.opnfv.org>

You can reach the person managing the list at

opnfv-tech-discuss-ow...@lists.opnfv.org<mailto:opnfv-tech-discuss-ow...@lists.opnfv.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of opnfv-tech-discuss digest..."


Today's Topics:

   1. Re: SFC functionality test (Manuel Buil)
   2. RE :  SFC functionality test 
(morgan.richo...@orange.com<mailto:morgan.richo...@orange.com>)
   3. Details for Summit registration etc (SULLIVAN, BRYAN L)


--

Message: 1
Date: Sat, 10 Jun 2017 17:41:10 +0200
From: Manuel Buil mailto:mb...@suse.com>>
To: Igor Jochem Sanz mailto:s...@gta.ufrj.br>>, Jose Lausuch
mailto:jose.laus...@ericsson.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] SFC functionality test
Message-ID: 
<1497109270.2763.4.ca...@suse.com<mailto:1497109270.2763.4.ca...@suse.com>>
Content-Type: text/plain; charset="UTF-8"

HI Igor,

That is strange. @Jose: Do you know what might be happening?

Could you check if you have the variabl

Re: [opnfv-tech-discuss] functest in master (euphrates milestone 3.1)

[Jose Lausuch]

That is great! Milestone passed successfully :)
/Jose


-Original Message-
From: Steven Pisarski [mailto:s.pisar...@cablelabs.com] 
Sent: Tuesday, June 20, 2017 20:20 PM
To: Tim Rozet; Raymond Paik; David McBride
Cc: TECH-DISCUSS OPNFV; Jose Lausuch; ollivier cedric
Subject: Re: functest in master (euphrates milestone 3.1)

Awesome, thanks for the update!

On 6/20/17, 11:54 AM, "Tim Rozet"  wrote:

Hi Ray, David,
It looks like SNAPS/Functest is now fixed.  I see our master healthcheck 
passed here:
https://gerrit.opnfv.org/gerrit/#/c/35999/

Thanks Steve, Jose and Cedric for fixing this during the busy summit week.

Tim Rozet
Red Hat SDN Team



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

Re: [opnfv-tech-discuss] Multiple docker containers from one project

[Jose Lausuch]

+1

No need for an additional repo, the logic can be in Releng..
Functest will probably move to different containers some time soon, so that is 
something we could also leverage.

-Jose-


On 23 Jun 2017, at 18:39, Julien 
mailto:julien...@gmail.com>> wrote:

Agree,

If StorPerf can list some rules and examples, current scripts can be adapted 
for multiple docker image building and other project can use this type of 
changes. It is not deserved to add a new repo just for build a new image.



Fatih Degirmenci 
mailto:fatih.degirme...@ericsson.com>>于2017年6月21日周三
 上午2:26写道：
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifacts for the projects from releng point of view.

Once you decide what to do for storperf, we can take a look and adapt docker 
build job/script to build storperf images, create additional repos on docker 
hub to push images and activate the builds when things are ready.

/Fatih

On 20 Jun 2017, at 19:18, Beierl, Mark 
mailto:mark.bei...@dell.com>> wrote:

Hello,

I'd like to poll the various groups about ideas for how to handle this 
scenario.  I have interns working on breaking down services from StorPerf into 
different containers.  In one case, it will be a simple docker compose that is 
used to fire up existing containers from the repos, but the other case requires 
more thought.

We are creating a second container (storperf-reporting) that will need to be 
built and pushed to hub.docker.com.  Right now the 
build process for docker images lives in releng, and it only allows for one 
image to be built.  Should I be requesting a second git repo in this case, or 
should we look at changing the releng process to allow multiple docker images 
to be build?

Regards,
Mark

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

___
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 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] Status of Functest / Apex

[Jose Lausuch]

Hi David,

This is what I can say from Functest side:

Nosdn-nofeature scenario is 100% working now after removing domino test case.

There is a tempest error which fails in odl_l3-nofeature, maybe due to an odl 
bug… no sure… See logs [1]
tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops
Logs here:

nosdn-fdio scenarios don’t pass healthcheck. However, odl-fdio scenarios do, 
but have some other problems on later tests.


We should notice that this blacklist [2] is currently being applied for Tempest 
in Danube. This file hasn’t been maintained very much in Danube. Maybe it’s a 
bit too late but for Master we are planning to remove all the blacklisted test 
cases as a cleanup mechanism and I bet most of the bugs listed here are already 
fixed upstream.

Regards,
Jose

[1] 
http://artifacts.opnfv.org/logs/functest/lf-pod1/danube/2017-06-26_06-34-27/tempest/tempest.log
[2] 
https://git.opnfv.org/functest/plain/functest/opnfv_tests/openstack/tempest/custom_tests/blacklist.txt


From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Sunday, July 02, 2017 01:21 AM
To: Daniel Radez ; Jose Lausuch ; 
Tim Rozet 
Cc: TECH-DISCUSS OPNFV 
Subject: Re: Status of Functest / Apex

+Dan

On Sat, Jul 1, 2017 at 4:17 PM David McBride 
mailto:dmcbr...@linuxfoundation.org>> wrote:
Tim and Jose,

Have Functest results improved for Apex scenarios? Any remaining issues with 
either Apex/Triple O or with the Functest framework that we should be aware of? 
 Thanks.

David
--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride
--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto: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] [Dovetail] sdnvpn test cases with dovetail.cvp.0.1.0 throw an error

[Jose Lausuch]

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 
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 
mailto: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
主题: 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 
mailto:srikanth.vavilapa...@ericsson.com>>; 
opnf

Re: [opnfv-tech-discuss] Multiple docker containers from one project

[Jose Lausuch]

Hi Mark,

I would incline for option 1), it sounds better than searching for a file. We 
could define specific values of DOCKERFILE var for each project.

/Jose


From: Beierl, Mark [mailto:mark.bei...@dell.com]
Sent: Thursday, July 06, 2017 16:18 PM
To: opnfv-tech-discuss@lists.opnfv.org
Cc: Julien ; Fatih Degirmenci 
; Jose Lausuch 
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Ideas:


  *   Change the DOCKERFILE parameter in releng jjb so that it can accept a 
comma delimited list of Dockerfile names and paths.  Problem with this, of 
course, is how do I default it to be different for StorPerf vs. Functest, etc?
  *   Change the opnfv-docker.sh to search for the named DOCKERFILE in all 
subdirectories.  This should cover the .aarch64 and vanilla docker file cases.

Please +1/-1 or propose other ideas, thanks!

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 Jun 24, 2017, at 04:05, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

+1

No need for an additional repo, the logic can be in Releng..
Functest will probably move to different containers some time soon, so that is 
something we could also leverage.

-Jose-


On 23 Jun 2017, at 18:39, Julien 
mailto:julien...@gmail.com>> wrote:

Agree,

If StorPerf can list some rules and examples, current scripts can be adapted 
for multiple docker image building and other project can use this type of 
changes. It is not deserved to add a new repo just for build a new image.



Fatih Degirmenci 
mailto:fatih.degirme...@ericsson.com>>于2017年6月21日周三
 上午2:26写道：
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifacts for the projects from releng point of view.

Once you decide what to do for storperf, we can take a look and adapt docker 
build job/script to build storperf images, create additional repos on docker 
hub to push images and activate the builds when things are ready.

/Fatih

On 20 Jun 2017, at 19:18, Beierl, Mark 
mailto:mark.bei...@dell.com>> wrote:
Hello,

I'd like to poll the various groups about ideas for how to handle this 
scenario.  I have interns working on breaking down services from StorPerf into 
different containers.  In one case, it will be a simple docker compose that is 
used to fire up existing containers from the repos, but the other case requires 
more thought.

We are creating a second container (storperf-reporting) that will need to be 
built and pushed to hub.docker.com<http://hub.docker.com/>.  Right now the 
build process for docker images lives in releng, and it only allows for one 
image to be built.  Should I be requesting a second git repo in this case, or 
should we look at changing the releng process to allow multiple docker images 
to be build?

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>

___
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<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

Re: [opnfv-tech-discuss] Multiple docker containers from one project

[Jose Lausuch]

Hi Mark,

I wonder if that docker-list.txt should be located in each project’s repo... I 
know you want to avoid having patches in Releng and have the control in your 
repo, but I think that is the purpose of Release engineering :)

Also, that file is useless without the Releng mechanism, so if I clone Storperf 
and see that file in there, I won’t understand the purpose of as it isn’t 
really part of storperf framework/code... it can’t work without OPNFV CI.

The idea is good, but we could try to move that logic to Releng. For example, 
something like this:
http://paste.openstack.org/raw/614708/

Projects do not add new Dockerfiles so often, so it won’t really be a burden to 
put that file in a central place. Besides, it also exposes visibility to what 
all the projects are building.

For those Dockerfiles that are .patch we have to pay special attention as they 
can’t be built as is, but that logic can be done in the docker script.


/Jose



From: Chigang (Justin) [mailto:chig...@huawei.com]
Sent: Friday, July 07, 2017 09:02 AM
To: Yujun Zhang (ZTE) ; Jose Lausuch 
; Beierl, Mark ; 
opnfv-tech-discuss@lists.opnfv.org
Subject: 答复: [opnfv-tech-discuss] Multiple docker containers from one project

+1

We have used automated build  docker images in  docker hub account[1]. But each 
github repository just builds a docker image.
If it is supported, it will be great.

Regards
Justin

https://hub.docker.com/search/?isAutomated=0&isOfficial=0&page=1&pullCount=0&q=Compass4nfv&starCount=0


发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Yujun Zhang (ZTE)
发送时间: 2017年7月6日 23:42
收件人: Jose Lausuch; Beierl, Mark; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Does anybody consider using the build service from docker-hub[1] ?

It supports multiple Dockerfile from same repository and easy to integrate with 
OPNFV Github mirror.

[1]: https://docs.docker.com/docker-hub/builds/


On Thu, Jul 6, 2017 at 11:02 PM Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi Mark,

I would incline for option 1), it sounds better than searching for a file. We 
could define specific values of DOCKERFILE var for each project.

/Jose


From: Beierl, Mark [mailto:mark.bei...@dell.com<mailto:mark.bei...@dell.com>]
Sent: Thursday, July 06, 2017 16:18 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Julien mailto:julien...@gmail.com>>; Fatih Degirmenci 
mailto:fatih.degirme...@ericsson.com>>; Jose 
Lausuch mailto:jose.laus...@ericsson.com>>
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Ideas:


  *   Change the DOCKERFILE parameter in releng jjb so that it can accept a 
comma delimited list of Dockerfile names and paths.  Problem with this, of 
course, is how do I default it to be different for StorPerf vs. Functest, etc?
  *   Change the opnfv-docker.sh to search for the named DOCKERFILE in all 
subdirectories.  This should cover the .aarch64 and vanilla docker file cases.

Please +1/-1 or propose other ideas, thanks!

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 Jun 24, 2017, at 04:05, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

+1

No need for an additional repo, the logic can be in Releng..
Functest will probably move to different containers some time soon, so that is 
something we could also leverage.

-Jose-


On 23 Jun 2017, at 18:39, Julien 
mailto:julien...@gmail.com>> wrote:

Agree,

If StorPerf can list some rules and examples, current scripts can be adapted 
for multiple docker image building and other project can use this type of 
changes. It is not deserved to add a new repo just for build a new image.



Fatih Degirmenci 
mailto:fatih.degirme...@ericsson.com>>于2017年6月21日周三
 上午2:26写道：
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifacts for the projects from releng point of view.

Once you decide what to do for storperf, we can take a look and adapt docker 
build job/script to build storperf images, create additional repos on docker 
hub to push images and activate the builds when things are ready.

/Fatih

On 20 Jun 2017, at 19:18, Beierl, Mark 
mailto:mark.bei...@dell.com>> wrote:
Hello,

I'd like to poll the various groups about ideas for how to handle this 
scenario.  I have interns working on breaking down services from StorPerf into 
different containers.  In one case, it will be a simple docker compose that is 
used to fire up existing containers from the repos, but the other case requires 
more thought.

We are creating a second container (storperf-reporting) 

Re: [opnfv-tech-discuss] Multiple docker containers from one project

[Jose Lausuch]

s,
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 Jul 7, 2017, at 11:01, Xuan Jia 
mailto:jason.jiax...@gmail.com>> wrote:

+1 Using build service from docker-hub

On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) 
mailto:zhangyujun+...@gmail.com>> wrote:
Does anybody consider using the build service from docker-hub[1] ?

It supports multiple Dockerfile from same repository and easy to integrate with 
OPNFV Github mirror.

[1]: https://docs.docker.com/docker-hub/builds/


On Thu, Jul 6, 2017 at 11:02 PM Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:
Hi Mark,

I would incline for option 1), it sounds better than searching for a file. We 
could define specific values of DOCKERFILE var for each project.

/Jose


From: Beierl, Mark [mailto:mark.bei...@dell.com<mailto:mark.bei...@dell.com>]
Sent: Thursday, July 06, 2017 16:18 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Julien mailto:julien...@gmail.com>>; Fatih Degirmenci 
mailto:fatih.degirme...@ericsson.com>>; Jose 
Lausuch mailto:jose.laus...@ericsson.com>>
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Ideas:


  *   Change the DOCKERFILE parameter in releng jjb so that it can accept a 
comma delimited list of Dockerfile names and paths.  Problem with this, of 
course, is how do I default it to be different for StorPerf vs. Functest, etc?
  *   Change the opnfv-docker.sh to search for the named DOCKERFILE in all 
subdirectories.  This should cover the .aarch64 and vanilla docker file cases.

Please +1/-1 or propose other ideas, thanks!

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 Jun 24, 2017, at 04:05, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

+1

No need for an additional repo, the logic can be in Releng..
Functest will probably move to different containers some time soon, so that is 
something we could also leverage.

-Jose-


On 23 Jun 2017, at 18:39, Julien 
mailto:julien...@gmail.com>> wrote:

Agree,

If StorPerf can list some rules and examples, current scripts can be adapted 
for multiple docker image building and other project can use this type of 
changes. It is not deserved to add a new repo just for build a new image.




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

Re: [opnfv-tech-discuss] Multiple docker containers from one project

[Jose Lausuch]

More inline

From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Tuesday, July 11, 2017 16:40 PM
To: Jose Lausuch ; Fatih Degirmenci 
; Beierl, Mark 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Inline…

From: Jose Lausuch mailto:jose.laus...@ericsson.com>>
Date: Tuesday, July 11, 2017 at 4:27 AM
To: Fatih Degirmenci 
mailto:fatih.degirme...@ericsson.com>>, "Beierl, 
Mark" mailto:mark.bei...@dell.com>>, "Alec Hothan 
(ahothan)" mailto:ahot...@cisco.com>>
Cc: 
"opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: RE: [opnfv-tech-discuss] Multiple docker containers from one project

Hi,

We excluded incremental tags because we overflooded our docker repos (I had to 
remove ~300 tags manually once in Functest docker repo). For projects that 
merge patches almost every day, that approach is unmaintainable.

This is what we are currently following:

latest:
built from latest master. It is used in CI master jenkins jobs --> 
Continuous Delivery

[Alec]
Does latest always refer to the “current development release” – e.g. it would 
be Euphrates as of today?
How about latest for Danube?
[Jose]
More or less, but Euphrates is not released yet. So it is latest-master, which 
will become Euphrates in the end.
latest for Danube = stable tag


stable:
built from “latest” patch of stable branch. It doesn’t change so 
frequently but it contains latest bugfixes from stable branches. It is used in 
CI Danube jenkins jobs.
[Alec]
What is defined as the “stable branch”? Is it the danube branch as of today?
Is it needed to have a stable for euphrates or for Colorado?
[Jose]
Yes. Stable tag refers to the latest state of stable/danube currently and 
stable/euphrates once we branch the repos. This is meant for CI testing. The 
released image won’t be called “stable”.

danube.X.0
built once the project is ready for release. It must be done manually 
by the PTL or Jenkins admin. Not tested directly in CI, but it should be the 
same image as stable tag at the end of the release cycle.

[Alec]
Is there a manifest per project somewhere that indicates what artifacts go into 
a release for that project?
This along with a project list for the release will provide exactly the full 
content of a release.
[Jose]
Not explicitly
In Functest case, everything is in our Dockerfile and requirements.txt. That 
will conform the content of the Functest release (a docker image). I guess it’s 
applicable for other projects.


A few of the questions I raised in a previous email:

  *   do force every project to have a git tag that matches the container tag ( 
this obviously does not apply to non unique container tags such as “stable” or 
“latest”)? Without that, it is very difficult to track a container version to a 
git repo commit.
[Jose] I can talk only for Functest, and we try to do it, but we need all the 
repos to be tagged when we build the image.


  *   How are incremental versions supported for a given release (e.g. when 
danube 3.0 comes out, how can a project push out a new maintenance release of a 
container say 2 days after the danube 3.0 was released), we can’t just 
overwrite the “danube.3.0” container
[Jose] Good point.. maybe we should create danube.3.1



For the concern:
“As for the git clone issue, or pip install from git, there is no tag provided. 
 This is a concern that I have with the way there is a separation of docker 
build (in releng) and git clone.  We cannot actually rebuild from a label at 
this time.”
If you are doing a git clone of your repository to be installed by pip. You can 
setup arguments in your Dockerfile. Example:

   ARG BRANCH=master
   RUN git clone --depth 1 -b $BRANCH 
https://gerrit.opnfv.org/gerrit/storperf

BRANCH argument can be overwritten by the docker build command (default is 
‘master’ in this example) and it’s exactly what the jenkins job is doing.

[Alec]
That’s good but we still have to solve the resulting container tag 
appropriately ;-)


Thanks,

/Alec






Regards,
Jose


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 Fatih 
Degirmenci ARG BRANCH=master
Sent: Monday, July 10, 2017 18:24 PM
To: Beierl, Mark mailto:mark.bei...@dell.com>>; Alec 
Hothan (ahothan) mailto:ahot...@cisco.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Hi,

About the tagging question; in the past we tagged all the images we built and 
stored on Docker hub. The tags for the intermediate versions were set 
incrementally and applied automatically by the build jo

Re: [opnfv-tech-discuss] [test-wg] docker container versioning

[Jose Lausuch]

Hi,

Is there time to discuss this during the next infra wg meeting on Monday? 
Although the test projects are the main ones using docker containers, we are 
talking about versioning here, which I believe is topic the Infra team should 
address.

I also would like to add to the agenda:
  -  decision on where to host the docker build scripts (common one or 
project´s repo?). It has been proposed but not decided.

Thanks,
Jose

 

> On 12 Jul 2017, at 20:10, Alec Hothan (ahothan)  wrote:
> 
> July/August is tricky with PTOs.
> Perhaps we should start the discussion by email on this mailer and discuss 
> about it in 2 weeks at the test-wg meeting? 
> Do you guys usually use a text document reviewed with gerrit to 
> discuss/collaborate on a spec? Or any other method? Please let me know and I 
> can get a head start on this.
> 
> Thanks
> 
>  Alec
> 
> On 7/12/17, 8:54 AM, "morgan.richo...@orange.com" 
>  wrote:
> 
>I will be in PTO too :)
> 
>Unfortunately the weekly meeting was today at 8 UTC (APAC slot)
>we will use the slot of tomorrow to organize an ad-hoc meeting with 
>Bitergia on result vizualization
>not sure we will have 15 minutes for another topic
> 
>It is maybe possible to organize an ad-hoc meeting on this topic after 
>the point with Bitergia?
> 
>Do not hesitate to modify directly the agenda at your convenience 
>(https://wiki.opnfv.org/display/meetings/Test+Working+Group+Weekly+Meeting)
> 
>/Morgan
> 
> 
> 
>On 12/07/2017 17:43, Alec Hothan (ahothan) wrote:
>> Morgan,
>> 
>> Unfortunately, I won’t be able to attend next week (on PTO).
>> Can this be squeezed into tomorrow’s meeting (July 13)? We could shorten it 
>> and follow up with a separate meeting or on email/IRC.
>> 
>> Thanks
>> 
>>   Alec
>> 
>> 
>> 
>> On 7/12/17, 8:32 AM, "morgan.richo...@orange.com" 
>>  wrote:
>> 
>> topic added for the next meeting (20th of July)
>> https://wiki.opnfv.org/display/meetings/Test+Working+Group+Weekly+Meeting
>> 
>> Mark and Jose are already involved in several activities dealing with
>> docker.
>> Cedric has a good view on this topic.
>> 
>> /Morgan
>> 
>> On 12/07/2017 17:27, Alec Hothan (ahothan) wrote:
>>> I’d like to add this topic to the next weekly meeting of the test-wg and 
>>> would like to know if anybody else from test-wg would be interested to help 
>>> redact a proposal for enhancing the docker container versioning and build 
>>> workflow in OPNFV. As I understand this will only concern a subset of test 
>>> projects for now at least.
>>> 
>>> To the agenda:
>>> - Problem statement for those who have not followed the email thread
>>> - General goals
>>> - Get feedback from current projects wrt current container versioning 
>>> scheme, Q&A
>>> - Who would like to participate and how to proceed
>>> We might need about 15’ to go over these points (no question we will need 
>>> more detailed discussion which can be better done through email or IRC 
>>> after that meeting).
>>> 
>>> What would be great is for those concerned project owners to think about 
>>> how the requirements of their respective project wrt to their container 
>>> versioning:
>>> - How often do you think you need to build your containers
>>> - Any hurdles experienced while building/managing container images
>>> - How do your container images relate to OPNFV releases (e.g. do you have a 
>>> 1 container version per release of do you prefer to have 1 version that 
>>> tackles all supported releases)
>>> - How do you “bundle” your containers to OPNFV releases (or how do your 
>>> users know what version of container to use for a given release)
>>> 
>>> We can also use email to get a head start or for those who cannot attend 
>>> the meeting.
>>> I hope we can get a draft proposal by early August.
>>> 
>>> Thanks
>>> 
>>>   Alec
>>> 
>>> 
>>> On 7/11/17, 8:29 AM, "Fatih Degirmenci"  wrote:
>>> 
>>> +1 to "Can we work on a proposal and get every project that deals with 
>>> containers involved?"
>>> 
>>> It is mainly test projects who use containers so I again let testing 
>>> community to take the lead and point you to where/how the conversation 
>>> started.
>>> 
>>> We can then try to generalize it later on.
>>> 
>>> /Fatih
>>> 
>>> On 11 Jul 2017, at 17:16, Alec Hothan (ahothan)  
>>> wrote:
>>> 
>>> Can we work on a proposal and get every project that deals with 
>>> containers involved?
>>> 
>>> ___
>>> test-wg mailing list
>>> test...@lists.opnfv.org
>>> https://lists.opnfv.org/mailman/listinfo/test-wg
>> 
>> 
>> --
>> Morgan Richomme
>> Orange/ IMT/ OLN/ CNC/ NCA/ SINA
>> 
>> Network architect for innovative services
>> Future of the Network community member
>> Open source Orange community manager
>> 
>> 
>> tel. +33 (0) 296 072 106
>> mob. +33 (0) 637 753 326
>> morgan.richo...@orange.com
>> 
>> 
>> 
>> 

Re: [opnfv-tech-discuss] SFC Project

[Jose Lausuch]

Hi Pavan,

It seems your installer is not supported by the script fetch_os_creds.sh

In that case, you need to provide the openstack RC file from your deployment 
manually to the container, or just copy the content to  
/home/opnfv/functest/conf/openstack.creds

Let me know if it still fails that way.

Regards,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Pavan Gupta
Sent: Thursday, July 13, 2017 14:29 PM
To: Manuel Buil 
Cc: andres.sanchez.ra...@estudiant.upc.edu; OPNFV-TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] SFC Project

Hi Manuel/Andres,
When I run 'functest env prepare’, I also see this issue:


/home/opnfv/repos/releng/utils/fetch_os_creds.sh: line 76: SALT_MASTER_IP: 
unbound variable

What should be SALT_MASTER_IP address?
Pavan

On 13-Jul-2017, at 3:37 PM, Manuel Buil mailto:mb...@suse.com>> 
wrote:

10.20.0.2

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

Re: [opnfv-tech-discuss] [test-wg] docker container versioning

[Jose Lausuch]

Hi Alec,

The versioning is not an urgent matter and it is working well today.  I agree 
it is a topic to be discussed but maybe it is better to wait until everyone is 
back from PTO as it will be difficult to align without the participation of the 
people who are really involved.

- Jose -




> On 13 Jul 2017, at 17:00, Alec Hothan (ahothan)  wrote:
> 
> Jose,
> 
> You should start the discussion at the next infra wg meeting (I’ll be on PTO 
> whole of next week). I think if the issue can be raised and acknowledged it 
> will already be a good step.
> I will just note that:
> - this has to be a joint work by both infra and project teams
> - perhaps we could use some help from OPNFV members who do 
> packaging/versioning for a living ;-) (e.g. Linux distro vendors
> 
> To clarify, I’m willing to help on the container/VM image/docs 
> workflow/versioning since my project produces those. Not so much on the other 
> artifacts such as RPM (which might be more complex).
> I’m not familiar enough with OPNFV to know who works on what, I was hoping to 
> get more active feedback from at least the main/most active OPNFV container 
> owners. The current versioning is clearly insufficient and I’d like to get 
> the input from projects that have been publishing containers for a while.
> 
> Can anybody describe quickly how specs are usually being discussed/redacted 
> by working groups? Email is usually not the best (written) format. OpenStack 
> uses etherpads or text files that are reviewed through gerrit.
> 
> Thanks
> 
>  Alec
> 
> 
> On 7/12/17, 11:35 PM, "Jose Lausuch"  wrote:
> 
>Hi,
> 
>Is there time to discuss this during the next infra wg meeting on Monday? 
> Although the test projects are the main ones using docker containers, we are 
> talking about versioning here, which I believe is topic the Infra team should 
> address.
> 
>I also would like to add to the agenda:
>  -  decision on where to host the docker build scripts (common one or 
> project´s repo?). It has been proposed but not decided.
> 
>Thanks,
>Jose
> 
> 
> 
>> On 12 Jul 2017, at 20:10, Alec Hothan (ahothan)  wrote:
>> 
>> July/August is tricky with PTOs.
>> Perhaps we should start the discussion by email on this mailer and discuss 
>> about it in 2 weeks at the test-wg meeting? 
>> Do you guys usually use a text document reviewed with gerrit to 
>> discuss/collaborate on a spec? Or any other method? Please let me know and I 
>> can get a head start on this.
>> 
>> Thanks
>> 
>> Alec
>> 
>> On 7/12/17, 8:54 AM, "morgan.richo...@orange.com" 
>>  wrote:
>> 
>>   I will be in PTO too :)
>> 
>>   Unfortunately the weekly meeting was today at 8 UTC (APAC slot)
>>   we will use the slot of tomorrow to organize an ad-hoc meeting with 
>>   Bitergia on result vizualization
>>   not sure we will have 15 minutes for another topic
>> 
>>   It is maybe possible to organize an ad-hoc meeting on this topic after 
>>   the point with Bitergia?
>> 
>>   Do not hesitate to modify directly the agenda at your convenience 
>>   (https://wiki.opnfv.org/display/meetings/Test+Working+Group+Weekly+Meeting)
>> 
>>   /Morgan
>> 
>> 
>> 
>>   On 12/07/2017 17:43, Alec Hothan (ahothan) wrote:
>>> Morgan,
>>> 
>>> Unfortunately, I won’t be able to attend next week (on PTO).
>>> Can this be squeezed into tomorrow’s meeting (July 13)? We could shorten it 
>>> and follow up with a separate meeting or on email/IRC.
>>> 
>>> Thanks
>>> 
>>>  Alec
>>> 
>>> 
>>> 
>>> On 7/12/17, 8:32 AM, "morgan.richo...@orange.com" 
>>>  wrote:
>>> 
>>>topic added for the next meeting (20th of July)
>>>https://wiki.opnfv.org/display/meetings/Test+Working+Group+Weekly+Meeting
>>> 
>>>Mark and Jose are already involved in several activities dealing with
>>>docker.
>>>Cedric has a good view on this topic.
>>> 
>>>/Morgan
>>> 
>>>On 12/07/2017 17:27, Alec Hothan (ahothan) wrote:
>>>> I’d like to add this topic to the next weekly meeting of the test-wg and 
>>>> would like to know if anybody else from test-wg would be interested to 
>>>> help redact a proposal for enhancing the docker container versioning and 
>>>> build workflow in OPNFV. As I understand this will only concern a subset 
>>>> of test projects for now at least.
>>>> 
>>>> To the agenda:
>>>> 

Re: [opnfv-tech-discuss] SFC Project

[Jose Lausuch]

Ok, just for your information:
if you are using Functest Danube, you need connectivity to the admin network. 
We are working on removing that constraint in Euphrates against OpenStack Ocata.

Thanks,
Jose



On 14 Jul 2017, at 08:45, Pavan Gupta 
mailto:pavan.gu...@calsoftinc.com>> wrote:

Hi Jose,
I added the following route on Junper host and connectivity worked, so the SFC 
test environment was successfully prepared.
sudo route add -net 192.168.0.0 netmask 255.255.255.0 gw 172.26.48.23

Thanks for your help.
Pavan

On 13-Jul-2017, at 7:06 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

Hi Pavan,

It seems your installer is not supported by the script fetch_os_creds.sh

In that case, you need to provide the openstack RC file from your deployment 
manually to the container, or just copy the content to  
/home/opnfv/functest/conf/openstack.creds

Let me know if it still fails that way.

Regards,
Jose


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 Pavan Gupta
Sent: Thursday, July 13, 2017 14:29 PM
To: Manuel Buil mailto:mb...@suse.com>>
Cc: 
andres.sanchez.ra...@estudiant.upc.edu<mailto:andres.sanchez.ra...@estudiant.upc.edu>;
 OPNFV-TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] SFC Project

Hi Manuel/Andres,
When I run 'functest env prepare’, I also see this issue:


/home/opnfv/repos/releng/utils/fetch_os_creds.sh: line 76: SALT_MASTER_IP: 
unbound variable

What should be SALT_MASTER_IP address?
Pavan

On 13-Jul-2017, at 3:37 PM, Manuel Buil mailto:mb...@suse.com>> 
wrote:

10.20.0.2


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

Re: [opnfv-tech-discuss] SFC Project

[Jose Lausuch]

Hi Pavan,

Can you please attach functest log, located in 
/home/opnfv/functest/results/functest.log ?

Also answer to the following questions about your environment:

Which docker image (tag) are you using?
Which installer? Version?

The credentials to access the installer node are in [1]. If you have deployed 
your installer node with different user/password, make sure you update that as 
well.

Jose

[1] 
https://git.opnfv.org/functest/tree/functest/ci/installer_params.yaml?h=stable/danube




On 14 Jul 2017, at 13:31, Pavan Gupta 
mailto:pavan.gu...@calsoftinc.com>> wrote:

Hi Manuel,
- I am using funkiest command list. I run this command: 'functest testcase run 
odl-sfc’

- I am new openstack as well, can you please tell me, what all env variables 
need to be set. Do I need to copy these in openstack.creds. This is what is 
there at present in this file:
OS_REGION_NAME=RegionOne
OS_DEFAULT_DOMAIN=default
OS_USER_DOMAIN_NAME=Default
OS_PROJECT_NAME=admin
OS_IDENTITY_API_VERSION=3
OS_PASSWORD=admin
OS_AUTH_STRATEGY=keystone
OS_AUTH_URL=http://192.168.0.2:5000/
OS_USERNAME=admin
OS_TENANT_NAME=admin
OS_ENDPOINT_TYPE=internalURL
OS_NO_CACHE=true
OS_PROJECT_DOMAIN_NAME=Default

- Where do I run ‘openstack server list’ command. I tried running it on node-1 
machine, which is a controller machine, the output was blank.

Any useful pointer would be appreciated.
Pavan
-
On 14-Jul-2017, at 4:49 PM, Manuel Buil mailto:mb...@suse.com>> 
wrote:

HI Pavan,

I think your openstack env. variables are not set. How do you execute the tests?

If you are not using the functest command line, you need to source the env 
variables (from openrc or tackerc). To check that everything is ok, try to 
execute one openstack command before executing the test and check that you 
don't get any error (e.g. openstack server list).

Regards,
Manuel

On Fri, 2017-07-14 at 16:40 +0530, Pavan Gupta wrote:
Hello Folks,
I have managed to begin the test but hit across this error:

Traceback (most recent call last):
  File "./run_tests.py", line 189, in 
main(report=args.report)
  File "./run_tests.py", line 91, in main
disable_heat_resource_finder_cache(nodes)
  File "./run_tests.py", line 67, in disable_heat_resource_finder_cache
controller.run_cmd('rm -f {0}'.format(remote_heat_conf))
  File "/home/opnfv/repos/releng/modules/opnfv/deployment/manager.py", line 
184, in run_cmd
_, stdout, stderr = (self.ssh_client.exec_command(cmd))
AttributeError: 'NoneType' object has no attribute ‘exec_command'


Does anyone know fix for this?
Pavan

On 14-Jul-2017, at 12:56 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

Ok, just for your information:
if you are using Functest Danube, you need connectivity to the admin network. 
We are working on removing that constraint in Euphrates against OpenStack Ocata.

Thanks,
Jose



On 14 Jul 2017, at 08:45, Pavan Gupta 
mailto:pavan.gu...@calsoftinc.com>> wrote:

Hi Jose,
I added the following route on Junper host and connectivity worked, so the SFC 
test environment was successfully prepared.
sudo route add -net 192.168.0.0 netmask 255.255.255.0 gw 172.26.48.23

Thanks for your help.
Pavan

On 13-Jul-2017, at 7:06 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

Hi Pavan,

It seems your installer is not supported by the script fetch_os_creds.sh

In that case, you need to provide the openstack RC file from your deployment 
manually to the container, or just copy the content to  
/home/opnfv/functest/conf/openstack.creds

Let me know if it still fails that way.

Regards,
Jose


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 Pavan Gupta
Sent: Thursday, July 13, 2017 14:29 PM
To: Manuel Buil mailto:mb...@suse.com>>
Cc: 
andres.sanchez.ra...@estudiant.upc.edu<mailto:andres.sanchez.ra...@estudiant.upc.edu>;
 OPNFV-TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] SFC Project

Hi Manuel/Andres,
When I run 'functest env prepare’, I also see this issue:


/home/opnfv/repos/releng/utils/fetch_os_creds.sh: line 76: SALT_MASTER_IP: 
unbound variable

What should be SALT_MASTER_IP address?
Pavan

On 13-Jul-2017, at 3:37 PM, Manuel Buil mailto:mb...@suse.com>> 
wrote:

10.20.0.2





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

Re: [opnfv-tech-discuss] SFC Project

[Jose Lausuch]

Pavan,

I don't see any attachment.

| 2. Docker image: Docker version 17.04.0-ce, build 4845c56
I meant the Functest docker image. Just run: docker ps or docker images to see 
which Functest version you are using.

- Jose -

From: Pavan Gupta [mailto:pavan.gu...@calsoftinc.com]
Sent: Friday, July 14, 2017 14:28 PM
To: Jose Lausuch 
Cc: Manuel Buil ; andres.sanchez.ra...@estudiant.upc.edu; 
OPNFV-TECH-DISCUSS OPNFV 
Subject: Re: [opnfv-tech-discuss] SFC Project

Hi Jose,
1. I have attached functest.log.

2. Docker image: Docker version 17.04.0-ce, build 4845c56

3. Installer: Fuel, version 10.0.0

4. Credentials: Same as mentioned in the link (root, r00tme)

Thank you.
Pavan

On 14-Jul-2017, at 5:15 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

/home/opnfv/functest/results/functest.log

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

Re: [opnfv-tech-discuss] SFC Project

[Jose Lausuch]

Hi,

Functest looks fine. Can you now attach sfc.log located in the same directory? 
Maybe it’s a problem with the test case as such while trying to access the 
deployment. Maybe Manuel has more experience with it.

- Jose -


On 14 Jul 2017, at 14:47, Pavan Gupta 
mailto:pavan.gu...@calsoftinc.com>> wrote:

HI Jose,
- I have attached the log file this time.

- Output of docker images:

REPOSITORY  TAG IMAGE IDCREATED 
SIZE
opnfv/functest  stable  2553087919e09 days ago  
1.57GB
ryu7249125/yardsticklatest  e37ee4c07ca82 months 
ago3.52GB
opnfv/yardstick stable  7fc31a6fc1d52 months 
ago1.2GB
autolytiks_logstash latest  0b8f850cf5922 months 
ago565MB
autolytiks_elasticsearchlatest  f73bc006eb572 months 
ago352MB
autolytiks_nginxlatest  b3d688b354172 months 
ago206MB
autolytiks_web  latest  7c2907bd15d82 months 
ago727MB
python  3.5-onbuild 2d1685b88f322 months 
ago689MB
redis   latest  e32ef7250bc12 months 
ago184MB
postgreslatest  3902208677552 months 
ago267MB
influxdblatest  95b868946bae2 months 
ago224MB
logstash5.2 e2e0c054df393 months 
ago494MB
elasticsearch   5.2 0206b7302cfe3 months 
ago352MB
grafana/grafana latest  8c4ef64b4ad13 months 
ago278MB
autolytiks_kibana   latest  724639b709153 months 
ago329MB
kibana  5.2 724639b709153 months 
ago329MB
hello-world latest  c54a2cc56cbb12 months 
ago   1.85kB
opennetworklinux/builder7   1.2 a0a471ea8d5513 months 
ago   1.92GB
tutum/nginx latest  a2e9b71ed36616 months 
ago   206MB


- Output of docker ps:
CONTAINER IDIMAGECOMMAND  CREATED   
  STATUS  PORTS 
   NAMES
9b1c47899d65opnfv/functest:stable"/bin/bash"  6 hours 
ago Up 6 hours  
 sfc
0eb2d3ff7e4dautolytiks_nginx "/usr/sbin/nginx"2 months 
agoUp 8 days   0.0.0.0:80->80/tcp   
autolytiks_nginx_1
ce4e265af4cdgrafana/grafana:latest   "/run.sh"2 months 
agoUp 8 days   0.0.0.0:3000->3000/tcp   
autolytiks_grafana_1
87e2e67d8924autolytiks_web   "/usr/local/bin/gu..."   2 months 
agoUp 8 days   8000/tcp 
autolytiks_web_1
f7e290be942dinfluxdb:latest  "/entrypoint.sh in..."   2 months 
agoUp 8 days   0.0.0.0:8084->8083/tcp, 0.0.0.0:8087->8086/tcp, 
0.0.0.0:8090->8089/tcp   autolytiks_influxdb_1
6e77fd10b6c8postgres:latest  "docker-entrypoint..."   2 months 
agoUp 8 days   0.0.0.0:5432->5432/tcp   
autolytiks_postgres_1
da192814b82bredis:latest "docker-entrypoint..."   2 months 
agoUp 8 days   0.0.0.0:6379->6379/tcp   
autolytiks_redis_1


Please let me know if you need any other information.
Pavan

On 14-Jul-2017, at 6:09 PM, Jose Lausuch 
mailto:jose.laus...@ericsson.com>> wrote:

Pavan,

I don’t see any attachment.

| 2. Docker image: Docker version 17.04.0-ce, build 4845c56
I meant the Functest docker image. Just run: docker ps or docker images to see 
which Functest version you are using.

- Jose -

From: Pavan Gupta [mailto:pavan.gu...@calsoftinc.com]
Sent: Friday, July 14, 2017 14:28 PM
To: Jose Lausuch mailto:jose.laus...@ericsson.com>>
Cc: Manuel Buil mailto:mb...@suse.com>>; 
andres.sanchez.ra...@estudiant.upc.edu<mailto:andres.sanchez.ra...@estudiant.upc.edu>;
 OPNFV-TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] SFC Project

Hi Jose,
1. I have attached functest.log.

2. Docker image: Docker version 17.04.0-ce, build 4845c56

3. Installer: Fuel, version 10.0.0

4. Credentials: Same as mentioned i

Re: [opnfv-tech-discuss] [test-wg] docker container versioning

[Jose Lausuch]

Hi Alec,
Sounds good. We can talk about that during the meeting. Thanks for proposing it.
Jose

-Original Message-
From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com] 
Sent: Friday, July 14, 2017 16:53 PM
To: Jose Lausuch 
Cc: Morgan Richomme ; Mark Beierl 
; opnfv-tech-discuss@lists.opnfv.org; 
test...@lists.opnfv.org; Fatih Degirmenci 
Subject: Re: [test-wg] docker container versioning

Hi Jose,

I have moved this topic and added a sub-agenda to the July 27 test-wg weekly 
meeting agenda 
(https://wiki.opnfv.org/display/meetings/Test+Working+Group+Weekly+Meeting)
It is good that this issue has not caused any big problem yet for container 
owners (likely because none of the artifacts has been widely deployed outside 
of OPNFV labs yet) but I’d like to recommend to address it very quickly. 
Fatih has noted rightly that this is actually a larger scope issue (extending 
to all other artifacts: VM images, doc, rpms). It is good to see the larger 
picture but I’d like to avoid making it too complex and start with container 
images with adoption of simple industry best practice versioning.

Thanks

   Alec




On 7/13/17, 8:43 AM, "Jose Lausuch"  wrote:

Hi Alec,

The versioning is not an urgent matter and it is working well today.  I 
agree it is a topic to be discussed but maybe it is better to wait until 
everyone is back from PTO as it will be difficult to align without the 
participation of the people who are really involved.

- Jose -




> On 13 Jul 2017, at 17:00, Alec Hothan (ahothan)  wrote:
> 
> Jose,
> 
> You should start the discussion at the next infra wg meeting (I’ll be on 
PTO whole of next week). I think if the issue can be raised and acknowledged it 
will already be a good step.
> I will just note that:
> - this has to be a joint work by both infra and project teams
> - perhaps we could use some help from OPNFV members who do 
packaging/versioning for a living ;-) (e.g. Linux distro vendors
> 
> To clarify, I’m willing to help on the container/VM image/docs 
workflow/versioning since my project produces those. Not so much on the other 
artifacts such as RPM (which might be more complex).
> I’m not familiar enough with OPNFV to know who works on what, I was 
hoping to get more active feedback from at least the main/most active OPNFV 
container owners. The current versioning is clearly insufficient and I’d like 
to get the input from projects that have been publishing containers for a while.
> 
> Can anybody describe quickly how specs are usually being 
discussed/redacted by working groups? Email is usually not the best (written) 
format. OpenStack uses etherpads or text files that are reviewed through gerrit.
> 
> Thanks
> 
    >  Alec
> 
> 
> On 7/12/17, 11:35 PM, "Jose Lausuch"  wrote:
> 
>Hi,
> 
>Is there time to discuss this during the next infra wg meeting on 
Monday? Although the test projects are the main ones using docker containers, 
we are talking about versioning here, which I believe is topic the Infra team 
should address.
> 
>I also would like to add to the agenda:
>  -  decision on where to host the docker build scripts (common one or 
project´s repo?). It has been proposed but not decided.
> 
>Thanks,
>Jose
> 
> 
> 
>> On 12 Jul 2017, at 20:10, Alec Hothan (ahothan)  
wrote:
>> 
>> July/August is tricky with PTOs.
>> Perhaps we should start the discussion by email on this mailer and 
discuss about it in 2 weeks at the test-wg meeting? 
>> Do you guys usually use a text document reviewed with gerrit to 
discuss/collaborate on a spec? Or any other method? Please let me know and I 
can get a head start on this.
>> 
>> Thanks
>> 
>> Alec
>> 
>> On 7/12/17, 8:54 AM, "morgan.richo...@orange.com" 
 wrote:
>> 
>>   I will be in PTO too :)
>> 
>>   Unfortunately the weekly meeting was today at 8 UTC (APAC slot)
>>   we will use the slot of tomorrow to organize an ad-hoc meeting with 
>>   Bitergia on result vizualization
>>   not sure we will have 15 minutes for another topic
>> 
>>   It is maybe possible to organize an ad-hoc meeting on this topic after 
>>   the point with Bitergia?
>> 
>>   Do not hesitate to modify directly the agenda at your convenience 
>>   
(https://wiki.opnfv.org/display/meetings/Test+Working+Group+Weekly+Meeting)
>> 
>>   /Morgan
>> 
>> 
>> 
>>   On 12/07/2017 17:43, Alec Hothan (ahothan) wrote:
>>> Morgan,
>>>

[opnfv-tech-discuss] OPNFV Docker builds on Dockerhub account

[Jose Lausuch]

Hi,

Following up on the discussion about how to build our Docker images, I started 
a trial with Trevor Bramwell with automated builds on Dockerhub for some of the 
new Functest Docker images:

https://hub.docker.com/r/opnfv/functest-core/builds/

https://hub.docker.com/r/opnfv/functest-smoke/builds/

https://hub.docker.com/r/opnfv/functest-healthcheck/builds/



It triggers a build after the corresponding repository in Github (mirror) has 
new code. Basically, whenever a new patch is merged on OPNFV gerrit and synched 
with Github.



There is currently a small limitation in the OPNFV Dockerhub account: it can 
build only 1 image at a time, but we can change that up to 5 or more parallel 
builds by requesting an account upgrade to LF. You can see the pricing plan 
here:

https://hub.docker.com/account/billing-plans/



We could use this to avoid load on our build servers, use them for something 
else and of course stop maintaining docker builds in OPNFV.

I would like to know your opinion on that.



Thanks,

Jose


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

Re: [opnfv-tech-discuss] Jenkins servers Docker versions?

[Jose Lausuch]

Hi Mark,

Please create a JIRA ticket and assign it to Dianfeng Du.

Thank you,
Jose


On 26 Jul 2017, at 03:46, Beierl, Mark 
mailto:mark.bei...@dell.com>> wrote:

Hello,

The latest storperf-master docker build is failing [1] on ericsson-build3 as it 
is unable to parse the FROM source AS label syntax [2] for Dockerfiles.  What 
version is installed and how do I request it be upgraded?  It works on Intel 
pod 24, which has docker 17.05 installed.

[1] 
https://build.opnfv.org/ci/view/storperf/job/storperf-master-docker-build-push-master/4/console
[2] https://docs.docker.com/engine/reference/builder/#from

Regards,
Mark

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

___
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][openretriever] OpenRetriever wants to know how k8s e2e test integrated with functest

[Jose Lausuch]

Hi,

We are not covering K8 deployments in Functest yet. Basically because we have 
no resources to work on that. Therefore we opened an intern project proposal to 
find someone that can help us with that task.
https://wiki.opnfv.org/display/DEV/Intern+Project%3A+Functional+tests+for+Kubernetes+deployments

We would like to offer a bunch of simple test cases that make sense only for 
container based deployments without openstack (e.g. k8 deployments in JOID). If 
possible, we could also integrate upstream suites from Kubernetes as we are 
doing today with Tempest/Rally. This is of course our wish, but the topic is 
still open.

I think there is a python module for kubernetes, so the idea would be to start 
writing tests in python using Functest framework using that client.

Thanks,
Jose



From: 贾玄 [mailto:jiax...@chinamobile.com]
Sent: Tuesday, July 25, 2017 13:52 PM
To: Jose Lausuch 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss][functest][openretriever] OpenRetriever wants to 
know how k8s e2e test integrated with functest

Hi Jose:
   OpenRetriever (Container integrated for NFV ) is a project to provide 
container environment for NFV in Edge Node or Core-network Node.  We have 
collaborated with yardstick team to write the test cases for container 
<->container and container <->virtual machine.
   We have another requirement for functest. How can we make kubernetes e2e 
test integrated with functest?  I can pick a volunteer with your project to 
finish this task . But I don’t know how many gap between k8s e2e and functest 
for integration. Have you investigated before ?

   Thanks

Xuan Jia
Project Manager
Big Data & IT Technology Research Center China Mobile Research Institute
32 Xuanwumen West Street, Xicheng Distirct, Beijing 100032, China
Mobile: (+86) 13811000575
E-mail: jiax...@chinamobile.com<mailto:jiax...@chinamobile.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][openretriever] OpenRetriever wants to know how k8s e2e test integrated with functest

[Jose Lausuch]

Hi,

We haven’t thought about test cases yet, that is the task that the intern 
should be looking at.

+ Morgan (Functest) and Nadinder (Joid).

Regards,
Jose



From: 贾玄 [mailto:jiax...@chinamobile.com]
Sent: Thursday, July 27, 2017 08:08 AM
To: Jose Lausuch 
Cc: opnfv-tech-discuss@lists.opnfv.org; ruijing@intel.com; 'Bin Lu' 

Subject: 答复: [opnfv-tech-discuss][functest][openretriever] OpenRetriever wants 
to know how k8s e2e test integrated with functest

Thanks Jose.

That will be great if functest can offer a bunch of simple test case. 
OpenRetriever is not using Magnum and Zun now as these projects are not stable 
and convenient now. We collaborate with JOID to deply k8s on bare metal machine.

Could you kindly provide one simple test case , then we can process this task?

Thanks

Xuan Jia
Project Manager
Big Data & IT Technology Research Center China Mobile Research Institute
32 Xuanwumen West Street, Xicheng Distirct, Beijing 100032, China
Mobile: (+86) 13811000575
E-mail: jiax...@chinamobile.com<mailto:jiax...@chinamobile.com>

发件人: Jose Lausuch [mailto:jose.laus...@ericsson.com]
发送时间: 2017年7月26日 21:17
收件人: 贾玄 mailto:jiax...@chinamobile.com>>
抄送: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: RE: [opnfv-tech-discuss][functest][openretriever] OpenRetriever wants to 
know how k8s e2e test integrated with functest

Hi,

We are not covering K8 deployments in Functest yet. Basically because we have 
no resources to work on that. Therefore we opened an intern project proposal to 
find someone that can help us with that task.
https://wiki.opnfv.org/display/DEV/Intern+Project%3A+Functional+tests+for+Kubernetes+deployments

We would like to offer a bunch of simple test cases that make sense only for 
container based deployments without openstack (e.g. k8 deployments in JOID). If 
possible, we could also integrate upstream suites from Kubernetes as we are 
doing today with Tempest/Rally. This is of course our wish, but the topic is 
still open.

I think there is a python module for kubernetes, so the idea would be to start 
writing tests in python using Functest framework using that client.

Thanks,
Jose



From: 贾玄 [mailto:jiax...@chinamobile.com]
Sent: Tuesday, July 25, 2017 13:52 PM
To: Jose Lausuch mailto:jose.laus...@ericsson.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss][functest][openretriever] OpenRetriever wants to 
know how k8s e2e test integrated with functest

Hi Jose:
   OpenRetriever (Container integrated for NFV ) is a project to provide 
container environment for NFV in Edge Node or Core-network Node.  We have 
collaborated with yardstick team to write the test cases for container 
<->container and container <->virtual machine.
   We have another requirement for functest. How can we make kubernetes e2e 
test integrated with functest?  I can pick a volunteer with your project to 
finish this task . But I don’t know how many gap between k8s e2e and functest 
for integration. Have you investigated before ?

   Thanks

Xuan Jia
Project Manager
Big Data & IT Technology Research Center China Mobile Research Institute
32 Xuanwumen West Street, Xicheng Distirct, Beijing 100032, China
Mobile: (+86) 13811000575
E-mail: jiax...@chinamobile.com<mailto:jiax...@chinamobile.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] [opnfv-tsc] [announce] Opening nominations for Committers-at-Large TSC & Committer Board elections

[Jose Lausuch]

Hi,

Thank you Rosella!
Yes, I accept the nomination.

Regards,
Jose

> On 08 Sep 2017, at 16:37, Raymond Paik  wrote:
> 
> Thanks Rossella
> 
> Jose, do you accept the nomination?
> 
> Ray
> 
> On Fri, Sep 8, 2017 at 3:57 AM, Rossella Sblendido  <mailto:rsblend...@suse.com>> wrote:
> Hi all,
> 
> I'd like to nominate Jose Lausuch for the Committers-at-Large TSC board.
> Jose has done a great job as Functest PTL for Danube and Euphrates. He
> got a developer award in Beijing and has server as a mentor for the
> internship program. He's a very active and respected member of the
> community, he could be a great addition to the TSC.
> 
> Rossella
> 
> On 09/03/2017 07:42 PM, Raymond Paik wrote:
> > All,
> >
> > I'm kicking off the nomination process for Committers-at-Large TSC
> > (electing 5 members) plus the Committer Board (electing 1) elections.
> >
> > The list of eligible committers who can run for & vote in both elections
> > are posted here <http://Eligible <http://eligible/> Committers for 
> > Elections>, and I want
> > to encourage all eligible committers to nominate community members who
> > can represent the OPNFV technical community in both the TSC and the
> > Board.  Self nominations are also welcome.   As I mentioned earlier in
> > the week, I hope to see a diverse group of community members
> > represented--in terms of geography, gender, projects,  service
> > providers/vendors, etc.--in the nominations.
> >
> > Nominations should be posted to opnfv-tech-discuss & opnfv-tsc mailing
> > lists by 5pm Pacific Time on September 8th (Friday).  You are welcome to
> > reply to this email or if you're sending out a separate note, please
> > include phrases like "Committer Board nomination" or "Committer-at-Large
> > TSC nomination" in email subjects.  In nomination statements, please
> > list the following information:
> >
> >   * Which election (TSC vs. Board) the nomination is for
> >   * Name of the nominee
> >   * Organization
> >   * A brief description of nominee's qualifications
> >
> > As nominations are accepted, I will add them to this page
> > <https://wiki.opnfv.org/display/DEV/Nominees+for+2017+Elections 
> > <https://wiki.opnfv.org/display/DEV/Nominees+for+2017+Elections>>.  There
> > will be separate Condorcet ballot for these two elections, and they will
> > be sent out by September 11th.
> >
> > Thanks,
> >
> > Ray
> >
> >
> >
> > ___
> > opnfv-tsc mailing list
> > opnfv-...@lists.opnfv.org <mailto:opnfv-...@lists.opnfv.org>
> > https://lists.opnfv.org/mailman/listinfo/opnfv-tsc 
> > <https://lists.opnfv.org/mailman/listinfo/opnfv-tsc>
> >
> 

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

[opnfv-tech-discuss] Functest return value and color on Jenkins

[Jose Lausuch]

Hi,

You might have noticed recently that Functest is reporting BLUE even though 
some test cases fail, e.g. [1].

This is due to the new way of running Functest using different Docker images 
based on Alpine:

1. healthcheck 
   connection_check, api_check, snaps_healthcheck...
2. smoke 
   vping, odl, tempest, rally, ….
3. features
   promise, doctor, bgpvpn, sfc, ...
4. vnf
  cloudify_ims, ...

Since they are run independently one after each other, we just return BLUE if 
the execution succeeds regardless of the test results. This approach is also 
done currently in Yardstick as well. You can see the status of the 
scenarios/test results on the Functest dashboard [2] which is a snapshot of 
what happens in CI.

If anyone thinks this is not a good approach, we could discuss it during the 
TSC meeting or the Weekly Technical Community meeting.


Thank you,
Jose

[1] 
https://build.opnfv.org/ci/view/functest/job/functest-compass-baremetal-daily-master/1473/
 

[2] http://testresults.opnfv.org/reporting/master/functest/status-apex.html 



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

Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed

[Jose Lausuch]

+1

What about using tag "release-x.y.z" instead of "opnfv-x.y.z" since the name 
“opnfv” is already included in the image name? e.g. opnfv/functest:release-5.0.0
This way we differentiate between an official OPNFV release artifact from a 
none released.

- Jose -





> On 27 Sep 2017, at 20:00, Raymond Paik  wrote:
> 
> All, 
> 
> Please let Alec know if you have any other questions/feedback on the 
> proposal.  The plan is to have a quick vote on the TSC call next week 
> (October 3rd).
> 
> Thanks, 
> 
> Ray
> 
> On Tue, Sep 26, 2017 at 5:38 AM, MORTON, ALFRED C (AL)  > wrote:
> +1 and thanks for the proposal, Alex!
> 
>  
> 
> Al
> 
>  
> 
> From: opnfv-tech-discuss-boun...@lists.opnfv.org 
>  
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org 
> ] On Behalf Of Frank 
> Brockners (fbrockne)
> Sent: Tuesday, September 26, 2017 4:44 AM
> To: Alec Hothan (ahothan); opnfv-tech-discuss@lists.opnfv.org 
> 
> Subject: Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed
> 
>  
> 
> +1 – per what Alec mentioned below, the new tagging scheme is only a small 
> change incremental change from the earlier plans, but offers a lot of 
> flexibility moving forward.
> 
> Frank
> 
>  
> 
> From: Alec Hothan (ahothan) 
> Sent: Montag, 25. September 2017 21:34
> To: opnfv-tech-discuss@lists.opnfv.org 
> 
> Cc: David McBride  >; Fatih Degirmenci 
> mailto:fatih.degirme...@ericsson.com>>; Frank 
> Brockners (fbrockne) mailto:fbroc...@cisco.com>>; 
> Tallgren, Tapio (Nokia - FI/Espoo)  >
> Subject: [opnfv-tech-discuss] urgent euphrates git tags vote needed
> 
>  
> 
>  
> 
> I would like to get a quick vote from any person that works directly or 
> indirectly with code in OPNFV
> 
>  
> 
> Please reply with -1, 0 +1
> 
>  
> 
> For using prefixed git tags for the Euphrates release: “opnfv-5.0.0”
> 
>  
> 
> This is a slight change to the plan on record (which was to use “5.0.0”). 
> This does NOT impact euphrates deliverables for participating OPNFV projects 
> (git tags on stable/euphrates are applied by releng).
> 
> The only externally visible effect is the naming of container tags for 
> Euphrates official images in DockerHub will be named accordingly (e.g. 
> “opnfv/functest:opnfv-5.0.0”).
> 
> Everything else remains the same.
> 
>  
> 
> If you’d like to know more, the rationale is described here: 
> https://wiki.opnfv.org/display/releng/OPNFV+projects+and+OPNFV+release+versioning
>  
> 
>  (thanks for Fatih, David, Frank, Tapio for reviewing)
> 
> In a nutshell, this adjustment is needed to prepare the path for proper 
> continuous delivery support by projects.
> 
> Any clarification/questions/discussion can be done over email or at the TSC 
> or release meetings tomorrow.
> 
>  
> 
> Thank You.
> 
>  
> 
>   Alec
> 
>  
> 
>  
> 
> 
> ___
> 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 mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-tsc] [release][euphrates] Euphrates status

[Jose Lausuch]

Hi David,

You can now update that table for Functest column on Compass [1] and Fuel-ARM 
[2]. They have been reporting results in the past day or 2, so therefore there 
is no history yet to plot a trend in the graphs.

Regards,
Jose

[1]: 
http://testresults.opnfv.org/reporting/euphrates/functest/status-compass.html 

[2]: 
http://testresults.opnfv.org/reporting/euphrates/functest/status-f...@aarch64.html
 







> On 30 Sep 2017, at 04:50, David McBride  wrote:
> 
> TSC Members,
> 
> As you know, the Euphrates release is scheduled for Oct 6.  In advance of the 
> next TSC meeting, here is the status of the release. Let me know if you have 
> questions or comments.
> 
> Installer Summary
> 
>  
> 
> DEPLOY ON EUPHRATES
> 
> FUNCTEST DASHBOARD ON EUPHRATES
> 
> YARDSTICK DASHBOARD ON EUPHRATES
> 
> APEX
> 
> yes
> 
> yes
> 
> yes
> 
> COMPASS
> 
> yes
> 
> no
> 
> no
> 
> DAISY
> 
> yes
> 
> yes
> 
> n/a
> 
> FUEL (X86)
> 
> yes
> 
> yes
> 
> no
> 
> FUEL (AARCH64)
> 
> yes
> 
> no
> 
> no
> 
> JOID
> 
> yes
> 
> yes
> 
> yes
> 
> 
> 
> Scenario Summary
> 
> Total (listed on scenario status page and found in Jenkins)   45
> Pass Deploy   47%
> Fail Deploy   42%
> Not Running   11%
> Functest results  49%
> YardStick results 38%
> 
> Major Issues
> Chinese National Holiday.  There is a Chinese holiday from Oct 1 - 8.  During 
> this period, there will be power maintenance in the building where the Huawei 
> lab is located and the pods will be offline.  
> (https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-September/018333.html
>  
> )
>  This will impact the Compass and JOID installers, as well as all of the 
> projects that depend on those installers. The Yardstick project will also be 
> impacted by the Huawei lab outage.
> Intel lab firewall reconfiguration.  The status remains unchanged.  In the 
> mean time, the LF release engineering team has identified a workaround which 
> could be in place by Monday or Tuesday.  The main impact has been that the 
> Apex, Compass, and JOID installers have had to shift builds to an alternate 
> POD, thereby reducing capacity.  In addition, the VSPerf and KVM4NFV projects 
> are without CI support.
> Docker builds.  See RELENG-315 .  
> With the increase of the number of docker jobs in Euphrates, there have been 
> a lot of failures due to timeouts.  This has been partially resolved with 
> additional capacity and improvements to the script, but remains an open 
> issue.  This affects any project that requires docker builds, such as 
> StorPerf.
> 
> -- 
> David McBride
> Release Manager, OPNFV
> Mobile: +1.805.276.8018 
> Email/Google Talk: dmcbr...@linuxfoundation.org 
> 
> Skype: davidjmcbride1
> IRC: dmcbride
> ___
> opnfv-tsc mailing list
> opnfv-...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tsc

___
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-project-leads] [release][euphrates] proposal to eliminate one of the two point releases for Euphrates

[Jose Lausuch]

+1

Regards,
Jose





> On 04 Oct 2017, at 20:46, Beierl, Mark  wrote:
> 
> +1
> 
> Regards,
> Mark
> 
> Mark Beierl
> SW System Sr Principal Engineer
> Dell EMC | Office of the CTO
> mobile +1 613 314 8106 
> mark.bei...@dell.com 
>> On Oct 4, 2017, at 14:44, David McBride > > wrote:
>> 
>> Team,
>> 
>> Please respond to this mail with (+1, 0, -1) and your thoughts, suggestions, 
>> or alternatives.  
>> 
>> During the TSC call on Tues, Oct 3, the TSC agreed to slip the initial 
>> Euphrates release (5.0) to October 20.  In addition, I also proposed 
>> eliminating one of the two point releases (5.1, 5.2) planned for Euphrates.  
>> The reasoning was as follows:
>> Moving the 5.0 release to Oct 20 places that release just 3 weeks before the 
>> planned release of 5.1 (Nov 10).
>> Slipping 5.1 and 5.2 could have negative consequences for the OPNFV "F" 
>> release, as happened with Euphrates when we decided to slip Danube 3.0.
>> Therefore, the proposal is to eliminate the planned release on Nov 10, so 
>> that there would just be one point release on Dec 15.  
>> 
>> The proposal is described in more detail in the slide deck that I presented 
>> during the TSC meeting 
>>  (see link 
>> labeled "euphrates contingency.pptx" under the heading "Euphrates update").
>> 
>> David
>> 
>> -- 
>> David McBride
>> Release Manager, OPNFV
>> Mobile: +1.805.276.8018 
>> Email/Google Talk: dmcbr...@linuxfoundation.org 
>> 
>> Skype: davidjmcbride1
>> IRC: dmcbride
>> ___
>> opnfv-project-leads mailing list
>> opnfv-project-le...@lists.opnfv.org 
>> 
>> https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads
> 
> ___
> 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] Alpine for arch

[Jose Lausuch]

Maybe late for 5.0, but not late for Euphrates 5.1. 

Can we collect a list the requirements we need from Releng in this wiki [1]?
It will facilitate the support and I will help to speed it up. Otherwise, 
nothing will happen as people don’t know what we need.

[1] https://wiki.opnfv.org/display/functest/Docker+Requirements+on+Releng 







> On 11 Oct 2017, at 09:42, Cristina Pauna  wrote:
> 
> Hi Cedric,
>  
> Which E are you refering to in this email? The one with deadline on 15th 
> December?
>  
> Cristina
>  
> From: cedric.olliv...@orange.com  
> [mailto:cedric.olliv...@orange.com ] 
> Sent: Wednesday, October 11, 2017 7:24 AM
> To: RICHOMME Morgan IMT/OLN  >; jalaus...@suse.com 
> ; Delia Popescu  >; Alexandru Avadanii 
> mailto:alexandru.avada...@enea.com>>; Cristina 
> Pauna mailto:cristina.pa...@enea.com>>; 
> wangwu...@huawei.com 
> Cc: opnfv-tech-discuss  >
> Subject: Re: [functest] Alpine for arch
>  
> Hello, 
> 
> I quickly tested to build aarch64 Functest images via Docker automated builds 
> what is impossible (several prerequisites are unmet). I precise the first 
> published images were built locally.
> 
> I'm thinking about an alternative way which will be too much disruptive for E 
> release. Again it will be suitable for my own repositories. But releng should 
> have been the target to build all Docker images (I bet it won't be ready for 
> E). Today's releng can't meet functest prerequisites about Docker. 
> 
> I will inform as soon as my own repositories are ready. 
> 
> Cédric 
> 
>  Cristina Pauna a écrit 
> 
> Hi,
>  
> There has been a lot of confusion and changes around this topic and I want to 
> clear things up going forward, so we do not waste any of our time.
> What I understand from all the disparate discussions around this topic is:
> 1.   We will not do alpine for E0 release on arm, we are targeting E1/E2
> 2.   For the Functest-core image we will have 1 Dockerfile for x86, and a 
> patch for arm that overrides this Dockerfile; from this file we will create 
> one Functest-core image and thearchitecture will be mentioned in its tag
> 3.   The subsequent images (Functest-healthcheck, Functest-smoke, etc) 
> will be based on the previously built Functest-core image. We will do a 
> manifest to choose the correct Functest-core image based on its tag. These 
> dependent  images will also have its arch in the tag.
> 4.   The problem we are facing now is how to make sure that for 1 build, 
> the Functest-core image always get built before the other ones. For x86 that 
> is now done with a workaround directly in dockerhub. The target is to do it 
> with Jenkins jobs builders, considering image dependencies. 
>  
> Is this the approach we are all agreeing on? 
>  
> Thanks,
> Cristina
> _
>  
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>  
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> 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] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Jose Lausuch]

Hi,

With regards to Functest, you can run it on any OpenStack deployment as long as 
you provide a proper RC file and meet the requirements on the jumphost (docker, 
connectivity to the deployment, …).

However, in some cases, some test cases from feature projects require SSH 
access to the deployment and to make things centralized, the deployment handler 
was created [1]. This is a library that allows users to get the number of nodes 
from the deployment, functions to SCP things from the nodes and some other 
utils. The bad part of it is that it only supports Apex, Fuel and OSA for now…  
unless someones volunteers to write the other adapters for joid, mcp, compass 
osa..  This library might be used to extract the desired logs after 
Functest/Yardstick runs in CI to place them in artifact repo and post-analize. 

Regards,
Jose

[1] https://git.opnfv.org/releng/tree/modules/opnfv/deployment 





> On 11 Oct 2017, at 16:23, Beierl, Mark  wrote:
> 
> Hello,
> 
> StorPerf very much relies on knowledge of the installer to gather information 
> about the block storage underlay.  For example, the number of Ceph nodes, or 
> even Ceph vs. LVM, is very relevant to the final report.  I also wish there 
> were an installer agnostic method of collecting this information as right now 
> I keep that code in the ci/daily.sh and other scripts.
> 
> With the new releng repository being created, perhaps it is time to start 
> moving some of the installer specific code there?  I also see that being of 
> benefit when adding XCI support, as technically that would be yet another 
> type of installer.
> 
> Regards,
> Mark
> 
> Mark Beierl
> SW System Sr Principal Engineer
> Dell EMC | Office of the CTO
> mobile +1 613 314 8106 
> mark.bei...@dell.com 
>> On Oct 11, 2017, at 02:25, xudan (N) > > 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 
>> 
>> 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 
>> : 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 
>> 
> ___
> 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

[Jose Lausuch]

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
 
<https://raw.githubusercontent.com/opnfv/yardstick/master/etc/yardstick/nodes/fuel_virtual/pod.yaml>



> On 11 Oct 2017, at 18:08, Georg Kunz  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 
> <mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>] On Behalf Of Jose Lausuch
> Sent: Wednesday, October 11, 2017 4:40 PM
> To: Beierl, Mark mailto:mark.bei...@dell.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,
>  
> With regards to Functest, you can run it on any OpenStack deployment as long 
> as you provide a proper RC file and meet the requirements on the jumphost 
> (docker, connectivity to the deployment, …).
>  
> However, in some cases, some test cases from feature projects require SSH 
> access to the deployment and to make things centralized, the deployment 
> handler was created [1]. This is a library that allows users to get the 
> number of nodes from the deployment, functions to SCP things from the nodes 
> and some other utils. The bad part of it is that it only supports Apex, Fuel 
> and OSA for now…  unless someones volunteers to write the other adapters for 
> joid, mcp, compass osa..  This library might be used to extract the desired 
> logs after Functest/Yardstick runs in CI to place them in artifact repo and 
> post-analize. 
>  
> Regards,
> Jose
>  
> [1] https://git.opnfv.org/releng/tree/modules/opnfv/deployment 
> <https://git.opnfv.org/releng/tree/modules/opnfv/deployment>
>  
>  
>  
>  
> On 11 Oct 2017, at 16:23, Beierl, Mark  <mailto:mark.bei...@dell.com>> wrote:
>  
> Hello,
>  
> StorPerf very much relies on knowledge of the installer to gather information 
> about the block storage underlay.  For example, the number of Ceph nodes, or 
> even Ceph vs. LVM, is very relevant to the final report.  I also wish there 
> were an installer agnostic method of collecting this information as right now 
> I keep that code in the ci/daily.sh and other scripts.
>  
> With the new releng repository being created, perhaps it is time to start 
> moving some of the installer specific code there?  I also see that being of 
> benefit when adding XCI support, as technically that would be yet another 
> type of installer.
>  
> 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)  <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 
> <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 
> <mailto:srikanth.vavilapa...@ericsson.com>] 
> Sent:

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

[Jose Lausuch]

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> 
> [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
> +---+
>  
> 发件人: opnfv-tech-discuss-boun...@lists.opnfv.org 
> <mailto: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 
> <mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>] On Behalf Of Jose Lausuch
> Sent: Wednesday, October 11, 2017 10:45 AM
> To: Georg Kunz mailto:georg.k...@ericsson.com>>
> Cc: opnfv-tech-discuss@lists.opnfv.org 
> <mailto:opnfv-tech-discuss@lists.opnfv.org>
> Subject: Re: [opnfv-tech-discuss] [

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

[Jose Lausuch]

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) ; Morgan, Jack 
> 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)  <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 
> <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
> +-------+
>  
> 发件人: opnfv-tech-discuss-boun...@lists.opnfv.org 
> <mailto: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 Ku

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