Re: [opnfv-tech-discuss] Weekly technical discussion meeting

[Cedric OLLIVIER]

Hi,

OPNFV is an integration project leveraging continuous integration best
practices.
Most of the well-known OPNFV milestones can be achieved by linters,
unit tests and fonctional gates (see Functest).

I would encourage a release management focusing on Jenkins rather than
on JIRA.
If we do create JIRA tickets for any non technical reasons, I would
encourage to create a specific release management project rather than
tickets per projects.
The JIRA ticket/task per each project shoud rather be end user driven.

About technical projects, I could suggest a couple of topics:
  - run CNTT RC1/RC2 via GitlabCI/CD
  - CNTT RCX are about deployment not commercial products (OVP)
  - why GitlabCI/CD may not be simpler than Gerrit+Jenkins
  - call for contributions for CNTT RC1/Functest
  - call for contribution for CNTT RC2/Functest

Cédric

Le samedi 28 novembre 2020 à 20:54 +, Al Morton a écrit :
> I'm sure we can think of an efficient way to accomplish release
> management using the existing Jira features in each project's JERMA
> issues.  January, we need to agree on how we will create or revise 
> JIRA issues, and the kinds of fields/tags we will use before we start
> another release.
>  
> Al
>  
> From: opnfv-tech-discuss@lists.opnfv.org [mailto:opnfv-tech-
> disc...@lists.opnfv.org]On Behalf Of Georg Kunz via lists.opnfv.org
> Sent: Wednesday, November 25, 2020 6:44 AM
> To: opnfv-tech-discuss@lists.opnfv.org
> Subject: [opnfv-tech-discuss] Weekly technical discussion meeting
>  
> Hi all,
>  
> This is a call for topics for next week’s technical discussion
> meeting. Please let me know if you’d like to bring up a topic for
> discussion.
>  
> Meeting details:
> 1. Day and Time: 6:00am US Pacific Time /NOW 14:00 UTC (when US
> Standard
> Time) / 13:00 UTC (when US Daylight Savings Time), Mondays.
> 1. Find your Your local time
> 1. Bridge: 
> 1. Zoom
> Meeting: https://zoom.us/j/92285083624?pwd=dTg0WE1aS053eGpHWnc0RlRRai
> 9Cdz09
> 2. You can also dial in using your phone:
> 1. United States (Long distance): +1-669-900-6833 or +1 646 558 8656
> 2. United States (Toll Free): +1-877-369-0926 or +1-855-880-1246
> 3. International numbers
> available:https://zoom.us/zoomconference?m=Xn-
> Kas4jq2GuyfbCCKYpwvi6FpHEYX8n
> 1. More information aboutOPNFV Conferencing Bridge:
> 1. Zoom Meeting info
>   
> Best regards
> Georg
>  
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#24511): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/24511
Mute This Topic: https://lists.opnfv.org/mt/78497648/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] arm-build3 and arm-build4 will be retired

[Cedric OLLIVIER]

Hi Alexandru,

Well noted. I will update the Functest jjbs.
Byw I'm able to build the containers without arm64 build servers.

Thank you for all your contributions,
Cedric

Le jeu. 24 sept. 2020 à 18:41, Alexandru Avadanii <
alexandru.avada...@enea.com> a écrit :

> Hi,
>
> Since we are taking most of the Enea Pharos Lab offline soon, arm-build3
> and arm-build4 will be retired.
>
> I see there are some functest build jobs still occasionally running on
> arm-build4 – these should either be disabled or moved to different hosts,
> either aarch64 baremetal/VMs or using qemu in emulation mode.
>
>
>
> Sorry for the inconvenience,
>
> Alex
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#24428): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/24428
Mute This Topic: https://lists.opnfv.org/mt/77061441/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] FUNCTEST - singlevm1 is failing

[Cedric OLLIVIER]

What's the OpenStack version?
I would rather advise you to select the rolling ones (hunter, iruya, jerma,
kali or latest).


Le mer. 9 sept. 2020 à 20:35, Cedric OLLIVIER  a
écrit :

> Hi,
>
> The timeout are huge and we shouldn't modify them.
>
> Could you please send me all Functest logs (/home/opnfv/functest/results)?
> It will ease finding the root cause.
>
> Cédric
>
> Le mer. 9 sept. 2020 à 19:21, Ankit Goel  a
> écrit :
>
>> Hi All,
>>
>> We have deployed OPNFV via FUEL installer on Azure ubuntu-18.04 instance
>> as Virtual deploy. Deployment is successful.
>>
>> Then we triggered FUNCTEST (with build tag opnfv-9.0.0) and in FUNCTEST
>> - singlevm1 is failing with below error.
>>
>> 2020-09-09 12:26:25,782 - xtesting.ci.run_tests - INFO - Loading test
>> case 'singlevm1'...
>> 2020-09-09 12:26:26,326 - xtesting.ci.run_tests - INFO - Running test
>> case 'singlevm1'...
>> 2020-09-09 12:37:02,985 - functest.core.singlevm - ERROR - cannot connect
>> to 10.16.0.190
>> 2020-09-09 12:37:02,985 - functest.core.singlevm - ERROR - Cannot run
>> singlevm1
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/functest/core/singlevm.py", line
>> 446, in run
>> (self.fip, self.ssh) = self.connect(self.sshvm)
>> TypeError: 'NoneType' object is not iterable
>> 2020-09-09 12:37:02,986 - xtesting.ci.run_tests - INFO - Test result:
>>
>>
>> When we looked into the issue and observed that an instance is being
>> created during this test execution and before it can ssh to the instance,
>> the instance is getting deleted. Thus to fix this issue I logged into the
>> FUNCTEST docker container and increased the ssh_time_out in the file (
>> "/usr/lib/python2.7/site-packages/functest/core/singlevm.py ) so that it
>> can wait for some more time before deleting it. I committed my changes and
>> created a local docker image and created the FUNCTEST container again. This
>> time i could see the vm is not getting deleted within 1-2 min as earlier
>> but it is staying there for 10 min.And i manually tried to ping the
>> instance floating point IP from the host and it was pinging. But the test
>> again failed with an ssh issue with the error as mentioned above.
>>
>> We would appreciate any workaround to resolve this issue.
>>
>> Thanks,
>> Ankit Goel
>>
>> 
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#24377): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/24377
Mute This Topic: https://lists.opnfv.org/mt/76737492/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] FUNCTEST - singlevm1 is failing

[Cedric OLLIVIER]

Hi,

The timeout are huge and we shouldn't modify them.

Could you please send me all Functest logs (/home/opnfv/functest/results)?
It will ease finding the root cause.

Cédric

Le mer. 9 sept. 2020 à 19:21, Ankit Goel  a
écrit :

> Hi All,
>
> We have deployed OPNFV via FUEL installer on Azure ubuntu-18.04 instance
> as Virtual deploy. Deployment is successful.
>
> Then we triggered FUNCTEST (with build tag opnfv-9.0.0) and in FUNCTEST
> - singlevm1 is failing with below error.
>
> 2020-09-09 12:26:25,782 - xtesting.ci.run_tests - INFO - Loading test case
> 'singlevm1'...
> 2020-09-09 12:26:26,326 - xtesting.ci.run_tests - INFO - Running test case
> 'singlevm1'...
> 2020-09-09 12:37:02,985 - functest.core.singlevm - ERROR - cannot connect
> to 10.16.0.190
> 2020-09-09 12:37:02,985 - functest.core.singlevm - ERROR - Cannot run
> singlevm1
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/functest/core/singlevm.py", line
> 446, in run
> (self.fip, self.ssh) = self.connect(self.sshvm)
> TypeError: 'NoneType' object is not iterable
> 2020-09-09 12:37:02,986 - xtesting.ci.run_tests - INFO - Test result:
>
>
> When we looked into the issue and observed that an instance is being
> created during this test execution and before it can ssh to the instance,
> the instance is getting deleted. Thus to fix this issue I logged into the
> FUNCTEST docker container and increased the ssh_time_out in the file (
> "/usr/lib/python2.7/site-packages/functest/core/singlevm.py ) so that it
> can wait for some more time before deleting it. I committed my changes and
> created a local docker image and created the FUNCTEST container again. This
> time i could see the vm is not getting deleted within 1-2 min as earlier
> but it is staying there for 10 min.And i manually tried to ping the
> instance floating point IP from the host and it was pinging. But the test
> again failed with an ssh issue with the error as mentioned above.
>
> We would appreciate any workaround to resolve this issue.
>
> Thanks,
> Ankit Goel
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#24376): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/24376
Mute This Topic: https://lists.opnfv.org/mt/76737492/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] 答复: work on test api - cirv

[Cedric OLLIVIER]

Hi,

You do connect to the root url (/test), login, and then you can declare
your new testcase as PTL.

Swagger can't be used for a while.

Cédric

Le lun. 31 août 2020 à 18:59, Chen Liang  a
écrit :

> Hello all,
>
>
>
> I would like to integrate with test api, by following a
> https://wiki.opnfv.org/pages/viewpage.action?pageId=6825128
>
>
>
> I am facing  “401 Authorization Required” issue when try to create
> a case? http://testresults.opnfv.org/test/swagger/spec.html
> 
>
>
>
> Thank you.
>
> 陈亮|CHEN Liang
>
> 网络与IT技术研究所
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#24350): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/24350
Mute This Topic: https://lists.opnfv.org/mt/76538155/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [opnfv-discuss] Airship external

[Cedric OLLIVIER]

Hi,

Could you please check the routes defined in your jumphost (check the
external network)?
You may try to simply reach any floating ip via your jumphost (docker
simply adds an addional nat).

Cédric

Le lun. 24 août 2020 à 18:55, Vivekanandan Muthukrishnan <
vmuthukrish...@aarnanetworks.com> a écrit :

> Hi All,
>
> Could someone help us with the following issue in the Airship network
> issue.
>
> https://jira.opnfv.org/browse/AIRSHIP-46
>
> The issue is that we are not able to access the external/public virtual
> network created by Airship.
>
> Here is the brief
>
> 1. We could bring up Airship successfully
>
> 2. But functests are failing with the following error message
>
> [image: image.png]
>
> 4. We are not able to access the Airship openstack instances
> public/external IP that is the reason for failure.
>
> We would appreciate any workaround to resolve this issue.
>
> Regards
> Vivek
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#24338): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/24338
Mute This Topic: https://lists.opnfv.org/mt/76389571/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [opnfv-tsc] Closing of Swisscom Open Innovation Lab

[Cedric OLLIVIER]

Hi Daniel,
We will miss you a lot ! It has been a true pleasure to discuss with
you especially during the LFN technical events.You're amongst the best
OPNFV supporters and you always emphasize our leitmotiv: Code first!
+1 for "May the source be with you!""Try it, you will love it" as used
in a few Xtesting presentations makes sense too when you're in the
room.
Cédric
Le mardi 21 avril 2020 à 16:31 +, daniel.balsi...@swisscom.com a
écrit :
> Dear OPNFV & CNTT community
> 
> 
> 
> 
> 
> 
> 
> I hope you are all healthy and enjoy the virtual LFN event these
> days.
> 
> 
> For those who wonder why I was not in the last calls/meetings and not
> participating in the event, here the short explanation:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Swisscom decided to stop all the activities around the Open
> Innovation Lab, which I was responsible for.
> 
> 
> 
> 
> I am not very happy about this strategy but decisions are made. I
> think it is a strategical mistake not to participate in such
> impactful Open Source Initiatives anymore but I could unfortunately
> not influence the decision for a better one.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Since my job does not exist anymore beginning May 1st, my community
> activities for OPNFV and CNTT on behalf of Swisscom have to stop.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> It was a great pleasure for me to work together with you for the last
> half decade, and we also had some impactful results. Especially worth
> to mention is the ONAP BBS use-case which Swisscom contributed
> together with partners. I will try hard to finalize the
>  ONAP BBS use-case testing for Frankfurt (
> https://wiki.onap.org/display/DW/BBS+Swisscom+Lab) together with
> David (CC) before it is unavailable and powered off by end of April.
>  Also my recent activities in OPNFV and CNTT regarding Reference
> Architecture & Implementation / Hardware Validation and NFV-I
> Installers do not make much sense anymore without having a Lab for
> testing available.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Of course I will follow the communities on a private basis, while
> also looking for a new interesting position. After May 1st I will not
> have access to my company email anymore, therefore I am now sharing
> my private contact with you:
> 
> 
> 
> 
> 
> 
> 
> Email: dbals...@bluewin.ch
> 
> 
> IRC: dbalsige
> 
> 
> LinkedIn: 
> https://ch.linkedin.com/in/daniel-balsiger-6b328b114
> 
> 
> 
> 
> Mobile: +41 79 293 14 83
> 
> 
> 
> 
> 
> 
> 
> I wish you all the best and much success with the ongoing activities.
> May the source be with you!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kind regards
> 
> 
> 
> 
> 
> 
> 
> Daniel Balsiger
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#24115): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/24115
Mute This Topic: https://lists.opnfv.org/mt/73236595/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] Who from OPNFV can -2/+2 lf-releng possibly blocking all OPNFV jjb verification

[Cedric OLLIVIER]

+1.For the previous release, it was the exact opposite: lots of
branches were created without any PTL ack (neither author or reviewer)!
https://gerrit.opnfv.org/gerrit/q/owner:jenkins-opnfv-ci%2540opnfv.org+status:merged
Please send me your ticket. I may be able to help you regarding
Dockerhub.
Cédric
On Fri, 2019-12-13 at 22:40 +, Alec Hothan (ahothan) wrote:
>  
> I would propose that PTLs are given permission to manage the branches
> for their repos directly. Those who prefer to go through jjb can do
> so, but we should not force everybody to go
>  thorough JJB.
> I have same concern for
> 
> 
> OPNFV dockerhub repo. I cannot manage my container versions and the
> ticket I had open for it for months is now closed without
>  any resolution due to the move to LF helpdesk (June 2019, I replied
> with the information requested but no follow up unfortunately)OPNFV
> documentation.
>  
> We basically need to allow PTL to bypass JJB based workflows which is
> IMHO very inconvenient and discouraging. How are other LF projects
> doing?
>  
> Thanks
>  
>Alec
>  
>  
> 
> From:
>  on behalf of Cedric OLLIVIER <
> ollivier.ced...@gmail.com>
> 
> Date: Friday, December 13, 2019 at 2:28 PM
> 
> To: "opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>, "opnfv-...@lists.opnfv.org" <
> opnfv-...@lists.opnfv.org>
> 
> Subject: [opnfv-tech-discuss] Who from OPNFV can -2/+2 lf-releng
> possibly blocking all OPNFV jjb verification
> 
> 
>  
> 
> 
> Hi,
> 
> 
>  
> 
> 
> I think a few people have faced with Releng issues for the last days
> 
> 
> when creating their stable branches. The problem is linked to releng-
> 
> 
> jjb-verify which seems defined out of OPNFV via submodule [1] (hoping
> 
> 
> I'm wrong as all OPNFV projects would depend on it) or to the build
> 
> 
> host.
> 
> 
>  
> 
> 
>jenkins_jobs.errors.JenkinsJobsException: Unable to lock cache for
> '
> 
> 
>
> https://build.opnfv.org/ci'
> 
> 
>  
> 
> 
> Please don't call reverify/recheck because the second verification
> 
> 
> seems incorrect due to wrong triggers and could postpone bigger
> issues.
> 
> 
> https://gerrit.opnfv.org/gerrit/c/releng/+/69334
> 
> 
>  
> 
> 
> Can someone manage this issue?
> 
> 
> And who, from OPNFV active members and out of LF, can merge in
> 
> 
> lfit/releng-global-jjb?
> 
> 
>  
> 
> 
> [1] 
> 
> 
> 
https://github.com/lfit/releng-global-jjb/blob/v0.35.0/jjb/lf-ci-jobs.yaml#L898
> 
> 
>  
> 
> 
> Cédric
> 
> 
>  
> 
> 
>  
> 
> 
> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23790): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23790
Mute This Topic: https://lists.opnfv.org/mt/68554822/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] Who from OPNFV can -2/+2 lf-releng possibly blocking all OPNFV jjb verification

[Cedric OLLIVIER]

Please see:
https://jira.opnfv.org/browse/RELENG-427
https://jira.opnfv.org/browse/RELENG-428

Again who, from OPNFV active members and out of LF, can merge in
lfit/releng-global-jjb?

Cédric

On Sat, 2019-12-14 at 22:29 +0100, Cedric OLLIVIER via Lists.Opnfv.Org
wrote:
> Ok the root cause of the false verify +1 is very simple. It was
> verified on May 09 against a very old tree.
> https://build.opnfv.org/ci/job/releng-jjb-verify/1369/
> 
> Else most of the patches were voted -1 due to the failure when
> locking
> cache. https://build.opnfv.org/ci/job/releng-jjb-verify/1584/console
> triggered by https://gerrit.opnfv.org/gerrit/c/releng/+/69327
> 
> Cédric
> 
> On Sat, 2019-12-14 at 14:08 -0500, Aric Gardner wrote:
> > Cedic, I don't understand what you mean
> > 
> > The patchset that caused the problem was reverted.
> > here: https://gerrit.opnfv.org/gerrit/c/releng/+/69343
> > and your patchset was rebased and is verified and ready to submit
> > here.
> > https://gerrit.opnfv.org/gerrit/c/releng/+/69334
> > 
> > On Sat, Dec 14, 2019 at 4:57 AM  wrote:
> > > 
> > > From my understanding, they are multiple issues here.
> > > 
> > > The jjb shouldn't have be merged and the merge error is pretty
> > > clear
> > > How was it verified by the jjb linter? Classical falsy Releng
> > > recheck
> > > or reverify?
> > > 
> > > 13:29:45 yaml.composer.ComposerError: found undefined alias
> > > 'gambia'
> > > https://build.opnfv.org/ci/job/releng-jjb-merge/861/
> > > 
> > > Yes, all next patches will be rated -1 but we can't reach this
> > > step
> > > because the cache is locked.
> > > 
> > > @Aric: Would you mind removing the lock on jjb cache first
> > > (nobody
> > > can't do it out of LF)? and then reverting this change breaking
> > > master?
> > > 
> > > Cédric
> > > 
> > > On Fri, 2019-12-13 at 19:57 -0500, Aric Gardner wrote:
> > > > It was actually this change, that failed jjb-merge
> > > > 
> > > > https://gerrit.opnfv.org/gerrit/c/releng/+/67813
> > > > 
> > > > that is breaking future commits.
> > > > 
> > > > I will look at it tomorrow.
> > > > 
> > > > 
> > > > On Fri, Dec 13, 2019 at 5:28 PM Cedric OLLIVIER
> > > >  wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I think a few people have faced with Releng issues for the
> > > > > last
> > > > > days
> > > > > when creating their stable branches. The problem is linked to
> > > > > releng-
> > > > > jjb-verify which seems defined out of OPNFV via submodule [1]
> > > > > (hoping
> > > > > I'm wrong as all OPNFV projects would depend on it) or to the
> > > > > build
> > > > > host.
> > > > > 
> > > > >jenkins_jobs.errors.JenkinsJobsException: Unable to lock
> > > > > cache
> > > > > for '
> > > > >https://build.opnfv.org/ci'
> > > > > 
> > > > > Please don't call reverify/recheck because the second
> > > > > verification
> > > > > seems incorrect due to wrong triggers and could postpone
> > > > > bigger
> > > > > issues.
> > > > > https://gerrit.opnfv.org/gerrit/c/releng/+/69334
> > > > > 
> > > > > Can someone manage this issue?
> > > > > And who, from OPNFV active members and out of LF, can merge
> > > > > in
> > > > > lfit/releng-global-jjb?
> > > > > 
> > > > > [1]
> > > > > 
> > > 
> > > 
> 
> 
https://github.com/lfit/releng-global-jjb/blob/v0.35.0/jjb/lf-ci-jobs.yaml#L898
> > > > > 
> > > > > Cédric
> > > > > 
> > > > > -=-=-=-=-=-=-=-=-=-=-=-
> > > > > Links: You receive all messages sent to this group.
> > > > > 
> > > > > View/Reply Online (#23781):
> > > > > https://lists.opnfv.org/g/opnfv-tech-discuss/message/23781
> > > > > Mute This Topic: https://lists.opnfv.org/mt/68554822/1009618
> > > > > Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> > > > > Unsubscribe: 
> > > > > https://lists.opnfv.org/g/opnfv-tech-discuss/unsubb  [
> > > > > agard...@linuxfoundation.org]
> > > > > -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#23788): 
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/23788
> Mute This Topic: https://lists.opnfv.org/mt/68554822/1217365
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsubb  [ol
> livier.ced...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23789): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23789
Mute This Topic: https://lists.opnfv.org/mt/68554822/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] Who from OPNFV can -2/+2 lf-releng possibly blocking all OPNFV jjb verification

[Cedric OLLIVIER]

Ok the root cause of the false verify +1 is very simple. It was
verified on May 09 against a very old tree.
https://build.opnfv.org/ci/job/releng-jjb-verify/1369/

Else most of the patches were voted -1 due to the failure when locking
cache. https://build.opnfv.org/ci/job/releng-jjb-verify/1584/console
triggered by https://gerrit.opnfv.org/gerrit/c/releng/+/69327

Cédric

On Sat, 2019-12-14 at 14:08 -0500, Aric Gardner wrote:
> Cedic, I don't understand what you mean
> 
> The patchset that caused the problem was reverted.
> here: https://gerrit.opnfv.org/gerrit/c/releng/+/69343
> and your patchset was rebased and is verified and ready to submit
> here.
> https://gerrit.opnfv.org/gerrit/c/releng/+/69334
> 
> On Sat, Dec 14, 2019 at 4:57 AM  wrote:
> > 
> > From my understanding, they are multiple issues here.
> > 
> > The jjb shouldn't have be merged and the merge error is pretty
> > clear
> > How was it verified by the jjb linter? Classical falsy Releng
> > recheck
> > or reverify?
> > 
> > 13:29:45 yaml.composer.ComposerError: found undefined alias
> > 'gambia'
> > https://build.opnfv.org/ci/job/releng-jjb-merge/861/
> > 
> > Yes, all next patches will be rated -1 but we can't reach this step
> > because the cache is locked.
> > 
> > @Aric: Would you mind removing the lock on jjb cache first (nobody
> > can't do it out of LF)? and then reverting this change breaking
> > master?
> > 
> > Cédric
> > 
> > On Fri, 2019-12-13 at 19:57 -0500, Aric Gardner wrote:
> > > It was actually this change, that failed jjb-merge
> > > 
> > > https://gerrit.opnfv.org/gerrit/c/releng/+/67813
> > > 
> > > that is breaking future commits.
> > > 
> > > I will look at it tomorrow.
> > > 
> > > 
> > > On Fri, Dec 13, 2019 at 5:28 PM Cedric OLLIVIER
> > >  wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > I think a few people have faced with Releng issues for the last
> > > > days
> > > > when creating their stable branches. The problem is linked to
> > > > releng-
> > > > jjb-verify which seems defined out of OPNFV via submodule [1]
> > > > (hoping
> > > > I'm wrong as all OPNFV projects would depend on it) or to the
> > > > build
> > > > host.
> > > > 
> > > >jenkins_jobs.errors.JenkinsJobsException: Unable to lock
> > > > cache
> > > > for '
> > > >https://build.opnfv.org/ci'
> > > > 
> > > > Please don't call reverify/recheck because the second
> > > > verification
> > > > seems incorrect due to wrong triggers and could postpone bigger
> > > > issues.
> > > > https://gerrit.opnfv.org/gerrit/c/releng/+/69334
> > > > 
> > > > Can someone manage this issue?
> > > > And who, from OPNFV active members and out of LF, can merge in
> > > > lfit/releng-global-jjb?
> > > > 
> > > > [1]
> > > > 
> > 
> > 
https://github.com/lfit/releng-global-jjb/blob/v0.35.0/jjb/lf-ci-jobs.yaml#L898
> > > > 
> > > > Cédric
> > > > 
> > > > -=-=-=-=-=-=-=-=-=-=-=-
> > > > Links: You receive all messages sent to this group.
> > > > 
> > > > View/Reply Online (#23781):
> > > > https://lists.opnfv.org/g/opnfv-tech-discuss/message/23781
> > > > Mute This Topic: https://lists.opnfv.org/mt/68554822/1009618
> > > > Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> > > > Unsubscribe: 
> > > > https://lists.opnfv.org/g/opnfv-tech-discuss/unsubb  [
> > > > agard...@linuxfoundation.org]
> > > > -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23788): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23788
Mute This Topic: https://lists.opnfv.org/mt/68554822/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] Who from OPNFV can -2/+2 lf-releng possibly blocking all OPNFV jjb verification

[Cedric OLLIVIER]

>From my understanding, they are multiple issues here.

The jjb shouldn't have be merged and the merge error is pretty clear
How was it verified by the jjb linter? Classical falsy Releng recheck
or reverify?

13:29:45 yaml.composer.ComposerError: found undefined alias 'gambia'
https://build.opnfv.org/ci/job/releng-jjb-merge/861/

Yes, all next patches will be rated -1 but we can't reach this step
because the cache is locked.

@Aric: Would you mind removing the lock on jjb cache first (nobody
can't do it out of LF)? and then reverting this change breaking master?

Cédric

On Fri, 2019-12-13 at 19:57 -0500, Aric Gardner wrote:
> It was actually this change, that failed jjb-merge
> 
> https://gerrit.opnfv.org/gerrit/c/releng/+/67813
> 
> that is breaking future commits.
> 
> I will look at it tomorrow.
> 
> 
> On Fri, Dec 13, 2019 at 5:28 PM Cedric OLLIVIER
>  wrote:
> > 
> > Hi,
> > 
> > I think a few people have faced with Releng issues for the last
> > days
> > when creating their stable branches. The problem is linked to
> > releng-
> > jjb-verify which seems defined out of OPNFV via submodule [1]
> > (hoping
> > I'm wrong as all OPNFV projects would depend on it) or to the build
> > host.
> > 
> >jenkins_jobs.errors.JenkinsJobsException: Unable to lock cache
> > for '
> >https://build.opnfv.org/ci'
> > 
> > Please don't call reverify/recheck because the second verification
> > seems incorrect due to wrong triggers and could postpone bigger
> > issues.
> > https://gerrit.opnfv.org/gerrit/c/releng/+/69334
> > 
> > Can someone manage this issue?
> > And who, from OPNFV active members and out of LF, can merge in
> > lfit/releng-global-jjb?
> > 
> > [1]
> > 
https://github.com/lfit/releng-global-jjb/blob/v0.35.0/jjb/lf-ci-jobs.yaml#L898
> > 
> > Cédric
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > 
> > View/Reply Online (#23781): 
> > https://lists.opnfv.org/g/opnfv-tech-discuss/message/23781
> > Mute This Topic: https://lists.opnfv.org/mt/68554822/1009618
> > Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> > Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsubb  [
> > agard...@linuxfoundation.org]
> > -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23786): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23786
Mute This Topic: https://lists.opnfv.org/mt/68554822/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] Who from OPNFV can -2/+2 lf-releng possibly blocking all OPNFV jjb verification

[Cedric OLLIVIER]

Hi,

I think a few people have faced with Releng issues for the last days
when creating their stable branches. The problem is linked to releng-
jjb-verify which seems defined out of OPNFV via submodule [1] (hoping
I'm wrong as all OPNFV projects would depend on it) or to the build
host.

   jenkins_jobs.errors.JenkinsJobsException: Unable to lock cache for '
   https://build.opnfv.org/ci'

Please don't call reverify/recheck because the second verification
seems incorrect due to wrong triggers and could postpone bigger issues.
https://gerrit.opnfv.org/gerrit/c/releng/+/69334

Can someone manage this issue?
And who, from OPNFV active members and out of LF, can merge in
lfit/releng-global-jjb?

[1] 
https://github.com/lfit/releng-global-jjb/blob/v0.35.0/jjb/lf-ci-jobs.yaml#L898

Cédric

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23781): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23781
Mute This Topic: https://lists.opnfv.org/mt/68554822/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] Functest Ims-based testcases are currently failing (Clearwater repo is down for maintainance)

[Cedric OLLIVIER]

Hi,

Clearwater repo is down for maintainance which raises side effects in
our Ims-based testcases:

http://lists.projectclearwater.org/pipermail/clearwater_lists.projectclearwater.org/2019-October/001800.html

http://lists.projectclearwater.org/pipermail/clearwater_lists.projectclearwater.org/2019-October/001807.html

http://lists.projectclearwater.org/pipermail/clearwater_lists.projectclearwater.org/2019-October/001802.html

Here are this night's Functest runs highlighting the issues:
 - Functest master (OpenStack master) 
https://build.opnfv.org/ci/view/functest/job/functest-latest-daily/355/
 - Functest Iruya (OpenStack Stein) 
https://build.opnfv.org/ci/view/functest/job/functest-iruya-daily/233/
 - Functest Hunter (OpenStack Hunter) 
https://build.opnfv.org/ci/view/functest/job/functest-hunter-daily/291/

To be precise Functest Jerma (OpenStack Train) run failed in rally_full
(just before running the VNFs)

http://artifacts.opnfv.org/functest/functest-opnfv-functest-benchmarking-jerma-rally_full-run-21/results/rally_full/rally_full.html

Only 1 live migrations out of 10 failed which is simply induces by the
extense testing (Jerma and Iruya rally_full are tested in // vs the
same POD (only 1 all-in-one + 1 compute)).
Once again, Functest requires two additional servers to verify Hunter
else we should stop maintaining it.
And that will be an issue for CNTT (OpenStack Pike)...

Cédric
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23696): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23696
Mute This Topic: https://lists.opnfv.org/mt/40889337/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [releng] job dovetail-rtd-verify-master failed

[Cedric OLLIVIER]

Hi,

Functest doesn't need this job as we build our docs directly on readthedocs
(rtd).

Else we (DOC PTL?) could update the job to a newer interpreter available on
the build servers.

Cédric

Le mer. 9 oct. 2019 à 04:25, Dan Xu  a écrit :

> Hi all,
>
>
>
> When I submit a patch to gerrit, it automatically triggers job
> ‘dovetail-rtd-verify-master’. But after Dovetail changing from Python 2 to
> Python 3, this job always failed. See
> https://build.opnfv.org/ci/job/dovetail-rtd-verify-master/97/console
>
> The main error message is,
>
>
>
> ERROR: InterpreterNotFound: python3.5
>
> ___ summary
> 
>
> ERROR:  docs: InterpreterNotFound: python3.5
>
> Build step 'Execute shell' marked build as failure
>
>
>
> I am not very clear about what this job do and why it is triggered for
> Dovetail  (Because I have checked some other projects, and they won’t
> trigger this job).
>
> It seems that this job couldn’t work well for python 3 projects because
> there are only python 2 commands appeared in the console log, such as:
>
>
>
> python -m pip install --user --quiet --upgrade pip
>
> python -m pip install --user --quiet --upgrade setuptools
>
> python -m pip install --user --quiet --upgrade -r /tmp/requirements-cHFa.txt
>
> pip freeze
>
>
>
> Do anyone know something about this?
>
>
>
> Thanks,
>
> Dan Xu
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#23625):
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/23625
> Mute This Topic: https://lists.opnfv.org/mt/34449927/1217365
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [
> ollivier.ced...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23627): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23627
Mute This Topic: https://lists.opnfv.org/mt/34449927/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [Functest] Forbidden: Access denied error

[Cedric OLLIVIER]

Hello,
What's the roles defined for Swift?Could you please send me all
artifacts located in /home/opnfv/functest/results? It will help here.
Thank you,Cédric
Le vendredi 27 septembre 2019 à 06:07 +,  via Lists.Opnfv.Org a
écrit :
> Hi all,
> 
> 
> 
> 
> 
> 
> 
>  While running functest all the tests passed except tempest_smoke
> ,and the error is shown as forbidden.
> 
> 
> Detailed error of one of the test in tempest_smoke is described
> below. Similar errors are there for almost 14 tests.Please help to
> rectify it.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> tempest.api.object_storage.test_account_services.AccountTest.test_lis
> t_containers 
> 
> 
> 
> 
> 
> 
> 
> Traceback (most recent call last):  File
> "/root/.rally/verification/verifier-401a1c02-ee23-4f21-8e14-
> eefd6f9d0f83/repo/tempest/test.py", line 173, in
> setUpClasssix.reraise(etype, value, trace)  File
> "/root/.rally/verification/verifier-401a1c02-ee23-4f21-8e14-
> eefd6f9d0f83/repo/tempest/test.py", line 166, in
> setUpClasscls.resource_setup()  File
> "/root/.rally/verification/verifier-401a1c02-ee23-4f21-8e14-
> eefd6f9d0f83/repo/tempest/api/object_storage/test_account_services.py
> ", line 46, in
> resource_setupcls.container_client.update_container(name)  File
> "/root/.rally/verification/verifier-401a1c02-ee23-4f21-8e14-
> eefd6f9d0f83/repo/tempest/lib/services/object_storage/container_clien
> t.py", line 37, in update_containerresp, body = self.put(url,
> body=None, headers=headers)  File
> "/root/.rally/verification/verifier-401a1c02-ee23-4f21-8e14-
> eefd6f9d0f83/repo/tempest/lib/common/rest_client.py", line 347, in
> putreturn self.request('PUT', url, extra_headers, headers, body,
> chunked)  File "/root/.rally/verification/verifier-401a1c02-ee23-
> 4f21-8e14-eefd6f9d0f83/repo/tempest/lib/common/rest_client.py", line
> 679, in requestself._error_checker(resp, resp_body)  File
> "/root/.rally/verification/verifier-401a1c02-ee23-4f21-8e14-
> eefd6f9d0f83/repo/tempest/lib/common/rest_client.py", line 780, in
> _error_checkerraise exceptions.Forbidden(resp_body,
> resp=resp)tempest.lib.exceptions.Forbidden: ForbiddenDetails:
> ForbiddenAccess was denied to this
> resource.
> 
> 
> 
> 
> 
> 
> 
> 
> Thank you
> 
> 
> 
> 
> 
> 
> 
> Best Regards,
> 
> 
>  
> 
> 
>  Malavika Krishna 
> 
> 
> 
> 
> Confidentiality Notice: This e-mail is strictly confidential and
> intended only for the person or entity to which it is addressed. It
> may contain information that is privileged, confidential or otherwise
> protected from disclosure. If you are
>  not the intended recipient, you must not copy, disclose, distribute
> or take any action in reliance on information contained in this e-
> mail. If you have received this e-mail in error, please notify the
> sender by return e-mail and destroy the original message
>  and all copies thereof.
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-Links: You receive all messages sent to this
> group.
> View/Reply Online (#23605): 
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/23605
> Mute This Topic: https://lists.opnfv.org/mt/34308508/1217365
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [oll
> ivier.ced...@gmail.com]-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23606): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23606
Mute This Topic: https://lists.opnfv.org/mt/34308508/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [Dovetail] Failure of volume related tests

[Cedric OLLIVIER]

Hi,
Forcing cinder = true could please the SUT here which may be wrong
regarding verification or certification.
At first glance , I think block-storage should have been created in
Apex (I'm very suprised we didn't catch it in OPNFV gates) and XCI.
I'm diving into the details but devstack (and the comment in code) is
clear.
Thank your for the feedbacks
Cédric
On Fri, 2019-08-30 at 06:02 +, Malavika Krishna wrote:
> Hi All,
> 
> I was using dovetail: ovp-2.2.0 release,  it used to take 6.3.0
> release of functest  .  As said by Dan , I set cinder = true in ovp-
> 2.2.0 release of dovetail and it did not work. But when I used the
> latest release of dovetail, it took hunter release of
>  functest ,and when I set cinder to true, it passed the volume test. 
> 
> 
> 
> 
> 
> 
> 
>  openstack version: rocky
> 
>   
> 
> 
> 
>  I am using apex installer : hunter release
> 
> 
> 
> 
> 
> I think it should have automatically taken cinderv2 or v3 because
> they are the latest versions of cinder as cinder v1 is deprecated.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thank you
> 
> 
> 
> 
> 
> Best Regards,
> 
> 
> 
> 
> 
> Malavika Krishna
> 
> 
> 
> 
> 
> 
> 
> 
> From: xudan (N) 
> 
> Sent: Thursday, August 29, 2019 1:45 PM
> 
> To: ollivier.ced...@gmail.com ; Malavika
> Krishna ; 
> opnfv-tech-discuss@lists.opnfv.org <
> opnfv-tech-discuss@lists.opnfv.org>
> 
> Subject: RE: [opnfv-tech-discuss] [Dovetail] Failure of volume
> related tests
>  
> 
> 
> 
> 
> 
> 
> Hi Cedric,
>  
> Thanks for helping looking into this problem.
> As I mentioned in my last email that I have met this problem several
> weeks ago. I am using Dovetail latest (Functest Hunter) and XCI
> master.
> Hope this could help to debug this problem.
>  
> Thanks,
> Dan
>  
> 
> 
> From: ollivier.ced...@gmail.com [mailto:ollivier.ced...@gmail.com]
> 
> 
> Sent: Thursday, August 29, 2019 3:56 PM
> 
> To: xudan (N) ; malavik...@thinkpalm.com; 
> opnfv-tech-discuss@lists.opnfv.org
> 
> Subject: Re: [opnfv-tech-discuss] [Dovetail] Failure of volume
> related tests
> 
> 
>  
> 
> Hi,
> 
> 
>  
> 
> 
> We could rather add the right endpoint according to the OpenStack
> release under test.
> 
> 
> 
> Could you please precise the release here?
> 
> 
> 
> 
>  
> 
> 
> From an overall point of view, that hook is incorrect because Rally
> must discover the service and then must write the right tempest
> config.
> 
> 
> 
> 
> Also we may also care about the compatibilities between OS and
> Functest which is very old when executed via Dovetail.
> 
> 
> 
>  
> 
> 
> They are few upstream changes about cinder endpoints and we (Functest
> + Rally) made few many month ago related to latest cinder changes
> (mostly about block-storage).
> 
> 
> https://review.opendev.org/#/c/510939/
> 
> 
> 
> https://review.opendev.org/#/c/652405/
> 
> 
>  
> 
> 
> 
> I may also appreciate any test vs latest Functest (Iruya or Hunter)
> in that conditions.
> 
> 
>  
> 
> 
> Cédric
> 
> 
>  
> 
> 
> Le jeudi 29 août 2019
> à 01:38 +, xudan a 
> écrit :
> 
> > Hi Malavika,
> >  
> > I also met this before. It’s because of that there are only
> > ‘cinderv2’ and ‘cinderv3’ services in the service list. For all
> > tempest test cases,
> >  they automatically generate a default tempest.conf file for
> > running all of them. While there is no service named ‘cinder’ in
> > the list, so the service ‘cinder’ will be set as ‘False’ in
> > tempest.conf. That’s the reason why all volume related tests
> > skipped and
> >  you can also find this file under $DOVETAIL_HOME/results/.
> >  
> > Besides the default tempest.conf, Dovetail also supports end users
> > to make changes to this file. The ‘tenpest_conf.yaml’ under
> > $DOVETAIL_HOME/pre_config
> >  is used to do this.
> > I suggest you to add the following lines to this file and try
> > again. It works for me.
> >  
> > service_available:
> > cinder: True
> >  
> > Feel free to contact me if you have any other questions.
> >  
> > BR,
> > Dan
> >  
> >  
> > 
> > 
> > From:
> > opnfv-tech-discuss@lists.opnfv.org [mailto:
> > opnfv-tech-discuss@lists.opnfv.org]
> > On Behalf Of via Lists.Opnfv.Org
> > 
> > Sent: Wednesday, August 28, 2019 3:08 PM
> > 
> > To: opnfv-tech-discuss@lists.opnfv.org
> > 
> > Cc: opnfv-tech-discuss@lists.opnfv.org
> > 
> > Subject: [opnfv-tech-discuss] [Dovetail] Failure of volume related
> > tests
> > 
> > 
> >  
> > 
> > Hi all,
> > 
> > 
> >  
> > 
> > 
> > I was trying dovetail testing in our infrastructure. All the volume
> > service tests are skipped. The reason given is cinder service is
> > not available. But the service
> >  is available in the openstack and I could attach and detach
> > volumes through dashboard and cli. Please help me to rectify it.
> > 
> > 
> > The openstack service list is listed below
> > 
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > 
> > +--+++
> > 
> > | ID   | Name   | 

Re: [opnfv-tech-discuss] [Dovetail] Failure of volume related tests

[Cedric OLLIVIER]

Hi,
If I'm not wrong, XCI still deploys OpenStack Rocky, right?
https://git.opnfv.org/releng-xci/tree/xci/config/pinned-versions#n40
Devstack creates 'block-storage' which seems fine regarding the
comments
https://github.com/openstack/devstack/blob/stable/rocky/lib/cinder#L350https://github.com/openstack/devstack/blob/stable/rocky/lib/cinder#L354https://github.com/openstack/service-types-authority/blob/master/service-types.yaml#L72
Here are the endpoints defined in our SUT (Rocky)cinder   | block-
storage  | True| public| 
http://172.30.13.91/volume/v3/$(project_id)scinderv2 |
volumev2   | True| public| 
http://172.30.13.91/volume/v2/$(project_id)scinderv3 |
volumev3   | True| public| 
http://172.30.13.91/volume/v3/$(project_id)scinder   |
volume | True| public| 
http://172.30.13.91/volume/v1/$(project_id)s
https://build.opnfv.org/ci/view/functest/job/functest-hunter-daily/221/
Cédric
Le jeudi 29 août 2019 à 08:15 +, xudan (N) a écrit :
> Hi Cedric,
>  
> Thanks for helping looking into this problem.
> As I mentioned in my last email that I have met this problem several
> weeks ago. I am using Dovetail latest (Functest Hunter) and XCI
> master.
> Hope this could help to debug this problem.
>  
> Thanks,
> Dan
>  
> 
> 
> From: ollivier.ced...@gmail.com [mailto:ollivier.ced...@gmail.com]
> 
> 
> Sent: Thursday, August 29, 2019 3:56 PM
> 
> To: xudan (N) ; malavik...@thinkpalm.com; 
> opnfv-tech-discuss@lists.opnfv.org
> 
> Subject: Re: [opnfv-tech-discuss] [Dovetail] Failure of volume
> related tests
> 
> 
>  
> 
> Hi,
> 
> 
>  
> 
> 
> We could rather add the right endpoint according to the OpenStack
> release under test.
> 
> 
> 
> Could you please precise the release here?
> 
> 
> 
> 
>  
> 
> 
> From an overall point of view, that hook is incorrect because Rally
> must discover the service and then must write the right tempest
> config.
> 
> 
> 
> 
> Also we may also care about the compatibilities between OS and
> Functest which is very old when executed via Dovetail.
> 
> 
> 
>  
> 
> 
> They are few upstream changes about cinder endpoints and we (Functest
> + Rally) made few many month ago related to latest cinder changes
> (mostly about block-storage).
> 
> 
> https://review.opendev.org/#/c/510939/
> 
> 
> 
> https://review.opendev.org/#/c/652405/
> 
> 
>  
> 
> 
> 
> I may also appreciate any test vs latest Functest (Iruya or Hunter)
> in that conditions.
> 
> 
>  
> 
> 
> Cédric
> 
> 
>  
> 
> 
> Le jeudi 29 août 2019
> à 01:38 +, xudan a 
> écrit :
> 
> > Hi Malavika,
> >  
> > I also met this before. It’s because of that there are only
> > ‘cinderv2’ and ‘cinderv3’ services in the service list. For all
> > tempest test cases, they
> >  automatically generate a default tempest.conf file for running all
> > of them. While there is no service named ‘cinder’ in the list, so
> > the service ‘cinder’ will be set as ‘False’ in tempest.conf. That’s
> > the reason why all volume related tests skipped and you
> >  can also find this file under $DOVETAIL_HOME/results/.
> >  
> > Besides the default tempest.conf, Dovetail also supports end users
> > to make changes to this file. The ‘tenpest_conf.yaml’ under
> > $DOVETAIL_HOME/pre_config
> >  is used to do this.
> > I suggest you to add the following lines to this file and try
> > again. It works for me.
> >  
> > service_available:
> > cinder: True
> >  
> > Feel free to contact me if you have any other questions.
> >  
> > BR,
> > Dan
> >  
> >  
> > 
> > 
> > From:
> > opnfv-tech-discuss@lists.opnfv.org [mailto:
> > opnfv-tech-discuss@lists.opnfv.org]
> > On Behalf Of via Lists.Opnfv.Org
> > 
> > Sent: Wednesday, August 28, 2019 3:08 PM
> > 
> > To: opnfv-tech-discuss@lists.opnfv.org
> > 
> > Cc: opnfv-tech-discuss@lists.opnfv.org
> > 
> > Subject: [opnfv-tech-discuss] [Dovetail] Failure of volume related
> > tests
> > 
> > 
> >  
> > 
> > Hi all,
> > 
> > 
> >  
> > 
> > 
> > I was trying dovetail testing in our infrastructure. All the volume
> > service tests are skipped. The reason given is cinder service is
> > not available. But the service
> >  is available in the openstack and I could attach and detach
> > volumes through dashboard and cli. Please help me to rectify it.
> > 
> > 
> > The openstack service list is listed below
> > 
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > 
> > +--+++
> > 
> > | ID   | Name   | Type   |
> > 
> > 
> > +--+++
> > 
> > 
> > | 0def4826e05848e7918e076f77dbacf9 | glance | image  |
> > 
> > 
> > | 0f1cc869dd594718ae0f5c18698dc85d | heat-cfn   | cloudformation |
> > 
> > 
> > | 5587c327181544e080056211e1703be4 | gnocchi| metric |
> > 
> > 
> > | 898efdf9d7c0428bb3bd5b8e6af8e874 | heat   | orchestration  |
> > 
> > 
> > | 

Re: [opnfv-tech-discuss] [Dovetail] Failure of volume related tests

[Cedric OLLIVIER]

Hi,
We could rather add the right endpoint according to the OpenStack
release under test.Could you please precise the release here?
>From an overall point of view, that hook is incorrect because Rally
must discover the service and then must write the right tempest
config.Also we may also care about the compatibilities between OS and
Functest which is very old when executed via Dovetail.
They are few upstream changes about cinder endpoints and we (Functest +
Rally) made few many month ago related to latest cinder changes (mostly
about block-storage).
https://review.opendev.org/#/c/510939/https://review.opendev.org/#/c/652405/

I may also appreciate any test vs latest Functest (Iruya or Hunter) in
that conditions.
Cédric
Le jeudi 29 août 2019 à 01:38 +, xudan a écrit :
> Hi Malavika,
>  
> I also met this before. It’s because of that there are only
> ‘cinderv2’ and ‘cinderv3’ services in the service list. For all
> tempest test cases, they
>  automatically generate a default tempest.conf file for running all
> of them. While there is no service named ‘cinder’ in the list, so the
> service ‘cinder’ will be set as ‘False’ in tempest.conf. That’s the
> reason why all volume related tests skipped and you
>  can also find this file under $DOVETAIL_HOME/results/.
>  
> Besides the default tempest.conf, Dovetail also supports end users to
> make changes to this file. The ‘tenpest_conf.yaml’ under
> $DOVETAIL_HOME/pre_config
>  is used to do this.
> I suggest you to add the following lines to this file and try again.
> It works for me.
>  
> service_available:
> cinder: True
>  
> Feel free to contact me if you have any other questions.
>  
> BR,
> Dan
>  
>  
> 
> 
> From: opnfv-tech-discuss@lists.opnfv.org [mailto:
> opnfv-tech-discuss@lists.opnfv.org]
> On Behalf Of via Lists.Opnfv.Org
> 
> Sent: Wednesday, August 28, 2019 3:08 PM
> 
> To: opnfv-tech-discuss@lists.opnfv.org
> 
> Cc: opnfv-tech-discuss@lists.opnfv.org
> 
> Subject: [opnfv-tech-discuss] [Dovetail] Failure of volume related
> tests
> 
> 
>  
> 
> Hi all,
> 
> 
>  
> 
> 
> I was trying dovetail testing in our infrastructure. All the volume
> service tests are skipped. The reason given is cinder service is not
> available. But the service
>  is available in the openstack and I could attach and detach volumes
> through dashboard and cli. Please help me to rectify it.
> 
> 
> The openstack service list is listed below
> 
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
> +--+++
> 
> | ID   | Name   | Type   |
> 
> 
> +--+++
> 
> 
> | 0def4826e05848e7918e076f77dbacf9 | glance | image  |
> 
> 
> | 0f1cc869dd594718ae0f5c18698dc85d | heat-cfn   | cloudformation |
> 
> 
> | 5587c327181544e080056211e1703be4 | gnocchi| metric |
> 
> 
> | 898efdf9d7c0428bb3bd5b8e6af8e874 | heat   | orchestration  |
> 
> 
> | a400238085e24112b4320cc6f4b803a2 | cinderv2   | volumev2   |
> 
> 
> | a9b2885022e545cbaaae6dcbe6498fa8 | aodh   | alarming   |
> 
> 
> | adedf196a7e44929b1b6f85e4f7c67e0 | panko  | event  |
> 
> 
> | aec0887ed93c45b196c141f7945db0d8 | nova   | compute|
> 
> 
> | afe3685d798b4940b5922ae11f87cf0b | cinderv3   | volumev3   |
> 
> 
> | b5342f4efa364d54bd74b02600cb2d00 | keystone   | identity   |
> 
> 
> | cdfd3b6a5dd94e94898c8f3f3c82a324 | swift  | object-store   |
> 
> 
> | d6b3d664783e4f7d9b88d96119bf1dbc | neutron| network|
> 
> 
> | d82ce54a51054d1dbd3b300b17905955 | ceilometer | metering   |
> 
> 
> | f83e3ee618bd4cbdb09bcc6395718722 | placement  | placement  |
> 
> 
> +--+++
> 
> 
> 
>  
> 
> 
>  
> 
> 
> cinder service list is also given below:
> 
> 
>  
> 
> 
> +--+--+--+---
> --+---++-+
> 
> | Binary   | Host | Zone |
> Status  | State | Updated_at | Disabled Reason |
> 
> 
> +--+--+--+---
> --+---++-+
> 
> 
> | cinder-scheduler | overcloud-controller-0   | nova |
> enabled | up| 2019-08-28T06:53:55.00 | -   |
> 
> 
> | cinder-volume| overcloud-controller-0@tripleo_iscsi | nova |
> enabled | up| 2019-08-28T06:54:02.00 | -   |
> 
> 
> +--+--+--+---
> --+---++-+
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
> Thank you
> 
> 
>  
> 
> 
> Regards,
> 
> 
> Malavika Krishna
> 
> 
>  
> 
> 
>  
> 
>  
> 
> 
> 
> 
> Confidentiality Notice: This e-mail is strictly confidential and
> intended only for the person or entity to 

Re: [opnfv-tech-discuss] [Functest] How to debug Functest using PyCharm

[Cedric OLLIVIER]

Hi Malavika,
Have you precised the upper-constraints when installing the
package?Then the right versions will be automatically installed. 
Cédric
Le mardi 30 juillet 2019 à 07:00 +,  via Lists.Opnfv.Org a écrit :
> Hi all,
> 
> 
>  
> 
> 
> Recently I tried to debug functest code in visual studio code
> (outside docker) by installing prerequisites specified in docker but
> couldnt succeed . I checked in developer guides but I could'nt find
> anything helpful. Can you specify any related docs on how
>  to debug functest.
> 
> 
> 
> 
> 
> 
> 
> Thank you
> 
> 
> 
> 
> 
> 
> 
> Malavika Krishna
> 
> 
> 
> 
> Confidentiality Notice: This e-mail is strictly confidential and
> intended only for the person or entity to which it is addressed. It
> may contain information that is privileged, confidential or otherwise
> protected from disclosure. If you are
>  not the intended recipient, you must not copy, disclose, distribute
> or take any action in reliance on information contained in this e-
> mail. If you have received this e-mail in error, please notify the
> sender by return e-mail and destroy the original message
>  and all copies thereof.
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-Links: You receive all messages sent to this
> group.
> View/Reply Online (#23419): 
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/23419
> Mute This Topic: https://lists.opnfv.org/mt/32684474/1217365
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [oll
> ivier.ced...@gmail.com]-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23479): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23479
Mute This Topic: https://lists.opnfv.org/mt/32684474/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [opnfv-tsc] Can installers use CircleCI?

[Cedric OLLIVIER]

Hi,

Could we please clean the Jenkins job cache and generate the Jenkins
jobs. Some multijobs have been false for a while and it will be great
to maintain the current system even if it concerns a few active
projects right now.

It would have been great to investigate why it has occured a few times
(git revert?).

Thank you in advance,
Cédric

On Mon, 2019-08-05 at 11:33 -0700, Trevor Bramwell wrote:
> Hey Manuel,
> 
> Always happy to have help! :)
> 
> I think I need to verify I can deploy XCI first before tossing CI at
> it,
> as that tends to add more complexity.
> 
> The runners in Gitlab are analagous to machines in Jenkins, with the
> exception that 1 runner = 1 executor; to add more executors on a
> server
> you'd need to start more runner processes. But to do a baremetal
> deployment I would just need to reserve the 6 servers in LaaS and
> connect the jumpserver as the runner.
> 
> Regards,
> Trevor Bramwell
> 
> On Fri, Aug 02, 2019 at 03:43:32PM +, Manuel Buil wrote:
> > Hello Trevor,
> > 
> > Cool! Thanks.
> > 
> > If you want we work together to try to understand why it fails for
> > XCI. That way we will probably find gaps.
> > 
> > Note that you are doing a "virtual" deployment, where controller
> > and computes are in VMs. When you were reading the documentation,
> > did you find a way to deploy baremetal?
> > 
> > Thanks,
> > Manuel
> > 
> > 
> > From: opnfv-...@lists.opnfv.org  on
> > behalf of Trevor Bramwell 
> > Sent: Tuesday, July 30, 2019 12:10 AM
> > To: Manuel Buil 
> > Cc: ahot...@cisco.com ; 
> > opnfv-tech-discuss@lists.opnfv.org <
> > opnfv-tech-discuss@lists.opnfv.org>; opnfv-...@lists.opnfv.org <
> > opnfv-...@lists.opnfv.org>
> > Subject: Re: [opnfv-tsc] Can installers use CircleCI?
> > 
> > Hi Manuel, Alec, et al.
> > 
> > I finished up a guide[1] for setting up repos on CircleCI, Gitlab-
> > CI,
> > and Azure Pipelines for testing these proof-of-concepts (PoCs).
> > 
> > Hopefully this will help anyone who has the cycles to dig into
> > these
> > platforms and find if they'll meet our needs.
> > 
> > It was pretty easy to get a machine from LaaS connected up the
> > Gitlab-CI
> > and attempt to run XCI[2] (though I've yet to successfully deploy
> > it),
> > and I don't think I'll have any issues trying to connect it to
> > Azure
> > Pipelines. From what I know of CircleCI it will take a bit more
> > work
> > though as it can only SSH out, and that would require first setting
> > up
> > the VPN connection.
> > 
> > Regards,
> > Trevor Bramwell
> > 
> > [1] https://wiki.opnfv.org/display/INF/PoC+Setup
> > [2] https://gitlab.com/bramweltci/releng-xci/pipelines
> > 
> > On Tue, Jul 09, 2019 at 04:49:42PM +, Manuel Buil wrote:
> > > Thanks for sharing the details Alec. It sounds like an
> > > interesting PoC and will give us a lot of insights .
> > > 
> > > I also think those baremetal features will be hard to get but
> > > that needs to be investigated. By your information, I am also
> > > realizing that multi-distro is not supported and we are tight to
> > > the images they offer, which are not that many, just ubuntu-1604. 
> > > For example, by looking at Airship's CI, they use ubuntu-1804 for
> > > OpenStack Stein or later, so we would not be able to deploy it in
> > > CircleCI. Not sure how much influence we could have over CircleCI
> > > to get multi-distro support .
> > > 
> > > 
> > > Regards,
> > > Manuel
> > > 
> > > From: opnfv-...@lists.opnfv.org  on
> > > behalf of Alec via Lists.Opnfv.Org <
> > > ahothan=cisco@lists.opnfv.org>
> > > Sent: Tuesday, July 9, 2019 5:53 PM
> > > To: Manuel Buil
> > > Cc: opnfv-...@lists.opnfv.org
> > > Subject: Re: [opnfv-tsc] Can installers use CircleCI?
> > > 
> > > 
> > > Hi Manuel,
> > > 
> > > 
> > > 
> > > I doubt circleci can do any of the features you describe below
> > > other than perhaps nested virtualization (VM in VM).
> > > 
> > > Circle ci is great to build software and do unit testing of it,
> > > what you need for the below is a bare metal cloud such as
> > > packet.net or OPNFV LaaS.
> > > 
> > > You can chose between a few flavors of VMs or docker containers
> > > to run your workload (
> > > https://circleci.com/docs/2.0/configuration-reference/#machine)
> > > 
> > > I don’t see how they can provide anything closer to bare metal.
> > > 
> > > 
> > > 
> > > I am planning to test circleci to do the following with nfvbench:
> > > 
> > >   *   Build VM images and push them to a VM image repo
> > >   *   Build docker containers and push them to docker hub
> > > 
> > > Unit testing that does not require any HW dependencies
> > > 
> > > Nothing really extraordinary…
> > > 
> > > My project is a good example of tool that is highly dependent on
> > > NIC hardware and kernel settings. If I can’t control those by API
> > > I’m pretty much limited to SW unit testing.
> > > 
> > > 
> > > 
> > > The only way to test an installer is to run it on a set of

Re: [opnfv-tech-discuss] Functest Execution on Remote Jumphost

[Cedric OLLIVIER]

Hello,

You must be able to reach all $OS_INTERFACE endpoints and Keystone internal
endpoint from our containers, and then public endpoints from VMs (VNF).
Else this error is returned.
If I'm not wrong, you can directly run your containers from Director.

EXTERNAL_NETWORK is the public network defined as gateway for the routers.
Functest can find it but they are few cases which require to set the env
var (testcases executed in parallel, falsy external networks, etc...).

Your env file seems right (you may add one env var if ceph)

Gambia is over.
I would advice you to run our hunter (rocky) or iruya (stein) containers
thanks to the backward compatibilites.

Cédric


Le lun. 22 juil. 2019 à 09:03, Serkan ERKMEN  a
écrit :

> Hello All,
>
> We are trying to initiate Functest:Gambia test suite for our RedHat
> Openstack Environment.
>
> Our challange is having seperate networks for Jumphost and RedHat
> Openstack Environment.
>
>
>
> However, we are not sure how to configure Functest:Gambia in order to
> reach remote RedHat Openstack Environment while running its tests.
>
> I will appreciate for any comments on this problem.
>
>
>
>
>
> I am not sure what to set for EXTERNAL_NETWORK variable.
>
>
>
> Here is my env file configuration for functest:
>
> [root@localhost ~]# more env
>
> EXTERNAL_NETWORK=floating_network
>
> DEPLOY_SCENARIO=os-nosdn-nofeature-ha
>
> NAMESERVER=10.154.7.21
>
>
>
> Below, you may see some outputs about test results:
>
> 2019-07-22 09:48:04,717 -
> functest.opnfv_tests.openstack.api.connection_check - ERROR - Cannot run
> connection_check
>
> Traceback (most recent call last):
>
>   File
> "/usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/api/connection_check.py",
> line 39, in run
>
> assert self.cloud
>
> AssertionError
>
>
>
>
>
>
> ++--+-+--++
>
> | TEST CASE  | PROJECT  | TIER
> | DURATION | RESULT |
>
>
> ++--+-+--++
>
> |  connection_check  | functest | healthcheck
> |  XX:XX   |  FAIL  |
>
> |   tenantnetwork1   | functest | healthcheck
> |  00:00   |  SKIP  |
>
> |   tenantnetwork2   | functest | healthcheck
> |  00:00   |  SKIP  |
>
>
>
>
>
> Thank you
>
> Regards
>
> Serkan
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#23381):
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/23381
> Mute This Topic: https://lists.opnfv.org/mt/32556095/1217365
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [
> ollivier.ced...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23382): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23382
Mute This Topic: https://lists.opnfv.org/mt/32556095/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] TSC Nomination: Cedric Ollivier from Orange

[Cedric OLLIVIER]

I accept the nomination.
Thank you,Cédric
On Sat, 2019-07-06 at 20:11 +, HU, BIN wrote:
> Dear OPNFV Community,
>  
> I would like to nominate Cedric Ollivier from Orange for a seat on
> the TSC.
>  
> Being a current member of TSC, Cedric has made many contributions to
> OPNFV over the past years. He has been leading FuncTest project as
> well as been an active contributor in the Test community. In the past
>  year, Cedric is the most productive contributor to OPNFV according
> to the consolidated metrics as well as in Code Merge and Code Review
> categories. He received Hunter Community Award for 3 categories –
> Code Development, Integration and Testing.
>  
> Thank you for consideration.
>  
> Bin
>  
> 
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-Links: You receive all messages sent to this
> group.
> View/Reply Online (#23332): 
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/23332Mute This
> Topic: https://lists.opnfv.org/mt/32330775/1217365Group Owner: opnfv-
> tech-discuss+owner@lists.opnfv.orgUnsubscribe: 
> https://lists.opnfv.org/g/opnfv-tech-discuss/unsubb  [ollivier.cedric
> @gmail.com]-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/2
Mute This Topic: https://lists.opnfv.org/mt/32330775/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] Regarding Functest execution with member user role

[Cedric OLLIVIER]

Hi Deepak,
Most notably, IaaS verification requires the admin role to check or
call the admin operations (tempest, rally, vmtp, etc...).But Functest
also asks for this role to ensure that the testcases can be executed
whatever the resources already allocated when:  - verifying production
environment  - running the Functest testcases in parallel  - etc
Creating users simply avoids reaching quotas, protects vs conflicts
with existing resources, bypasses bugs/limitations in upstream
components, etc...
It's worth mentioning that the new user created will be member if the
testcase allows it (e.g. VNFs). 

I will dive into the testcase list which could run in that context +
the hacks required.
But I won't promote that way due to the quick troubles.

The question is opened to ease developing new testcases on top of our
Functest scenarios (functest/core).
At least we may add logics to stop creating flavors which may be also
reconsidered in the context of CNTT/GSMA.

Thank you for your feedbacks,
Cédric

On Mon, 2019-07-01 at 02:39 +,  via Lists.Opnfv.Org wrote:
> Hello All,
>  
> Since I am a new user of Functest and trying to run some Functest
> suites on my setup.
> In my test setup, I have a tenant and a user on that tenant with
> member access role.
>  
> I want to know which all Functest suites or Functest cases can be
> executed on a tenant without admin role as my user has only member
> privilege.
> 
> And, if this is possible for some suites then what modifications
> needs to be done for this ?
>  
>  
> 
> Thanks & Regards,
> 
> Deepak Chandella
> Tech Lead
> TGI/OLN- INDIA
> 
> Tower B, 8th Floor, DLF Infinity Towers, 
> 
> DLF Cyber City Phase - II
> 
> Gurgaon - 122002, Haryana, INDIA
> 
> ( Tel:
>  +91-124-4358000
> 
> ( Mobile: +91-8802972597
> 
> [CVS]  
> 357 4921
> 
> [Email]
> deepak.chande...@orange.com
>  
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent doncpas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signalera 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.
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-Links: You receive all messages sent to this
> group.
> View/Reply Online (#23307): 
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/23307Mute This
> Topic: https://lists.opnfv.org/mt/32281623/1217365Group Owner: opnfv-
> tech-discuss+owner@lists.opnfv.orgUnsubscribe: 
> https://lists.opnfv.org/g/opnfv-tech-discuss/unsubb  [ollivier.cedric
> @gmail.com]-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23324): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23324
Mute This Topic: https://lists.opnfv.org/mt/32281623/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [functest] a question about using tempest_custom/blacklist.yaml

[Cedric OLLIVIER]

Hi,
Yes we can easily update that part even if the benefits are not so
clear out of '*'.We can allow regex in our logics (or simply exclude
the tests for all values if scenarios is unset in blacklist.yaml).I
will add you as reviewer. 
Cédric

On Fri, 2019-06-21 at 08:25 +, xudan wrote:
> Hi all,
> 
>  
> 
> As Cedric suggested in the Plugfest, Dovetail can use blacklist.yaml
> to exclude some sub test cases from the whole test list (e.g.
> patrole, refstack_defcore).
> 
> I have tried to use blacklist.yaml for patrole and it almost works
> well except a tiny issue.
> 
> The scenario condition in tempest_custom/blacklist.yaml seems to be
> exactly match [1] while there is another rally/blacklist.yaml
> supports to use regular expression [2] to match scenarios.
> 
> For Dovetail, it should exclude the sub test cases in blacklist for
> all scenarios even the arbitrary strings set by users.
> 
> Is there any solution for this? Do I miss something?
> 
>  
> 
> BR,
> 
> Dan Xu
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23323): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23323
Mute This Topic: https://lists.opnfv.org/mt/32156487/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [opnfv-tsc] Experimenting Cloud Service (GitHub + CircleCI) Recommended by TAC Infra WG

[Cedric OLLIVIER]

Hi,

My main concern about Releng is simply its overall architecture (I consider
Jenkins jobs builder as quite powerful even if we do spend time before
mastering it).
It forbids all projects to manage jobs in project branches (see Zuul,
travis-ci,etc...). Then a simple renaming leads to lots of staff to bypass
Releng rolling mode.
And all projects must publish changes in a centralized place where PTLs
don't have right to merge for good reasons.
Instead we should have implemented an additional layer between jjbs and
yaml files which could have been hosted in OPNFV project.

Functest team has proposed for a while configuration for building
containers in travis-ci.org (see Rapberry PI containers).
It's much more easier even if we are able to convert yaml files hosted in
Functest to Releng jjbs via xtesting ansible role.
https://git.opnfv.org/functest/tree/.travis.yml
https://git.opnfv.org/functest-kubernetes/tree/ansible/site.yml
https://git.opnfv.org/releng/tree/jjb/functest/functest-kubernetes.yaml

@Alec: please add me as reviewer of your changes in releng.

Cédric

Le ven. 7 juin 2019 à 22:21, Alec via Lists.Opnfv.Org  a écrit :

> I would be interested to participate (NFVbench project). I am actually
> willing to try anything that moves us away from releng repo and JJB.
>
>
>
> I would like to point out that the current CI/CD based on Jenkins is not
> providing sufficient permission for PTLs to customize as almost every
> aspect of CI/CD is based on the releng repo which requires lengthy
> turnaround time when the releng team is busy doing other work.
>
>
>
> One example is a gerrit review I submitted about 7 days ago and still
> waiting for a review from the releng team. I have to generate new VM image
> versions in my CI/CD and such a simple task has proved difficult to achieve
> or adjust with the current framework.
>
> Same goes with docker images generated in dockerhub and for which PTLs
> have no way to customize (e.g. remove stale images, edit the project
> dockerhub description content etc…) as it is owned by “opnfv”. I think
> these will get resolved with patience but I would have taken care of these
> roadblocks easily if I had more control on the CI/CD workflow for my
> project.
>
>
>
> Using Jenkins as the CI/CD base engine might provide good support for
> exiting opnfv projects but my own experience with it has not been good
> overall as it relies on knowing the arcane behavior of JJB (Jenkins job
> builder) which is not exactly very intuitive, especially we have little way
> of testing our changes without involving the releng team and doing trial
> commits into the releng repo. The releng team has been doing a great job
> trying to keep up with the reviews generally but I don’t think we can
> continue that path to have releng team gate every single aspect of a
> project CI/CD, especially with less and less resources allocated to that
> task.
>
> The only scalable way moving forward is to give more power to PTLs so they
> can customize their CI/CD as much as possible without having to depend on a
> third party team.
>
>
>
> I hope the new proposal will move us to that direction.
>
>
>
> Thanks
>
>
>
> Alec
>
>
>
> *From: * on behalf of "HU, BIN"  >
> *Date: *Friday, June 7, 2019 at 10:59 AM
> *To: *"opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>, opnfv-project-leads <
> opnfv-project-le...@lists.opnfv.org>
> *Cc: *"opnfv-...@lists.opnfv.org" 
> *Subject: *[opnfv-tsc] Experimenting Cloud Service (GitHub + CircleCI)
> Recommended by TAC Infra WG
>
>
>
> Hello PTLs and Community,
>
>
>
> Following TAC Infra WG’s recommendation of the path of infrastructure
> evolution [1], and TAC’s discussion on May 22nd [2], TSC discussed this
> topic at our TSC meeting on May 28th.
>
>
>
> According to OPNFV TSC Meeting on May 28th [3], OPNFV TSC “*AGREED*: The
> TSC agrees with the recommendation from the TAC infra WG and will
> investigate how best to implement the recommendation within OPNFV.”
>
>
>
> We are starting the effort of investigating the implementation and
> transition plan. We will set up experimental repos in GitHub, and
> experiment project’s integration with CircleCI there. Some experts who
> already have experimented in TAC Infra WG, e.g. ONAP CLAMP, FD.io VPP,
> etc., will be able to help us.
>
>
>
> For those projects or anyone who are interested in participating in this
> experiment, please contact me directly.
>
>
>
> Thank you and have a great weekend.
>
> Bin
>
>
>
> [1]
> https://wiki.lfnetworking.org/display/LN/Infrastructure+Working+Group+Summary+Report
>
> [2] https://wiki.lfnetworking.org/display/LN/2019-05-22+Meeting+notes
>
> [3]
> http://meetbot.opnfv.org/meetings/opnfv-meeting/2019/opnfv-meeting.2019-05-28-12.55.html
>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#5306):
> https://lists.opnfv.org/g/opnfv-tsc/message/5306
> Mute This Topic: https://lists.opnfv.org/mt/31977409/1217365

Re: [opnfv-tech-discuss] ONS Un-conference topic - Leverage OPNFV Test Frameworks

[Cedric OLLIVIER]

Xtesting is the former Functest framework which has been released
separately since march 2018.I second Morgan and we can consider it as
an old OPNFV project.
https://lists.onap.org/g/onap-discuss/message/16422
Here are the OPNFV links:
https://git.opnfv.org/functest-xtesting/https://build.opnfv.org/ci/view/xtesting/https://hub.docker.com/r/opnfv/xtesting/tags
Only the ansible role is hosted by collivier in Ansible  Galaxy.As far
as I know OPNFV hasn't created an account in Ansible Galaxy as opposed
to OpenStack.And we had to quickly setup the git project and the
Ansible galaxy repo for the OPNFV plugfest demos.  
Cédric
Le lundi 01 avril 2019 à 13:30 +, Beierl, Mark a écrit :
> With all due respect, I would not call David’s message damaging.
>  
> In the software/releases Wiki space,, there is only one passing
> reference to Xtesting put in place by you starting around April 9,
> 2018.  Note: David is a release manager, and as such closely follows
> the releases.  If Xtesting is not releases,
>  then it is perfectly understandable that he is not aware of it.
>  
> When I search for Xtesting in the wiki, I get references to pages
> that refer to “collivier” in sources.  I would definitely not have
> considered those to be part of OPNFV, so if Xtesting is supposed to
> be official, then please do make it
>  so and host it via LFN.
>  
> 
> Regards,
> Mark
>  
> Mark Beierl
> SW System Sr Principal Developer
> Dell EMC |
>  Cloud & Communication Service Provider Solution
> 
> mark.bei...@dell.com
>  
> 
> From:  on behalf of Cedric
> OLLIVIER 
> 
> Date: Saturday, March 30, 2019 at 13:12
> 
> To: "HU, BIN" , "Cooper, Trevor" <
> trevor.coo...@intel.com>, "opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>, "test...@lists.opnfv.org" <
> test...@lists.opnfv.org>
> 
> Cc: "dmcbr...@linuxfoundation.org" ,
> Pierre Lynch , "Limingjiang (Rex)" <
> limingji...@huawei.com>, Heather Kirksey <
> hkirk...@linuxfoundation.org>, "cedric.olliv...@orange.com" <
> cedric.olliv...@orange.com>
> 
> Subject: Re: [opnfv-tech-discuss] ONS Un-conference topic - Leverage
> OPNFV Test Frameworks
> 
> 
>  
> 
> 
> [EXTERNAL EMAIL] 
> 
> 
> Hello,
> 
> 
>  
> 
> 
> Who is the target audience here? internal or external?
> 
> 
> At firth glance, I would have considered internal discussions to
> prevent from next damaging public messages like the next 2 email sent
> to ONAP TSC and OPNFV TSC.
> 
> 
> https://lists.onap.org/g/onap-tsc/message/4804
> 
> 
> https://lists.opnfv.org/g/opnfv-tsc/message/5050?p=,,,20,0,0,0::Created,,Lack+of+developers,20,2,0,29775334
> 
> 
>  
> 
> 
> We have given lots of speechs in the last ONS summits about that
> topic and it seems we are still unsuccessfull in OPNFV (and our tools
> are already reused by LFN projects)
> 
> 
> https://sched.co/EF9Z
> 
> 
> https://www.sdxcentral.com/articles/news/opnfvs-6th-release-brings-testing-capabilities-that-orange-is-already-using/2018/05/
> 
> 
> https://sched.co/Fmsd
> 
> 
> https://sched.co/LKU3
> 
> 
>  
> 
> 
> + OPNFV Hackfest/Plugest
> 
> 
> http://testresults.opnfv.org/functest/gambia/
> 
> 
> http://testresults.opnfv.org/functest/functest2019/
> 
> 
> etc...
> 
> 
>  
> 
> 
> 
> Yes Xtesting is hosted by OPNFV (Functest).
> 
> 
> It's worth mentioning that Bitergia quickly highlights that more than
> 50% of the overall code contribution in OPNFV from the beginning of
> the year is about Functest and its subprojects.
> 
> 
> It should be even bigger if we take the other OPNFV test frameworks
> into account.
> 
> 
> https://opnfv.biterg.io/app/kibana
> 
> 
> 
>  
> 
> 
> Cédric
> 
> 
>  
> 
> 
> Le jeudi 28 mars 2019 à 18:54 +, HU, BIN a écrit :
> 
> > Great, Trevor, thank you for leading this effort.
> >  
> > Would you add this topic in 
> > https://wiki.opnfv.org/display/EVNT, where we collect OPNFV related
> > topics for ONS so that people will have an overall insight of all
> > OPNFV related activities in ONS?
> >  
> > Thank you
> > Bin
> >  
> > 
> > 
> > From: test...@lists.opnfv.org 
> > On Behalf Of Cooper, Trevor
> > 
> > Sent: Thursday, March 28, 2019 11:51 AM
> > 
> > To: opnfv-tech-discuss@lists.opnfv.org; test...@lists.opnfv.org
> > 
> > Cc: dmcbr...@linuxfoundation.org; Pierre Lynch <
> > pierre.ly...@keysight.com>; Limingjiang (Rex) <
> > limingji.

Re: [opnfv-tech-discuss] ONS Un-conference topic - Leverage OPNFV Test Frameworks

[Cedric OLLIVIER]

Hello,
Who is the target audience here? internal or external?At firth glance,
I would have considered internal discussions to prevent from next
damaging public messages like the next 2 email sent to ONAP TSC and
OPNFV TSC.
https://lists.onap.org/g/onap-tsc/message/4804https://lists.opnfv.org/g/opnfv-tsc/message/5050?p=,,,20,0,0,0::Created,,Lack+of+developers,20,2,0,29775334
We have given lots of speechs in the last ONS summits about that topic
and it seems we are still unsuccessfull in OPNFV (and our tools are
already reused by LFN projects)
https://sched.co/EF9Zhttps://www.sdxcentral.com/articles/news/opnfvs-6th-release-brings-testing-capabilities-that-orange-is-already-using/2018/05/https://sched.co/Fmsdhttps://sched.co/LKU3
+ OPNFV Hackfest/Plugest
http://testresults.opnfv.org/functest/gambia/http://testresults.opnfv.org/functest/functest2019/etc
...
Yes Xtesting is hosted by OPNFV (Functest).
It's worth mentioning that Bitergia quickly highlights that more than
50% of the overall code contribution in OPNFV from the beginning of the
year is about Functest and its subprojects.
It should be even bigger if we take the other OPNFV test frameworks
into account.
https://opnfv.biterg.io/app/kibana id="-x-evo-selection-start-marker">
Cédric
Le jeudi 28 mars 2019 à 18:54 +, HU, BIN a écrit :
> Great, Trevor, thank you for leading this effort.
>  
> Would you add this topic in 
> https://wiki.opnfv.org/display/EVNT, where we collect OPNFV related
> topics for ONS so that people will have an overall insight of all
> OPNFV related activities in ONS?
>  
> Thank you
> Bin
>  
> 
> 
> From: test...@lists.opnfv.org 
> On Behalf Of Cooper, Trevor
> 
> Sent: Thursday, March 28, 2019 11:51 AM
> 
> To: opnfv-tech-discuss@lists.opnfv.org; test...@lists.opnfv.org
> 
> Cc: dmcbr...@linuxfoundation.org; Pierre Lynch <
> pierre.ly...@keysight.com>; Limingjiang (Rex)  >
> 
> Subject: [test-wg] ONS Un-conference topic - Leverage OPNFV Test
> Frameworks
> 
> 
>  
> Based on a discussion in the Test Working Group today I have added
> this proposed un-conference topic on testing. We are looking for
> volunteers to help lead the discussion, please consider adding your
> name
>  and creating awareness with other LFN communities that may be
> interested.
> https://wiki.lfnetworking.org/display/LN/Open+Networking+Summit+North+America+2019+-+Un-conference+Topic+Proposals
>  
>  
> Detailed Description: OPNFV has developed significant functional and
> performance test assets including frameworks, tools, methods, test
> cases and test data. For an overview of the OPNFV Test Ecosystem
> refer
>  to 
> https://docs.opnfv.org/en/stable-gambia/testing/ecosystem/overview.html. The 
> significant investments in OPNFV test projects and related
> activities could be leveraged by other LFN projects that require
> testing of integrated upstream ingredients and platforms.
>  This discussion is to brainstorm about how to reuse existing work
> and artifacts so that we do not reinvent proverbial wheels in this
> arena. All ideas and input are welcome!
>  
> /Trevor
>  
>  
> 
> _._,_._,_
> 
> 
> 
> 
> Links:
> You receive all messages sent to this group. 
> View/Reply
>  Online (#696) | 
> Reply To Sender | 
> Reply To Group | 
> Mute This Topic | 
> New Topic
> 
> 
> 
> Your
>  Subscription | Contact Group Owner |
> 
> Unsubscribe [bh5...@att.com]
> 
> _._,_._,_
> 
> 
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-Links: You receive all messages sent to this
> group.
> View/Reply Online (#22996): 
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/22996
> Mute This Topic: https://lists.opnfv.org/mt/30814739/1217365
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [oll
> ivier.ced...@gmail.com]-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23000): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23000
Mute This Topic: https://lists.opnfv.org/mt/30814739/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] How to activate tests in functest-features

[Cedric OLLIVIER]

snaps has been removed from the upper-constraints provided by
Functest.Then the former snaps package is selected from PYPI instead of
the git commit id previously defined.And the sfc module can't be
imported due to the snaps api changes.
I'm adding snaps again in constraints to ensure only one version is
selected amongst all the OPNFV features.
bash-4.4# pythonPython 2.7.15 (default, Aug 16 2018, 14:17:09) [GCC
6.4.0] on linux2Type "help", "copyright", "credits" or "license" for
more information.>>> import sfc.tests.functest.run_sfc_testsTraceback
(most recent call last):  File "", line 1, in   File
"/usr/lib/python2.7/site-packages/sfc/tests/functest/run_sfc_tests.py", 
line 21, in from sfc.lib import cleanup as sfc_cleanup 
File "/usr/lib/python2.7/site-packages/sfc/lib/cleanup.py", line 4, in
import sfc.lib.openstack_utils as os_sfc_utils  File
"/usr/lib/python2.7/site-packages/sfc/lib/openstack_utils.py", line 13,
in from snaps.config.vm_inst import
FloatingIpConfigImportError: No module named config.vm_inst>>> 


Le jeudi 14 mars 2019 à 17:39 +0100, Cedric OLLIVIER via
Lists.Opnfv.Org a écrit :
> Manuel,
> 
> The testcase is enabled (see Loading test case 'functest-odl-sfc').
> Here it looks like a programming mistake as the sfc module can't be
> loaded. I'm checking your code.
> 
> 
> Cédric
> 
> Le jeudi 14 mars 2019 à 17:31 +0100, Manuel Buil a écrit :
> > Hi Cedric,
> > Now I can see SFC in master but I think something is wrong because
> > the module cannot be loaded:
> > https://hastebin.com/dipibupihu.bash
> > Is there anything else that I must activate?
> > Thanks,Manuel
> > 
> > 
> > On Thu, 2019-03-07 at 10:00 +0100, Manuel Buil wrote:
> > > Hello Cedric,
> > > 
> > > As you suggested, I started using the container "opnfv/functest-
> > > features:latest"; however, I don't see sfc project there. Is
> > > there anything wrong?  
> > > 
> > > Regards,
> > > Manuel
> > > 
> > > On Wed, 2019-03-06 at 19:00 +0100, Cedric OLLIVIER wrote:
> > > > SFC is now enabled in Functest master which could be the best
> > > > containers regarding your SUT (XCI).
> > > > https://gerrit.opnfv.org/gerrit/#/c/66811/
> > > > 
> > > > It had been disabled in Functest master when the SFC hunter
> > > > branch didn't exist (requirement synchronization). 
> > > > 
> > > > Cédric
> > > > 
> > > > Le mercredi 06 mars 2019 à 11:39 +0100, Manuel Buil a écrit :
> > > > > Thanks Cristina!
> > > > > 
> > > > > On Wed, 2019-03-06 at 09:10 +, Cristina Pauna wrote:
> > > > > > Hi Manuel,
> > > > > >  
> > > > > > When you start the Functest container, you need to pass
> > > > > > DEPLOY_SCENARIO variable, that needs to match the regex in
> > > > > > the
> > > > > >  testcases file [1] 
> > > > > > In your case, it needs to match odl.*sfc [2]
> > > > > >  
> > > > > > Thanks,
> > > > > > Cristina
> > > > > >  
> > > > > >  
> > > > > > [1]
> > > > > > 
> > > > > > https://github.com/opnfv/functest/blob/master/functest/ci/t
> > > > > > estcases.yaml
> > > > > > [2]
> > > > > > 
> > > > > > https://github.com/opnfv/functest/blob/master/functest/ci/t
> > > > > > estcases.yaml#L492
> > > > > >  
> > > > > > 
> > > > > > 
> > > > > > From: opnfv-tech-discuss@lists.opnfv.org [mailto:opnfv-tech
> > > > > > -disc...@lists.opnfv.org]
> > > > > > On Behalf Of Manuel Buil
> > > > > > 
> > > > > > Sent: Wednesday, March 6, 2019 10:54 AM
> > > > > > 
> > > > > > To: OPNFV-tech 
> > > > > > 
> > > > > > Subject: Re: [opnfv-tech-discuss] How to activate tests in
> > > > > > functest-features
> > > > > > 
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > > Hey,
> > > > > > 
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > > 
> > > > > > Nobody knows the answer? We are stuck in SFC...
> > > >

Re: [opnfv-tech-discuss] How to activate tests in functest-features

[Cedric OLLIVIER]

Manuel,
The testcase is enabled (see Loading test case 'functest-odl-sfc').Here 
it looks like a programming mistake as the sfc module can't be loaded.
I'm checking your code.
Cédric
Le jeudi 14 mars 2019 à 17:31 +0100, Manuel Buil a écrit :
> Hi Cedric,
> Now I can see SFC in master but I think something is wrong because
> the module cannot be loaded:
> https://hastebin.com/dipibupihu.bash
> Is there anything else that I must activate?
> Thanks,Manuel
> 
> 
> On Thu, 2019-03-07 at 10:00 +0100, Manuel Buil wrote:
> > Hello Cedric,
> > 
> > As you suggested, I started using the container "opnfv/functest-
> > features:latest"; however, I don't see sfc project there. Is there
> > anything wrong?  
> > 
> > Regards,
> > Manuel
> > 
> > On Wed, 2019-03-06 at 19:00 +0100, Cedric OLLIVIER wrote:
> > > SFC is now enabled in Functest master which could be the best
> > > containers regarding your SUT (XCI).
> > > https://gerrit.opnfv.org/gerrit/#/c/66811/
> > > 
> > > It had been disabled in Functest master when the SFC hunter
> > > branch didn't exist (requirement synchronization). 
> > > 
> > > Cédric
> > > 
> > > Le mercredi 06 mars 2019 à 11:39 +0100, Manuel Buil a écrit :
> > > > Thanks Cristina!
> > > > 
> > > > On Wed, 2019-03-06 at 09:10 +, Cristina Pauna wrote:
> > > > > Hi Manuel,
> > > > >  
> > > > > When you start the Functest container, you need to pass
> > > > > DEPLOY_SCENARIO variable, that needs to match the regex in
> > > > > the
> > > > >  testcases file [1] 
> > > > > In your case, it needs to match odl.*sfc [2]
> > > > >  
> > > > > Thanks,
> > > > > Cristina
> > > > >  
> > > > >  
> > > > > [1]
> > > > > 
> > > > > https://github.com/opnfv/functest/blob/master/functest/ci/testcases.yaml
> > > > > [2]
> > > > > 
> > > > > https://github.com/opnfv/functest/blob/master/functest/ci/testcases.yaml#L492
> > > > >  
> > > > > 
> > > > > 
> > > > > From: opnfv-tech-discuss@lists.opnfv.org [mailto:
> > > > > opnfv-tech-discuss@lists.opnfv.org]
> > > > > On Behalf Of Manuel Buil
> > > > > 
> > > > > Sent: Wednesday, March 6, 2019 10:54 AM
> > > > > 
> > > > > To: OPNFV-tech 
> > > > > 
> > > > > Subject: Re: [opnfv-tech-discuss] How to activate tests in
> > > > > functest-features
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > Hey,
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > Nobody knows the answer? We are stuck in SFC...
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > We have also checked 
> > > > > https://opnfv-functest.readthedocs.io/en/stable-gambia/testing/user/userguide/runfunctest.html
> > > > >  but we could not find anything
> > > > > either.
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > Any hint or pointer to docs would be great!
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > 
> > > > > Manuel
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > On Mon, 2019-03-04 at 15:31 +0100, Manuel Buil wrote:
> > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > > 
> > > > > > When I run 'run_tests -t functest-odl-sfc' inside the
> > > > > > functest-
> > > > > > 
> > > > > > 
> > > > > > features:gambia or hunter version, the tests are skipped. I
> > > > > > have been
> > > > > > 
> > > > > > 
> > > > > > reading the wiki but I could not find how to make functest
&g

Re: [opnfv-tech-discuss] How to activate tests in functest-features

[Cedric OLLIVIER]

SFC is now enabled in Functest master which could be the best
containers regarding your SUT (XCI).https://gerrit.opnfv.org/gerrit/#/c
/66811/
It had been disabled in Functest master when the SFC hunter branch
didn't exist (requirement synchronization). 
Cédric
Le mercredi 06 mars 2019 à 11:39 +0100, Manuel Buil a écrit :
> Thanks Cristina!
> 
> On Wed, 2019-03-06 at 09:10 +, Cristina Pauna wrote:
> > Hi Manuel,
> >  
> > When you start the Functest container, you need to pass
> > DEPLOY_SCENARIO variable, that needs to match the regex in the
> >  testcases file [1] 
> > In your case, it needs to match odl.*sfc [2]
> >  
> > Thanks,
> > Cristina
> >  
> >  
> > [1]
> > 
> > https://github.com/opnfv/functest/blob/master/functest/ci/testcases
> > .yaml
> > [2]
> > 
> > https://github.com/opnfv/functest/blob/master/functest/ci/testcases
> > .yaml#L492
> >  
> > 
> > 
> > From: opnfv-tech-discuss@lists.opnfv.org [mailto:opnfv-tech-discuss
> > @lists.opnfv.org]
> > On Behalf Of Manuel Buil
> > 
> > Sent: Wednesday, March 6, 2019 10:54 AM
> > 
> > To: OPNFV-tech 
> > 
> > Subject: Re: [opnfv-tech-discuss] How to activate tests in
> > functest-features
> > 
> > 
> >  
> > 
> > Hey,
> > 
> > 
> >  
> > 
> > 
> > Nobody knows the answer? We are stuck in SFC...
> > 
> > 
> >  
> > 
> > 
> > We have also checked 
> > https://opnfv-functest.readthedocs.io/en/stable-gambia/testing/user
> > /userguide/runfunctest.html but we could not find anything either.
> > 
> > 
> >  
> > 
> > 
> > Any hint or pointer to docs would be great!
> > 
> > 
> >  
> > 
> > 
> > Thanks,
> > 
> > 
> > Manuel
> > 
> > 
> >  
> > 
> > 
> > On Mon, 2019-03-04 at 15:31 +0100, Manuel Buil wrote:
> > 
> > > Hi,
> > > 
> > > 
> > >  
> > > 
> > > 
> > > When I run 'run_tests -t functest-odl-sfc' inside the functest-
> > > 
> > > 
> > > features:gambia or hunter version, the tests are skipped. I have
> > > been
> > > 
> > > 
> > > reading the wiki but I could not find how to make functest run
> > > the sfc
> > > 
> > > 
> > > tests:
> > > 
> > > 
> > >  
> > > 
> > > 
> > > https://wiki.opnfv.org/pages/viewpage.action?pageId=29098314
> > > 
> > > 
> > >  
> > > 
> > > 
> > > Any help or pointer to the correct doc will help!
> > > 
> > > 
> > >  
> > > 
> > > 
> > > Thanks,
> > > 
> > > 
> > > Manuel
> > > 
> > > 
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > > 
> > > 
> > > Links: You receive all messages sent to this group.
> > > 
> > > 
> > >  
> > > 
> > > 
> > > View/Reply Online (#22879): 
> > > https://lists.opnfv.org/g/opnfv-tech-discuss/message/22879
> > > 
> > > 
> > > Mute This Topic: 
> > > https://lists.opnfv.org/mt/30213915/675458
> > > 
> > > 
> > > Group Owner: 
> > > opnfv-tech-discuss+ow...@lists.opnfv.org
> > > 
> > > 
> > > Unsubscribe: 
> > > https://lists.opnfv.org/g/opnfv-tech-discuss/unsubb  [mbuil@suse.
> > > com]
> > > 
> > > 
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > > 
> > 
> > 
> > 
> > 
> > This message, including attachments, is CONFIDENTIAL. It may also
> > be privileged or otherwise protected by law. If you received
> > this email by mistake please let us know by reply and then delete
> > it from your system; you should not copy it or disclose its
> > contents
> >  to anyone. All messages sent to and from Enea may be monitored to
> > ensure compliance with internal policies and to protect our
> > business. Emails are not secure and cannot be guaranteed to be
> > error free as they can be intercepted, a mended, lost or destroyed,
> >  or contain viruses. The sender therefore does not accept liability
> > for any errors or omissions in the contents of this message, which
> > arise as a result of email transmission. Anyone who communicates
> > with us by email accepts these risks.
> > 
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > 
> > View/Reply Online (#22890): https://lists.opnfv.org/g/opnfv-tech-di
> > scuss/message/22890
> > Mute This Topic: https://lists.opnfv.org/mt/30213915/675458
> > Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> > Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [m
> > b...@suse.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#22891): https://lists.opnfv.org/g/opnfv-tech-disc
> uss/message/22891
> Mute This Topic: https://lists.opnfv.org/mt/30213915/1217365
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [oll
> ivier.ced...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22893): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22893
Mute This Topic: https://lists.opnfv.org/mt/30213915/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] Side effects after the last gerrit migration (13 February 2019)

[Cedric OLLIVIER]

Hello Aric,

Yes. Our gates are rolling this morning
https://build.opnfv.org/ci/view/functest/job/functest-latest-gate/72/

Thank you for your quick fix!

Have a nice weekend,
Cédric

Le vendredi 15 février 2019 à 16:08 -0500, Aric Gardner a écrit :
> Side effects after the last gerrit migration (13 February 2019)
> 
> Hi Cedric,
> 
> This was an oversight on our part, the replication was following the
> decommissioned server after the move.
> The fix is in and those links you sent are working now.
> 
> Regards,
> Aric
> 
> 
> On Fri, Feb 15, 2019 at 5:58 AM  wrote:
> > 
> > Hello,
> > 
> > It seems that we can't access to git refs anymore via cgit.
> > e.g.
> > https://git.opnfv.org/functest/tree/upper-constraints.txt?h=refs/ch
> > anges/35/67035/3
> > 
> > Or even by commit id:
> > https://git.opnfv.org/functest/commit/upper-constraints.txt?id=fa8c
> > 50f4fd19576a2fde5b04077810d4ca91b330
> > 
> > Is it my mistake, a side effect or is it on purpose?
> > It looks weird to force a git clone to access one single file such
> > as
> > upper-constraints (see OpenStack).
> > 
> > For your information, it's breaking all Functest functional
> > verifications.
> > 
> > Cédric
> > 
> > Le mercredi 30 janvier 2019 à 18:59 +, nore...@statuspage.io a
> > écrit :
> > > OPNFV
> > > Gerrit Migration and Service Upgrades
> > > Upcoming scheduled maintenance notice
> > > We will be migrating OPNFV's Gerrit from a VM running on hardware
> > > to
> > > AWS and at the same time we will be performing system maintenance
> > > across all systems which includes kernel updates, package
> > > updates,
> > > and system reboots. During this time individual services will be
> > > unavailable for up to 30 minutes.
> > > 
> > > The following systems are affected:
> > > - Gerrit (gerrit.opnfv.org)
> > > - Confluence (wiki.opnfv.org)
> > > - JIRA (jira.opnfv.org)
> > > - Etherpad (etherpad.opnfv.org)
> > > - Pharos Dashboard v1 (labs.opnfv.org)
> > > - Test Results Dashboard (testresults.opnfv.org)
> > > 
> > > As Gerrit will be moved behind a loadbalancer with a rotating
> > > pool of
> > > IPv4 addresses, we have create a separate domain
> > > (gerritssh.opnfv.org) with a single static IP for companies that
> > > restrict outgoing SSH access.
> > > 
> > > For users at companies that don't restrict outgoing SSH
> > > connections,
> > > you should not need to take any action to continue using Gerrit
> > > over
> > > SSH at the gerrit.opnfv.org address.
> > > 
> > > However if you do work at such a company, please inform your
> > > internal
> > > networking staff to allow outgoing connections on the following
> > > IPv4
> > > address and port:
> > > 
> > > IPv4: 34.213.23.63
> > > Port: 29418
> > > 
> > > Users at these companies will also need to update the git remote
> > > of
> > > their cloned repositories to use the correct connection:
> > > 
> > > git remote set-url --push gerrit
> > > ssh://@gerritssh.opnfv.org:29418/.git
> > > 
> > > As usual 30 minutes prior to maintenance Jenkins will be put in
> > > shutdown mode to ensure clones do not fail.
> > > 
> > > If you have any questions or concerns or feel we should
> > > reschedule,
> > > please reach out at helpd...@opnfv.org, or respond on the mailing
> > > list.
> > > Start time
> > > Feb 13, 15:00 UTC
> > > Estimated duration
> > > 2 hours
> > > Components affected
> > > Jenkins CI (build.opnfv.org) - build.opnfv.org - Asia
> > > Jenkins CI (build.opnfv.org) - build.opnfv.org - North Am...
> > > Jenkins CI (build.opnfv.org) - build.opnfv.org - Europe
> > > Jenkins CI (build.opnfv.org) - Jenkins Queue Health
> > > Etherpad (etherpad.opnfv.org) - etherpad.opnfv.org - Nort...
> > > ...and 13 more components.
> > > View full scheduled maintenance details
> > > You received this email because you are subscribed to OPNFV's
> > > service
> > > status notifications.
> > > 
> > > Unsubscribe
> > > Powered by Statuspage
> > > 
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > > Links: You receive all messages sent to this group.
> > > 
> > > View/Reply Online (#22754):
> > > https://lists.opnfv.org/g/opnfv-tech-discuss/message/22754
> > > 
> > > Mute This Topic:
> > > https://lists.opnfv.org/mt/29597785/1217365
> > > 
> > > Group Owner:
> > > opnfv-tech-discuss+ow...@lists.opnfv.org
> > > 
> > > Unsubscribe:
> > > https://lists.opnfv.org/g/opnfv-tech-discuss/unsub
> > >   [
> > > ollivier.ced...@gmail.com
> > > ]
> > > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22813): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22813
Mute This Topic: https://lists.opnfv.org/mt/29860970/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] Side effects after the last gerrit migration (13 February 2019)

[Cedric OLLIVIER]

Hello,

It seems that we can't access to git refs anymore via cgit.
e.g. 
https://git.opnfv.org/functest/tree/upper-constraints.txt?h=refs/changes/35/67035/3

Or even by commit id: 
https://git.opnfv.org/functest/commit/upper-constraints.txt?id=fa8c50f4fd19576a2fde5b04077810d4ca91b330

Is it my mistake, a side effect or is it on purpose?
It looks weird to force a git clone to access one single file such as
upper-constraints (see OpenStack).

For your information, it's breaking all Functest functional
verifications.

Cédric

Le mercredi 30 janvier 2019 à 18:59 +, nore...@statuspage.io a
écrit :
> OPNFV
> Gerrit Migration and Service Upgrades
> Upcoming scheduled maintenance notice
> We will be migrating OPNFV's Gerrit from a VM running on hardware to
> AWS and at the same time we will be performing system maintenance
> across all systems which includes kernel updates, package updates,
> and system reboots. During this time individual services will be
> unavailable for up to 30 minutes.
> 
> The following systems are affected:
> - Gerrit (gerrit.opnfv.org)
> - Confluence (wiki.opnfv.org)
> - JIRA (jira.opnfv.org)
> - Etherpad (etherpad.opnfv.org)
> - Pharos Dashboard v1 (labs.opnfv.org)
> - Test Results Dashboard (testresults.opnfv.org)
> 
> As Gerrit will be moved behind a loadbalancer with a rotating pool of
> IPv4 addresses, we have create a separate domain
> (gerritssh.opnfv.org) with a single static IP for companies that
> restrict outgoing SSH access.
> 
> For users at companies that don't restrict outgoing SSH connections,
> you should not need to take any action to continue using Gerrit over
> SSH at the gerrit.opnfv.org address.
> 
> However if you do work at such a company, please inform your internal
> networking staff to allow outgoing connections on the following IPv4
> address and port:
> 
> IPv4: 34.213.23.63
> Port: 29418
> 
> Users at these companies will also need to update the git remote of
> their cloned repositories to use the correct connection:
> 
> git remote set-url --push gerrit 
> ssh://@gerritssh.opnfv.org:29418/.git
> 
> As usual 30 minutes prior to maintenance Jenkins will be put in
> shutdown mode to ensure clones do not fail.
> 
> If you have any questions or concerns or feel we should reschedule,
> please reach out at helpd...@opnfv.org, or respond on the mailing
> list.
> Start time
> Feb 13, 15:00 UTC
> Estimated duration
> 2 hours
> Components affected
> Jenkins CI (build.opnfv.org) - build.opnfv.org - Asia
> Jenkins CI (build.opnfv.org) - build.opnfv.org - North Am...
> Jenkins CI (build.opnfv.org) - build.opnfv.org - Europe
> Jenkins CI (build.opnfv.org) - Jenkins Queue Health
> Etherpad (etherpad.opnfv.org) - etherpad.opnfv.org - Nort...
> ...and 13 more components.
> View full scheduled maintenance details 
> You received this email because you are subscribed to OPNFV's service
> status notifications.
> 
> Unsubscribe
> Powered by Statuspage
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#22754): 
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/22754
> 
> Mute This Topic: 
> https://lists.opnfv.org/mt/29597785/1217365
> 
> Group Owner: 
> opnfv-tech-discuss+ow...@lists.opnfv.org
> 
> Unsubscribe: 
> https://lists.opnfv.org/g/opnfv-tech-discuss/unsub
>   [
> ollivier.ced...@gmail.com
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22810): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22810
Mute This Topic: https://lists.opnfv.org/mt/29860970/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] Code and Release improvements

[Cedric OLLIVIER]

Hi Alec,
You're right.
It should be noted that we are excluding the oldest opensource projects
(Linux, GNU/Linux distributions, etc...) from that discussion.We are
just listing few LFN projects and OpenStack (and wrongly in case of ODL
which has been cited multiple times).
But it's simply related to the average opensource experience in OPNFV.
Cédric
Le mercredi 13 février 2019 à 02:07 +, Alec via Lists.Opnfv.Org a
écrit :
> Hi Manuel,
>  
> I don’t think it is valid to compare large open source projects that
> have a lots of contributors  with smaller ones that are just what
> they are, niche projects.
> 
> If you ask a contributor of these high visibility projects if they
> want to contribute to a small niche OPNFV project, I don’t think
> there will much interest and it will not be because of loose commit
> requirements.
>  
> In the past few years I’ve noticed pretty large resource shift from
> openstack related projetcs to orchestration (ONAP), edge cloud and
> containers/k8s, not because there is no more work to do in the
> traditional
>  openstack/NFVi space but because of vendors shift of strategy and
> priority.
> I don’t think having looser commit rules has any bearing in the
> defection of developers (even openstack has been losing a lot of
> developers and interest compared to a few years ago).
>  
> BR,
>  
>    Alec
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
> From:
> Manuel Buil 
> 
> Date: Tuesday, February 12, 2019 at 1:57 PM
> 
> To: "cedric.olliv...@orange.com" , "Alec
> Hothan (ahothan)" , Cristina Pauna  @enea.com>, "opnfv-tech-discuss@lists.opnfv.org"  lists.opnfv.org>
> 
> Subject: Re: [opnfv-tech-discuss] Code and Release improvements
> 
> 
>  
> 
> 
> Hello,
> 
> 
>  
> 
> 
> This is the last mail I got in this thread but perhaps it is not the
> last one. For unknown reasons, this thread is being flagged as SPAM
> and I am not sure if something got blocked in between (e.g. I never
> got Alec's
>  mail).
> 
> 
>  
> 
> 
> Ok, now I get your points, thanks Alec and Cedric. Unfortunately, I
> still think it is bad if this is not enforced (with temporary
> exceptions) because of what I said in my previous mail. I'd suggest
> to ask around
>  people working in other communities about this (kernel, openstack,
> CNCF...). Last week I was on a business trip and had the opportunity
> to ask open source people. Everyone I asked was surprised and I
> agreed with a couple of them who said that they would never
>  join a project that allows this. If a project does not attract
> developers, allowing to self-merge patches is not going to help,
> right the opposite. 
> 
> 
>  
> 
> 
> It seems to me, and correct me if I am wrong, that you guys are fine
> if OPNFV becomes a community for multiple projects with only one/two
> committers (as long as those are niche projects (@Alec: what about
> installers?
>  what about yardstick/functest/dovetail?) or projects with an ideally
> perfect CI). That is a vision I don't share and I thought OPNFV in
> general did not share but I can just talk for myself, let's hear some
> other opinions ;).
> 
> 
>  
> 
> 
> Regards,
> 
> 
> Manuel
> 
> 
>  
> 
> 
> On Mon, 2019-02-11 at 14:41 +, cedric.olliv...@orange.com wrote:
> 
> 
> 
> Hello,
>  
> 
> New development process enforcement for which developers?
> 
> 
> The proposal could maybe make sense in a very active community with
> lots of developers without any automated verification jobs.
> 
> 
> Both assumptions are false:
> 
> 
> ·
> as bitergia statistics (https://opnfv.biterg.io) have been showing
>  for several months, OPNFV is progressively becoming a community
> without developers.
> 
> 
> ·
> as a consequence we put in place lots of verification jobs which
> compensate the lack of reviews and which strongly improve the code
> quality.
> 
>  
> 
> 
> Some of them are being adopted by Yardstick (I voted +1).
> 
> 
> Imposing new process rules from the top will clearly discourage the
> remaining contributors and increase the risk of fork out of the
> community.
> 
> 
> It is at least an option I can clearly foresee for my project.
> 
> 
>  
> 
> 
> Is adding process enforcements the top priority topic of OPNFV?
> 
> 
> Regarding the previous statement, is it really the top priority of
> OPNFV TSC to debate on new development processes which constraints
> the
>  developers without any direct improvement regarding the project
> quality ?
> 
> 
> Is there no more critical decisions to take if we simply want to
> survive as a community?
> 
> 
> 
> As service provider I am still fully convinced of the interest of
> OPNFV.
> 
> 
> The creation of the LF Networking should be a catalyst to work with
> the other projects and disseminate the best practices that are
> already
>  in place and have been demonstrated by the code.
> 
> 
> It is already the case with the discussions on Xtesting with ONAP and
> Akraino. Docker production, Alpine adoption, CI/CD best practices
>  which have been initiated 

Re: [opnfv-tech-discuss] Code and Release improvements

[Cedric OLLIVIER]

Hello Manuel.
I fully second you about asking Linux team about their processes.The
Linux Kernel leverages on maintainers which is far from what we are
proposing.And you become arch/release maintainers thanks to your skills
(Meritocraty). https://www.kernel.org/doc/html/latest/process/2.Process
.html?highlight=merge%20window#how-patches-get-into-the-kernel
It's the opposite process of what we are defining here.And as far as I
know, Linux doesn't have any problem to attrack developpers, and the
best ones!
Cédric

Le mardi 12 février 2019 à 23:00 +0100, Manuel Buil a écrit :
> Hello,
> 
> This is the last mail I got in this thread but perhaps it is not the
> last one. For unknown reasons, this thread is being flagged as SPAM
> and I am not sure if something got blocked in between (e.g. I never
> got Alec's mail).
> 
> Ok, now I get your points, thanks Alec and Cedric. Unfortunately, I
> still think it is bad if this is not enforced (with temporary
> exceptions) because of what I said in my previous mail. I'd suggest
> to ask around people working in other communities about this (kernel,
> openstack, CNCF...). Last week I was on a business trip and had the
> opportunity to ask open source people. Everyone I asked was surprised
> and I agreed with a couple of them who said that they would never
> join a project that allows this. If a project does not attract
> developers, allowing to self-merge patches is not going to help,
> right the opposite. 
> 
> It seems to me, and correct me if I am wrong, that you guys are fine
> if OPNFV becomes a community for multiple projects with only one/two
> committers (as long as those are niche projects (@Alec: what about
> installers? what about yardstick/functest/dovetail?) or projects with
> an ideally perfect CI). That is a vision I don't share and I thought
> OPNFV in general did not share but I can just talk for myself, let's
> hear some other opinions ;).
> 
> Regards,
> Manuel
> 
> On Mon, 2019-02-11 at 14:41 +, cedric.olliv...@orange.com wrote:
> > Hello,
> >  
> > New development process enforcement for which developers?
> > The proposal could maybe make sense in a very active community with
> > lots of developers without any automated verification jobs.
> > Both assumptions are false:
> > 
> > as bitergia statistics (https://opnfv.biterg.io) have been showing
> > for several months, OPNFV is progressively becoming a community
> > without developers.
> > as a consequence we put in place lots of verification jobs which
> > compensate the lack of reviews and which strongly improve the code
> > quality.
> > 
> > 
> > 
> > Some of them are being adopted by Yardstick (I voted +1).
> > Imposing new process rules from the top will clearly discourage the
> > remaining contributors and increase the risk of fork out of the
> > community.
> > It is at least an option I can clearly foresee for my project.
> >  
> > Is adding process enforcements the top priority topic of OPNFV?
> > Regarding the previous statement, is it really the top priority of
> > OPNFV TSC to debate on new development processes which constraints
> > the developers without any direct improvement regarding the project
> > quality ?
> > Is there no more critical decisions to take if we simply want to
> > survive as a community?
> > 
> > As service provider I am still fully convinced of the interest of
> > OPNFV.
> > The creation of the LF Networking should be a catalyst to work with
> > the other projects and disseminate the best practices that are
> > already in place and have been demonstrated by the code.
> > It is already the case with the discussions on Xtesting with ONAP
> > and Akraino. Docker production, Alpine adoption, CI/CD best
> > practices which have been initiated in OPNFV.
> >  
> > We certainly agree not to enable it in Functest.
> > 
> > 
> > Cédric
> >  
> > 
> > 
> > De : opnfv-tech-discuss@lists.opnfv.org [opnfv-tech-discuss@lists.o
> > pnfv.org] de la part de Alec via Lists.Opnfv.Org [ahothan=cisco.com
> > @lists.opnfv.org]
> > 
> > Envoyé : samedi 9 février 2019 04:08
> > 
> > À : Manuel Buil; Cristina Pauna; opnfv-tech-discuss@lists.opnfv.org
> > 
> > Cc : opnfv-tech-discuss@lists.opnfv.org
> > 
> > Objet : Re: [opnfv-tech-discuss] Code and Release improvements
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > I do not disagree on the general benefits of having multiple
> > reviewers for every commit, no question about it. If you can afford
> > it – go for it.
> > However, I would like to point out that for most low-key or “niche”
> > projects with few committers, a rule to enforce dual review and
> > forbid self commit will quickly force any remaining participants to
> > exit opnfv
> >  and head out direct to gihtub ot bitbucket.
> >  
> > So I would vote to let the PTL decide on how to regulate the
> > commits of his/her project. I think OPNFV PTL have generally been
> > quite responsible in the past and I have not personally seen any of
> > the behavior
> >  listed below.
> > I 

Re: [opnfv-tech-discuss] Code and Release improvements

[cedric . ollivier]

Hello,



New development process enforcement for which developers?
The proposal could maybe make sense in a very active community with lots of 
developers without any automated verification jobs.
Both assumptions are false:

  *   as bitergia statistics (https://opnfv.biterg.io) have been showing for 
several months, OPNFV is progressively becoming a community without developers.
  *   as a consequence we put in place lots of verification jobs which 
compensate the lack of reviews and which strongly improve the code quality.

Some of them are being adopted by Yardstick (I voted +1).
Imposing new process rules from the top will clearly discourage the remaining 
contributors and increase the risk of fork out of the community.
It is at least an option I can clearly foresee for my project.

Is adding process enforcements the top priority topic of OPNFV?
Regarding the previous statement, is it really the top priority of OPNFV TSC to 
debate on new development processes which constraints the developers without 
any direct improvement regarding the project quality ?
Is there no more critical decisions to take if we simply want to survive as a 
community?
As service provider I am still fully convinced of the interest of OPNFV.
The creation of the LF Networking should be a catalyst to work with the other 
projects and disseminate the best practices that are already in place and have 
been demonstrated by the code.
It is already the case with the discussions on Xtesting with ONAP and Akraino. 
Docker production, Alpine adoption, CI/CD best practices which have been 
initiated in OPNFV.



We certainly agree not to enable it in Functest.

Cédric




De : opnfv-tech-discuss@lists.opnfv.org [opnfv-tech-discuss@lists.opnfv.org] de 
la part de Alec via Lists.Opnfv.Org [ahothan=cisco@lists.opnfv.org]
Envoyé : samedi 9 février 2019 04:08
À : Manuel Buil; Cristina Pauna; opnfv-tech-discuss@lists.opnfv.org
Cc : opnfv-tech-discuss@lists.opnfv.org
Objet : Re: [opnfv-tech-discuss] Code and Release improvements



I do not disagree on the general benefits of having multiple reviewers for 
every commit, no question about it. If you can afford it – go for it.
However, I would like to point out that for most low-key or “niche” projects 
with few committers, a rule to enforce dual review and forbid self commit will 
quickly force any remaining participants to exit opnfv and head out direct to 
gihtub ot bitbucket.

So I would vote to let the PTL decide on how to regulate the commits of his/her 
project. I think OPNFV PTL have generally been quite responsible in the past 
and I have not personally seen any of the behavior listed below.
I think many PTL are in the same situation, with projects that are not 
sufficiently attractive to afford the luxury of requesting multiple reviews. 
Most PTL would welcome any “reasonable” review but in  many cases, it just 
happens that the code that is being managed in not that easy to understand, not 
because it is spaghetti code, but because of the nature of the beast. In my 
case, people with good understanding of networking performance, traffic 
generation and TRex APIs are unfortunately very hard to come by. This is by no 
means and rarely the case that PTLs do not like multi-vendor participation or 
consider themselves as god 

I am PTL and I commit my own code and I am happy to add and encourage new 
committers and new reviewers (I do get some great “external” contributions only 
too occasionally).
OPNFV has many great PTL for low key projects, I think we should not make their 
life more difficult and trust them to do what is best for their project.
If OPNFV wants to attract more talents/contributors/projects I think adding 
more rules and process may not be the best approach.

Thanks

  Alec






From:  on behalf of Manuel Buil 

Date: Friday, February 8, 2019 at 12:48 PM
To: Cristina Pauna , 
"opnfv-tech-discuss@lists.opnfv.org" 
Subject: Re: [opnfv-tech-discuss] Code and Release improvements

Hi Cristina,

SFC has been doing this from the beginning and I think it is a great idea which 
should be enforced. There are of course exceptions which should be handled with 
a workaround, especially at the beginning, but as you say, they should be 
limited on time. When a person merges his own patches, there are some dangerous 
potential consequences which jeopardize the values of community driven 
development, for example:

1 - Single Point of Failure. That person is the only one that knows about some 
piece of the code. If that person stops working in the project, can other 
people continue the development?
2 - Coding hero/god mentality which is very bad for the health of the community 
and will frighten potential new committers or consumers of that project
3 - Quality of code becomes worse. Several eyes on the code is better than just 
two. Jenkins tests will give +1 to spaghetti code
4 - Knowledge sharing is stopped. By code reviews, developers share 

[opnfv-tech-discuss] Deploy easily your own OPNFV-based toolchain to verify OS, K8s, ONAP or anything else! #xtesting

[cedric . ollivier]

Hello,

New Xtesting and Functest Ansible playbooks were recently published to ease 
deploying your own testing toolchains (even on your laptop).
They conform with the OPNFV model except for the dependency to Google Storage 
(Minio is selected here).
For the time being, the next components are automatically installed and fully 
configured:

· Jenkins

· Minio

· S3www

· MongoDB

· TestAPI

They can be easily reused for any test leveraging on Xtesting even out of the 
infrastructure domain.
Be free to adapt site.yml to your needs (it requires more or less to list the 
containers and the testcases included).

· Xtesting https://git.opnfv.org/functest-xtesting/tree/ansible/site.yml

· Functest https://git.opnfv.org/functest/tree/ansible/site.yml

To deploy your toolchain on your laptop:
$ virtualenv xtesting
$ . xtesting/bin/activate
$ pip install ansible docker
$ ansible-galaxy install collivier.xtesting
$ git clone https://gerrit.opnfv.org/gerrit/functest-xtesting 
functest-xtesting-src
$ ansible-playbook functest-xtesting-src/ansible/site.yml
$ deactivate

We will integrate a new dashboard soon (testresults.opnfv.org is OPNFV centric).
Then we may add the CD part if it makes sense for the endusers.

All the procedure is described on the next wiki page
https://wiki.opnfv.org/pages/viewpage.action?pageId=32015004

Cédric

_

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.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22552): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22552
Mute This Topic: https://lists.opnfv.org/mt/28744242/21656
Mute #xtesting: https://lists.opnfv.org/mk?hashtag=xtesting=2783016
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [opnfv-tsc] Discussion of OPNFV Strategic Plan

[Cedric OLLIVIER]

Hello,
I would like to comment a little bit  the removal of "Operate a set of
servers/labs and services (git, gerrit, jenkins,..)".It may partially
work at OPNFV project level but I'm not convinced it's doable
everywhere in OPNFV.I would have thought it's up to OPNFV projects to
ease the reuse by giving configs for docker build, travis-ci,
readthedocs, jjbs, etc... as Functest has done.

Docker automated build allows building any monolithic container but we
may suffer from the current design if we publish sliced containers as
Functest does.By adding hooks [1], we could bypass that but the
notification system doesn't work in case of git tags in such a
case.Docker automated build only supports amd64 and then forbids
building arm64 containers
https://git.opnfv.org/functest/tree/docker/smoke/hooks/post_checkout 
Travis-ci gives us the flexibility to cross-compile containers to arm64
(or arm32 in case of Raspberry PI) but we will face with the overall
timeout due to the Qemu translations.I have also faced with lots of
network issues when building my third-parties containers for few
anticipation works (OpenStack master, etc...).But it's true that
travis-ci is improving and releng is not better regarding that part.I
don't see how we could deploy kubernetes or OpenStack quicker than the
default timeout as required by functional gates.
https://git.opnfv.org/functest/tree/.travis.yml
We do care about deploying/testing under nested virtualisation even if
it eases the development process.Then performance results won't be
relevant (-10%) and then OPNFV will drop the public fair test database
which is one of our key benefits.It's even more true for Kubernetes as
we would add a virtualisation layer lesser (from a performance point of
view) than containers.
In case of Functest, we already support lots of external tools and we
are offering a way to deploy the full CI/CD (from Jenkins to
dashboards) via docker-compose.
We are able to publish all artifacts out of OPNFV but we still depend
on hardware to ensure Functest is always stable.
Or we are forced to setup an external bot running on local resources
for fully verifying the changes (I haven't tested that out of gerrit).

Cédric 
Le vendredi 30 novembre 2018 à 11:44 +, Frank Brockners via
Lists.Opnfv.Org a écrit :
>  
> In the TSC meeting, Manuel voiced a pretty important ask that might
> help the discussion moving forward: "Cloud we create a table that
> compares OPNFV today with the proposed future", assuming that we'd
> evolve along
>  the path that Bin started to articulate. The table format is to make
> things more concrete and could help us in a second step to articulate
> where we’d want to focus on moving forward. This includes which
> additional work areas we’d like to inspire projects to
>  work on (or even new projects to be created for). I've tried to
> capture the current discussion and proposal into a table below (see
> also attached in case groups.io messes up the formatting and color) –
> feel free to add/evolve/change per your understanding
>  – the below is just my reading of Bin’s deck. 
>  
> Thoughts?
>  
> Thanks, Frank
>  
>  
> 
> 
> 
> 
> OPNFV today
> 
> 
> Potential Evolution (changes in
> blue)
> 
> 
> 
> 
> Design – Outline requirements; Design NFV components and solution
> stacks
> 
> 
> Design – Outline requirements; Design NFV components and solution
> stacks;
> Focus on cloud native and edge use cases.
> 
> 
> 
> 
> Create – Create new and/or enhance components (most often by working
> upstream) to meet the design/requirements
> 
> 
> Create – Create new and/or enhance components (most often by working
> upstream) to meet the design/requirements.
> 
> 
> 
> 
> 
> Compose – Follow the design and create a running system from a set of
> components
> 
> 
> 
> Compose – Follow the design and create a running system from a set of
> components
> 
> 
> 
> 
> 
> Deploy – Install and run the composed system on a set of labs
> worldwide. This includes enhancement and creation of specific test
> and deployment tools (installers, XCI,..).
> 
> 
> Deploy – Install and run the composed system on a set of labs
> worldwide. This includes enhancement and creation of specific test
> and deployment tools (installers, XCI,..).
> 
> 
> 
> 
> Test – Test the installation, i.e. running system that represents an
> NFV solution stack; as well as test specific aspects of a system.
> This includes creation and enhancement of specific
>  test and deployment tools. In addition, this includes tooling for
> verification (OVP/CVP).
> 
> 
> Test – Test the installation, i.e. running system that represents an
> NFV solution stack; as well as test specific aspects of a system.
> This includes creation and enhancement of specific
>  test and deployment tools. In addition, this includes tooling for
> verification (OVP/CVP).
> 
> Tool suite: Compose individual tools into a tool suite.
> 
> 
> 
> 
> Iterate/Automate – Create guidelines and tooling for automated
> 

[opnfv-tech-discuss] Run Functest containers on Raspberry PI

[cedric . ollivier]

Hello,

On behalf of OPNFV Functest team, I'm proud to announce that Functest
containers run on Raspberry PI. Then we can verify any OpenStack
deployment at the price of 50 euros (hardware and software included).

Be free to apply the procedures described in our wiki:
https://wiki.opnfv.org/display/functest/Run+Functest+containers+on+Rasperry+PI

>From the time being, only barbican and juju_epc are skipped due to
runtime issues and missing dependencies respectively.

It should be noted that the current System Under Test (all-in-one)
can't host our VNFs (pending). Any feedback is more that welcome.

All containers were built on top of OPNFV Functest master and then can
verify all OpenStack releases currently supported by OPNFV (Queens,
Rocky and master).

They are compatible with ARM v6 32 bits to support all Raspberry PI
models. Last Rasperry PI 3 have been used for the results printed in
the wiki page. But it should be noted that Healthcheck and Smoke
(partially) were successfully executed vs Rasperry PI B+.

More details and updates during our next plugfest
https://wiki.opnfv.org/display/EVNT/Plugfest+-+Gambia+Release

Cédric


_

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.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22487): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22487
Mute This Topic: https://lists.opnfv.org/mt/28570141/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [opnfv-tsc] Discussion of OPNFV Strategic Plan

[Cedric OLLIVIER]

Hello,

I don't know if the current issues are related to a missing strategy
but I think we are moving away from the project scope.

Why not emphazing here XCI which only supports virtual machine
deployment and the compliance program which mainly includes sparsed
functional tests. But our endusers are waiting for platforms able to
host VNFs and verified to do so (benchmarks, vnfs, etc..).

I second the referent platforms as long as they are fully verified by
the underlying OPNFV test frameworks.

And I vote yes to reduce the dev cycles by removing the dependencies
between our projects. I hope it won't result in a lack of testing as
we're seeing in one place. It's great to accelerate new disruptive
scenarios or ideas but it shouldn't have led to the lowest levels (see
OpenStack gates) even if it fits few developpers.

OPNFV differs from the upstream communities thanks to its Lab and its
DB fulfilled by test frameworks which is a fair public comparison
between installers, networking implementations and enhancements, etc...

Cédric

Le mardi 27 novembre 2018 à 19:18 +, HU, BIN a écrit :
> Georg,
> 
> Thank you for your questions and concerns.
> 
> One key role of TSC is to provide direction to the community, which
> is the other pillar that strengthens the community-driven approach.
> The direction from TSC will inspire the community and represent our
> community externally, and the "personal motivation" will ultimately
> decide where the resource will go.
> 
> One of the questions in the TSC discussion today is whether or not we
> have had strategy from TSC in the past. As far as I know, there
> wasn't. Correct me if I am wrong and show me where it is documented.
> So community needs a direction from TSC, which is more urgent for now
> than ever, because:
> - We don't have a strategy. Everything is driven by "personal
> motivation", which is good and bad. Sorry that I am quite frank and
> straightforward. If everything is driven by "personal motivation"
> without a direction, it eventually hurts the entire community. And it
> won't achieve your goal of strengthening platform and compliance
> program at all.
> - We are losing developers and other resources, and primarily reason
> is ROI. If we keep on doing today's way without a direction, no one
> will magically come back. We will lose more exponentially. A new
> vision and direction will bring a fresh look of OPNFV, and we will
> have the opportunity to bring new developers and investments that are
> interested in working on this direction.
> - The WG mechanism is a good way of how to organize the work in a
> tactic level. However, without the blessing of a strategy, vision and
> direction that can be articulated and marketed, it won't bring new
> developers. So tactics (slide #16) is the way of how to achieve the
> strategy (slide #13). However, under no circumstance can a tactic
> replace a strategy.
> - You brought a great example of XCI. It was bottom up, and has
> achieved great result. However, because there was no strategy, there
> were hiccups in terms of scenarios v.s. installers etc. Now we face
> the difficulties - evolve CI/CD in a more installer-centric way, or
> in a more CI/CD-compliant way. I don't intend to discuss those
> details of choice here. Those are tactical discussion, and many times
> we chose a shortcut for the sake of release instead of a right way
> for long term benefit. However, a strategy and direction will guide
> those choices when we face those difficulties.
> 
> So there is a reality urgency and need of having a direction for our
> community, not only for new things to bring in new developers, but
> also help solve the issues for many projects when they are facing the
> choices of where to go, what to do next, and whether a shortcut or
> for long term.
> 
> At last, no one disagrees with strengthening platform and compliance
> program, which has been captured on slide #13. Adding new direction
> will not only help bring in new developers but also help many
> existing projects to make the right choice. Eventually, "personal
> motivation" decides where resources will go, because no one can force
> anyone else to work on a specific project. So I don't see the concern
> of new direction will be competing with existing developers. For
> example, "personal motivation" may bring all developers to platform
> capabilities and compliance program, which is great.
> 
> Again, thank you for your question, but I do see the urgency of
> having a strategy asap, because of the reality needs as I stated
> above.
> 
> Best regards
> Bin
> 
> -Original Message-
> From: opnfv-...@lists.opnfv.org  On Behalf
> Of Georg Kunz
> Sent: Tuesday, November 27, 2018 9:46 AM
> To: HU, BIN ; Tim Irnich ;
> Trevor Bramwell 
> Cc: AshYoung ; opnfv-tech-discuss@lists.opnfv.org; 
> opnfv-...@lists.opnfv.org; Manuel Buil 
> Subject: Re: [opnfv-tsc] Discussion of OPNFV Strategic Plan
> 
> Hi Bin,
> Hi all,
> 
> Due to the lively discussions during 

Re: [opnfv-tech-discuss] Intent to Participate in the OPNFV Hunter Release #release #hunter

[Cedric OLLIVIER]

Hello,
The purpose of this mail is to notify the OPNFV TSC that Functest
project intends to participate in the OPNFV Hunter and Iruya
releases.We intend to follow both the traditional track and the
continuous delivery track.
It should be noted that:  - Functest Hunter was released   - Functest
Iruya will be released right after OpenStack Stein (2019-04-10
estimated)
Best Regards,Cédric Ollivier
Le lundi 29 octobre 2018 à 06:46 -0700, David McBride a écrit :
> Team,
> Today marks the opening of the intent-to-participate window for the
> Hunter release (i.e. MS0).  Please find the procedure here.  The
> window closes as of MS1, tentatively planned for Nov 23.
> 
> Please let me know which release track you intend to participate in
> by including one of the following statements in
> your intent to participate notification:
> We intend to follow the traditional track.
> We intend to follow the continuous delivery trackWe intend to follow
> both the traditional track and the continuous delivery track
> Also, please remember that if you are planning a new project for the
> Hunter release, you have until Nov 9 to submit your proposal to the
> TSC and still have time to be approved and to join the release before
> the intent-to-participate window closes.
> 
> Let me know if you have questions.  Thanks.
> 
> David
> 
> -- 
> David McBrideRelease Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#8): https://lists.opnfv.org/g/opnfv-tech-disc
> uss/message/8
> Mute This Topic: https://lists.opnfv.org/mt/27781534/1217365
> Mute #release: https://lists.opnfv.org/mk?hashtag=release=27834
> 63
> Mute #hunter: https://lists.opnfv.org/mk?hashtag=hunter=2783463
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [oll
> ivier.ced...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22278): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22278
Mute This Topic: https://lists.opnfv.org/mt/27781534/21656
Mute #release: https://lists.opnfv.org/mk?hashtag=release=2783016
Mute #hunter: https://lists.opnfv.org/mk?hashtag=hunter=2783016
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [opnfv-tsc] Issues with Gambia release #release #gambia

[Cedric OLLIVIER]

+1

We could improve the process here.
If I'm not wrong, it's not the first release delayed few days before the
first schedule.

Cédric

Le ven. 2 nov. 2018 à 09:25, Yang (Gabriel) Yu 
a écrit :

> +1
>
> -Original Message-
> From: opnfv-...@lists.opnfv.org [mailto:opnfv-...@lists.opnfv.org] On
> Behalf Of limingjiang
> Sent: Friday, November 02, 2018 3:34 PM
> To: Trevor Bramwell ; David McBride <
> dmcbr...@linuxfoundation.org>
> Cc: TSC OPNFV ; Bin Hu ; Aric
> Gardner ; Tim Rozet ;
> huangxiangyu ; Sofia Wallin <
> sofia.wal...@ericsson.com>; Cristina Pauna ;
> Alexandru Avadanii ; TECH-DISCUSS OPNFV <
> opnfv-tech-discuss@lists.opnfv.org>
> Subject: Re: [opnfv-tsc] Issues with Gambia release #release #gambia
>
> +1
>
> Best Regards,
> Rex Lee
>
>
> +---+
>
> + Mingjiang Li (Rex) Mobile: +86 13761275017 Shanghai Institute, Huawei
> + No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
>
> +---+
>
>
> -Original Message-
> From: opnfv-...@lists.opnfv.org [mailto:opnfv-...@lists.opnfv.org] On
> Behalf Of Trevor Bramwell
> Sent: Friday, November 02, 2018 3:11 PM
> To: David McBride 
> Cc: TSC OPNFV ; Bin Hu ; Aric
> Gardner ; Tim Rozet ;
> huangxiangyu ; Sofia Wallin <
> sofia.wal...@ericsson.com>; Cristina Pauna ;
> Alexandru Avadanii ; TECH-DISCUSS OPNFV <
> opnfv-tech-discuss@lists.opnfv.org>
> Subject: Re: [opnfv-tsc] Issues with Gambia release #release #gambia
>
> +1
>
> On Thu, Nov 01, 2018 at 11:49:48AM -0700, David McBride wrote:
> > I haven't received any comments or questions, so I'd like to go ahead
> > and start an email vote.
> >
> > TSC members, please respond to this email with +1, 0, or -1.
> >
> > Does the TSC approve of delaying the release of Gambia 7.0, including
> > milestones 8, 9, 10, and 11 by one week, as follows?
> >
> >- Nov 6 - MS8 - end of formal testing
> >- Nov 7 - MS9 - final documentation
> >- Nov 8 - MS10 - JIRA cleanup
> >- Nov 9 - MS11 - project tagging
> >
> > No other milestones for Gambia or Hunter are affected.
> >
> > David
> >
> > On Tue, Oct 30, 2018 at 3:09 PM David McBride
> > 
> > wrote:
> >
> > > Team,
> > >
> > > As I said during the TSC meeting today, I have some concerns about
> > > the status of the Gambia release and I am recommending that we delay
> > > the release 1 week to November 9.
> > >
> > > Before we vote on that recommendation, I'd like to explain my
> > > concerns and allow a day for feedback/discussion.
> > >
> > >- Apex deployments
> > >.
> > >Approximately 2/3 of recent deployments have failed.
> > >- Compass healthcheck
> > ><
> https://build.opnfv.org/ci/job/functest-compass-baremetal-daily-gambia/8/console
> >.
> > >Not running because the initial ping test is failing.
> > >- Scenario documentation.  Sofia reports that many scenarios are
> still
> > >lacking documentation.
> > >
> > > We discussed these issues during the release today.  There was no
> > > objection to the recommendation to delay the release 1 week.
> > >
> > > Please feel free to respond to this email with your comments and
> > > questions.  Let's have a brief email discussion, followed by a vote.
> > > Thanks.
> > >
> > > David
> > >
> > > --
> > > *David McBride*
> > > Release Manager, OPNFV
> > > Mobile: +1.805.276.8018
> > > Email/Google Talk: dmcbr...@linuxfoundation.org
> > > Skype: davidjmcbride1
> > > IRC: dmcbride
> > >
> >
> >
> > --
> > *David McBride*
> > Release Manager, OPNFV
> > Mobile: +1.805.276.8018
> > Email/Google Talk: dmcbr...@linuxfoundation.org
> > Skype: davidjmcbride1
> > IRC: dmcbride
>
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> >
> > View/Reply Online (#4779):
> > https://lists.opnfv.org/g/opnfv-tsc/message/4779
> > Mute This Topic: https://lists.opnfv.org/mt/27799555/557206
> > Group Owner: opnfv-tsc+ow...@lists.opnfv.org
> > Unsubscribe: https://lists.opnfv.org/g/opnfv-tsc/unsub
> > [tbramw...@linuxfoundation.org]
> > -=-=-=-=-=-=-=-=-=-=-=-
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#22269):
> https://lists.opnfv.org/g/opnfv-tech-discuss/message/22269
> Mute This Topic: https://lists.opnfv.org/mt/27825402/1217365
> Mute #release: https://lists.opnfv.org/mk?hashtag=release=2783463
> Mute #gambia: https://lists.opnfv.org/mk?hashtag=gambia=2783463
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [
> ollivier.ced...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22271): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22271
Mute This Topic: 

[opnfv-tech-discuss] Disable Functest Gambia (via Dovetail) in Installer master jobs

[Cedric OLLIVIER]

Hello,

Functest Gambia targets OpenStack Queens (or older thanks to backward
compatibility).
It mustn't be executed in any installer master jobs (even more in case
of Apex which is already deploying OpenStack master or Rocky).
It shouldn't work by design as it has been already widely explained.
https://build.opnfv.org/ci/job/dovetail-apex-baremetal-default-optional
-master/64/consoleFull 

We should conform with OpenStack and Functest rules.
Dovetail should select Functest latest to verify OpenStack master and
Functest hunter to verify Rocky as defined in Functest jobs.

It would save time to all installers and test frameworks to avoid falsy
runs as it was already discussed during the previous release.

Cédric
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22257): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22257
Mute This Topic: https://lists.opnfv.org/mt/27816776/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [functest][dovetail] The issue of project user random password

[Cedric OLLIVIER]

Hello,
Yes, we can easily take that rule into account.If I'm not wrong, the
issue is just about adding 1 upper-case char here.
It should work already if you rename all testcases in testcases.yaml.

The only issue is more or less about the Functest version
selected.Dovetail is far away from Functest and (if I'm not wrong) I
haven't seen any OPNFV Installer Fraser run for a while.
Thank you for the report,Cédric
Le mercredi 31 octobre 2018 à 13:58 +0800, louie long a écrit :
>  Hi，dovetail and functest，
> 
>  In our 2018 SDN+NFV+IPv6 Plugfest test we did some tests using
> dovetail and functest，
> and we had an issue when functest creating project users. For
> security reasons，some vendor
> set a strong password check(such as: at lest 1 upper case, 1 lower
> case, 1 digit) when creating project users，
> functest use uuid to set a random password[1], for this case the test
> tool will run failed at the beginning.
>   For this situation，could we set the project password configurable
> in functest. 
> 
> 
> [1]https://github.com/opnfv/functest/blob/master/functest/core/tenant
> network.py#L57
> 
> 
> 
> BRs,
> Louie
> 
> 
> 
> 
> 
> 
> --
> Louie Long E-mail: yl...@biigroup.cn
> 
>  Mobile: +86 13261979365
> 
> 
> 
> Fax: 86-10-5867-8466
> Postcode：10
> 
> 
> Add: 2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, China
> 
> 
> 
> Website: www.biigroup.com  www.cfiec.net
> 
> 
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#22245): https://lists.opnfv.org/g/opnfv-tech-disc
> uss/message/22245
> Mute This Topic: https://lists.opnfv.org/mt/27802556/1217365
> Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
> Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  [oll
> ivier.ced...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22246): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22246
Mute This Topic: https://lists.opnfv.org/mt/27802556/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] Functest Gambia and Hunter are available

[cedric . ollivier]

Hello,

Functest team proudly announces the first publications of Functest Gambia [1] 
and Hunter [2].
As OpenStack Rocky was released [3], Functest branches have to be created 
earlier (regarding the traditional track).
That's the best way to manage all 3 OpenStack releases which have been asked by 
OPNFV for the last months:
  - latest (Apex master)
  - hunter (Apex Rocky and XCI)
  - gambia (Compass, Fuel and Daisy)

It should be noted that we are following the same model for Kubernetes.

Functest is now synchronized to the OpenStack schedules which have been 
possible thanks to a huge work done by Functest team and thanks to early 
successful runs vs OpenStack master via Apex.
All versions have been verified in Orange Openlab as well.  

Here are several key benefits (more details are available here [4]):
  - the enduser can easily build its own toolchains by loading our Jenkins jobs
  - all developers can easily verify their changes before merge
  - our testcases may be run vs VIM in production
  - all testcases can run in parallel to decrease the overall duration
  - Functest includes most of the OpenStack gate jobs

All installers are currently running Functest master which should be only 
selected when verifying OpenStack master (Apex).
Compass, Fuel and Daisy should now select Functest Gambia instead (even if it 
may work thanks to backward compatibility).
If XCI now conforms with Functest (?), it should be verified by Functest 
Hunter.  
https://wiki.opnfv.org/pages/viewpage.action?pageId=29098314

All OPNFV features testcases are temporarily disabled in Functest Hunter and 
Functest master as they are currently following the traditional track.
As soon as SFC (or any other OPNV Features) team creates the required branches, 
the testcases will be enabled in all possible branches.
Functest Gambia will be continuously built to integrate changes required by 
Features.

Cédric
Functest PTL

[1] 
https://functest.readthedocs.io/projects/releasenotes/en/stable-gambia/functest-release.html
[2] 
https://functest.readthedocs.io/projects/releasenotes/en/stable-hunter/functest-release.html
[3] https://www.openstack.org/software/rocky/
[4] 
https://functest.readthedocs.io/projects/releasenotes/en/stable-gambia/functest-release.html#key-changes


_

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.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#22033): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22033
Mute This Topic: https://lists.opnfv.org/mt/25721234/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] RE: Identity v2 in OVP 2018.08

[cedric . ollivier]

Hello Georg,

Functest simply reads the input env vars which would suit very well your next 
v3->v2 proxy.

Cédric

De : Georg Kunz [mailto:georg.k...@ericsson.com]
Envoyé : mardi 11 septembre 2018 00:46
À : Cedric OLLIVIER
Cc : Yuyang (Gabriel); OLLIVIER Cédric IMT/OLN; Rex Lee; xudan (N); Raineri, 
Eddy; Lincoln Lavoie; Rautakumpu, Mika (Nokia - FI/Espoo); 
fuq...@chinamobile.com; SerenaFeng(zte); Cooper, Trevor; Dimitrios Tsiolakis; 
Katsaounis Molyvas Stamatios; RICHOMME Morgan IMT/OLN; Motamary, Shabrinath via 
opnfv-tech-discuss
Objet : RE: [opnfv-tech-discuss] RE: Identity v2 in OVP 2018.08

Hi Cedric,

Thanks for the links. However, the issue is that Functest makes v3 calls to the 
system under test and I don’t think that Dovetail can and should proxy the API 
calls made by Functest.

Anyhow, I’ll try to squeeze in a brief update to the TSC in tomorrow’s TSC 
meeting agenda. As the TSC is responsible for the scope of OVP and this is a 
larger deviation from the scope that was approved some time ago, I’d just like 
to get a corresponding approval for OVP from the TSC.

Cheers
Georg

From: Cedric OLLIVIER 
Sent: Saturday, September 8, 2018 2:19 AM
To: Georg Kunz 
Cc: Yuyang (Gabriel) ; OLLIVIER Cédric IMT/OLN 
; Rex Lee ; xudan (N) 
; Raineri, Eddy ; Lincoln 
Lavoie ; Rautakumpu, Mika (Nokia - FI/Espoo) 
; fuq...@chinamobile.com; SerenaFeng(zte) 
; Cooper, Trevor ; 
Dimitrios Tsiolakis ; Katsaounis Molyvas Stamatios 
; RICHOMME Morgan IMT/OLN 
; Motamary, Shabrinath via opnfv-tech-discuss 

Subject: Re: [opnfv-tech-discuss] RE: Identity v2 in OVP 2018.08

I think there is one packaged in sdesbure/identity_wrapper. I don't know if the 
code can be shared.
https://hub.docker.com/r/sdesbure/identity_wrapper/tags/

It should not be so difficult for Dovetail to implement it if you need to 
support v2 due to your backport rules.
https://github.com/openstack/keystone-specs/blob/master/attic/v3/identity-api-v3-v2-comparison.rst

Cédric

Le ven. 7 sept. 2018 à 11:27, Georg Kunz 
mailto:georg.k...@ericsson.com>> a écrit :
Hi Cedric,

I am not aware of a Keystone v2/v3 proxy. Can you point me to some 
documentation?

Thanks
Georg

From: ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com> 
mailto:ollivier.ced...@gmail.com>>
Sent: Thursday, September 6, 2018 7:11 PM
To: Georg Kunz mailto:georg.k...@ericsson.com>>; 
Yuyang (Gabriel) mailto:gabriel.yuy...@huawei.com>>; 
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; Limingjiang 
(Rex) mailto:limingji...@huawei.com>>
Cc: xudan (N) mailto:xuda...@huawei.com>>; Raineri, Eddy 
mailto:eddy.rain...@windriver.com>>; Lincoln Lavoie 
mailto:lylav...@iol.unh.edu>>; Rautakumpu, Mika (Nokia - 
FI/Espoo) mailto:mika.rautaku...@nokia.com>>; 
fuq...@chinamobile.com<mailto:fuq...@chinamobile.com>; SerenaFeng(zte) 
mailto:serena.feng.711%2b...@gmail.com>>; 
trevor.cooper mailto:trevor.coo...@intel.com>>; 
Dimitrios Tsiolakis 
mailto:d...@intracom-telecom.com>>; Katsaounis 
Molyvas Stamatios 
mailto:mok...@intracom-telecom.com>>; RICHOMME 
Morgan IMT/OLN mailto:morgan.richo...@orange.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] RE: Identity v2 in OVP 2018.08

Georg,

You could meet your backward compatibility requirements by adding a Keystone 
v2/v3 proxy.
It will be the best (and not so difficult) approach if Dovetail selects Fraser 
containers.

Or Dovetail may pick the right OPNFV releases according to SUT.

Cédric

On jeu., 2018-09-06 at 12:56 +, Georg Kunz wrote:
Hi all,

Thank you all for your quick feedback. I have added the mailing list, which I 
forgot on my previous email.

In the context of a compliance program, we need to strive for a good balance 
between

i)keeping the bar up in terms of requirements on new 
features and

ii)   backwards compatibility to older versions of OpenStack 
which are typically part of commercial systems.

In order to get some guidance in this regard, we can take a look at the 
OpenStack Powered programs for example. Every guideline (release spec) is 
supposed to be backwards compatible with 4 releases of OpenStack. So, the 
2017.09 guideline [1], which matches Fraser, covers OpenStack releases back to 
Mitaka [2]. During Mikata, identity v2 was still a valid API choice, to my 
understanding.

The exact number of backwards compatible releases in OVP is debatable, but I 
believe the need for backwards compatibility is apparent.

As a consequence, this naturally imposes additional burden on the test projects 
– not even talking about CI resources (which is already now a huge problem for 
Dovetail) and gating against older releases. It is not my or Dovetail’s 
position to impose such requirements on test projects – which already lift the 
bulk load of work anyway. So, I wanted to come to a community 

Re: [opnfv-tech-discuss] RE: Identity v2 in OVP 2018.08

[Cedric OLLIVIER]

I think there is one packaged in sdesbure/identity_wrapper. I don't know if
the code can be shared.
https://hub.docker.com/r/sdesbure/identity_wrapper/tags/

It should not be so difficult for Dovetail to implement it if you need to
support v2 due to your backport rules.
https://github.com/openstack/keystone-specs/blob/master/attic/v3/identity-api-v3-v2-comparison.rst

Cédric

Le ven. 7 sept. 2018 à 11:27, Georg Kunz  a écrit :

> Hi Cedric,
>
>
>
> I am not aware of a Keystone v2/v3 proxy. Can you point me to some
> documentation?
>
>
>
> Thanks
>
> Georg
>
>
>
> *From:* ollivier.ced...@gmail.com 
> *Sent:* Thursday, September 6, 2018 7:11 PM
> *To:* Georg Kunz ; Yuyang (Gabriel) <
> gabriel.yuy...@huawei.com>; cedric.olliv...@orange.com; Limingjiang (Rex)
> 
> *Cc:* xudan (N) ; Raineri, Eddy <
> eddy.rain...@windriver.com>; Lincoln Lavoie ;
> Rautakumpu, Mika (Nokia - FI/Espoo) ;
> fuq...@chinamobile.com; SerenaFeng(zte) ;
> trevor.cooper ; Dimitrios Tsiolakis <
> d...@intracom-telecom.com>; Katsaounis Molyvas Stamatios <
> mok...@intracom-telecom.com>; RICHOMME Morgan IMT/OLN <
> morgan.richo...@orange.com>; opnfv-tech-discuss@lists.opnfv.org
> *Subject:* Re: [opnfv-tech-discuss] RE: Identity v2 in OVP 2018.08
>
>
>
> Georg,
>
>
>
> You could meet your backward compatibility requirements by adding a
> Keystone v2/v3 proxy.
>
> It will be the best (and not so difficult) approach if Dovetail selects
> Fraser containers.
>
>
>
> Or Dovetail may pick the right OPNFV releases according to SUT.
>
>
>
> Cédric
>
>
>
> On jeu., 2018-09-06 at 12:56 +, Georg Kunz wrote:
>
> Hi all,
>
>
>
> Thank you all for your quick feedback. I have added the mailing list,
> which I forgot on my previous email.
>
>
>
> In the context of a compliance program, we need to strive for a good
> balance between
>
> i)keeping the bar up in terms of requirements on new
> features and
>
> ii)   backwards compatibility to older versions of
> OpenStack which are typically part of commercial systems.
>
>
>
> In order to get some guidance in this regard, we can take a look at the
> OpenStack Powered programs for example. Every guideline (release spec) is
> supposed to be backwards compatible with 4 releases of OpenStack. So, the
> 2017.09 guideline [1], which matches Fraser, covers OpenStack releases back
> to Mitaka [2]. During Mikata, identity v2 was still a valid API choice, to
> my understanding.
>
>
>
> The exact number of backwards compatible releases in OVP is debatable, but
> I believe the need for backwards compatibility is apparent.
>
>
>
> As a consequence, this naturally imposes additional burden on the test
> projects – not even talking about CI resources (which is already now a
> *huge* problem for Dovetail) and gating against older releases. It is not
> my or Dovetail’s position to impose such requirements on test projects –
> which already lift the bulk load of work anyway. So, I wanted to come to a
> community agreement and – if needed – a TSC discussion and decision on this.
>
>
>
> Further feedback and input is welcome.
>
>
>
> [1] https://git.openstack.org/cgit/openstack/interop/tree/2017.09.json
>
> [2] https://git.openstack.org/cgit/openstack/interop/tree/2017.09.json#n10
>
>
>
> Best regards
>
> Georg
>
>
>
> *From:* Yuyang (Gabriel) 
> *Sent:* Thursday, September 6, 2018 2:25 PM
> *To:* cedric.olliv...@orange.com; Limingjiang (Rex) <
> limingji...@huawei.com>; Georg Kunz 
> *Cc:* xudan (N) ; Raineri, Eddy <
> eddy.rain...@windriver.com>; Lincoln Lavoie ;
> Rautakumpu, Mika (Nokia - FI/Espoo) ;
> fuq...@chinamobile.com; SerenaFeng(zte) ;
> trevor.cooper ; Dimitrios Tsiolakis <
> d...@intracom-telecom.com>; Katsaounis Molyvas Stamatios <
> mok...@intracom-telecom.com>; RICHOMME Morgan IMT/OLN <
> morgan.richo...@orange.com>
> *Subject:* RE: Identity v2 in OVP 2018.08
>
>
>
> Hi Georg,
>
>
>
> The stress_ping test in Bottlenecks call yardstick to executing tests. For
> the Bottlenecks part, both v2 and v3 are supported.
>
> I am not sure about Yardstick. The stress-ping test has been run on any v2
> openstack quite a while.
>
> I will try to find a v2 openstack and do some test to find out.
>
>
>
> Best,
>
> Gabriel
>
>
>
> *From:* cedric.olliv...@orange.com [mailto:cedric.olliv...@orange.com
> ]
> *Sent:* Thursday, September 06, 2018 7:42 PM
> *To:* Limingjiang (Rex) ; Georg Kunz <
> georg.k...@ericsson.com>
> *Cc:* xudan (N) ; Raineri, Eddy <
> eddy.rain...@windriver.com>; Lincoln Lavoie ;
> Rautakumpu, Mika (Nokia - FI/Espoo) ;
> fuq...@chinamobile.com; SerenaFeng(zte) ;
> trevor.cooper ; Dimitrios Tsiolakis <
> d...@intracom-telecom.com>; Katsaounis Molyvas Stamatios <
> mok...@intracom-telecom.com>; Yuyang (Gabriel) ;
> RICHOMME Morgan IMT/OLN 
> *Subject:* RE: Identity v2 in OVP 2018.08
>
>
>
> Hello,
>
>
>
> The support has been fully removed in Queens (Gambia) and was highly
> deprecated in Pike (since many releases).
>
>
>
> A compliance program should be also conformed 

Re: [opnfv-tech-discuss] RE: Identity v2 in OVP 2018.08

[Cedric OLLIVIER]

Georg,
You could meet your backward compatibility requirements by adding a
Keystone v2/v3 proxy.It will be the best (and not so difficult)
approach if Dovetail selects Fraser containers.
Or Dovetail may pick the right OPNFV releases according to SUT.
Cédric
On jeu., 2018-09-06 at 12:56 +, Georg Kunz wrote:
> Hi all,
>  
> Thank you all for your quick feedback. I have added the mailing list,
> which I forgot on my previous email.
> 
>  
> In the context of a compliance program, we need to strive for a good
> balance between
> 
> 
> i)   
> keeping the bar up in terms of requirements on new features and
> 
> 
> ii)  
> backwards compatibility to older versions of OpenStack which are
> typically part of commercial systems.
> 
>  
> In order to get some guidance in this regard, we can take a look at
> the OpenStack Powered programs for example. Every guideline (release
> spec) is supposed to be backwards compatible with 4 releases of
> OpenStack. So, the 2017.09 guideline
>  [1], which matches Fraser, covers OpenStack releases back to Mitaka
> [2]. During Mikata, identity v2 was still a valid API choice, to my
> understanding.
>  
> The exact number of backwards compatible releases in OVP is
> debatable, but I believe the need for backwards compatibility is
> apparent.
>  
> As a consequence, this naturally imposes additional burden on the
> test projects – not even talking about CI resources (which is already
> now a
> huge problem for Dovetail) and gating against older releases. It is
> not my or Dovetail’s position to impose such requirements on test
> projects – which already lift the bulk load of work anyway. So, I
> wanted to come to a community agreement and – if needed
>  – a TSC discussion and decision on this.
>  
> Further feedback and input is welcome.
>  
> [1] 
> https://git.openstack.org/cgit/openstack/interop/tree/2017.09.json
> [2] 
> https://git.openstack.org/cgit/openstack/interop/tree/2017.09.json#n10
>  
> Best regards
> Georg
>  
> 
> 
> From: Yuyang (Gabriel)  
> 
> Sent: Thursday, September 6, 2018 2:25 PM
> 
> To: cedric.olliv...@orange.com; Limingjiang (Rex) <
> limingji...@huawei.com>; Georg Kunz 
> 
> Cc: xudan (N) ; Raineri, Eddy <
> eddy.rain...@windriver.com>; Lincoln Lavoie ;
> Rautakumpu, Mika (Nokia - FI/Espoo) ; 
> fuq...@chinamobile.com; SerenaFeng(zte) <
> serena.feng.711+...@gmail.com>;
>  trevor.cooper ; Dimitrios Tsiolakis <
> d...@intracom-telecom.com>; Katsaounis Molyvas Stamatios <
> mok...@intracom-telecom.com>; RICHOMME Morgan IMT/OLN <
> morgan.richo...@orange.com>
> 
> Subject: RE: Identity v2 in OVP 2018.08
> 
> 
>  
> Hi Georg,
>  
> The stress_ping test in Bottlenecks call yardstick to executing
> tests. For the Bottlenecks part, both v2 and v3 are supported.
> I am not sure about Yardstick. The stress-ping test has been run on
> any v2 openstack quite a while.
> I will try to find a v2 openstack and do some test to find out.
>  
> Best,
> Gabriel
>  
> 
> 
> From:
> cedric.olliv...@orange.com [mailto:cedric.olliv...@orange.com]
> 
> 
> Sent: Thursday, September 06, 2018 7:42 PM
> 
> To: Limingjiang (Rex) ; Georg Kunz <
> georg.k...@ericsson.com>
> 
> Cc: xudan (N) ; Raineri, Eddy <
> eddy.rain...@windriver.com>; Lincoln Lavoie ;
> Rautakumpu,
>  Mika (Nokia - FI/Espoo) ;
> fuq...@chinamobile.com; SerenaFeng(zte) <
> serena.feng.711+...@gmail.com>; trevor.cooper <
> trevor.coo...@intel.com>; Dimitrios
>  Tsiolakis ; Katsaounis Molyvas Stamatios
> ; Yuyang (Gabriel) <
> gabriel.yuy...@huawei.com>;
>  RICHOMME Morgan IMT/OLN 
> 
> Subject: RE: Identity v2 in OVP 2018.08
> 
> 
>  
> Hello,
>  
> The support has been fully removed in Queens (Gambia) and was highly
> deprecated in Pike (since many releases).
>  
> A compliance program should be also conformed with OpenStack.
> But it’s true that there is already a strong exception in Dovetail
> refuted by OpenStack from a while about nova micro-api versions.
>  
> I’m afraid that you may select opnfv/functest:danube in case of
> Keystone v2.
>  
> Cédric
>  
> 
> 
> De : Limingjiang (Rex)
>  [mailto:limingji...@huawei.com] 
> 
> Envoyé : jeudi 6 septembre 2018 13:19
> 
> À : Georg Kunz
> 
> Cc : xudan (N); Raineri, Eddy; Lincoln Lavoie; Rautakumpu, Mika
> (Nokia - FI/Espoo);
> fuq...@chinamobile.com; SerenaFeng(zte); trevor.cooper; Dimitrios
> Tsiolakis; Katsaounis Molyvas Stamatios; OLLIVIER Cédric IMT/OLN;
> Yuyang (Gabriel)
> 
> Objet : RE: Identity v2 in OVP 2018.08
> 
> 
>  
> Hi Georg,
>  
> I think it works for Openstack Pike. But I suppose it will be
> deprecated anyway in the later release of Openstack. [1]
>  
> [1] 
> 
https://docs.openstack.org/releasenotes/keystone/pike.html#deprecation-notes
>  
> 
> Best Regards,
> Rex Lee
>  
> +--
> -+
> 
> +
> Mingjiang Li (Rex) Mobile: +86 13761275017
> + Shanghai Institute, Huawei
> + No. , Xinjinqiao Road, Pudong, Shanghai, 201206, 

Re: [opnfv-tech-discuss] Reduce concurrency to 1 for refstack_defcore tests in Fraser

[Cedric OLLIVIER]

Hello,
Nothing has been proved by reducing the number of threads
here.OpenStack sets it to 4 because they know the number of cores
available in their VMsIn the context of OPNFV we could have increased
this value.
Refstack runs in parallel the previous release as well.It would be
better to go into a deeper analysis in that case and then to check
other installers as well.
Could you please provide us an env to debug?
Cédric

On mer., 2018-09-05 at 16:11 +0300, mardim wrote:
> Hello all,
>  
> As you remember we decided to reduce the concurrency in fraser to 4
> for the refstack_defcore tests [3]. 
>  
> This approach really helped in running all 200 tests [0] (for the
> first time) in apex for os-nosdn-nofeature-ha scenario. On the other
> side the odl-bgpvpn scenario still has the same problem as before but
> here we should point out that the tests which have been executed are
> more than the previous runs. Also we should not forget that the
> scenarios that include odl are more fragile and get overwhelmed
> easier than the nosdn scenarios.
>  
> So I would like to propose to reduce the concurrency to 1 (serial
> execution) and see if this will solve the problem ones and for all.
> What do you think?
>  
> [0]: 
> https://artifacts.opnfv.org/logs/functest/lf-pod1/fraser/2018-09-05_00-36-03/refstack_defcore/tempest-report.html
>  
> [1] 
> https://artifacts.opnfv.org/logs/functest/lf-pod1/fraser/2018-09-04_13-01-19/refstack_defcore/tempest-report.html
>  
> [2] 
> http://artifacts.opnfv.org/logs/functest/lf-pod1/fraser/2018-08-22_01-13-29/refstack_defcore/tempest-report.html
>  
> [3] https://gerrit.opnfv.org/gerrit/#/c/61671/ 
>  
> Regards,
>  
> Dimitrios Markou
> Software Engineer
> SDN/NFV Team
> __
> Intracom Telecom
> 19.7 km Markopoulou Ave., Peania, GR 19002
> t:   +30 2106677408
> f:   +30 2106671887
> mar...@intracom-telecom.com
> www.intracom-telecom.com
>  
>  
>JOIN USMobile World Congress 
> 26 Feb-01 Mar
> Barcelona, Spain
>  Mobile World Congress Shanghai
> 27-29 June
> Shanghai, China
>  Mobile World Congress Americas
> 12-14 September
> Los Angeles, USA
>  Gitex Technology Week
> 14-18 October
> Dubai, UAE
>  FutureCom
> 15-18 October
> Sao Paolo, Brazil
>  AfricaCom
> 13-15 November
> Cape Town, S. Africa
>   
>  
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21959): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21959
Mute This Topic: https://lists.opnfv.org/mt/25210134/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tsc] [opnfv-tech-discuss] [announce][election] Opening nominations for OPNFV Technical Steering Committee (TSC)

[Cedric OLLIVIER]

Thank you, Morgan,I accept the nomination.
Cédric
On ven., 2018-08-31 at 09:02 +, Morgan Richomme wrote:
> 
> 
> Hi
> 
> 
> 
>  
> 
> 
> 
> I would like to nominate Cedric Ollivier for the TSC.
> 
> 
> 
> He has been involved in OPNFV for a long time now and is the Functest
> PTL since Euphrates.
> 
> 
> 
> He is a recognized technical leader (several dev awards, rank #1 for
> contributions https://opnfv.biterg.io) within and beyond OPNFV.
> 
> 
> 
>  
> 
> 
> 
> In fact he introduced several key concepts in OPNFV testing
> community:
> 
> 
> 
> - xtesting allowing the integration of several new upstream projects
> (shaker, vmtp, vEPC, ..)
> 
> 
> 
> - alpine dockers / test slicing
> 
> 
> 
> - clean management of the upstream dependencies (functest is ready
> now for Gambia and Hunter and can even be run on Openstack master)
> 
> 
> 
> - functional gating
> 
> 
> 
> - parallelization of the tests within CI
> 
> 
> 
>  
> 
> 
> 
> From a functional testing perspective, he greatly contributed to
> align OPNFV testing quality level to Openstack, which is one of the
> top Open Source references.
> 
> 
> 
>  
> 
> 
> 
> He is also committer in Openstack, ODL, ONAP and has rich free
> software background.
> 
> 
> 
>  
> 
> 
> 
> As a member of the TSC, he would help to strengthen the technical
> views and affirm the technical leading role of this commitee.
> 
> 
> 
>  
> 
> 
> 
> Regards
> 
> 
> 
>  
> 
> 
> 
> Morgan
> 
> 
> > 
> > 
> > From: opnfv-tech-discuss@lists.opnfv.org <
> > opnfv-tech-discuss@lists.opnfv.org>
> > On Behalf Of David McBride
> > 
> > Sent: Friday, August 24, 2018 10:48 AM
> > 
> > To: TSC OPNFV; TECH-DISCUSS OPNFV
> > 
> > Cc: tim.irn...@ericsson.com; Heather Kirksey
> > 
> > Subject: [opnfv-tech-discuss] [announce][election] Opening
> > nominations for OPNFV Technical Steering Committee (TSC)
> > 
> > 
> >  
> > 
> > Team, 
> > 
> >  
> > 
> > 
> > Today, we begin nominations for a new TSC, consisting of 15
> > members, in accordance with the
> > 
> > Community Election Procedures.  Individuals who are eligible to
> > both vote and run for a TSC position are those with 20 or more
> > contributions on this
> > 
> > list of active contributors.  Before nominating someone, please
> > consult the list and verify that the individual has 20 or more
> > contributions.  You may find a schedule of election activities
> > 
> > here.
> > 
> > 
> >  
> > 
> > 
> > PTL Input to the Active Contributor List
> > 
> > 
> > Note that the election procedures have a provision for adding and
> > individual to the active contributor list, who has less than 20
> > contributions, yet who has make significant contributions to the
> > OPNFV community.  Per the election procedure:
> > 
> > 
> >  
> > 
> > > PTLs have an input on the "active contributor list" compiled over
> > > a 2-week review period (with a view that this step primarily
> > >  targets at making sure qualified people that haven't been
> > > identified via the metric get added to the list)
> > 
> > I am working with the TSC to define a specific process for this
> > situation.  In the mean time, if you are a PTL, and you would like
> > to add someone to the active contributor list, please contact me
> > directly with the name and a brief statement
> >  about why they should be included on the list.  Note that this
> > action simply adds them to the active contributor list, they still
> > must be nominated, separately.  Also, note that the 2-week review
> > period for the active contributor list, cited in the election
> >  procedure, ends on Aug 31.   
> > 
> >  
> > 
> > 
> > Nomination procedure
> > 
> > 
> > 
> > 
> > You may nominate yourself, or someone else.   
> > 
> > 
> > 
> > Remember that both you and the person nominated must be on the 
> > active contributor list with 20 or more contributions.
> > If you nominate someone else, I will confirm with that person that
> > they accept the nomination.
> > 
> > 
> > 
> > Announce the nomination with a "reply all" to this email prior to 5
> > p.m. (PT), Sept 7.  
> > Please include the following information: 
> &

Re: [opnfv-tech-discuss] Continuously Releasing Test Projects

[Cedric OLLIVIER]

Hello Alec.

No it's clear and I agree with you.

I would simply add that there is no real requirements management in OPNFV
which has been a key issue in the current release model.
https://wiki.opnfv.org/display/functest/Requirements+management

Only Functest and few Features are synchronized with OpenStack.
But even in that case, Functest container builds pull the last OPNFV master
commit id instead of a real Package.
In OpenStack master gating, only the services (Neutron, Nova, etc.) are
selecting by id.

Cédric

2018-08-08 21:25 GMT+02:00 Alec via Lists.Opnfv.Org <
ahothan=cisco@lists.opnfv.org>:

> Thanks for starting this discussion Trevor.
>
>
>
> There are several purposes of test projects in OPNFV (with some test
> projects serving multiple purposes)
>
>- Gate an OPNFV releases (meaning they are used to validate OPNFV
>releases of installers and features), example: Functest
>- Test an external/commercial NFVi distribution – e.g. Dovetail for
>OVP (which itself relies on Functest for example) or NFVbench for external
>distributions
>- Test an OPNFV release but no gating – e.g. Bottleneck
>- Test and measure an NFVi component – e.g. VSPERF for vswitches
>
>
>
> The TSC has decided recently that it would be good for OPNFV test projects
> to be reused in the industry independently of OPNFV releases, to test
> external NFVi systems and be used by non OPNFV audience.
>
> This has already started to happen for a few test components. Functest or
> NFVbench for example are already being used by vendors or SP (deployers) to
> validate their openstack solution – completely independently of the OPNFV
> release and of OVP.
>
>
>
> The common point about all test projects today is that they all follow the
> OPNFV release model and cadence – regardless of whether they gate the OPNFV
> release or not.
>
> There are certainly some benefits in doing so (such as standardizing on
> the documentation format, release cadence, release management…) but I think
> this becomes very cumbersome for projects that start to have more users
> outside of OPNFV releases:
>
>- Follow milestones for no real reason (since the project is not even
>gating any OPNFV release)
>- Not able to create releases outside of the OPNFV release cadence
>- Create unnecessary branches and labels
>
>
>
> Furthermore, this model also:
>
>- Adds a lot of burden for the OPNFV release team because they have to
>track the milestones for a lot of projects, even for those that do not gate
>OPNFV releases!
>- Discourages new projects to be hosted in OPNFV due to the high
>overhead imposed on every project
>
>
>
> I think that is not sustainable.
>
> What I would suggest is to get back to basics and use a model that is
> proven and widely used by most open source projects:
>
>- Let every project version independently based on the project’s own
>roadmap/feature/bug fixing cadence – we can suggest to use semver 2.0
>- Gating for the project should be controlled by the project owners
>using its own CD pipeline
>- If  project contributes to a release (OPNFV release or any other non
>OPNFV project release), it is up to the release manager and project PTL to
>agree to pick the proper project version
>- Project documentation can keep the same integration with OPNFV doc
>or go its own path (for example publish to a separate per-project space in
>opnfv doc web site)
>
>
>
> Examples of application of this model:
>
>
>
> VSPERF (test components of NFVi – does not gate any OPNFV release):
>
>- Could have its own semver version to track changes in the vsperf
>code (eg bug fixing in the Trex traffic generator driver)
>- Can have its own branches (if desired)
>- Has and controls its own gating process (e.g run and pass a set of
>tests on pod12)
>- Benchmark results can be versioned after the VSPERF version (e.g
>benchmark for OVS-DPDK version X tested with VSPERF version 2.0.3)
>- Can be used by external users with a well known version that is
>independent of an OPNFV release version
>- Could publish its doc to  separate space under the OPNFV doc web
>site (indexed by the VSPERF own version)
>
>
>
> STORPERF/BOTTLENECK…(test full stack - mostly control plane):
>
>- Could have its own semver version to track changes
>- Can have its own branches (if desired)
>- Can be used by external users with a well known version that is
>independent of an OPNFV release version
>- Controls its own gating by for example running STORPERF on a set of
>well known openstack distros (e.g APEX Fraser noha-nosdn) using the new CD
>pipeline
>- Can publish its own public stable versions at its own pace
>- Can publish its own artifacts at its own pace (e.g. containers under
>dockerhub/opnfv/storperf/)
>
>
>
> FUNCTEST (tests full stack and gates multiple projects):
>
>- Same as above
>- Each Functest 

Re: [opnfv-tech-discuss] Continuously Releasing Test Projects

[Cedric OLLIVIER]

Hello Gabriel,

Functest was split into a test framework and (OpenStack and Kubernetes)
test cases before Fraser.
Xtesting (aka the framework) is already continuously delivered and reused
by other opensource projects.
https://pypi.org/project/xtesting/
https://xtesting.readthedocs.io/en/latest/

Yes Xtesting is already verified via tox (py27, py35, etc..).
http://testresults.opnfv.org/functest/gates/

Cédric

2018-08-08 13:14 GMT+02:00 Yang (Gabriel) Yu :

> Hi Trevor,
>
>
>
> It's great that we can continue discussing CD releases for testing
> projects.
>
> In my mind, there are mainly two kinds of deliverables for a specific
> testing project: 1) test framework; 2) test cases.
>
> As to the continuous delivery of testing project, I tent to include both
> of the deliverables.
>
>
>
> Validation of a test framework consists of validations of the abilities to
> do unit test (and maybe style check), to adapt to different community
> installers/scenarios, to be compatible to at least 2 OPNFV releases, etc.
>
> Validation of test cases requires validating its integrity, successfully
> running on latest releases, clear and concrete testing scopes/purpose, etc.
>
>
>
> So, I guess we could have 2 delivery gates for the testing project: 1)
> test framework ready; 2) test cases ready.
>
> Just some preliminary thoughts, please comments.
>
>
>
> As a side notes, Yardstick and Bottlenecks are working on transforming
> themselves into services on cloud native CD pipeline in Clover project.
>
> Maybe we could discuss more towards that direction.
>
>
>
>
>
> Best,
>
> Gabriel
>
>
>
>
>
> -Original Message-
> From: opnfv-tech-discuss@lists.opnfv.org [mailto:opnfv-tech-discuss@
> lists.opnfv.org] On Behalf Of Trevor Bramwell
> Sent: Wednesday, August 08, 2018 7:13 AM
> To: opnfv-tech-discuss@lists.opnfv.org
> Subject: [opnfv-tech-discuss] Continuously Releasing Test Projects
>
>
>
> Hi all,
>
>
>
> Today me and Mark Beirel started a discussion during the release call[1]
> that I wanted to continue here regarding what the process could look like
> for releasing testing projects or testing tools in a continuous manner.
> (NFVBench, StorPerf, Yardstick, Functest, Bottlenecks, Dovetail,
>
> etc)
>
>
>
> This could also be seen as a continuation of the discussion we started at
> the Plugfest in France regarding gating in the CD process[2], but aimed
> specifically at the testing tools.
>
>
>
> The question I'm hoping we can collectively come to answer is:
>
>
>
>   What does a continuous release process look like for OPNFV test tools?
>
>
>
> As I don't work on a testing project myself, obviously I'm not the best
> one to answer this question, so instead of imposing my views on a process,
> I'd rather hear the thoughts from our community.
>
>
>
> I think by laying out some of the issues projects have with the current
> release process, and listing what a successful release process might look
> like to you will definitely help move this discussion in the right
> direction.
>
>
>
> Regards,
>
> Trevor Bramwell
>
>
>
> [1] http://meetbot.opnfv.org/meetings/opnfv-release/2018/
> opnfv-release.2018-08-07-14.01.log.html
>
> [2] https://etherpad.opnfv.org/p/minum_test_sets_gating_cd
>
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21746): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21746
Mute This Topic: https://lists.opnfv.org/mt/24225095/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] Continuously Releasing Test Projects

[Cedric OLLIVIER]

Hello Trevor,

I think the key issues have been already deeply explained many times for
more than 6 months.
The testing frameworks cannot be verified independently for many reasons:
  - no hardware resources
  - no referent platform (at least one OPNFV Queens installer is closed to
be fully verified)
  - no workflow process for test frameworks
  - etc...

Then OPNFV links by design all test frameworks to the Installer plannings
and then forbid to offer our releases.
And then we are forced to follow all models by checking our code in the
middle of deployment issues.

Only a part of Functest can be fully verified by unit tests.
Then we already apply the best delivery Technics for that package
(Xtesting) out of the classical OPNFV release milestones: pypi,
readthedocs, etc.

I don't understand why this topic is looping when prerequisites are clear
and unmet.
We do succeed by using virtual deployments (vnf?) and external CI/CD (we
require another Jenkins to host Functest Jenkins Jobs)..
>From the time being, Pharos and Releng are still installer-centric.

Cédric


2018-08-08 1:12 GMT+02:00 Trevor Bramwell :

> Hi all,
>
> Today me and Mark Beirel started a discussion during the release call[1]
> that I wanted to continue here regarding what the process could look
> like for releasing testing projects or testing tools in a continuous
> manner. (NFVBench, StorPerf, Yardstick, Functest, Bottlenecks, Dovetail,
> etc)
>
> This could also be seen as a continuation of the discussion we started
> at the Plugfest in France regarding gating in the CD process[2], but
> aimed specifically at the testing tools.
>
> The question I'm hoping we can collectively come to answer is:
>
>   What does a continuous release process look like for OPNFV test tools?
>
> As I don't work on a testing project myself, obviously I'm not the best
> one to answer this question, so instead of imposing my views on a
> process, I'd rather hear the thoughts from our community.
>
> I think by laying out some of the issues projects have with the current
> release process, and listing what a successful release process might
> look like to you will definitely help move this discussion in the right
> direction.
>
> Regards,
> Trevor Bramwell
>
> [1] http://meetbot.opnfv.org/meetings/opnfv-release/2018/
> opnfv-release.2018-08-07-14.01.log.html
> [2] https://etherpad.opnfv.org/p/minum_test_sets_gating_cd
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21745): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21745
Mute This Topic: https://lists.opnfv.org/mt/24225095/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [Functest] vping failed

[Cedric OLLIVIER]

I'm running multiple containers (3 containers * 3 branches) in // to find
the best timeouts.
I will give you the overall results after few days/weeks.
>From the time being, let's set 180 as you propose (I may have reached one
timeout).

It seems that Functest supports parallel testing very well. We just need to
update Vmtp.
http://testresults.opnfv.org/functest/gambiachallenges/

Then @Trevor, it would be great to work on
https://gerrit.opnfv.org/gerrit/#/c/57899/ as we proposed before the
previous release.
But it requires to increase the number of executors first.
All Functest actions have already been done (remove the iptable rules in
alpine.sh, redesign our testcases, etc...).

The key point is to reduce the job duration even in addition of
functest-components.
It would be very useful for Functional gating as well.

Thank you for your feedbacks,
Cédric


2018-07-31 10:40 GMT+02:00 xudan (N) :

> Hi Cedric,
>
>
>
> I don’t really have any results which failed because of the timeout. I am
> just curious about the timeout Functest set. Because as I know, the default
> timeout of Tempest is 300 and 180 for shade. So a little worried about the
> 60 Functest set.
>
>
>
> Yes. The default wait is False for shade, but Functest has already set it
> to be True when calling create_server(). So the wait_for_server() seems to
> be duplicate.
>
>
>
> For more information about the vping test case on VLAN environment, I have
> attached them in the JIRA ticket [1].
>
> And as I mentioned in the comments, I have a simple discussion with the
> shade team about this question [2]. Hope this can help you.
>
>
>
> [1] https://jira.opnfv.org/browse/FUNCTEST-996
>
> [2] http://lists.openstack.org/pipermail/openstack-infra/
> 2018-June/005983.html
>
>
>
> *From:* opnfv-tech-discuss@lists.opnfv.org [mailto:opnfv-tech-discuss@
> lists.opnfv.org] *On Behalf Of *Cedric OLLIVIER
> *Sent:* Monday, July 30, 2018 8:22 PM
> *To:* xudan (N) 
> *Cc:* opnfv-tech-discuss@lists.opnfv.org; Georg Kunz <
> georg.k...@ericsson.com>; louie long 
> *Subject:* Re: [opnfv-tech-discuss] [Functest] vping failed
>
>
>
> Hello Xudan,
>
>
>
> 60s is just in case of Cirros. That duration is very big regarding the one
> required: vping testcases ends before that minute.
>
> In case of Cloudify, the image is much more bigger which increases the
> duration when caching images.
>
>
>
> Why not setting 180 but all installers are passing all Cirros-based
> testcases.
>
> But be free to send us any log showing that the timeout has to be
> increased. It has to be guided by experiment.
>
>
>
> Our target is simply to select the right timeout according to the image we
> have selected (shade selects an arbitrary value).
>
> We should detect if the duration is abnormally long instead of setting the
> biggest timeouts.
>
> At the end of the day, the end users will face with that issues.
>
>
>
> As far as I know, wait arg is set to False by default in create_server().
>
> Then we do wait via wait_for_server() or setting wait=True (both are
> equal).
>
>
>
> Yes we would like to support vlan (even if few ids are supported) but
> badly it's out of OPNFV gates.
>
> To check your results, we need all logs and config files (please send me
> them by email).
>
> I don't know if you correctly modify
>
> · network_type
>
> · physical_network
>
> · segmentation_id
>
> We can implement a fallback mechanism based on the port created if Shade team 
> doesn't update its code.
>
> But following our leitmotiv "upstream first", we should work on shade instead 
> of Functest here.
>
>
>
> Cédric
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2018-07-30 10:33 GMT+02:00 xudan :
>
> Hi Functest team,
>
>
>
> I found there is a patch [1] aims at increasing timeout when creating
> servers.
>
> It sets the timeout of creating servers to be 60 while the default value
> of shade is 180s. Does 60 a little short? I suggest to keep it as the shade
> default value.
>
> Another question is what the function ‘wait_for_server’ [2] for? It
> already waits during the function ‘create_server’.
>
>
>
> The Functest vping test cases failed on my local environment. I guess it’s
> because of that my environment is VLAN and shade failed to get the server’s
> private ip in this case.
>
> I have created a JIRA ticket. Can someone help to check it?
>
>
>
> @louie I remembered that you have met a similar problem several days
> before. Could you help to confirm if the error is the same as yours and can
> it work well on your environment now?
>

Re: [opnfv-tech-discuss] [Functest] vping failed

[Cedric OLLIVIER]

Hello Xudan,

60s is just in case of Cirros. That duration is very big regarding the one
required: vping testcases ends before that minute.
In case of Cloudify, the image is much more bigger which increases the
duration when caching images.

Why not setting 180 but all installers are passing all Cirros-based
testcases.
But be free to send us any log showing that the timeout has to be
increased. It has to be guided by experiment.

Our target is simply to select the right timeout according to the image we
have selected (shade selects an arbitrary value).
We should detect if the duration is abnormally long instead of setting the
biggest timeouts.
At the end of the day, the end users will face with that issues.

As far as I know, wait arg is set to False by default in create_server().
Then we do wait via wait_for_server() or setting wait=True (both are equal).

Yes we would like to support vlan (even if few ids are supported) but badly
it's out of OPNFV gates.
To check your results, we need all logs and config files (please send me
them by email).
I don't know if you correctly modify


   - network_type
   - physical_network
   - segmentation_id

We can implement a fallback mechanism based on the port created if
Shade team doesn't update its code.
But following our leitmotiv "upstream first", we should work on shade
instead of Functest here.

Cédric








2018-07-30 10:33 GMT+02:00 xudan :

> Hi Functest team,
>
>
>
> I found there is a patch [1] aims at increasing timeout when creating
> servers.
>
> It sets the timeout of creating servers to be 60 while the default value
> of shade is 180s. Does 60 a little short? I suggest to keep it as the shade
> default value.
>
> Another question is what the function ‘wait_for_server’ [2] for? It
> already waits during the function ‘create_server’.
>
>
>
> The Functest vping test cases failed on my local environment. I guess it’s
> because of that my environment is VLAN and shade failed to get the server’s
> private ip in this case.
>
> I have created a JIRA ticket. Can someone help to check it?
>
>
>
> @louie I remembered that you have met a similar problem several days
> before. Could you help to confirm if the error is the same as yours and can
> it work well on your environment now?
>
>
>
> [1] https://gerrit.opnfv.org/gerrit/#/c/60243/
>
> [2] https://github.com/opnfv/functest/blob/stable/fraser/
> functest/core/singlevm.py#L184
>
> [3] https://jira.opnfv.org/browse/FUNCTEST-996
>
>
>
> Thanks,
>
> Xudan
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21643): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21643
Mute This Topic: https://lists.opnfv.org/mt/23858006/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] Dovetail testcase naming

[Cedric OLLIVIER]

Hello,

Could you please clarify why there are two different rules applied about
Dovetail testcase names?
Most of the testcases coming from OPNFV Test Frameworks are renamed
Dovetail without the real OPNFV project supporting them (even if they are
ran asis).

If I'm not wrong, the only exception is SDNVPN.
This exception seems even more strange because the testcases test the
BGPVPN [1] API even if ODL is selected as backend.

I don't understand why the same rule is not applied for the other OPNFV
projects especially when their testcases are executed without any change.
Supporting juju_epc and all VNFS are much more difficult than mainly
copy/paste our docs and add few yml files [2]
We would appreciate any little help from Dovetail about the VNF dev/support.

Cédric

[1] https://docs.openstack.org/networking-bgpvpn/latest/
[2] https://gerrit.opnfv.org/gerrit/#/c/57095/
[3] https://gerrit.opnfv.org/gerrit/#/c/59675/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21640): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21640
Mute This Topic: https://lists.opnfv.org/mt/23844846/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [Functest]VNF Cloudify_ims doesn't enable hugepage

[cedric . ollivier]

Hello Louie,

Our vnfs run only for os-nosdn-nofeature-* scenarios (amd64) in OPNFV gates.
It makes sense to activate vnfs in that scenarios too.
Thank you for the feedback.

We are rewriting all our vnfs to allow hugepages.
(And it’s also required to support vmdk images, provider networks, etc…).

For the time being, only the cloudify part (orchestrator) is ready.
All testcases except vnfs should work in your case.

We will inform you as soon as soon as it’s updated.
Please let’s know if it has to be backported In Fraser.

Cédric

De : opnfv-tech-discuss@lists.opnfv.org 
[mailto:opnfv-tech-discuss@lists.opnfv.org] De la part de louie long
Envoyé : jeudi 12 juillet 2018 10:56
À : opnfv-tech-discuss
Objet : [opnfv-tech-discuss] [Functest]VNF Cloudify_ims doesn't enable hugepage


 Hi,Functest,

 I have tested Functest cloudify_ims in fuel os-nosdn-ovs-ha(with DPDK) ，
it was failed due to vm flavor doesn't enable hugepage and I find cloudify vm 
flavor doesn't set hugepage[1].

Meanwhile，after cloudify_ims run failed functest haven't successfully clean the 
request resource.

2018-07-12 05:57:09,606 - xtesting.ci.run_tests - INFO - Test result:
+--+--+--++
|  TEST CASE   | PROJECT  | DURATION | RESULT |
+--+--+--++
| cloudify_ims | functest |  00:39   |  FAIL  |
+--+--+--++
2018-07-12 05:57:09,609 - functest.opnfv_tests.vnf.ims.cloudify_ims - ERROR - 
Some issue during the undeployment ..
Traceback (most recent call last):
  File 
"/usr/lib/python2.7/site-packages/functest/opnfv_tests/vnf/ims/cloudify_ims.py",
 line 418, in clean
cfy_client = self.orchestrator['object']
KeyError: 'object'
2018-07-12 05:57:09,609 - functest.core.vnf - INFO - Removing the VNF resources 
..
2018-07-12 05:57:22,513 - functest.core.vnf - ERROR - Unexpected error cleaning 
- Unable to complete operation on subnet aa406b70-8226-4a6c-84e6-c2d1b0ef43fc: 
One or more ports have an IP allocation from this subnet.
Neutron server returns request_ids: ['req-ef65d5f5-6a7f-4716-9188-b1e988ab61ae']
2018-07-12 05:57:22,513 - functest.core.vnf - ERROR - Unexpected error cleaning 
- Unable to complete operation on subnet aa406b70-8226-4a6c-84e6-c2d1b0ef43fc: 
One or more ports have an IP allocation from this subnet.
Neutron server returns request_ids: ['req-ef65d5f5-6a7f-4716-9188-b1e988ab61ae']
2018-07-12 05:57:22,622 - functest.core.vnf - ERROR - Unexpected error cleaning 
- 403 Forbidden
You are not permitted to delete this image.
(HTTP 403)

[1]https://github.com/opnfv/functest/blob/master/functest/opnfv_tests/vnf/ims/cloudify_ims.py#L131-L140

BRs,
Louie






--
Louie Long
 E-mail: yl...@biigroup.cn
 Mobile: +86 13261979365
Fax: 86-10-5867-8466
Postcode：10
Add: 2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, China
Website: www.biigroup.com  
www.cfiec.net
HTTPS   
详细X
基本翻译
abbr. 超文本传输协议安全（Hyper Text Transfer Protocol）
网络释义
HTTPS: 
HTTP Secure
HTTPS 
tracker:
 支援
android 
https:
 通信安全


_

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.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21556): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21556
Mute This Topic: https://lists.opnfv.org/mt/23263700/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] x86 POD for Auto Project

[Cedric OLLIVIER]

Hello Trevor,

I don't see the point about development.
As already explained during Release meetings and Weekly Technical
meetings (+mail Tue, 19 Jun 2018), Functest team wants to introduce
Functional Gating which is mandatory for our development.

We do stop linking the test frameworks gating and the installers one
(see the Releng model). It's also the first step towards a possible
rolling release 

We are fine to share it with other test projects as long as we don't
get false results (Workflow).

This topic is even more crucial at the beginning of the release because
of the Installer updates and then the lack of results even if MS3.1 is
reached.

Cédric

On lun., 2018-07-02 at 14:13 -0700, Trevor Bramwell wrote:
> Hi Alec,
> 
> Thanks for clarifying the use of POD 19. From what I know, most of
> the
> PODs at Intel are being used for development work.
> 
> Regards,
> Trevor Bramwell
> 
> On Mon, Jul 02, 2018 at 03:59:26PM +, Alec Hothan (ahothan)
> wrote:
> > please do not divert pod19, it is planned to be used for testing
> > projects. We can certainly share it with Auto when not in use.
> > The main requirement for pod19 is that we can rely on having a
> > stable bare metal installer/openstack on it so we can regress on
> > test projects – i.e. pod19 should not be used for testing
> > installers or for running installer CI jobs. I’m not sure what
> > “Auto CI” means exactly, if that relies on a stable openstack
> > running, it might work (assuming it does not trash openstack after
> > each run).
> > 
> > Have you looked at other Intel pods? I only know of 2 that are used
> > (12 and 19) and it seems there are more than 2 pods…
> > 
> > Thanks
> > 
> >   Alec
> > 
> > 
> > 
> > From:  on behalf of Trevor
> > Bramwell 
> > Date: Monday, July 2, 2018 at 8:40 AM
> > To: 
> > Cc: , ,  > oo...@intel.com>, 
> > Subject: [opnfv-tech-discuss] x86 POD for Auto Project
> > 
> > Hi Intel and Huawei Lab Owners,
> > 
> > The Auto project is looking for an x86 POD for running CI jobs on
> > and
> > I'm reaching out to see if you have any available resources they
> > could
> > use.
> > 
> > I see Intel POD 19 may be available (now that plugtest is over),
> > and
> > Huawei POD 6 says it's IDLE. Could either of these or any other
> > PODs be
> > made available for Auto's CI jobs?
> > 
> > Regards,
> > Trevor Bramwell
> > 
> > P.S. Trevor Cooper, I just remembered we discussed possibly using
> > POD 19
> > for test projects, though I don't recall if we reached a decision
> > on
> > that.
> > 
> > 
> > 
> > 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21516): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21516
Mute This Topic: https://lists.opnfv.org/mt/23003662/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] [functest] The vping test failed

[Cedric OLLIVIER]

Hello Louie,

You were absolutely right to verify your deployment via Functest
Fraser. I suggest you to switch to master because this version can be
already considered as better regarding deployment configurations which
are unverified or partially verified by OPNFV gates such for instance:
  - few vlan ids are allowed by firewall rules (network providers)
  - flavor specs or image extra properties are mandatory (e.g DPDK)

Yes we have done a huge refactoring to enforce the two previous
scenarios by design instead of a possible partial support (several
testcases would have to be updated).

Yes 6 new scenarios are now offered (tenantnetwork[1,2], vmready[1,2],
singlevm[1,2] which bring other benefits as well:
  - ease writing testcases for endusers and OPNFV Features
  - avoid duplicating code as for vnfs
  - follow the same rules in all testcase config sections
  - allow easily cleaning all remaining resources

There are several bugfixes including in the scenarios as the one you're
highlighting (cf. SingleVm2).

I fully agree with you that we should backport all the related patches.
I precise that no testcase will be created or moved for one tiers to
another. Then they may help Dovetail (based on Fraser) to correctly
certify this setups.

I will add this topic on the agenda of the next Functest meeting then
we would take the actions agreed by Functest team.

But our icmp packet raised lots of concerns last week, from few
installers to TSC and we don't know clearly what are our new
prerogatives. I would think we are free to decide but I prefer opening
the question here as well. No need to break the virtuous circle between
Test Frameworks and one additional installer which is, I think, the
worse case for OPNFV. But I think there is no technical reason to do so
here as well.

Cédric

On ven., 2018-06-29 at 15:19 +0800, louie long wrote:
> 
>  Hi，Cédric，
> 
>  The functest（opnfv/functest-healthcheck：latest）does work, and vping
> testcase can test successfully.
> 
>  Why I chose functest(opnfv/functest-smoke:fraser) is due to the
> dovetail use opnfv/functest-smoke:fraser, 
>  and the vping testcase of dovetail has failed, so I chose functest
> to test vping alone and try to find out why it was failed.
>  
>  I try to find out the patch on the master about the vping, but I
> find that the vping is refactored and became concise. 
> It seems to involve multiple patches. Is it possible to merge the
> patch on the master about the vping to the Fraser?
>  
>  Thank you.
> 
>  Louie
> 
>  
> -- Original --
> From:  "cedric.ollivier";
> Date:  Mon, Jun 25, 2018 11:38 PM
> To:  "louie long"; "opnfv-tech-discuss" -disc...@lists.opnfv.org>;
> Subject:  Re: [opnfv-tech-discuss] [functest] The vping test failed
>  
> Hello,
>  
> Would you mind trying the two vping testcases in master (they have
> moved to opnfv/functest-healthcheck)?
> We have switched to the floating ip address instead of the vm
> attribute.
>  
> Please let us know if it works, we would backport the required
> changes.
>  
> Thank you in advance,
> Cédric
>  
>  
> De : opnfv-tech-discuss@lists.opnfv.org [mailto:opnfv-tech-discuss@li
> sts.opnfv.org] De la part de louie long
> Envoyé : lundi 25 juin 2018 12:48
> À : opnfv-tech-discuss
> Objet : [opnfv-tech-discuss] [functest] The vping test failed
>  
>  
>   Hi,functest,
>  
>   I have problem with functest(opnfv/functest-smoke:fraser) vping
> testcase, the vping network and vm instance can be created normally
> by functest, and I can login the vm run ping test, also it can ping
> each other ok.
>  
>   But the functest vping show the testcase run failed, wether I use
> ssh or userdata. In vping_ssh testcase, the vm get a floating ip
> 192.168.20.140 and an intenal ip
> 192.168.130.7, I can use ssh to login the vm by using the floating ip
> and execute ping another vm ok. But the functest try to login vm by
> using 192.168.130.7, it seems abnormally.
>  
>  The attachment is vping_ssh and vping_userdata test logs. Please
> give me some help for this issue.
>  Thank you.
>  
>  Louie
> 
> 
> 
> 
> --
>  Louie Long
>  E-mail: yl...@biigroup.cn
> Mobile: +86 13261979365
> Fax: 86-10-5867-8466
> Postcode：10
> Add: 2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, China
> Website: www.biigroup.com  www.cfiec.net
> _
> 
> 
> 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 

Re: [opnfv-tech-discuss] [functest] The vping test failed

[cedric . ollivier]

Hello,

Would you mind trying the two vping testcases in master (they have moved to 
opnfv/functest-healthcheck)?
We have switched to the floating ip address instead of the vm attribute.

Please let us know if it works, we would backport the required changes.

Thank you in advance,
Cédric


De : opnfv-tech-discuss@lists.opnfv.org 
[mailto:opnfv-tech-discuss@lists.opnfv.org] De la part de louie long
Envoyé : lundi 25 juin 2018 12:48
À : opnfv-tech-discuss
Objet : [opnfv-tech-discuss] [functest] The vping test failed


  Hi,functest,

  I have problem with functest(opnfv/functest-smoke:fraser) vping testcase, the 
vping network and vm instance can be created normally by functest, and I can 
login the vm run ping test, also it can ping each other ok.

  But the functest vping show the testcase run failed, wether I use ssh or 
userdata. In vping_ssh testcase, the vm get a floating ip 192.168.20.140 and an 
intenal ip
192.168.130.7, I can use ssh to login the vm by using the floating ip and 
execute ping another vm ok. But the functest try to login vm by using 
192.168.130.7, it seems abnormally.

 The attachment is vping_ssh and vping_userdata test logs. Please give me some 
help for this issue.
 Thank you.

 Louie




--
 Louie Long
 E-mail: yl...@biigroup.cn
Mobile: +86 13261979365
Fax: 86-10-5867-8466
Postcode：10
Add: 2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, China
Website: www.biigroup.com  
www.cfiec.net


_

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.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#21454): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/21454
Mute This Topic: https://lists.opnfv.org/mt/22674506/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [opnfv-tech-discuss] Problems with sfc - functest integration (mater branch)

[Cedric OLLIVIER]

Hello David,

We have worked hard to clean the interfaces between Functest, SFC and
SDNVPN.
It remains from our side to add few remaining docstrings to complete the
API docs.

Cédric

2018-02-28 17:12 GMT+01:00 David McBride :

> Manuel,
>
> Did this resolve your issue?  Thanks.
>
> David
>
> On Wed, Feb 21, 2018 at 2:49 AM, Manuel Buil  wrote:
>
>> Hi Juha,
>>
>> Thanks! We will try today :)
>>
>> Regards,
>> Manuel
>>
>> On Wed, 2018-02-21 at 10:35 +, Kosonen, Juha (Nokia - FI/Espoo) wrote:
>>
>> Hi Dimitris & Manuel
>>
>>
>> The name of credential file was changed few weeks back (
>> https://gerrit.opnfv.org/gerrit/#/c/51283/), the new name is "env_file" (
>> https://wiki.opnfv.org/pages/viewpage.action?pageId=13211751).
>>
>> As a such CONST is still there but you need to change
>>
>> os_env_file=CONST.__getattribute__('openstack_creds')
>>
>> to
>>
>> os_env_file=getattr(CONST, 'env_file')
>>
>>
>> Regards,
>>
>> JK
>>
>> --
>> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org <
>> opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Manuel Buil <
>> mb...@suse.com>
>> *Sent:* Wednesday, February 21, 2018 11:43
>> *To:* OPNFV-TECH-DISCUSS OPNFV
>> *Subject:* [opnfv-tech-discuss] Problems with sfc - functest integration
>> (mater branch)
>>
>> Hey functest guys,
>>
>> We need again help with funcetst-sfc integration because there is
>> something broken now related to the removal of the CONST module from
>> your repo. This is our script:
>>
>> https://github.com/opnfv/sfc/blob/master/sfc/lib/openstack_utils.py
>>
>> In that script, we used to fetch several things with
>> CONST.__getattribute__:
>>
>> os_env_file=CONST.__getattribute__('openstack_creds'))
>> CONST.__getattribute__('EXTERNAL_NETWORK')
>> CONST.__getattribute__('OS_AUTH_URL')
>> CONST.__getattribute__('OS_PASSWORD')
>>
>> We tried to "s/CONST.__getattribute__/env.get" but
>> env.get('openstack_creds') returns None.
>>
>> We were checking your patch:
>>
>> https://gerrit.opnfv.org/gerrit/#/c/52221/4
>>
>> And we realized that some of those parameters are now gone, so we
>> wondered how should we do it now. We were checking your documented API:
>>
>> http://functest.readthedocs.io/en/latest/apidoc/functest.html
>>
>> However, we cannot see the functest.utils package there (CONST and env
>> belong to that), so we are a bit lost about what needs to be changed on
>> our side. We guess we must be using the functest API again in a
>> wrong/not-supported-anymore way :(. Any link or any explanation which
>> shows us how to do it properly will be appreciated.
>>
>> Thanks,
>> Dimitris & Manuel
>> ___
>> opnfv-tech-discuss mailing list
>> opnfv-tech-discuss@lists.opnfv.org
>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>> opnfv-tech-discuss Info Page
>> 
>> lists.opnfv.org
>> This list is for general technical discussion about OPNFV. It’s open to
>> anyone to join. If you have any questions, please contact Ray Paik at
>> rp...@linuxfoundation.org.
>>
>>
>> ___
>> opnfv-tech-discuss mailing list
>> opnfv-tech-discuss@lists.opnfv.org
>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>>
>>
>
>
> --
> *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 mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [fuel] Nominating Guillermo Herrero as committer

[Cedric OLLIVIER]

+1

Le 11 janv. 2018 8:47 AM, "Michael Polenchuk"  a
écrit :

> +1
>
> On Thu, Jan 11, 2018 at 5:15 AM, Alexandru Avadanii <
> alexandru.avada...@enea.com> wrote:
>
>> Hi,
>>
>> I would like to nominate Guillermo Herrero (Enea) as a committer in
>> Fuel@OPNFV.
>>
>> I have been in contact with Guillermo and he is willing to take on the
>> role.
>>
>>
>>
>> Guillermo is one of the main contributors in Armband and Fuel@OPNFV,
>>
>> and he has been one of the most active and valuable contributors during
>> the Euphrates release cycle.
>>
>>
>>
>> Fuel committers, reply to this mail with your vote (-1, 0, +1).
>>
>> I’ll start:
>>
>> +1
>>
>>
>>
>> BR,
>>
>> Alex
>>
>> ___
>> opnfv-tech-discuss mailing list
>> opnfv-tech-discuss@lists.opnfv.org
>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>>
>>
>
>
> --
>   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 mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Docker builds failing for ARM

[Cedric OLLIVIER]

Yes you can safely revert it from functest side (we have written our own
multijobs). But that may raise side effects if several projects don't write
it in their Dockerfiles.

Cédric

Le 22 déc. 2017 7:27 PM, "Beierl, Mark"  a écrit :

> Hello,
>
> All the StorPerf docker builds on ARM have been failing since some time in
> November.  Here is the last successful build [1], which shows the
> --build-arg for ARCH in place:
>
> docker build --no-cache -t opnfv/storperf-master:aarch64-latest
> --build-arg BRANCH=master *--build-arg ARCH=aarch64* -f Dockerfile
>
> The next build no longer has that code in place [2]:
>
> docker build --no-cache -t opnfv/storperf-master:aarch64-latest
> --build-arg BRANCH=master -f Dockerfile .
>
> This appears to be the related change [3].  Can we get that put back?  The
> git review to re-instate it is here [4].  I cannot push the OPNFV 5.1.0
> release of StorPerf without it.
>
> [1] https://build.opnfv.org/ci/view/storperf/job/storperf-
> master-docker-build-arm-push-master/22/console
> [2] https://build.opnfv.org/ci/view/storperf/job/storperf-
> master-docker-build-arm-push-master/23/console
> [3] https://github.com/opnfv/releng/commit/e25af7fd788db267247abb6b4efa4c
> f2dff73f32#diff-80ab330132d9f5ae6e27a1ae7b186eb8
> [4] https://gerrit.opnfv.org/gerrit/49565
>
> Regards,
> Mark
>
> *Mark Beierl*
> SW System Sr Principal Engineer
> *Dell **EMC* | Cloud & Communication Service Provider Solution
> mobile +1 613 314 8106 <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] [releng] Committer list per Releng repository

[Cedric OLLIVIER]

I consider this proposal as very good regarding the multiple different
skills involved in the current releng tree.
Functest could leverage on it too as it will incubate requirements and
xtesting which could differ on interests and skills.

Switching to a dedicated project will cost at least to rename the git
repository (gerrit?).

Cédric

Le 7 déc. 2017 4:21 PM, "Ryota Mibu"  a écrit :

> +1
>
>
>
> Also we need to consider long term transition. Each repo or sub-team would
> be getting bigger then could be independent project/repo eventually. So, it
> would be nice to find sub-team lead or key person who is responsible in
> each repo along with this list modification. Just two cents though.
>
>
>
> BR,
>
> Ryota
>
>
>
> *From:* Fatih Degirmenci [mailto:fatih.degirme...@ericsson.com]
> *Sent:* Friday, December 08, 2017 9:02 AM
> *To:* Aric Gardner ; Tim Rozet <
> tro...@redhat.com>; Morgan Richomme ; Jose
> Lausuch ; Mibu Ryota(壬生 亮太) ;
> Meimei ; Trevor Bramwell ;
> Serena Feng ; Yolanda Robla Mota <
> yrobl...@redhat.com>; Markos Chandras ; Luke Hinds <
> lhi...@redhat.com>
> *Cc:* opnfv-tech-discuss@lists.opnfv.org
> *Subject:* [releng] Committer list per Releng repository
>
>
>
> Hi Releng Committers,
>
>
>
> During OPNFV Plugfest, we had conversations around having committer list
> per Releng repository/Gerrit Project.
>
>
>
> The reason behind this is that, Releng project currently has 5 different
> repositories as listed below. [1]
>
>
>
> -  releng
>
> -  releng-anteater
>
> -  releng-testresults
>
> -  releng-utils
>
> -  releng-xci
>
>
>
> The work that is done in these repositories require different competence
> profiles. For example for releng repository, the committers need to have
> knowledge in CI, Jenkins, Jenkins Job Builder and so on.
>
> Apart from the required competence, some developers might not be
> interested in certain parts of Releng but interested in others.
>
>
>
> Having single committer list across all Releng owned repositories prevents
> us from recognizing contributors and promoting them as committers for the
> corresponding repositories since they will perhaps never have enough
> contributions across all of them.
>
> Another limitation is that, the current review practices followed by
> Releng is not good and we need to improve this. Having right set of
> committers per repo and getting patches reviewed by them properly will help
> with the quality of work we are doing.
>
>
>
> In order to address this limitation and have the ability and the
> possibility to recognize and promote developers who made great
> contributions to Releng in general in the repositories they worked in, I
> propose to create committer list per repo.
>
>
>
> Please respond to this mail with +1 and -1 and share questions, comments,
> concerns if you have any.
>
>
>
> I plan to bring this topic to TSC on December 12th if the vote passes.
>
>
>
> [1] https://gerrit.opnfv.org/gerrit/#/admin/projects/?filter=releng
>
>
>
> /Fatih
>
> ___
> 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] [releng] How to merge master to euphrates with gerrit

[Cedric OLLIVIER]

Again squashing is not a good technical solution as it will forbid the
next cherry-picks.
You will spend much more time to fix the next conflicts than
cherry-picking by hand now.

If you have many commits to fix docs or trivial fixes in code in the
week before release, it seems that your project is simply on time.
I'm glad to see Functest as a previous example ;)

I think the issue is simply related to the planning.
Technically speaking, you should have delayed the creation of your
stable branch (I know you can't).

Cédric

2017-10-19 16:06 GMT+02:00 Alec Hothan (ahothan) :
> Hi Yujun,
>
>
>
> The stable branch is created a few weeks before the release data and a lot
> can happen in a few weeks. It could be lots of small commits related to
> docs, lots of trivial fixes. The point I wanted to make is that you do not
> want to see all these small detail commits on your release branch and hence
> the notion of having a “clean” release branch devoid of detailed small
> commits that do not need to be tracked at that level of branch.
>
> Say you have 20 commits to fix docs or 20 trivial fixes in code in the week
> before release, will you want to have 20 commits on stable branch or one?
>
> This is a case where a merge makes sense rather than cherry picking each of
> them.
>
> Another case where merges make sense is when you deliver 5.1.0 with possibly
> lots of new enhancements to 5.0, it makes sense to merge rather than cherry
> pick lots of commits.
>
>
>
> The rebase/squash is OK too but as I noted you do not have the git pointer
> from master to release branch commit to indicate that you actually did a
> merge.
>
>
>
> Should the branch be stable state and not have too many commits at that
> stage? It depends on the type of commits and that should be left to the
> judgment of project committers. But we should allow merge commits to be
> allowed on gerrit reviews (they are not enabled today).
>
>
>
> Regards,
>
>
>
>Alec
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: "Yujun Zhang (ZTE)" 
> Date: Wednesday, October 18, 2017 at 7:23 PM
> To: Trevor Bramwell , "Alec Hothan (ahothan)"
> 
> Cc: "opnfv-tech-discuss@lists.opnfv.org"
> 
> Subject: Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates
> with gerrit
>
>
>
> This could do the trick but I don't quite recommend it. There would be some
> commits on master you do NOT want to include in stable branches.
>
>
>
> I suggest to pick commits carefully after inspection and do the cherrypick
> one by one on gerrit. It will keep a record of which patch sets have been
> cherry-picked in review history (not just git log).
>
>
>
> If you have too many patch sets to be cherrypicked. Something may have gone
> wrong. By the time we created stable branch, it should be considered as a
> stable branch and not expecting too many changes, except for bug fix and
> document amending.
>
>
>
> My 2 cents.
>
>
>
> On Thu, Oct 19, 2017 at 6:04 AM Trevor Bramwell
>  wrote:
>
> Hey Alec,
>
> Here's a quick way to cherry-pick these all over to the stable/euphrates
> branch. Though you'll still need to submit them all through Gerrit:
>
>   git checkout euphrates
>   git cherry -v stable/euphrates master | cut -d' ' -f2 | xargs -I{} git
> cherry-pick -x '{}'
>
> 'git review' will ask you to confirm you want to upload multiple
> patchsets. A 'yes' should put all of them up for review.
>
> Regards,
> Trevor Bramwell
>
> On Wed, Oct 18, 2017 at 08:14:59PM +, Alec Hothan (ahothan) wrote:
>> I have many commits in master which I’d like to merge to stable/euphrates.
>> Would like to check if anybody knows how to merge master into a release
>> branch using gerrit?
>> Looks like I may need the permission to upload merges with Gerrit.
>>
>> Here is what I did:
>>
>> $ git fetch origin  stable/euphrates:euphrates
>> $ git checkout euphrates
>>
>> $ git merge master –no-ff
>>
>> # at this point, so far so good, I got all my commits into my euphrates
>> branch
>>
>> # git review fails due to permission:
>>
>> $ git review
>> Warning: Permanently added
>> '[gerrit.opnfv.org]:29418,[198.145.29.81]:29418' (RSA) to the list of known
>> hosts.
>> remote: Processing changes: refs: 1, done
>> To ssh://gerrit.opnfv.org:29418/nfvbench.git
>> ! [remote rejected] HEAD -> refs/publish/master/euphrates (you are not
>> allowed to upload merges)
>> error: failed to push some refs to
>> 'ssh://ahot...@gerrit.opnfv.org:29418/nfvbench.git'
>>
>>
>> Is there a different way to achieve this?
>> I do not want to cherry pick my commits as I have too many of them.
>>
>> Thanks
>>
>>   Alec
>>
>
>> ___
>> opnfv-tech-discuss mailing list
>> opnfv-tech-discuss@lists.opnfv.org
>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> opnfv-tech-discuss 

Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates with gerrit

[Cedric OLLIVIER]

Hello Alec,

Yes Functest conforms with the "classical" guidelines as we "cherry-pick"
the commits from master to stable/euphrates.
It results in small commits because all are small bugfixes before the
release. That's the best way to easily maintain the branches.
Ii could be noted that we also mention if a conflict occurs when
"cherry-picking".
https://git.opnfv.org/functest/commit/?h=stable/euphrates=fed72336e3b50b8441f233a2f122e482ee83ae8c

I strongly advise not to squash the commits into one commit as you can't
compare the branches and the result can't be easily reviewed.
Merging patches is automatically done by gerrit not by the user (even if
the merge commit is associated to one author what breaks bitergia stats).

You're free to apply a special commit for stable/euphrates if it's the only
technical solution:
https://git.opnfv.org/functest/commit/?h=stable/euphrates=28a8e9c5a1e442c866947455dfe8cbe47b66a0c7

Regarding your issue, I would "cherry-pick" every commit by hand, one after
the others (you can call only one git review as previously proposed) .
Instead of applying a script to sync master and stable/euphrates, I would
seriously reconsider destroying/recreating stable/euphrates.

Cédric


2017-10-19 16:27 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>:

> Cedric,
>
>
>
> This openstack document describes the normal dev workflow. The Merge
> section in the document is related to what Gerrit does when a patchset is
> +2. In this thread, we’re talking about the ability to submit a merge
> request to Gerrit (so this is before +2 is done).
>
> The notion of branch merge to a release branch is part of the release
> model, meaning how do you move content from a non release branch (e.g.
> master) to a release branch. As of today the only way to do this from
> master to a stable branch is by cherry-picking. I think we should allow
> merges to be submitted to gerrit. Those merge requests can of course be
> approved or rejected by committers – same as normal patchsets.
>
>
>
> Here is a diagram that shows the difference between a cherry-pick and a
> merge from master to a release branch:
>
>
>
> With todays gerrit settings we can’t do merges because we cannot even
> submit them for gerrit reviews, we can only do cherry picking.
>
> I have currently ~40 commits sitting on master than I want to get into
> stable/euphrates. Only option for me is to do a rebase + squash. What I am
> losing (vs. a merge) is the arrow between my current tip of master and what
> will become the opnfv-5.0.0 commit. So if somebody looks at the git log
> later (say in a year) it won’t be obvious at all that this release commit
> has all the content of master up to the current tip because git will not
> represent that link.
>
> Is it going to jeopardize my euphrates release content? No. But as a
> maintainer it would have been really helpful to keep that formal link in
> the repo.
>
>
>
> This could be enabled very easily – only one place to change in the
> All-Projects config of gerrit. But it looks like it will take time to get
> this approved.
>
>
>
> For XCI, merging between branches will be inevitable to prevent
> multiplication of identical commits across branches.
>
>
>
> Regards,
>
>
>
>Alec
>
>
>
>
>
>
>
>
>
> *From: *Cedric OLLIVIER <ollivier.ced...@gmail.com>
> *Date: *Wednesday, October 18, 2017 at 11:09 PM
> *To: *"Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com>
> *Cc: *Trevor Bramwell <tbramw...@linuxfoundation.org>, "Alec Hothan
> (ahothan)" <ahot...@cisco.com>, "opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>
> *Subject: *Re: [opnfv-tech-discuss] [releng] How to merge master to
> euphrates with gerrit
>
>
>
> Hello,
>
>
>
> I would advice the offical OpenStack documentation about this topic:
>
> https://docs.openstack.org/infra/manual/developers.html
>
>
>
> Cédric
>
>
>
> 2017-10-19 4:23 GMT+02:00 Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>:
>
> This could do the trick but I don't quite recommend it. There would be some
>
> commits on master you do NOT want to include in stable branches.
>
>
>
> I suggest to pick commits carefully after inspection and do the cherrypick
>
> one by one on gerrit. It will keep a record of which patch sets have been
>
> cherry-picked in review history (not just git log).
>
>
>
> If you have too many patch sets to be cherrypicked. Something may have gone
>
> wrong. By the time we created stable branch, it should be considered as a
>
> stable branch and not expecting too many changes, except for bug fix an

Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates with gerrit

[Cedric OLLIVIER]

Hello,

I would advice the offical OpenStack documentation about this topic:
https://docs.openstack.org/infra/manual/developers.html

Cédric

2017-10-19 4:23 GMT+02:00 Yujun Zhang (ZTE) :
> This could do the trick but I don't quite recommend it. There would be some
> commits on master you do NOT want to include in stable branches.
>
> I suggest to pick commits carefully after inspection and do the cherrypick
> one by one on gerrit. It will keep a record of which patch sets have been
> cherry-picked in review history (not just git log).
>
> If you have too many patch sets to be cherrypicked. Something may have gone
> wrong. By the time we created stable branch, it should be considered as a
> stable branch and not expecting too many changes, except for bug fix and
> document amending.
>
> My 2 cents.
>
> On Thu, Oct 19, 2017 at 6:04 AM Trevor Bramwell
>  wrote:
>>
>> Hey Alec,
>>
>> Here's a quick way to cherry-pick these all over to the stable/euphrates
>> branch. Though you'll still need to submit them all through Gerrit:
>>
>>   git checkout euphrates
>>   git cherry -v stable/euphrates master | cut -d' ' -f2 | xargs -I{} git
>> cherry-pick -x '{}'
>>
>> 'git review' will ask you to confirm you want to upload multiple
>> patchsets. A 'yes' should put all of them up for review.
>>
>> Regards,
>> Trevor Bramwell
>>
>> On Wed, Oct 18, 2017 at 08:14:59PM +, Alec Hothan (ahothan) wrote:
>> > I have many commits in master which I’d like to merge to
>> > stable/euphrates.
>> > Would like to check if anybody knows how to merge master into a release
>> > branch using gerrit?
>> > Looks like I may need the permission to upload merges with Gerrit.
>> >
>> > Here is what I did:
>> >
>> > $ git fetch origin  stable/euphrates:euphrates
>> > $ git checkout euphrates
>> >
>> > $ git merge master –no-ff
>> >
>> > # at this point, so far so good, I got all my commits into my euphrates
>> > branch
>> >
>> > # git review fails due to permission:
>> >
>> > $ git review
>> > Warning: Permanently added
>> > '[gerrit.opnfv.org]:29418,[198.145.29.81]:29418' (RSA) to the list of known
>> > hosts.
>> > remote: Processing changes: refs: 1, done
>> > To ssh://gerrit.opnfv.org:29418/nfvbench.git
>> > ! [remote rejected] HEAD -> refs/publish/master/euphrates (you are not
>> > allowed to upload merges)
>> > error: failed to push some refs to
>> > 'ssh://ahot...@gerrit.opnfv.org:29418/nfvbench.git'
>> >
>> >
>> > Is there a different way to achieve this?
>> > I do not want to cherry pick my commits as I have too many of them.
>> >
>> > Thanks
>> >
>> >   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
>
> --
> Yujun Zhang
>
> ___
> 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

[Cedric OLLIVIER]

Hello Mark,

Manifest allows pulling the right image according to ARCH
(arm64/amd64). Please see the dump of ollivier/functest-core:latest
attached to this mail.
Here I would like to avoid variables in FROM (by default) mainly to
ensure a better compatibility with all toolings and to ease
maintenance.

If arm64 images are built on an arm64 PODs, the same Dockerfiles can
be shared between these archs for:
(all could refer to opnfv/functest-core:latest as parent)
  - functest-healthcheck
  - functest-smoke
  - functest-features
  - functest-components
  - ...

But it cannot work in case of cross-building as host and target host differ.
Then we must precise opnfv/functest-core:arm64-latest in this case.

Cédric

2017-10-16 7:04 GMT+02:00 Beierl, Mark <mark.bei...@dell.com>:
> Cédric,
>
> I am curious, how does the manifest help with avoiding FROM? Is it that we
> would use that to pull the correct base Alpine image?
>
> 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 15, 2017, at 23:55, "cedric.olliv...@orange.com"
> <cedric.olliv...@orange.com> wrote:
>
> Alex,
>
> Yes. You know I was waiting for tests from your side. As manifest works as
> expected, we can remove most of them.
>
> But I will keep the one to build/publish containers in any repo as it's very
> useful.
>
> My sentence was focused on Functest.
>
> Cédric
>
>  Alexandru Avadanii a écrit 
>
> Hi,
>
>> -Original Message-
>> From: Cedric OLLIVIER [mailto:ollivier.ced...@gmail.com]
>> Sent: Sunday, October 15, 2017 8:27 PM
>> To: Alec Hothan (ahothan)
>> Cc: Alexandru Avadanii; Fatih Degirmenci; cedric.olliv...@orange.com;
>> opnfv-
>> tech-discuss; Delia Popescu; David McBride; morgan.richo...@orange.com
>> Subject: Re: [opnfv-tech-discuss] [functest] Alpine for arch
>>
>> Hello Alec,
>>
>> Please find several answers inline.
>>
>> Cédric
>>
>> 2017-10-14 20:55 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>:
>> >
>> >
>> > Alex: this looks like a good plan and seems to take care of all
>> > functest requirements wrt build.
>> >
>>
>> [Cédric]
>> Absolutly not as the second point is false from our point of view.
>> We prefer Docker manifests to useless variables in FROM instructions what
>> would break the current builds.
>> I will translate my travis-ci jobs to releng jjobs after E is published.
>
> [Alex]
> For the record, the cost of dismissing FROM ARG is duplicating the
> Dockerfile (either with a patch, or with a series of runtime sed, e.g. [1]
> vs [2]).
> Also, Storperf requires the latest Docker, and has no issues on the current
> OPNFV builders, so those are already up to date.
> I'm not saying FROM ARG should be enforced, but if some projects want to use
> it, they should be allowed to, instead of juggling with FROM using sed or
> patches.
>
> BR,
> Alex
>
> [1] https://gerrit.opnfv.org/gerrit/#/c/44999/1/build.sh
> [2]
> https://github.com/opnfv/storperf/blob/master/docker/storperf-graphite/Dockerfile#L17-L19
>
>>
>> >
>> >
>> > What we need to nail down next is the versioning and how it plays out
>> > with Functest CI, Functest XCI and lastly to the release.
>> >
>> >
>> >
>> > It is critical to nail down the versioning and branching model first
>> > before rushing to modify the releng tools/scripts. The current
>> > versioning and branching model is insufficient (as a proof see what
>> > functest is doing to overcome the limitations). We need direction and
>> > the XCI project is the right place to determine the overall versioning
>> > model for all OPNFV projects.
>> >
>> >
>>
>> >
>> > Cedric: your wiki on releng requirements is a good start. It will be
>> > great if it could also have the following information:
>>
>> [Cédric]
>>
>> I think it's quite clear how Functest must be improved to implement a real
>> Functest Functional gating via XCI.
>> I believe releng could have been updated as soon as Functest started
>> splitting
>> the containers. We have developped build.sh as initially proposed.
>> For your information, the wiki page is hugely completed by my previous
>> email
>> and the travis-ci jobs already published (and running in my private repo):
>> https://git.opnfv.org/functest/tree/.travis.yml?h=stable/euphrates
>> https://travis-ci.org/collivier/functest/builds/287849046
>> https://travis-

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cedric OLLIVIER]

gt; functest-vnf
> functest-healthcheck
> functest-features
> functest-parser
> functest-components
> functest-restapi
>
> I am still missing the link between all these artifacts and the dependent
> project repos, for example where is the barometer code running (there is no
> functest-barometer)? Is it in functest-core? It would be helpful to document
> the exact dependency of every artifact.
>
> From what I see, external projects included in functest dockerifles are
> included properly (i.e. the code is pulled in the build using an explicit
> git hash or a version git tag) but OPNFV projects only use tip of branch
> (tip of master or top of stable branch). Example fir the functest-smoke
> dockerfile:
>
>
>
> ARG FDS_TAG=master
>
>
>
> git clone --depth 1 -b $FDS_TAG https://gerrit.opnfv.org/gerrit/fds
> /src/fds && \
>
>
>
> This is generally not recommended given the tip of master is not always what
> the fds team would want functest to use for smoke test (and the fds team has
> no idea on when functest-smoke is built). Note this is not the fault of
> functest, the reason is that fds does not version its code on master – and
> given that very few projects version their code at all, the problem is
> widespread.
>
>

[Cédric]
Could you please have a look to the stable branch instead? You're
reading the master Dockerfiles.
Here you are also mixing Project (FDS) and OPNFV gatings. We will
publish a kind of Functest Docker Framework to help creating a docker
per project based on Functest-core.
But functest-features always makes sense to qualify the release. Then
in this case we should clone stable branches for building the
containers, shouldn't we?

>
> We also need to review the versioning of all these artifacts, all
> contributing OPNFV projects, how they are deployed … And you start to see
> why tagging all these images with “stable” can become hard to handle e.g.
> what version of functest-core:stable (or which commit on the stable branch)
> was used to build a given version of functest-parser:stable).
>
>
>
> I think once we have a better understanding of the above questions
> (CI/XCI/release) we can come up with a versioning and branching model that
> satisfies the functest need for generating more frequently artifacts and
> satisfies the need for XCI and release (to track precisely versions of
> artifacts to use).
>
>
>
> And to answer to Cedric’s question on how do other projects like openstack
> do, it is pretty simple, they all version their project code (i.e they put
> git tags to mark versions using semver syntax) and their version is
> independent of the release version ;-) That is the fundamental and necessary
> condition to do proper versioning.
>
>
>
> Thanks
>
>
>
>Alec
>
>
>
>
>
> From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Alexandru
> Avadanii <alexandru.avada...@enea.com>
> Date: Saturday, October 14, 2017 at 8:30 AM
> To: Cedric OLLIVIER <ollivier.ced...@gmail.com>, Fatih Degirmenci
> <fde...@gmail.com>
> Cc: "cedric.olliv...@orange.com" <cedric.olliv...@orange.com>,
> opnfv-tech-discuss <opnfv-tech-discuss@lists.opnfv.org>, Delia Popescu
> <delia.pope...@enea.com>
>
>
> Subject: Re: [opnfv-tech-discuss] [functest] Alpine for arch
>
>
>
> Hi,
>
> I confirm that the current releng scripts don't support current functest
> requirements, but that is within our reach.
>
> Afaik, we are looking at 2 main issues:
>
> 1. functest-core needs to be built first - we can solve this by using
> multijobs, with an initial step of building functest-core (amd64 & arm64 in
> parallel), then all other builds in parallel;
>
> 2. functest Docker requires support for ARG in FROM - we can solve this by
> upgrading Docker to a newer version on all amd64 builders (arm64 already has
> a new enough version);
>
>
>
> We (armband) offered to take care of #1. Delia can implement the JJB changes
> next week, we estimate it will take 2-3 days.
>
> For #2, we need lab admins with access to the amd64 builder machines to do a
> simple package upgrade.
>
> As part of #2, we might need to install a new package (Docker manifest-tool)
> too.
>
>
>
> Imo, we can adapt releng scripts without too much trouble, and we (Armband)
> are willing to take care of the scripts, if you all agree.
>
>
>
> As for parallel building (not only amd64 and arm64, but all other containers
> aside from functest-core) - this will be solved by the design we proposed in
> #1.
>
> There is no need for qemu-user-static and binfmt-misc in OPNFV, as we
> provide an arm64 native builder (arm-build4). This was required

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cedric OLLIVIER]

Hello,

I disagree to add variables in FROM instructions simply because it
obliges latest versions and then breaks Docker Automated builds.
It simply useless if we rely on Docker manifests as I have already demonstrated.
Manifest will also help jjobs as it avoids multiplying daily jjobs per arch.

Cédric

2017-10-14 17:29 GMT+02:00 Alexandru Avadanii <alexandru.avada...@enea.com>:
> Hi,
> I confirm that the current releng scripts don't support current functest 
> requirements, but that is within our reach.
> Afaik, we are looking at 2 main issues:
> 1. functest-core needs to be built first - we can solve this by using 
> multijobs, with an initial step of building functest-core (amd64 & arm64 in 
> parallel), then all other builds in parallel;
> 2. functest Docker requires support for ARG in FROM - we can solve this by 
> upgrading Docker to a newer version on all amd64 builders (arm64 already has 
> a new enough version);
>
> We (armband) offered to take care of #1. Delia can implement the JJB changes 
> next week, we estimate it will take 2-3 days.
> For #2, we need lab admins with access to the amd64 builder machines to do a 
> simple package upgrade.
> As part of #2, we might need to install a new package (Docker manifest-tool) 
> too.
>
> Imo, we can adapt releng scripts without too much trouble, and we (Armband) 
> are willing to take care of the scripts, if you all agree.
>
> As for parallel building (not only amd64 and arm64, but all other containers 
> aside from functest-core) - this will be solved by the design we proposed in 
> #1.
> There is no need for qemu-user-static and binfmt-misc in OPNFV, as we provide 
> an arm64 native builder (arm-build4). This was required for Travis CI, since 
> they don't have native arm64 builders.
>
> BR,
> Alex
>
>
>> -Original Message-
>> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-
>> boun...@lists.opnfv.org] On Behalf Of Cedric OLLIVIER
>> Sent: Saturday, October 14, 2017 2:22 PM
>> To: Fatih Degirmenci
>> Cc: cedric.olliv...@orange.com; Delia Popescu; opnfv-tech-discuss
>> Subject: Re: [opnfv-tech-discuss] [functest] Alpine for arch
>>
>> Hello Fatih,
>>
>> My previous mail aims at listing our requirements and again I am convinced
>> that we should select releng instead of external tools for a better control.
>> The travis-ci links illustrate exactly our needs and could help synchronizing
>> Functest and Releng.
>>
>> Here are the related config files:
>>   - https://git.opnfv.org/functest/tree/.travis.yml
>>   - https://git.opnfv.org/functest/tree/.travis.yml?h=stable%2Feuphrates
>>
>> I had to setup external tools to beta test and share my Alpine containers 
>> during
>> the development cycle.
>> The issue was induced by the fact they were copied for OPNFV repositories (I
>> precise during my holidays) instead of updating Releng.
>> I have only fixed the Docker automated builds and complete them to build the
>> remaining containers.
>> I could have forced the sync even if I'm not in charge of that as Functest 
>> core
>> dev.
>>
>> But I strongly think it's fine to compare travis-ci and today's releng jjobs 
>> simply
>> to impove our CI/CD.
>>
>> Regarding tags, I fully agree that we have taken several quick decisions 
>> without
>> analysing what OpenStack, Docker or GNU/Linux distributions do.
>> Bottom up feedbacks may have helped.
>>
>> Cédric
>>
>> 2017-10-14 12:42 GMT+02:00 Fatih Degirmenci <fde...@gmail.com>:
>> > Hi Cedric,
>> >
>> > I see lots of conversations around how to build stuff, test them, apply 
>> > tags but
>> it is very hard to follow things. Things are going too fast and with little
>> explanation. Each and every new thing coming up will make it harder for us to
>> understand what you need.
>> >
>> > Also the builds first pushed to docker hub then travis ci now. I am not 
>> > sure
>> about this either. I suppose you will try all the external ci services 
>> instead of
>> telling us what you need clearly...
>> >
>> > So, before I say if something is possible or not, you need to come up with
>> clear requirements. We can then fix whatever you need together with you.
>> >
>> > /Fatih
>> >
>> > On 14 Oct 2017, at 12:32, Cedric OLLIVIER <ollivier.ced...@gmail.com>
>> wrote:
>> >
>> > Hello,
>> >
>> > We simply require concurrent jobs properties which can be simplified
>> > here as parallel builds, concurrency control and depe

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cedric OLLIVIER]

Hello Fatih,

My previous mail aims at listing our requirements and again I am
convinced that we should select releng instead of external tools for a
better control.
The travis-ci links illustrate exactly our needs and could help
synchronizing Functest and Releng.

Here are the related config files:
  - https://git.opnfv.org/functest/tree/.travis.yml
  - https://git.opnfv.org/functest/tree/.travis.yml?h=stable%2Feuphrates

I had to setup external tools to beta test and share my Alpine
containers during the development cycle.
The issue was induced by the fact they were copied for OPNFV
repositories (I precise during my holidays) instead of updating
Releng.
I have only fixed the Docker automated builds and complete them to
build the remaining containers.
I could have forced the sync even if I'm not in charge of that as
Functest core dev.

But I strongly think it's fine to compare travis-ci and today's releng
jjobs simply to impove our CI/CD.

Regarding tags, I fully agree that we have taken several quick
decisions without analysing what OpenStack, Docker or GNU/Linux
distributions do.
Bottom up feedbacks may have helped.

Cédric

2017-10-14 12:42 GMT+02:00 Fatih Degirmenci <fde...@gmail.com>:
> Hi Cedric,
>
> I see lots of conversations around how to build stuff, test them, apply tags 
> but it is very hard to follow things. Things are going too fast and with 
> little explanation. Each and every new thing coming up will make it harder 
> for us to understand what you need.
>
> Also the builds first pushed to docker hub then travis ci now. I am not sure 
> about this either. I suppose you will try all the external ci services 
> instead of telling us what you need clearly...
>
> So, before I say if something is possible or not, you need to come up with 
> clear requirements. We can then fix whatever you need together with you.
>
> /Fatih
>
> On 14 Oct 2017, at 12:32, Cedric OLLIVIER <ollivier.ced...@gmail.com> wrote:
>
> Hello,
>
> We simply require concurrent jobs properties which can be simplified
> here as parallel builds, concurrency control and dependency.
> They are mainly required as:
>  - functest-core must be built before other Functest containers
>  - other containers should be built in parallel as soon as
> functest-core is published
>  - amd64 containers and arm64 containers should be built in parallel
>
> I am not directly involved in Releng and I have read in reviews or
> mails that today's jjobs don't support that.
> All proposals to build Alpine containers haven't conformed with the
> concurrency control and the dependencies.
> @Fatih could you please confirm that? I'm quite sure that Jenkins supports 
> them.
>
> In case of cross building arm64 images on amd64 PODs, we also require
> several operations on PODs:
>  - to install qemu-user-static
>  - to support binfmt-misc [1]
>
> The current Docker Automated builds had been fine before we were asked
> to build Alpine arm64 images and to publish stable tags:
> - arm64 images can't be built via this CI tool as it requires
> qemu-user-static and binfmt_misc [1] support on Docker hosts.
> - publishing stable tags triggers useless builds simply because they
> are already triggered by euphrates tags.
>
> I'm currently beta testing travis-ci to meet all requirements:
> - https://travis-ci.org/collivier/functest/builds/287849046 (stable/euphrates)
> - https://travis-ci.org/collivier/functest/builds/287745681 (master)
>
> It works very well and all scripts are ran in parallel for all steps:
> - build functest-core images
> - publish functest-core manifests
> - build all functest images
> - publish all manifests
>
> I am considering we do switch from Docker Automated builds to
> travis-ci for official Functest images if releng jjobs are not
> updated.
> But I think it's too late regarding the deadline for E as we should
> multiply CI runs. @David, do you agree?
> (Of course I am not allowed to configure travis-ci for OPNFV github
> repositories).
>
> I will deeply update the wiki page "Docker Requirements on Releng" [2]
>
> [1] https://www.kernel.org/doc/html/v4.11/admin-guide/binfmt-misc.html
> [2] https://wiki.opnfv.org/display/functest/Docker+Requirements+on+Releng
>
> Cédric
>
> 2017-10-11 9:56 GMT+02:00 Jose Lausuch <jalaus...@suse.com>:
>> 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, a

Re: [opnfv-tech-discuss] [functest] Alpine for arch

[Cedric OLLIVIER]

Hello,

We simply require concurrent jobs properties which can be simplified
here as parallel builds, concurrency control and dependency.
They are mainly required as:
  - functest-core must be built before other Functest containers
  - other containers should be built in parallel as soon as
functest-core is published
  - amd64 containers and arm64 containers should be built in parallel

I am not directly involved in Releng and I have read in reviews or
mails that today's jjobs don't support that.
All proposals to build Alpine containers haven't conformed with the
concurrency control and the dependencies.
@Fatih could you please confirm that? I'm quite sure that Jenkins supports them.

In case of cross building arm64 images on amd64 PODs, we also require
several operations on PODs:
  - to install qemu-user-static
  - to support binfmt-misc [1]

The current Docker Automated builds had been fine before we were asked
to build Alpine arm64 images and to publish stable tags:
 - arm64 images can't be built via this CI tool as it requires
qemu-user-static and binfmt_misc [1] support on Docker hosts.
 - publishing stable tags triggers useless builds simply because they
are already triggered by euphrates tags.

I'm currently beta testing travis-ci to meet all requirements:
 - https://travis-ci.org/collivier/functest/builds/287849046 (stable/euphrates)
 - https://travis-ci.org/collivier/functest/builds/287745681 (master)

It works very well and all scripts are ran in parallel for all steps:
 - build functest-core images
 - publish functest-core manifests
 - build all functest images
 - publish all manifests

I am considering we do switch from Docker Automated builds to
travis-ci for official Functest images if releng jjobs are not
updated.
But I think it's too late regarding the deadline for E as we should
multiply CI runs. @David, do you agree?
(Of course I am not allowed to configure travis-ci for OPNFV github
repositories).

I will deeply update the wiki page "Docker Requirements on Releng" [2]

[1] https://www.kernel.org/doc/html/v4.11/admin-guide/binfmt-misc.html
[2] https://wiki.opnfv.org/display/functest/Docker+Requirements+on+Releng

Cédric

2017-10-11 9:56 GMT+02:00 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 ; Cristina Pauna
> ; 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 

Re: [opnfv-tech-discuss] Arch-specific Docker tags

[Cedric OLLIVIER]

I think the key point is about using multiple repositories or multiple
tags to differenciate the architectures listed in manifests.
Multiple repositories (eg: opnfv/functest-core_amd64 &
opnfv/functest-core_arm64) are more flexible (stable could be linked
to different versions according to the arch) and allows multiple
maintainers.
But it could break rules about cross repositories. That's why we
agreed to multiply tags as storperf did.

Cédric



2017-10-13 22:59 GMT+02:00 Cedric OLLIVIER <ollivier.ced...@gmail.com>:
> Hello,
>
> Of course I will vote for 1.
> I consider 2 and 3 as false from a Docker point of view.
>
> Yes we already have published manifests which are suitable solutions
> to avoid duplicating Dockerfiles and jenkins jobs.
> Let me know if you want much technical details.
>
> I must precise that the choice done by Storperf can't work for Functest
> Most of our containers depend on a parent which oblige to use external
> tools instead of releng (they mainly forbid variable in FROM
> instructions).
>
> Cédric
>
> 2017-10-13 21:50 GMT+02:00 Alexandru Avadanii <alexandru.avada...@enea.com>:
>> Hi, Alec,
>>
>> Thanks for the vote J
>>
>> That is exactly what Cédric implemented for Functest, using manifests.
>>
>>
>>
>> If we are not to duplicate tags (i.e. choose between #1 and #3), I will vote
>> for #1 too.
>>
>>
>>
>> From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
>> Sent: Friday, October 13, 2017 9:57 PM
>> To: Alexandru Avadanii; TECH-DISCUSS OPNFV
>> Subject: Re: [opnfv-tech-discuss] Arch-specific Docker tags
>>
>>
>>
>>
>>
>> I would prefer limiting the number of container images because we’re going
>> to have a lot more image versions for some projects (to tackle versioned
>> XCI/CD)
>>
>> So option 2 does not look great for me.
>>
>> I’d vote for option 1.
>>
>>
>>
>> Have you guys looked at support for multi-arch docker images?
>>
>> I find it really interesting and removes the need for an arch specific tag.
>>
>>
>>
>> http://container-solutions.com/multi-arch-docker-images/
>>
>>
>>
>> If we could implement this, that would be even better.
>>
>>
>>
>>Alec
>>
>>
>>
>>
>>
>> From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Alexandru
>> Avadanii <alexandru.avada...@enea.com>
>> Date: Friday, October 13, 2017 at 10:04 AM
>> To: TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org>
>> Subject: [opnfv-tech-discuss] Arch-specific Docker tags
>>
>>
>>
>> Hi,
>>
>> Cédric pointed out that Docker uses DEB/kernel format for describing the
>> architecture of a Docker container.
>>
>> To align with this, the Functest Docker tags were updated from
>> "x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest".
>>
>>
>>
>> Although the arch-naming convention is not enforced to this format (as long
>> as the manifest points for a specific architecture to a specific tag, that
>> tag can be named however we want), we agreed that aligning with the Docker
>> internal format would be a good idea.
>>
>>
>>
>> My personal preference would be to duplicate the tags, and have both
>> "x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest"
>> point to the same image.
>>
>>
>>
>> Anyway, I think we should agree on a format at the OPNFV-project level, and
>> try to use it for all our projects.
>>
>>
>>
>> So, for multiarch projects that push Docker images, we have at least 3
>> options:
>>
>> 1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently
>> used by Functest);
>>
>> 2. "amd64" + "x86_64" / "arm64" + "aarch64";
>>
>> 3. "x86_64" / "aarch64" (currently used by Storperf);
>>
>>
>>
>> Note that if the project provides a manifest, arch-specific tags are more or
>> less hidden from the end-user, and a simple `docker pull
>> opnfv/functest-core:latest' (or without a tag) will fetch the image for the
>> current system arch automatically (amd64-latest or arm64-latest for
>> Functest).
>>
>>
>>
>> Thank you, Cédric, for handling this for Functest on such short notice!
>>
>>
>>
>> BR,
>>
>> Alex
>>
>> ___
>>
>> 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] Arch-specific Docker tags

[Cedric OLLIVIER]

Hello,

Of course I will vote for 1.
I consider 2 and 3 as false from a Docker point of view.

Yes we already have published manifests which are suitable solutions
to avoid duplicating Dockerfiles and jenkins jobs.
Let me know if you want much technical details.

I must precise that the choice done by Storperf can't work for Functest
Most of our containers depend on a parent which oblige to use external
tools instead of releng (they mainly forbid variable in FROM
instructions).

Cédric

2017-10-13 21:50 GMT+02:00 Alexandru Avadanii :
> Hi, Alec,
>
> Thanks for the vote J
>
> That is exactly what Cédric implemented for Functest, using manifests.
>
>
>
> If we are not to duplicate tags (i.e. choose between #1 and #3), I will vote
> for #1 too.
>
>
>
> From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
> Sent: Friday, October 13, 2017 9:57 PM
> To: Alexandru Avadanii; TECH-DISCUSS OPNFV
> Subject: Re: [opnfv-tech-discuss] Arch-specific Docker tags
>
>
>
>
>
> I would prefer limiting the number of container images because we’re going
> to have a lot more image versions for some projects (to tackle versioned
> XCI/CD)
>
> So option 2 does not look great for me.
>
> I’d vote for option 1.
>
>
>
> Have you guys looked at support for multi-arch docker images?
>
> I find it really interesting and removes the need for an arch specific tag.
>
>
>
> http://container-solutions.com/multi-arch-docker-images/
>
>
>
> If we could implement this, that would be even better.
>
>
>
>Alec
>
>
>
>
>
> From:  on behalf of Alexandru
> Avadanii 
> Date: Friday, October 13, 2017 at 10:04 AM
> To: TECH-DISCUSS OPNFV 
> Subject: [opnfv-tech-discuss] Arch-specific Docker tags
>
>
>
> Hi,
>
> Cédric pointed out that Docker uses DEB/kernel format for describing the
> architecture of a Docker container.
>
> To align with this, the Functest Docker tags were updated from
> "x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest".
>
>
>
> Although the arch-naming convention is not enforced to this format (as long
> as the manifest points for a specific architecture to a specific tag, that
> tag can be named however we want), we agreed that aligning with the Docker
> internal format would be a good idea.
>
>
>
> My personal preference would be to duplicate the tags, and have both
> "x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest"
> point to the same image.
>
>
>
> Anyway, I think we should agree on a format at the OPNFV-project level, and
> try to use it for all our projects.
>
>
>
> So, for multiarch projects that push Docker images, we have at least 3
> options:
>
> 1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently
> used by Functest);
>
> 2. "amd64" + "x86_64" / "arm64" + "aarch64";
>
> 3. "x86_64" / "aarch64" (currently used by Storperf);
>
>
>
> Note that if the project provides a manifest, arch-specific tags are more or
> less hidden from the end-user, and a simple `docker pull
> opnfv/functest-core:latest' (or without a tag) will fetch the image for the
> current system arch automatically (amd64-latest or arm64-latest for
> Functest).
>
>
>
> Thank you, Cédric, for handling this for Functest on such short notice!
>
>
>
> BR,
>
> Alex
>
> ___
>
> 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] 答复: Re: 答复: Re: 答复: Re: About parser integration with functest usingthe lates container

[Cedric OLLIVIER]

Idem here. Thank you for the report.
It's on top of my TODO list
(Dockerfile seems fine. It could happen if rally is installed via pip
install -e after git clone)

Cédric

2017-09-20 4:58 GMT+02:00 <shang.xiaod...@zte.com.cn>:

> Hi,
>
>
> The docker image building has been failing in https://hub.docker.com/r/
> opnfv/functest-parser/builds/
> <https://hub.docker.com/r/opnfv/functest-parser/builds/,> since 7 days.
> but it is successful when build manually in my local env. Please have a
> look and fix it as soon as possible,thanks.
>
>
>
>
> Successfully installed certifi-2017.4.17 chardet-3.0.4 idna-2.5
> openstack-requirements pbr-3.1.1 pyparsing-2.2.0 requests-2.18.2
> testtools-2.3.0 urllib3-1.22 [91mfatal: destination path '/src/rally'
> already exists and is not an empty directory. [0mRemoving intermediate
> container 136d8ca27b2f
>
>
>
> 尚小冬 shangxiaodong
>
>
> IT开发工程师 IT Development Engineer
> 虚拟化四部/无线研究院/无线产品经营部 NIV Dept. IV/Wireless Product R＆D Institute/Wireless
> Product Operation Division
>
>
>
> 深圳市南山区科技南路55号
> <https://maps.google.com/?q=%E6%B7%B1%E5%9C%B3%E5%B8%82%E5%8D%97%E5%B1%B1%E5%8C%BA%E7%A7%91%E6%8A%80%E5%8D%97%E8%B7%AF55%E5%8F%B7=gmail=g>中兴通讯研发大楼33楼
>
> 33/F, R Building, ZTE Corporation Hi-tech Road South,
> Hi-tech Industrial Park Nanshan District, Shenzhen, P.R.China, 518057
> T: +86 755  F:+86 755 
> M: +86 xxx
> E: shang.xiaod...@zte.com.cn
> www.zte.com.cn
> 原始邮件
> *发件人：*尚小冬10032185
> *收件人：* <ollivier.ced...@gmail.com>;
> *抄送人：* <morgan.richo...@orange.com>; <opnfv-helpdesk@rt.
> linuxfoundation.org>;冯晓伟00125593; <opnfv-tech-discuss@lists.opnfv.org>;
> *日 期 ：*2017年09月19日 20:58
> *主 题 ：**答复: Re: 答复: Re: 答复: Re: [opnfv-tech-discuss] About parser
> integration with functest usingthe lates container*
>
>
>
> HI,
>
> It seems that the patch works. the test result of parser container is OK
> now in my local env.
>
>
>
>
>
> 尚小冬 shangxiaodong
>
>
> IT开发工程师 IT Development Engineer
> 虚拟化四部/无线研究院/无线产品经营部 NIV Dept. IV/Wireless Product R＆D Institute/Wireless
> Product Operation Division
>
>
>
> 深圳市南山区科技南路55号
> <https://maps.google.com/?q=%E6%B7%B1%E5%9C%B3%E5%B8%82%E5%8D%97%E5%B1%B1%E5%8C%BA%E7%A7%91%E6%8A%80%E5%8D%97%E8%B7%AF55%E5%8F%B7=gmail=g>中兴通讯研发大楼33楼
>
> 33/F, R Building, ZTE Corporation Hi-tech Road South,
> Hi-tech Industrial Park Nanshan District, Shenzhen, P.R.China, 518057
> T: +86 755  F:+86 755 
> M: +86 xxx
> E: shang.xiaod...@zte.com.cn
> www.zte.com.cn
>
>
>
> *发件人：* <ollivier.ced...@gmail.com>;
> *收件人：*尚小冬10032185; <morgan.richo...@orange.com>;
> *抄送人：* <opnfv-helpd...@rt.linuxfoundation.org>;冯晓伟00125593; <
> opnfv-tech-discuss@lists.opnfv.org>;
> *日 期 ：*2017年09月19日 17:40
> *主 题 ：**Re: 答复: Re: 答复: Re: [opnfv-tech-discuss] About parser integration
> with functest usingthe lates container*
>
>
> It's related to the latest ansible updates. I added a constraint.
> https://gerrit.opnfv.org/gerrit/#/c/42399/
>
> Thank you
> Cédric
>
> 2017-09-19 10:23 GMT+02:00 Cedric OLLIVIER <ollivier.ced...@gmail.com>:
>
>> Hello,
>>
>> Let's try with a newer rally version (pike) as I kept the one which we
>> have tested via the main containers.
>> It's globally a big overhead.
>>
>> Cédric
>>
>> 2017-09-19 9:17 GMT+02:00  <shang.xiaod...@zte.com.cn>:
>>
>>> Hi,ollivier.
>>>
>>> After updating your patch about Rally error, i built the functest-parsr
>>> image and tested it locally, it still doesn't pass step of creating rally
>>> deployment, the log is shown as following:
>>>
>>>
>>> 2017-09-19 07:02:50,682 - functest.ci.prepare_env - INFO -
>>> ==
>>>
>>> 2017-09-19 07:02:50,683 - functest.ci.prepare_env - INFO - Sourcing the
>>> OpenStack RC file...
>>>
>>> 2017-09-19 07:02:50,693 - functest.ci.prepare_env - INFO -
>>> ==
>>>
>>> 2017-09-19 07:02:50,693 - functest.ci.prepare_env - INFO - Creating
>>> Rally environment...
>>>
>>> Command failed, please check log for more info
>>>
>>> 2017-09-19 07:02:52.105 11 CRITICAL rally [-] Unhandled error:
>>> ImportError: cannot import name VariableManager
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally Traceback (most recent call last):
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/bin/rally", line 10,
>>> in 
>&g

Re: [opnfv-tech-discuss] 答复: Re: 答复: Re: 答复: Re: About parser integration with functest usingthe lates container

[Cedric OLLIVIER]

Great news! Thank you for testing it very quickly.

Cédric

2017-09-19 15:04 GMT+02:00 <shang.xiaod...@zte.com.cn>:

>
> HI,
>
> It seems that the patch works. the test result of parser container is OK
> now in my local env.
>
>
>
>
>
> 尚小冬 shangxiaodong
>
>
> IT开发工程师 IT Development Engineer
> 虚拟化四部/无线研究院/无线产品经营部 NIV Dept. IV/Wireless Product R＆D Institute/Wireless
> Product Operation Division
>
>
>
> 深圳市南山区科技南路55号
> <https://maps.google.com/?q=%E6%B7%B1%E5%9C%B3%E5%B8%82%E5%8D%97%E5%B1%B1%E5%8C%BA%E7%A7%91%E6%8A%80%E5%8D%97%E8%B7%AF55%E5%8F%B7=gmail=g>中兴通讯研发大楼33楼
>
> 33/F, R Building, ZTE Corporation Hi-tech Road South,
> Hi-tech Industrial Park Nanshan District, Shenzhen, P.R.China, 518057
> T: +86 755  F:+86 755 
> M: +86 xxx
> E: shang.xiaod...@zte.com.cn
> www.zte.com.cn
> 原始邮件
> *发件人：* <ollivier.ced...@gmail.com>;
> *收件人：*尚小冬10032185; <morgan.richo...@orange.com>;
> *抄送人：* <opnfv-helpd...@rt.linuxfoundation.org>;冯晓伟00125593; <
> opnfv-tech-discuss@lists.opnfv.org>;
> *日 期 ：*2017年09月19日 17:40
> *主 题 ：**Re: 答复: Re: 答复: Re: [opnfv-tech-discuss] About parser integration
> with functest usingthe lates container*
>
>
> It's related to the latest ansible updates. I added a constraint.
> https://gerrit.opnfv.org/gerrit/#/c/42399/
>
> Thank you
> Cédric
>
> 2017-09-19 10:23 GMT+02:00 Cedric OLLIVIER <ollivier.ced...@gmail.com>:
>
>> Hello,
>>
>> Let's try with a newer rally version (pike) as I kept the one which we
>> have tested via the main containers.
>> It's globally a big overhead.
>>
>> Cédric
>>
>> 2017-09-19 9:17 GMT+02:00  <shang.xiaod...@zte.com.cn>:
>>
>>> Hi,ollivier.
>>>
>>> After updating your patch about Rally error, i built the functest-parsr
>>> image and tested it locally, it still doesn't pass step of creating rally
>>> deployment, the log is shown as following:
>>>
>>>
>>> 2017-09-19 07:02:50,682 - functest.ci.prepare_env - INFO -
>>> ==
>>>
>>> 2017-09-19 07:02:50,683 - functest.ci.prepare_env - INFO - Sourcing the
>>> OpenStack RC file...
>>>
>>> 2017-09-19 07:02:50,693 - functest.ci.prepare_env - INFO -
>>> ==
>>>
>>> 2017-09-19 07:02:50,693 - functest.ci.prepare_env - INFO - Creating
>>> Rally environment...
>>>
>>> Command failed, please check log for more info
>>>
>>> 2017-09-19 07:02:52.105 11 CRITICAL rally [-] Unhandled error:
>>> ImportError: cannot import name VariableManager
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally Traceback (most recent call last):
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/bin/rally", line 10,
>>> in 
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally sys.exit(main())
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>>> "/usr/lib/python2.7/site-packages/rally/cli/main.py", line 38, in main
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally return cliutils.run(sys.argv,
>>> categories)
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>>> "/usr/lib/python2.7/site-packages/rally/cli/cliutils.py", line 661, in
>>> run
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally ret = fn(*fn_args,
>>> **fn_kwargs)
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally   File "", line
>>> 2, in destroy
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>>> "/usr/lib/python2.7/site-packages/rally/cli/envutils.py", line 68, in
>>> default_from_global
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally return f(*args, **kwargs)
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally   File "", line
>>> 2, in destroy
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>>> "/usr/lib/python2.7/site-packages/rally/plugins/__init__..py", line 42,
>>> in ensure_plugins_are_loaded
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally load()
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>>> "/usr/lib/python2.7/site-packages/rally/plugins/__init__.py", line 32,
>>> in load
>>>
>>> 2017-09-19 07:02:52.105 11 ERROR rally discover.import_modules_from_p
>>> ackage("rally.plugins")
>>>
>>> 2017-09-19 07:0

Re: [opnfv-tech-discuss] 答复: Re: 答复: Re: About parser integration with functest usingthe lates container

[Cedric OLLIVIER]

It's related to the latest ansible updates. I added a constraint.
https://gerrit.opnfv.org/gerrit/#/c/42399/

Thank you
Cédric

2017-09-19 10:23 GMT+02:00 Cedric OLLIVIER <ollivier.ced...@gmail.com>:

> Hello,
>
> Let's try with a newer rally version (pike) as I kept the one which we
> have tested via the main containers.
> It's globally a big overhead.
>
> Cédric
>
> 2017-09-19 9:17 GMT+02:00 <shang.xiaod...@zte.com.cn>:
>
>> Hi,ollivier.
>>
>> After updating your patch about Rally error, i built the functest-parsr
>> image and tested it locally, it still doesn't pass step of creating rally
>> deployment, the log is shown as following:
>>
>>
>> 2017-09-19 07:02:50,682 - functest.ci.prepare_env - INFO -
>> ==
>>
>> 2017-09-19 07:02:50,683 - functest.ci.prepare_env - INFO - Sourcing the
>> OpenStack RC file...
>>
>> 2017-09-19 07:02:50,693 - functest.ci.prepare_env - INFO -
>> ==
>>
>> 2017-09-19 07:02:50,693 - functest.ci.prepare_env - INFO - Creating Rally
>> environment...
>>
>> Command failed, please check log for more info
>>
>> 2017-09-19 07:02:52.105 11 CRITICAL rally [-] Unhandled error:
>> ImportError: cannot import name VariableManager
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally Traceback (most recent call last):
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/bin/rally", line 10,
>> in 
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally sys.exit(main())
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/rally/cli/main.py", line 38, in main
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally return cliutils.run(sys.argv,
>> categories)
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/rally/cli/cliutils.py", line 661, in
>> run
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally ret = fn(*fn_args, **fn_kwargs)
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File "", line
>> 2, in destroy
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/rally/cli/envutils.py", line 68, in
>> default_from_global
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally return f(*args, **kwargs)
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File "", line
>> 2, in destroy
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/rally/plugins/__init__.py", line 42,
>> in ensure_plugins_are_loaded
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally load()
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/rally/plugins/__init__.py", line 32,
>> in load
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally discover.import_modules_from_p
>> ackage("rally.plugins")
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/rally/common/plugin/discover.py", line
>> 60, in import_modules_from_package
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally module_name)
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 73,
>> in import_module
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally __import__(import_str)
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/rally/plugins/openstack/hook/fault_injection.py",
>> line 16, in 
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally import os_faults
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/os_faults/__init__.py", line 21, in
>> 
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally from os_faults.ansible import
>> executor
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally   File
>> "/usr/lib/python2.7/site-packages/os_faults/ansible/executor.py", line
>> 24, in 
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally from ansible.vars import
>> VariableManager
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally ImportError: cannot import name
>> VariableManager
>>
>> 2017-09-19 07:02:52.105 11 ERROR rally
>>
>> Command failed, please check log for more info
>>
>> 2017-09-19 07:02:53.633 17 CRITICAL rally [-] Unhandled error:
>> ImportError: cannot

Re: [opnfv-tech-discuss] 答复: Re: 答复: Re: About parser integration with functest usingthe lates container

[Cedric OLLIVIER]

Hello,

Let's try with a newer rally version (pike) as I kept the one which we have
tested via the main containers.
It's globally a big overhead.

Cédric

2017-09-19 9:17 GMT+02:00 :

> Hi,ollivier.
>
> After updating your patch about Rally error, i built the functest-parsr
> image and tested it locally, it still doesn't pass step of creating rally
> deployment, the log is shown as following:
>
>
> 2017-09-19 07:02:50,682 - functest.ci.prepare_env - INFO -
> ==
>
> 2017-09-19 07:02:50,683 - functest.ci.prepare_env - INFO - Sourcing the
> OpenStack RC file...
>
> 2017-09-19 07:02:50,693 - functest.ci.prepare_env - INFO -
> ==
>
> 2017-09-19 07:02:50,693 - functest.ci.prepare_env - INFO - Creating Rally
> environment...
>
> Command failed, please check log for more info
>
> 2017-09-19 07:02:52.105 11 CRITICAL rally [-] Unhandled error:
> ImportError: cannot import name VariableManager
>
> 2017-09-19 07:02:52.105 11 ERROR rally Traceback (most recent call last):
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/bin/rally", line 10,
> in 
>
> 2017-09-19 07:02:52.105 11 ERROR rally sys.exit(main())
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File 
> "/usr/lib/python2.7/site-packages/rally/cli/main.py",
> line 38, in main
>
> 2017-09-19 07:02:52.105 11 ERROR rally return cliutils.run(sys.argv,
> categories)
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/lib/python2.7/site-
> packages/rally/cli/cliutils.py", line 661, in run
>
> 2017-09-19 07:02:52.105 11 ERROR rally ret = fn(*fn_args, **fn_kwargs)
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "", line
> 2, in destroy
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/lib/python2.7/site-
> packages/rally/cli/envutils.py", line 68, in default_from_global
>
> 2017-09-19 07:02:52.105 11 ERROR rally return f(*args, **kwargs)
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "", line
> 2, in destroy
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/lib/python2.7/site-
> packages/rally/plugins/__init__.py", line 42, in ensure_plugins_are_loaded
>
> 2017-09-19 07:02:52.105 11 ERROR rally load()
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/lib/python2.7/site-
> packages/rally/plugins/__init__.py", line 32, in load
>
> 2017-09-19 07:02:52.105 11 ERROR rally discover.import_modules_from_
> package("rally.plugins")
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/lib/python2.7/site-
> packages/rally/common/plugin/discover.py", line 60, in
> import_modules_from_package
>
> 2017-09-19 07:02:52.105 11 ERROR rally module_name)
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/lib/python2.7/site-
> packages/oslo_utils/importutils.py", line 73, in import_module
>
> 2017-09-19 07:02:52.105 11 ERROR rally __import__(import_str)
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/lib/python2.7/site-
> packages/rally/plugins/openstack/hook/fault_injection.py", line 16, in
> 
>
> 2017-09-19 07:02:52.105 11 ERROR rally import os_faults
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/lib/python2.7/site-
> packages/os_faults/__init__.py", line 21, in 
>
> 2017-09-19 07:02:52.105 11 ERROR rally from os_faults.ansible import
> executor
>
> 2017-09-19 07:02:52.105 11 ERROR rally   File "/usr/lib/python2.7/site-
> packages/os_faults/ansible/executor.py", line 24, in 
>
> 2017-09-19 07:02:52.105 11 ERROR rally from ansible.vars import
> VariableManager
>
> 2017-09-19 07:02:52.105 11 ERROR rally ImportError: cannot import name
> VariableManager
>
> 2017-09-19 07:02:52.105 11 ERROR rally
>
> Command failed, please check log for more info
>
> 2017-09-19 07:02:53.633 17 CRITICAL rally [-] Unhandled error:
> ImportError: cannot import name VariableManager
>
> 2017-09-19 07:02:53.633 17 ERROR rally Traceback (most recent call last):
>
> 2017-09-19 07:02:53.633 17 ERROR rally   File "/usr/bin/rally", line 10,
> in 
>
> 2017-09-19 07:02:53.633 17 ERROR rally sys.exit(main())
>
> 2017-09-19 07:02:53.633 17 ERROR rally   File 
> "/usr/lib/python2.7/site-packages/rally/cli/main.py",
> line 38, in main
>
> 2017-09-19 07:02:53.633 17 ERROR rally return cliutils.run(sys.argv,
> categories)
>
> 2017-09-19 07:02:53.633 17 ERROR rally   File "/usr/lib/python2.7/site-
> packages/rally/cli/cliutils.py", line 661, in run
>
> 2017-09-19 07:02:53.633 17 ERROR rally ret = fn(*fn_args, **fn_kwargs)
>
> 2017-09-19 07:02:53.633 17 ERROR rally   File "", line 2,
> in create
>
> 2017-09-19 07:02:53.633 17 ERROR rally   File "/usr/lib/python2.7/site-
> packages/rally/plugins/__init__.py", line 42, in ensure_plugins_are_loaded
>
> 2017-09-19 07:02:53.633 17 ERROR rally load()
>
> 2017-09-19 07:02:53.633 17 ERROR rally   File "/usr/lib/python2.7/site-
> packages/rally/plugins/__init__.py", line 32, in load
>
> 2017-09-19 07:02:53.633 17 ERROR rally discover.import_modules_from_
> 

Re: [opnfv-tech-discuss] StorPerf ARM images available

[Cedric OLLIVIER]

Hello Mark,

It should be noticed that Docker automated builds forbid ARG defined
before FROM and variables in FROM too.
But it's fine if they are built via releng (thanks to last Docker versions)

Great job!
Cédric

2017-09-15 17:38 GMT+02:00 Beierl, Mark :
> Hello,
>
> It is with immense pleasure that I would like to announce that with a great
> community effort, StorPerf now has published its Docker images for aarch64
> as well as x86_64.  This is done using the same docker file, and passing the
> Architecture in as a build argument.  I want to thank the following people
> for their help:
>
> Alex Avadanii for his tireless and flexible hours collaborating on how to
> change the Releng JJBs and scripts so that we don't interfere with the
> existing docker jobs.
> Fatih Degirmenci, Trevor Bramwell and Aric Gardener for being so responsive
> when a Releng merge did have an unintended side effect and helping out.
> Shrenik Jain for laying the groundwork in StorPerf container breakdown and
> migration to Alpine that made this change possible.
>
> I am sure there are others who I forgot to mention, as this was truly a
> cross project, community effort.  To the whole OPNFV community, I extend my
> thanks.  This was a significant accomplishment and I am grateful to all!  My
> next goal is to get StorPerf daily running on ARM/Fuel :)
>
> https://hub.docker.com/r/opnfv/storperf-master/tags/
> https://hub.docker.com/r/opnfv/storperf-httpfrontend/tags/
> https://hub.docker.com/r/opnfv/storperf-graphite/tags/
> https://hub.docker.com/r/opnfv/storperf-swaggerui/tags/
> https://hub.docker.com/r/opnfv/storperf-reporting/tags/
>
> 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] 答复: Re: About parser integration with functest usingthe lates container

[Cedric OLLIVIER]

Badly we must install tempest even here as it's automically configured when
preparing env.
I will work during F dev cycle to split functest core/ci and testcases
hosted in Functest.

The issue is simply due to OpenStack upper-constraints. I must override
them to add -e (then it will be installed in /src).
That's what functest-core does.

Cédric

2017-09-14 14:43 GMT+02:00 :

>
> Yes, the image size increase about 100MB.
>
> Maybe it's a solution to install tempest directly when building parser
> container.
>
> But i wonder why it's neccessary to call tempest in parser container?
>
>
> 尚小冬 shangxiaodong
>
>
> IT开发工程师 IT Development Engineer
> 虚拟化四部/无线研究院/无线产品经营部 NIV Dept. IV/Wireless Product R＆D Institute/Wireless
> Product Operation Division
>
>
>
> 深圳市南山区科技南路55号
> 中兴通讯研发大楼33楼
>
> 33/F, R Building, ZTE Corporation Hi-tech Road South,
> Hi-tech Industrial Park Nanshan District, Shenzhen, P.R.China, 518057
> T: +86 755  F:+86 755 
> M: +86 xxx
> E: shang.xiaod...@zte.com.cn
> www.zte.com.cn
> 原始邮件
> *发件人：* ;
> *收件人：*尚小冬10032185;
> *抄送人：* ;冯晓伟00125593; <
> opnfv-tech-discuss@lists.opnfv.org>;
> *日 期 ：*2017年09月14日 20:25
> *主 题 ：**Re: [opnfv-tech-discuss] About parser integration with functest
> usingthe lates container*
>
>
> Hello,
>
> No you shouldn't inherit from opnfv/functest-core. Otherwise you're
> mixing requirements from stable/ocata and stable/pike.
> It could also increase the size of the container.
>
> I am working on it this afternoon.
>
> Cédric
>
> 2017-09-14 12:55 GMT+02:00  :
> > HI, ollivier.
> >
> > Using the latest container, parser and functest have been integrated
> > successfully in my local enviroment, and the following
> is a functest related
> > issue:
> >
> >
> > When start the parser container:
> >
> >
> > | Plugin base  | Name
> > | Namespace | Title
> > |
> >
> > +--+--
> --+---+-
> +
> >
> > | Chart| Lines
> > | default   | Display results as generic chart with lines.
> > |
> >
> > | Chart| Pie
> > | default   | Display results as pie, calculate
> average values for additive
> > data. |
> >
> > 2017-09-14 10:32:48,469 - functest.ci.prepare_env - INFO - Installing
> > tempest from existing repo...
> >
> > 2017-09-14 10:32:51.581 46 INFO rally.api [-] Creating verifier
> > 'opnfv-tempest'.
> >
> > Source path '/src/tempest' is not valid.
> >
> > 2017-09-14 10:32:52,047 - functest.utils.functest_utils
> - ERROR - Problem
> > while installing Tempest.
> >
> > 2017-09-14 10:32:52,047 - functest.ci.prepare_env -
> ERROR - Problem while
> > installing Tempest.
> >
> >
> > With the help from serena, we switch the base image from alpine to
> > functest-core in parser dockerfile, then it works and
> the parser testcase
> > runs successfully.
> >
> >   FROM alpine:3.6 -> FROM opnfv/functest-core
> >
> >
> > Please recheck it, thanks.
> >
> >
> > 尚小冬 shangxiaodong
> >
> >
> >
> > ___
> > 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] About parser integration with functest using the lates container

[Cedric OLLIVIER]

Hello,

No you shouldn't inherit from opnfv/functest-core. Otherwise you're
mixing requirements from stable/ocata and stable/pike.
It could also increase the size of the container.

I am working on it this afternoon.

Cédric

2017-09-14 12:55 GMT+02:00  :
> HI, ollivier.
>
> Using the latest container, parser and functest have been integrated
> successfully in my local enviroment, and the following is a functest related
> issue:
>
>
> When start the parser container:
>
>
> | Plugin base  | Name
> | Namespace | Title
> |
>
> +--++---+-+
>
> | Chart| Lines
> | default   | Display results as generic chart with lines.
> |
>
> | Chart| Pie
> | default   | Display results as pie, calculate average values for additive
> data. |
>
> 2017-09-14 10:32:48,469 - functest.ci.prepare_env - INFO - Installing
> tempest from existing repo...
>
> 2017-09-14 10:32:51.581 46 INFO rally.api [-] Creating verifier
> 'opnfv-tempest'.
>
> Source path '/src/tempest' is not valid.
>
> 2017-09-14 10:32:52,047 - functest.utils.functest_utils - ERROR - Problem
> while installing Tempest.
>
> 2017-09-14 10:32:52,047 - functest.ci.prepare_env - ERROR - Problem while
> installing Tempest.
>
>
> With the help from serena, we switch the base image from alpine to
> functest-core in parser dockerfile, then it works and the parser testcase
> runs successfully.
>
>   FROM alpine:3.6 -> FROM opnfv/functest-core
>
>
> Please recheck it, thanks.
>
>
> 尚小冬 shangxiaodong
>
>
>
> ___
> 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-project-leads] [release][euphrates] stable branch window

[Cedric OLLIVIER]

Alec,

No, I'm not part of the Doctor team.
I simply fix the requirements (and then packages) over the different
OPNFV projects which are integrated inside Functest.

From Functest point of view, the requirements are key compared to the
versioning as we are currently using git (instead of pypi) to install
the packages.
Stable branches (and tag in case of releng) are currently enough to
build Functest stable docker images.
https://git.opnfv.org/functest/tree/upper-constraints.txt
https://git.opnfv.org/functest/tree/docker/core/Dockerfile

You're right. I had to switch to 2017.9.0 instead of 5 due to the
previous pbr conditions in Doctor setup.cfg which I have mainly
defined in the other packages.
I agree with tagging OPNFV release with 5.0.0 and then with removing
version in setup.cfg.
I set 5 in setup.cfg as default value but it can be safely removed/modified.

If we select 2017.9.0, it can raise minor issues for projects which
would want to release their packages in between official OPNFV
releases.
As the packages are not published in pypi, I don't think it's
currently relevant.

Cédric

2017-09-12 8:54 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>:
> Hi Cedric,
>
>
>
> Inline…
>
>
>
>
>
> From: Cedric OLLIVIER <ollivier.ced...@gmail.com>
> Date: Monday, September 11, 2017 at 10:31 PM
> To: "Alec Hothan (ahothan)" <ahot...@cisco.com>
> Cc: "Beierl, Mark" <mark.bei...@dell.com>, Alexandru Avadanii
> <alexandru.avada...@enea.com>, opnfv-project-leads
> <opnfv-project-le...@lists.opnfv.org>, "opnfv-tech-discuss@lists.opnfv.org"
> <opnfv-tech-discuss@lists.opnfv.org>, Fatih Degirmenci
> <fatih.degirme...@ericsson.com>
> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates]
> stable branch window
>
>
>
> Alec,
>
>
>
> My comment simply highlighted a possible issue.
>
> You can simply trigger it via Doctor by setting version = 5 in its setup.cfg
>
>
>
>
>
> I precise doctor offers 2015.1.0 as tag.
>
> https://git.opnfv.org/doctor/tag/?h=2015.1.0
>
>
>
> Then you can simply call python setup.py install or pip install .
>
> ValueError: git history requires a target version of
>
> pbr.version.SemanticVersion(2015.1.1), but target version is
>
> pbr.version.SemanticVersion(5.0.0)
>
>
>
> As releng/modules version is 5.0, I think the same updated tag (eg
>
> 2017.09) would break the rules.
>
>
>
> [Alec]
>
> OK I think I understand what you mean now.
>
> I see that the doctor git repo has quite a rocky tagging history, starting
> with 2015.1.0, then using danube.3.0 notation and now having to change again
> on possibly a 5.0.0 notation.
>
> I also see that setup.cfg currently sets the metadata version to 2017.9.0
>
> I don’t want to pick on doctor project but this really shows the downside of
> trying to unify an overarching integration project release (in our case
> OPNFV release) and its constituents versioning.
>
>
>
> As a side note, I personally prefer to omit the version field in setup.cfg
> and let pbr derive the version directly from the git tagging - but of course
> this requires you can tag your versions with “2017.9.0” which indeed would
> conflict with an hypothetical OPNFV “5.0.0” tag (pbr would not know which
> one to pick since both are semver syntax compliant).
>
>
>
>
>
>
>
>
>
> When cleaning the requirements of OPNFV projects, I simply set 5 as
>
> default version value (all projects are free to modify that) as
>
> euphrates is an incorrect python package version.
>
> https://wiki.opnfv.org/display/functest/Requirements+management
>
>
>
> [Alec]
>
> How to manage dependencies across packages is an interesting and challenging
> problem but I’d like to focus on the OPNFV project versioning first – and
> hopefully find a good solution that works for everybody.
>
>
>
>
>
> By the way, I think we can hardly compare OPNFV and FD.io as the last
>
> one is java based (packaging and distributions are done via mvn).
>
> [Alec]
>
> Sorry I was merely pointing to the analogy of using a year and month as
> versioning.
>
>
>
> But it's fine to compare with OpenStack projects as we are now
>
> following quite their package rules.
>
>
>
> [Alec]
>
> I’m not familiar yet on who does what, are you part of the doctor team?
>
> Would you agree to a solution that allows projects to tag their repo using
> their own semver versioning (such as 2017.9.0) and tag OPNFV releases using
> a prefix such as opnfv-5.0.0 (which will be conveniently ignored by pbr)?
>
> That is what I am trying to get to with all these emails ;-)
>

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Cedric OLLIVIER]

Alec,

My comment simply highlighted a possible issue.
You can simply trigger it via Doctor by setting version = 5 in its setup.cfg

I precise doctor offers 2015.1.0 as tag.
https://git.opnfv.org/doctor/tag/?h=2015.1.0

Then you can simply call python setup.py install or pip install .
ValueError: git history requires a target version of
pbr.version.SemanticVersion(2015.1.1), but target version is
pbr.version.SemanticVersion(5.0.0)

As releng/modules version is 5.0, I think the same updated tag (eg
2017.09) would break the rules.

When cleaning the requirements of OPNFV projects, I simply set 5 as
default version value (all projects are free to modify that) as
euphrates is an incorrect python package version.
https://wiki.opnfv.org/display/functest/Requirements+management

By the way, I think we can hardly compare OPNFV and FD.io as the last
one is java based (packaging and distributions are done via mvn).
But it's fine to compare with OpenStack projects as we are now
following quite their package rules.

Cédric

2017-09-11 23:53 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>:
> Cedric,
>
>
>
> How to tag is a completely separate discussion and I’m actually very glad
> that you bring this up along with pbr ;-)
>
>
>
> But I’m curious why you bring up the “2017.09” example as it is not a semver
> tag and would not be recognized by pbr?
>
> For example, FD.io/VPP uses year/month to tag their releases (e.g. 17.04)
>
> OpenStack does not impose any tagging on constituent projects (that would
> cause a revolt from component owners I can guarantee that)
>
> Semver tagging has been so far always reserved to individual component
> tagging.
>
> I am currently feeling pretty uneasy with the looming E release and its
> tagging implication which could put all of us in a hole.
>
> If we don’t do anything, we will see “5.0.0” tags on every repo in OPNFV and
> that should be a cause for concern for every project owner.
>
> I am sorry to repeat myself but I don’t think everyone has grasped yet the
> implication that has on how projects should version their code and how they
> can manage their artifacts starting from Euphrates.
>
>
>
> Let me clarify again, I am not questioning the lock-step versioning that is
> in effect in Euphrates but a far more damaging decision would be to tie the
> OPNFV release version to semver tagging and hijack semver tagging for the
> purpose of OPNFV releases versioning (e.g. slap tags like “5.0.0” on every
> repo).
>
>
>
> I would prefer if we could keep an OPNFV prefix for the tags. That was
> perfect pre E release (dabube-1.0.0…). For Euphrates, if we do not want to
> see the release name (understandably as it is redundant to the release
> version) at least keep an opnfv prefix in front of it for the tags (e.g.
> “opnfv-5.0.0”) so that project owners can version independently of the OPNFV
> release using semver compatible tags (like virtually every other open source
> project out there)
>
>
>
>
>
> Regards,
>
>
>
>   Alec
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: Cedric OLLIVIER <ollivier.ced...@gmail.com>
> Date: Monday, September 11, 2017 at 1:38 PM
> To: "Alec Hothan (ahothan)" <ahot...@cisco.com>
> Cc: "Beierl, Mark" <mark.bei...@dell.com>, Alexandru Avadanii
> <alexandru.avada...@enea.com>, opnfv-project-leads
> <opnfv-project-le...@lists.opnfv.org>, "opnfv-tech-discuss@lists.opnfv.org"
> <opnfv-tech-discuss@lists.opnfv.org>, Fatih Degirmenci
> <fatih.degirme...@ericsson.com>
>
>
> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates]
> stable branch window
>
>
>
> I think it could hurt only if you select 2017.09 as tag.
>
> I precise pbr compares version (eg 5.0) and tags then it would break
>
> the python package.
>
>
>
> Cédric
>
>
>
> 2017-09-11 17:20 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>:
>
>
>
>
>
> Fatih mentioned that changes in F would be in a different repo after the
>
> reorganization of the releng repo – so branching releng would technically
>
> not be needed for Euphrates?
>
>
>
> In any case, it does not hurt to tag (I was surprised tags were not used
>
> more often in OPNFV repos to mark internal versions…)
>
>
>
>
>
>
>
>
>
>
>
> Alec
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: <opnfv-project-leads-boun...@lists.opnfv.org> on behalf of "Beierl,
>
> Mark" <mark.bei...@dell.com>
>
> Date: Monday, September 11, 2017 at 6:31 AM
>
> To: Alexandru Avadanii <alexandru.

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Cedric OLLIVIER]

I think it could hurt only if you select 2017.09 as tag.
I precise pbr compares version (eg 5.0) and tags then it would break
the python package.

Cédric

2017-09-11 17:20 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>:
>
>
> Fatih mentioned that changes in F would be in a different repo after the
> reorganization of the releng repo – so branching releng would technically
> not be needed for Euphrates?
>
> In any case, it does not hurt to tag (I was surprised tags were not used
> more often in OPNFV repos to mark internal versions…)
>
>
>
>
>
>Alec
>
>
>
>
>
>
>
>
>
> From: <opnfv-project-leads-boun...@lists.opnfv.org> on behalf of "Beierl,
> Mark" <mark.bei...@dell.com>
> Date: Monday, September 11, 2017 at 6:31 AM
> To: Alexandru Avadanii <alexandru.avada...@enea.com>
> Cc: opnfv-project-leads <opnfv-project-le...@lists.opnfv.org>, Cedric
> OLLIVIER <ollivier.ced...@gmail.com>, "opnfv-tech-discuss@lists.opnfv.org"
> <opnfv-tech-discuss@lists.opnfv.org>
> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates]
> stable branch window
>
>
>
> +1.  Would not want changes to the opnfv-docker.sh script for F to impact
> building of E maintenance releases.
>
>
>
> 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 Sep 11, 2017, at 09:26, Alexandru Avadanii <alexandru.avada...@enea.com>
> wrote:
>
>
>
> Hi,
> How about tagging releng, without branching it?
>
> Alex
>
>
> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-
> boun...@lists.opnfv.org] On Behalf Of Cedric OLLIVIER
> Sent: Monday, September 11, 2017 7:51 AM
> To: David McBride
> Cc: opnfv-project-leads; TECH-DISCUSS OPNFV
> Subject: Re: [opnfv-tech-discuss] [release][euphrates] stable branch window
>
> Hello,
>
> Could you please confirm that no stable/euphrates branch will be created for
> releng again?
> Else we are obliged to select a specific git commit id to build our Functest
> stable containers which is not the best way.
> I precise Functest depends on the opnfv python package which is hosted by
> releng (https://git.opnfv.org/releng/tree/modules).
>
> Cédric
>
> 2017-09-09 1:24 GMT+02:00 David McBride <dmcbr...@linuxfoundation.org>:
>
> Reminder...
>
> The stable branch window closes as of MS7, one week from today, on
> September
> 15 at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready
> to branch.  Aric will branch any projects that have not already been
> branched on Sept 15.
>
> Let me know if you have any questions.
>
> David
>
> On Tue, Aug 29, 2017 at 3:23 PM, David McBride
> <dmcbr...@linuxfoundation.org> wrote:
>
>
> Team,
>
> As you know, MS6 was this past Friday, Aug 25.  In addition to the
> requirements associated with MS6, this milestone also marks the
> opening of the stable branch window, which subsequently ends with MS7 on
>
> Sept 15.
>
>
> This means that PTLs may request to branch their project any time
> before Sept 15.  Note that I erroneously told the release meeting
> this morning that PTLs may create their own branch.  That's not the
> case.  Instead, please contact Aric (copied) and request that he create the
>
> branch for you.
>
>
> Also, as a reminder, we have changed the version number format as of
> the Euphrates release.
>
> 5.0.0 - Euphrates initial release version
> 5.1.0 - Euphrates SR1
> 5.2.0 - Euphrates SR2
>
> Let me know if you have any questions.
>
> David
>
> --
> David McBride
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>
>
>
>
>
> --
> David McBride
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> 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] [release][euphrates] stable branch window

[Cedric OLLIVIER]

Hello,

Could you please confirm that no stable/euphrates branch will be
created for releng again?
Else we are obliged to select a specific git commit id to build our
Functest stable containers which is not the best way.
I precise Functest depends on the opnfv python package which is hosted
by releng (https://git.opnfv.org/releng/tree/modules).

Cédric

2017-09-09 1:24 GMT+02:00 David McBride :
> Reminder...
>
> The stable branch window closes as of MS7, one week from today, on September
> 15 at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready to
> branch.  Aric will branch any projects that have not already been branched
> on Sept 15.
>
> Let me know if you have any questions.
>
> David
>
> On Tue, Aug 29, 2017 at 3:23 PM, David McBride
>  wrote:
>>
>> Team,
>>
>> As you know, MS6 was this past Friday, Aug 25.  In addition to the
>> requirements associated with MS6, this milestone also marks the opening of
>> the stable branch window, which subsequently ends with MS7 on Sept 15.
>>
>> This means that PTLs may request to branch their project any time before
>> Sept 15.  Note that I erroneously told the release meeting this morning that
>> PTLs may create their own branch.  That's not the case.  Instead, please
>> contact Aric (copied) and request that he create the branch for you.
>>
>> Also, as a reminder, we have changed the version number format as of the
>> Euphrates release.
>>
>> 5.0.0 - Euphrates initial release version
>> 5.1.0 - Euphrates SR1
>> 5.2.0 - Euphrates SR2
>>
>> Let me know if you have any questions.
>>
>> David
>>
>> --
>> David McBride
>> Release Manager, OPNFV
>> Mobile: +1.805.276.8018
>> Email/Google Talk: dmcbr...@linuxfoundation.org
>> Skype: davidjmcbride1
>> IRC: dmcbride
>
>
>
>
> --
> David McBride
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
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

[Cedric OLLIVIER]

I'm sorry I don't understand the point of git clone.
Here we simply install Functest via the python package.
Pip install does a local copy because it's not published in PyPI yet and
then removes it after installing the package.

Why should we clone again the repository?

Cédric

2017-07-10 3:10 GMT+02:00 Beierl, Mark <mark.bei...@dell.com>:

> Why should we avoid copy?  Why do a git clone of the existing git clone?
> Almost every dockerfile example I have seen uses copy, not a second got
> checkout of the same code.
>
> Regards,
> Mark
>
> *Mark Beierl*
> SW System Sr Principal Engineer
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Jul 9, 2017, at 21:00, Cedric OLLIVIER <ollivier.ced...@gmail.com>
> wrote:
>
> No we cannot (parent directory) and we should mostly avoid copying files
> (except for configurations).
>
> For instance, you could have a look to https://gerrit.opnfv.org/
> gerrit/#/c/36963/.
> All Dockerfiles simply download Alpine packages, python packages (Functest
> + its dependencies) and upper constraints files.
> testcases.yaml is copied from host as it differs between our containers
> (smoke, healthcheck...).
>
> Cédric
>
>
>
> 2017-07-10 1:25 GMT+02:00 Beierl, Mark <mark.bei...@dell.com>:
>
>> My only concern is for dockerfiles that do a "COPY . /home" in them. That
>> means all the code would be located under the docker directory.
>>
>> I suppose multiple ../ paths can be used instead.
>>
>> Regards,
>> Mark
>>
>> *Mark Beierl*
>> SW System Sr Principal Engineer
>> *Dell **EMC* | Office of the CTO
>> mobile +1 613 314 8106 <1-613-314-8106>
>> mark.bei...@dell.com
>>
>> On Jul 9, 2017, at 19:03, Julien <julien...@gmail.com> wrote:
>>
>> Hi Cédric,
>>
>> Patch in  https://gerrit.opnfv.org/gerrit/#/c/36963/ is exact what I
>> mean. Let's collect the opinions from the releng team.
>>
>> Julien
>>
>>
>>
>> Cedric OLLIVIER <ollivier.ced...@gmail.com>于2017年7月10日周一 上午4:15写道：
>>
>>> Hello,
>>>
>>> Please see https://gerrit.opnfv.org/gerrit/#/c/36963/ which introduces
>>> several containers for Functest too.
>>> I think the tree conforms with the previous requirements.
>>>
>>> Automating builds on Docker Hub is a good solution too.
>>>
>>> Cédric
>>>
>>> 2017-07-09 12:10 GMT+02:00 Julien <julien...@gmail.com>:
>>>
>>>> Hi Jose,
>>>>
>>>> According to the current implementation, current script only support
>>>> one Dockerfile, my personal suggestion is:
>>>> 1. list all the sub-directory which contains "Dockerfile"
>>>> 2. build for each sub-directory fetched in #1
>>>> 3. for the names, in the top directory using the project name, in the
>>>> sub-directory using: project_name-sub_directory_name
>>>> not too much changes for current script and easy for project to manage.
>>>>
>>>> /Julien
>>>>
>>>> Beierl, Mark <mark.bei...@dell.com>于2017年7月7日周五 下午11:35写道：
>>>>
>>>>> Hello,
>>>>>
>>>>> Having looked over the docker-hub build service, I also think this
>>>>> might be the better approach.  Less code for us to maintain, and the merge
>>>>> job from OPNFV Jenkins can use the web hook to remotely trigger the job on
>>>>> docker-hub.
>>>>>
>>>>> Who has the opnfv credentials for docker-hub, and the credentials for
>>>>> the GitHub mirror that can set this up?  Is that the LF Helpdesk?
>>>>>
>>>>> Regards,
>>>>> Mark
>>>>>
>>>>> *Mark Beierl*
>>>>> SW System Sr Principal Engineer
>>>>> *Dell **EMC* | Office of the CTO
>>>>> mobile +1 613 314 8106 <1-613-314-8106>
>>>>> mark.bei...@dell.com
>>>>>
>>>>> On Jul 7, 2017, at 11:01, Xuan Jia <jason.jiax...@gmail.com> wrote:
>>>>>
>>>>> +1 Using build service from docker-hub
>>>>>
>>>>>
>>>>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) <
>>>>> zhangyujun+...@gmail.com> wrote:
>>>>>
>>>>>> Does anybody consider using the build service from docker-hub[1] ?
>>>>>>
>>>>>> It supports multiple Dockerfile from same repository and

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

[Cedric OLLIVIER]

No we cannot (parent directory) and we should mostly avoid copying files
(except for configurations).

For instance, you could have a look to
https://gerrit.opnfv.org/gerrit/#/c/36963/.
All Dockerfiles simply download Alpine packages, python packages (Functest
+ its dependencies) and upper constraints files.
testcases.yaml is copied from host as it differs between our containers
(smoke, healthcheck...).

Cédric



2017-07-10 1:25 GMT+02:00 Beierl, Mark <mark.bei...@dell.com>:

> My only concern is for dockerfiles that do a "COPY . /home" in them. That
> means all the code would be located under the docker directory.
>
> I suppose multiple ../ paths can be used instead.
>
> Regards,
> Mark
>
> *Mark Beierl*
> SW System Sr Principal Engineer
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Jul 9, 2017, at 19:03, Julien <julien...@gmail.com> wrote:
>
> Hi Cédric,
>
> Patch in  https://gerrit.opnfv.org/gerrit/#/c/36963/ is exact what I
> mean. Let's collect the opinions from the releng team.
>
> Julien
>
>
>
> Cedric OLLIVIER <ollivier.ced...@gmail.com>于2017年7月10日周一 上午4:15写道：
>
>> Hello,
>>
>> Please see https://gerrit.opnfv.org/gerrit/#/c/36963/ which introduces
>> several containers for Functest too.
>> I think the tree conforms with the previous requirements.
>>
>> Automating builds on Docker Hub is a good solution too.
>>
>> Cédric
>>
>> 2017-07-09 12:10 GMT+02:00 Julien <julien...@gmail.com>:
>>
>>> Hi Jose,
>>>
>>> According to the current implementation, current script only support one
>>> Dockerfile, my personal suggestion is:
>>> 1. list all the sub-directory which contains "Dockerfile"
>>> 2. build for each sub-directory fetched in #1
>>> 3. for the names, in the top directory using the project name, in the
>>> sub-directory using: project_name-sub_directory_name
>>> not too much changes for current script and easy for project to manage.
>>>
>>> /Julien
>>>
>>> Beierl, Mark <mark.bei...@dell.com>于2017年7月7日周五 下午11:35写道：
>>>
>>>> Hello,
>>>>
>>>> Having looked over the docker-hub build service, I also think this
>>>> might be the better approach.  Less code for us to maintain, and the merge
>>>> job from OPNFV Jenkins can use the web hook to remotely trigger the job on
>>>> docker-hub.
>>>>
>>>> Who has the opnfv credentials for docker-hub, and the credentials for
>>>> the GitHub mirror that can set this up?  Is that the LF Helpdesk?
>>>>
>>>> Regards,
>>>> Mark
>>>>
>>>> *Mark Beierl*
>>>> SW System Sr Principal Engineer
>>>> *Dell **EMC* | Office of the CTO
>>>> mobile +1 613 314 8106 <1-613-314-8106>
>>>> mark.bei...@dell.com
>>>>
>>>> On Jul 7, 2017, at 11:01, Xuan Jia <jason.jiax...@gmail.com> wrote:
>>>>
>>>> +1 Using build service from docker-hub
>>>>
>>>>
>>>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) <
>>>> 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 <
>>>>> 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]
>>>>>> *Sent:* Thursday, July 06, 2017 16:18 PM
>>>>>> *To:* opnfv-tech-discuss@lists.opnfv.org
>>>>>> *Cc:* Julien <julien...@gmail.com>; Fatih Degirmenci <
>>>>>> fatih.degirme...@ericsson.com>; Jose Lausuch <

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

[Cedric OLLIVIER]

Hello,

Please see https://gerrit.opnfv.org/gerrit/#/c/36963/ which introduces
several containers for Functest too.
I think the tree conforms with the previous requirements.

Automating builds on Docker Hub is a good solution too.

Cédric

2017-07-09 12:10 GMT+02:00 Julien :

> Hi Jose,
>
> According to the current implementation, current script only support one
> Dockerfile, my personal suggestion is:
> 1. list all the sub-directory which contains "Dockerfile"
> 2. build for each sub-directory fetched in #1
> 3. for the names, in the top directory using the project name, in the
> sub-directory using: project_name-sub_directory_name
> not too much changes for current script and easy for project to manage.
>
> /Julien
>
> Beierl, Mark 于2017年7月7日周五 下午11:35写道：
>
>> Hello,
>>
>> Having looked over the docker-hub build service, I also think this might
>> be the better approach.  Less code for us to maintain, and the merge job
>> from OPNFV Jenkins can use the web hook to remotely trigger the job on
>> docker-hub.
>>
>> Who has the opnfv credentials for docker-hub, and the credentials for the
>> GitHub mirror that can set this up?  Is that the LF Helpdesk?
>>
>> Regards,
>> Mark
>>
>> *Mark Beierl*
>> SW System Sr Principal Engineer
>> *Dell **EMC* | Office of the CTO
>> mobile +1 613 314 8106 <1-613-314-8106>
>> mark.bei...@dell.com
>>
>> On Jul 7, 2017, at 11:01, Xuan Jia  wrote:
>>
>> +1 Using build service from docker-hub
>>
>>
>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) <
>> 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 
>>> 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]
 *Sent:* Thursday, July 06, 2017 16:18 PM
 *To:* opnfv-tech-discuss@lists.opnfv.org
 *Cc:* Julien ; Fatih Degirmenci <
 fatih.degirme...@ericsson.com>; 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 <1-613-314-8106>

 *mark.bei...@dell.com *



 On Jun 24, 2017, at 04:05, Jose Lausuch 
 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  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 于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  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,