[opnfv-tech-discuss] [anteater] build log for anteator

[Yujun Zhang (ZTE)]

I notices a warning on license header in
https://gerrit.opnfv.org/gerrit/#/c/36839/

[image: Screen Shot 2017-07-12 at 11.03.55 AM.png]

However the build log is not posted. It's OK for now since the failure is
clear enough. But it would be nice to have the build log as well as other
CI jobs.

--
Yujun

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

Re: [opnfv-tech-discuss] [OPNFV] Draft support for presentation to TSC

[Yuyang (Gabriel)]

Hi Dave,



Sorry to jump into the discussion here! In the proposal, if I may clarify, "N-1 
release" means at least from N-1.1.0 and not after N-1.3.0.

So we are not dealing things out of date.

Also, stress testing against "N-1 release" does not necessarily mean there will 
be unconstrained backports.

Even when we do fixed, we should follow the OPNFV stable branch policy 
(https://wiki.opnfv.org/display/SWREL/Stablebranch).

So generally, we are not attempt to break the upstream first policy here.



On the contrary, stress testing will bring lots of benefit to OPNFV, for more 
details please refer to Morgan's email:

https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-July/017025.html



As your last concern about "rolling release of tip-of master", I think it does 
not totally contradict with the proposal.

Since we are not try to force doing backport, issues found by the stress tests 
could be fixed in the master or follow the stable branch policy to do 
appropriate fixes. It will depend on different projects.

So it is generally not equal to managing another branch. Our initial intention 
is to do the stress tests over a relatively stable version so that we could 
focus on the issues that only occurs when heave system loads are raised.

If master could be relatively stable in a period, it would be the best we do 
the stress testing more earlier.



My two cents, correct me if there is any misleading messages!



Best,

Gabriel





-Original Message-
From: Dave Neary [mailto:dne...@redhat.com]
Sent: Wednesday, July 12, 2017 12:00 AM
To: morgan.richo...@orange.com; Yuyang (Gabriel); Brattain, Ross B; Gaoliang 
(kubi); Jose Lausuch; Cooper, Trevor; MORTON, ALFRED C (AL); 
mark.bei...@emc.com; Fatih Degirmenci; Donald Hunter (donaldh); Yujun Zhang
Cc: test...@lists.opnfv.org; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [OPNFV] Draft support for presentation to TSC



Hi Morgan,



Coming back to this old thread after the TSC discussion today.



My feeling is that the argument that we have to do stress testing on the

N-1 release because the installers are not available early in the cycle is an 
argument for changing the release process (or converting it to a continuous 
delivery model where the tip of master is always more or less releasable).



Based on the conversation earlier, I think that we should not be attempting to 
backport fixes at all in OPNFV if we can avoid it - if operators and vendors 
want to fix issues that we have identified and fixed in the tip of master, then 
the back-porting is their job, not OPNFV's - and I do not think that this is a 
sufficient reason to break the "gold standard" of no fork, upstream first which 
has been the OPNFV mantra since its creation.



If we can get towards a rolling release of tip-of-master in OPNFV, I think that 
this is what provides the greatest value to feature and testing projects, 
operators, and vendors. Features will be tested as integrated upstream, 
operators should get a higher cadence for new features, and in general we will 
not be expending extra effort in a community project back-porting fixes or 
features to N-1, or maintaining patches against N-1 to fix resiliency issues.



Thanks,

Dave.



On 06/23/2017 02:39 AM, 
morgan.richo...@orange.com wrote:

> Hi

>

> as discussed yesterday during the weekly meeting, I prepared a slide

> deck for the discussion with the TSC (I tried to summarize our

> discussion and hope it reflects the wiki pages we created on the topic).

>

> Feel free to comment/complete/criticize/modify

> @Gabriel: would you be OK to present the beginning? (stress tests

> created for Danube + wiki page and email thread)

>

> I already booked a slot for the meeting next week

> https://wiki.opnfv.org/display/meetings/TSC

> the agenda looks already pretty busy not sure we will have time, we

> will see

>

> /Morgan

>

>

>

> __

> ___

>

>

> Ce message et ses pieces jointes peuvent contenir des informations

> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,

> exploites ou copies sans autorisation. Si vous avez recu ce message

> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi

> que les pieces jointes. Les messages electroniques etant susceptibles

> d'alteration, Orange decline toute responsabilite si ce message a ete

> altere, deforme ou falsifie. Merci.

>

> This message and its attachments may contain confidential or

> privileged information that may be protected by law; they should not

> be distributed, used or copied without authorisation.

> If you have received this email in error, please notify the sender and

> delete this message and its attachments.

> As emails may be altered, Orange is not liable for messages that have

> been modified, changed or falsified.

Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

[joehuang]

Thank you Goutham for your great contribution in Kingbird/multi-site 
development!

Best Regards
Chaoyi Huang (joehuang)

From: Goutham Pratapa [pratapagout...@gmail.com]
Sent: 12 July 2017 9:30
To: joehuang
Cc: Chigang (Justin); opnfv-tech-discuss
Subject: Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

Hi Joe,

It was a great experience working with you in Kingbird & Multisite

I wish you all luck and all the best for the future goals.


Thanks
Goutham Pratapa.

On Wed, Jul 12, 2017 at 5:36 AM, joehuang 
> wrote:
Hello, Justin,

Thank you for providing help and resources to multi-site. Don't hesitate to 
talk to me and add me in the reviewer list if you want to integrate Tricircle.

Best Regards
Chaoyi Huang (joehuang)

From: Chigang (Justin)
Sent: 11 July 2017 19:29
To: joehuang
Cc: opnfv-tech-discuss
Subject: 答复: [opnfv-tech-discuss] [multisite]stepping down from PTL

Hi Joe,

I was impressed by multisite Demo in OPNFV summit, that brings a high 
availability VNF solution across multiple cloud. Thanks your contribution for 
multisite.

Regards
Justin

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 代表 Zhipeng Huang
发送时间: 2017年7月10日 14:14
收件人: joehuang
抄送: opnfv-tech-discuss
主题: Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

Thanks Joe,

You have lead an incredible effort in building the multisite project and it was 
a great journey for people like us who were among the first participants.



On Mon, Jul 10, 2017 at 9:04 AM, joehuang 
> wrote:

Hello,



Nice to work with you in Multi-site and OPNFV from 2015, there are still lots 
of interesting staff to do in multi-site area, just as what we discussed in the 
thread "multi-site next 
step?"(https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-June/016733.html).



Unfortunately, I am not able to continue multi-site PTL role, due to my time is 
occupied mostly by non-open source activities. I would like to say thanks to 
all of you, and step down from multi-site PTL.



Just as what we discussed in the thread "multi-site next step?", the inital 
goal of multi-site project is to identify and fill the gaps in OpenStack to 
fullfill multi-site requirements, most of them have been covered by respective 
projects, especially we have solution to support mission critical application 
high availability in multi-site (across multiple OpenStack cloud) through the 
help of Tricircle project, though the integration in OPNFV can be done by 
succedded contributions.



PTL candidates are welcome to continue the project, if there is no PTL 
candidate stepping up in two weeks, it's fine to ask for the termination of 
multi-site project, becasue the project has reached its initial goal.



New project or installer projects can do the integration and test for various 
multi-site requirements, I'll try my best to review multi-site relative patches 
if needed, especially if you need help for Tricircle integration, or you can 
ask for help from Tricircle team in OpenStack community.




Best Regards
Chaoyi Huang (joehuang)

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



--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

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




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

Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

[Goutham Pratapa]

Hi Joe,

It was a great experience working with you in Kingbird & Multisite

I wish you all luck and all the best for the future goals.


Thanks
Goutham Pratapa.

On Wed, Jul 12, 2017 at 5:36 AM, joehuang  wrote:

> Hello, Justin,
>
> Thank you for providing help and resources to multi-site. Don't hesitate
> to talk to me and add me in the reviewer list if you want to integrate
> Tricircle.
>
> Best Regards
> Chaoyi Huang (joehuang)
> --
> *From:* Chigang (Justin)
> *Sent:* 11 July 2017 19:29
> *To:* joehuang
> *Cc:* opnfv-tech-discuss
> *Subject:* 答复: [opnfv-tech-discuss] [multisite]stepping down from PTL
>
> Hi Joe,
>
>
>
> I was impressed by multisite Demo in OPNFV summit, that brings a high
> availability VNF solution across multiple cloud. Thanks your contribution
> for multisite.
>
>
>
> Regards
>
> Justin
>
>
>
> *发件人:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *代表 *Zhipeng Huang
> *发送时间:* 2017年7月10日 14:14
> *收件人:* joehuang
> *抄送:* opnfv-tech-discuss
> *主题:* Re: [opnfv-tech-discuss] [multisite]stepping down from PTL
>
>
>
> Thanks Joe,
>
>
>
> You have lead an incredible effort in building the multisite project and
> it was a great journey for people like us who were among the first
> participants.
>
>
>
>
>
>
>
> On Mon, Jul 10, 2017 at 9:04 AM, joehuang  wrote:
>
> Hello,
>
>
>
> Nice to work with you in Multi-site and OPNFV from 2015, there are still
> lots of interesting staff to do in multi-site area, just as what we
> discussed in the thread "multi-site next step?"(https://lists.opnfv.
> org/pipermail/opnfv-tech-discuss/2017-June/016733.html).
>
>
>
> Unfortunately, I am not able to continue multi-site PTL role, due to my
> time is occupied mostly by non-open source activities. I would like to say
> thanks to all of you, and step down from multi-site PTL.
>
>
>
> Just as what we discussed in the thread "multi-site next step?", the
> inital goal of multi-site project is to identify and fill the gaps in
> OpenStack to fullfill multi-site requirements, most of them have been
> covered by respective projects, especially we have solution to support
> mission critical application high availability in multi-site (across
> multiple OpenStack cloud) through the help of Tricircle project, though the
> integration in OPNFV can be done by succedded contributions.
>
>
>
> PTL candidates are welcome to continue the project, if there is no PTL
> candidate stepping up in two weeks, it's fine to ask for the termination of
> multi-site project, becasue the project has reached its initial goal.
>
>
>
> New project or installer projects can do the integration and test for
> various multi-site requirements, I'll try my best to review multi-site
> relative patches if needed, especially if you need help for Tricircle
> integration, or you can ask for help from Tricircle team in OpenStack
> community.
>
>
>
>
>
> Best Regards
>
> Chaoyi Huang (joehuang)
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
>
>
> --
>
> Zhipeng (Howard) Huang
>
>
>
> Standard Engineer
>
> IT Standard & Patent/IT Product Line
>
> Huawei Technologies Co,. Ltd
>
> Email: huangzhip...@huawei.com
>
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
>
>
> (Previous)
>
> Research Assistant
>
> Mobile Ad-Hoc Network Lab, Calit2
>
> University of California, Irvine
>
> Email: zhipe...@uci.edu
>
> Office: Calit2 Building Room 2402
>
>
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>


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

Re: [opnfv-tech-discuss] reply: [dovetail] weekly meeting agenda

[Tianhongbo]

Hi Trevor:

Yes, I fully agree with you.

How about the opinions from others?

If no objection, I suggest to add one more hour for this dovetail meeting.

Best regards

hongbo

From: Cooper, Trevor [mailto:trevor.coo...@intel.com]
Sent: 2017年7月12日 4:11
To: Tianhongbo ; Wenjing Chu 
; TECH-DISCUSS OPNFV 

Subject: RE: reply: [dovetail] weekly meeting agenda

Hi Hongbo

I think we agreed that getting the CVP addendum in shape is top priority and 
it’s clear from comments received so far that we have some ways to go. I think 
it would help to spend time discussing the comments on a call and I am pretty 
sure this will take more than an hour. Can we extend this week’s call to 2 hrs 
or setup an additional slot. I think are all feeling the urgency to make faster 
progress on this.

Thanks

Trevor





From: Tianhongbo [mailto:hongbo.tianhon...@huawei.com]
Sent: Monday, July 10, 2017 5:53 PM
To: Cooper, Trevor >; 
Wenjing Chu >; 
TECH-DISCUSS OPNFV 
>
Subject: reply: [dovetail] weekly meeting agenda

Hi Trevor:

Thanks for your effort. That helps a lot.

I will put that on the agenda.

Best regards

hongbo

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Cooper, Trevor
发送时间: 2017年7月11日 6:53
收件人: Wenjing Chu; TECH-DISCUSS OPNFV
主题: Re: [opnfv-tech-discuss] [dovetail] weekly meeting agenda

I have made a list of our recent discussion topics and things we are actively 
working on to make sure we are not neglecting or losing topics. If agreed we 
can use this to prioritize weekly meeting agenda and track things that need 
attention but are not currently progressing. Please review and add what I have 
missed. Do you think this is useful to update weekly?

https://wiki.opnfv.org/display/dovetail/Open+Topics+for+Dovetail

/Trevor



From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Wenjing Chu
Sent: Wednesday, June 28, 2017 7:59 PM
To: TECH-DISCUSS OPNFV 
>
Subject: [opnfv-tech-discuss] [dovetail] weekly meeting agenda

Hi Dovetailers

I propose we cover the most urgent topics this week:

-  Review the feedbacks from tsc members

-  Examine remaining work items required for first release and decide 
how to close them

-  Quick new status updates
For the first two topics, can everyone do homework ahead of time so we can hope 
to actually produce a good list?
Any other suggestions? Would also be good to share time availability info 
during the summer months when it happens to be crunch time for us.

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

Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

[joehuang]

Hi, Tianwei,

Thank you Tianwwei very much, it's great journey for us to bring the VNF high 
availability across multiple cloud in OPNFV Beijing Summit.

Best Regards
Chaoyi Huang (joehuang)

From: wutianwei
Sent: 11 July 2017 19:11
To: joehuang
Subject: 答复: [opnfv-tech-discuss] [multisite]stepping down from PTL

Thanks Joe,

 it was a great experience with you in Beijing opnfv summit. I learnt many 
things from you.

Best Regard
Tianwei Wu

发件人: opnfv-tech-discuss-boun...@lists.opnfv.org 
[opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 joehuang [joehu...@huawei.com]
发送时间: 2017年7月10日 16:45
收件人: Zhipeng Huang
抄送: opnfv-tech-discuss
主题: Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

Thank you Howard. You helped a lot in mutli-site project, especially in the 
creation of the project.

Best Regards
Chaoyi Huang (joehuang)

From: Zhipeng Huang [zhipengh...@gmail.com]
Sent: 10 July 2017 14:13
To: joehuang
Cc: opnfv-tech-discuss
Subject: Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

Thanks Joe,

You have lead an incredible effort in building the multisite project and it was 
a great journey for people like us who were among the first participants.



On Mon, Jul 10, 2017 at 9:04 AM, joehuang 
> wrote:

Hello,



Nice to work with you in Multi-site and OPNFV from 2015, there are still lots 
of interesting staff to do in multi-site area, just as what we discussed in the 
thread "multi-site next 
step?"(https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-June/016733.html).



Unfortunately, I am not able to continue multi-site PTL role, due to my time is 
occupied mostly by non-open source activities. I would like to say thanks to 
all of you, and step down from multi-site PTL.



Just as what we discussed in the thread "multi-site next step?", the inital 
goal of multi-site project is to identify and fill the gaps in OpenStack to 
fullfill multi-site requirements, most of them have been covered by respective 
projects, especially we have solution to support mission critical application 
high availability in multi-site (across multiple OpenStack cloud) through the 
help of Tricircle project, though the integration in OPNFV can be done by 
succedded contributions.



PTL candidates are welcome to continue the project, if there is no PTL 
candidate stepping up in two weeks, it's fine to ask for the termination of 
multi-site project, becasue the project has reached its initial goal.



New project or installer projects can do the integration and test for various 
multi-site requirements, I'll try my best to review multi-site relative patches 
if needed, especially if you need help for Tricircle integration, or you can 
ask for help from Tricircle team in OpenStack community.





Best Regards
Chaoyi Huang (joehuang)

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




--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

[joehuang]

Hello, Justin,

Thank you for providing help and resources to multi-site. Don't hesitate to 
talk to me and add me in the reviewer list if you want to integrate Tricircle.

Best Regards
Chaoyi Huang (joehuang)

From: Chigang (Justin)
Sent: 11 July 2017 19:29
To: joehuang
Cc: opnfv-tech-discuss
Subject: 答复: [opnfv-tech-discuss] [multisite]stepping down from PTL

Hi Joe,

I was impressed by multisite Demo in OPNFV summit, that brings a high 
availability VNF solution across multiple cloud. Thanks your contribution for 
multisite.

Regards
Justin

发件人: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Zhipeng Huang
发送时间: 2017年7月10日 14:14
收件人: joehuang
抄送: opnfv-tech-discuss
主题: Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

Thanks Joe,

You have lead an incredible effort in building the multisite project and it was 
a great journey for people like us who were among the first participants.



On Mon, Jul 10, 2017 at 9:04 AM, joehuang 
> wrote:

Hello,



Nice to work with you in Multi-site and OPNFV from 2015, there are still lots 
of interesting staff to do in multi-site area, just as what we discussed in the 
thread "multi-site next 
step?"(https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-June/016733.html).



Unfortunately, I am not able to continue multi-site PTL role, due to my time is 
occupied mostly by non-open source activities. I would like to say thanks to 
all of you, and step down from multi-site PTL.



Just as what we discussed in the thread "multi-site next step?", the inital 
goal of multi-site project is to identify and fill the gaps in OpenStack to 
fullfill multi-site requirements, most of them have been covered by respective 
projects, especially we have solution to support mission critical application 
high availability in multi-site (across multiple OpenStack cloud) through the 
help of Tricircle project, though the integration in OPNFV can be done by 
succedded contributions.



PTL candidates are welcome to continue the project, if there is no PTL 
candidate stepping up in two weeks, it's fine to ask for the termination of 
multi-site project, becasue the project has reached its initial goal.



New project or installer projects can do the integration and test for various 
multi-site requirements, I'll try my best to review multi-site relative patches 
if needed, especially if you need help for Tricircle integration, or you can 
ask for help from Tricircle team in OpenStack community.




Best Regards
Chaoyi Huang (joehuang)

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



--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Invitation: [ovn4nfv] project meeting @ Fri Jul 14, 2017 9am - 10am (PDT) (opnfv-tech-discuss@lists.opnfv.org)

[Vikram Dham]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20170714T16Z
DTEND:20170714T17Z
DTSTAMP:20170711T232536Z
ORGANIZER;CN=Vikram Dham:mailto:vikramd...@gmail.com
UID:smjo4hqc2u3qs3ke08d65sl...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Vikram Dham;X-NUM-GUESTS=0:mailto:vikramd...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=prakash.ramchand...@huawei.com;X-NUM-GUESTS=0:mailto:prakash.ramchandra
 n...@huawei.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=opnfv-tech-discuss@lists.opnfv.org;X-NUM-GUESTS=0:mailto:opnfv-tech
 -disc...@lists.opnfv.org
CREATED:20170711T231824Z
DESCRIPTION:ovn4nfv project meeting \n\nAgenda:\n\n 1. Agenda bashing\n 2. 
 ovn vs ovs scenarios by Trinath Somanchi (NXP)\n 3. Installer support updat
 e for own scenarios\n   3.b. JOID - (k8s-lxd) Narinder Gupta (Canonical)\n 
   3.c. Apex - (os-sdn-noha) Dan Radez (Red Hat)\n   3.d. Compass - (k8x-doc
 ker) Justin/Yifie (Huawei)\n 4. Testing for E release\n \n\nIRC - #ovn4nfv-
 meeting\nWhen Fri\, Jul 14\, 2017 9:00 AM - 10:00 AM PDT \n\nPlease join my
  meeting from your computer\, tablet or smartphone. \nhttps://global.gotome
 eting.com/join/203616245 \n\nYou can also dial in using your phone. \nUnite
 d States (Toll Free): 1 866 899 4679 \nUnited States: +1 (571) 317-3116 \n\
 nAccess Code: 203-616-245 \n\nMore phone numbers \nAustralia: +61 2 8355 10
 38 \nAustria: +43 1 2530 22500 \nBelgium: +32 28 93 7002 \nCanada: +1 (647)
  497-9373 \nDenmark: +45 32 72 03 69 \nFinland: +358 923 17 0556 \nFrance: 
 +33 170 950 590 \nGermany: +49 692 5736 7300 \nIreland: +353 15 360 756 \nI
 taly: +39 0 230 57 81 80 \nNetherlands: +31 207 941 375 \nNew Zealand: +64 
 9 913 2226 \nNorway: +47 21 93 37 37 \nSpain: +34 932 75 1230 \nSweden: +46
  853 527 818 \nSwitzerland: +41 225 4599 60 \nUnited Kingdom: +44 330 221 0
 097 \n\nJoining from a video-conferencing room or system? \nDial: 67.217.95
 .2##203616245 \nCisco devices: 203616245@67.217.95.2 \n\nFirst GoToMeeting?
  Try a test session: https://care.citrixonline.com/g2m/getready \nView your
  event at https://www.google.com/calendar/event?action=VIEW=c21qbzRocWM
 ydTNxczNrZTA4ZDY1c2wxcjggb3BuZnYtdGVjaC1kaXNjdXNzQGxpc3RzLm9wbmZ2Lm9yZw
 =MjAjdmlrcmFtZGhhbUBnbWFpbC5jb21lMjQ2ODA4NWYxNWIxNGMzOGZiYWI4ODJiMGY5M2VmOD
 k2ODg3YjFm=America/Los_Angeles=en.
LAST-MODIFIED:20170711T232536Z
LOCATION:https://global.gotomeeting.com/join/203616245
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:[ovn4nfv] project meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


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

Re: [opnfv-tech-discuss] [dovetail] Use-cases for Dovetail Danube Release

[Cooper, Trevor]

Hi Wenjing

Yes its new thread.

Re. EUAG I am aware of the Pain Points Wiki page however it's not clear to me 
how this is feeding initial scope of CVP. The CVP page 
https://wiki.opnfv.org/pages/viewpage.action?pageId=11700688 does not have any 
feedback yet from what I can see ... any idea on how we can facilitate getting 
some feedback?

I take your point about complexity of those applications and common patterns 
... but what was the suggestion for an alternative "use-case approach"? I 
assumed it meant using specific use-models e.g. VOLTE to derive platform 
capabilities that we should include in scope of tests ... this also seems to be 
what you are saying but I don't think that analysis has been done in Dovetail 
yet, correct?

/Trevor

From: Wenjing Chu [mailto:wenjing@huawei.com]
Sent: Tuesday, July 11, 2017 11:16 AM
To: Cooper, Trevor ; opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [opnfv-tech-discuss] [dovetail] Use-cases for Dovetail Danube 
Release

Hi Trevor

I'm not sure if your email is a follow-up of a previous message or not. I 
couldn't find another email so I'm assuming this is a new thread. Let me know 
if I'm mistaken.

First of all, we did receive detailed feedbacks from EUAG as far back as Feb 
and most recently during the Summit in June. So additional feedbacks are 
welcome but we are not waiting/gating on anything from EUAG at this time. As 
part of action items during the Summit when CVP was discussed with the EUAG, we 
agreed to set up a wiki in EUAG for tracking additional feedbacks. It's under 
the EUAG wiki page and just follow the link for cvp feedbacks.

I personally use the term "use case approach" in the context of CVP to mean 
that for a given SUT, we identify common use patterns, and develop automated 
test cases to exercise such patterns. I agree with Bryan's comment in 
yesterday's c call that applications like VOLTE and vCPE are too complex for 
our purposes - it won't be easy to separate issues of the application's 
implementation from the issues of SUT (the latter is what we wish to identify). 
A better approach is abstract the common design patterns out of a complex 
application, and develop test cases around those common patterns that have more 
general applicability to all similar applications.

For example, vPING is a common pattern of "2 virtual machines with virtual 
network connectivity between them". This can be seen as the simplest use 
pattern. Another use pattern may be multiple virtual machines load balancing to 
provide a common service. vCPE, if narrowly defined, can be a pattern of secure 
gateway between two network domains. I personally think this space between 
simplicity of a vPING to a well understood gateway function may be the most 
productive area we can focus on.

Many of OPNFV projects can contribute these use pattern test cases, by 
abstracting and by clarifying what the test intention is, in some cases. This 
is a great area of 'low hanging fruit' during the E release cycle.

Regards
Wenjing

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Cooper, Trevor
Sent: Monday, July 10, 2017 4:50 PM
To: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [dovetail] Use-cases for Dovetail Danube Release

My notes on the "use-case approach" with VOLTE and vCPE ... capture that EUAG 
supports the approach and will get back with some suggestions. Are we still 
waiting on the EUAG to get back? If yes what are our expectations for receiving 
guidance? Can we try to define the "use-case approach" better ... e.g. meld 
this with our current approach to say identify gaps/deficiencies with the test 
cases? What approach should we take for identifying and organizing VOLTE and 
vCPE capabilities and their relevant test-cases?

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

Re: [opnfv-tech-discuss] [barometer] TST008 analysis

[MORTON, ALFRED C (AL)]

Hi Maryam,

Thanks a million for your review! There are fairly
clear actions for TST008 (which was approved, and has
entered the maintenance mode with the rest of the
Release 2 specifications, so we can propose changes).

Following our discussion and agreements in the barometer
meeting today, I'll respond to your questions below
(from memory - I was in motion, so feel free to edit...).

I've started to edit TST008,
Al

From: Tahhan, Maryam [mailto:maryam.tah...@intel.com]
Sent: Tuesday, July 11, 2017 9:05 AM
To: MORTON, ALFRED C (AL)
Cc: opnfv-tech-discuss@lists.opnfv.org; Power, Damien; Mcmahon, Tony B
Subject: [barometer] TST008 analysis


Hi Al
I've gone through TST 008 and have a few questions:



Q. Parameters to metrics, are these intended to be sent as part of the metric 
being reported, or can they be sent as information themselves, link status 
being the example I would pick on :)

[ACM]

The Parameters should be reported when collection begins,

or when their values change. Both TST008 and our metrics

requirements wiki page list the metric Name, Scope, and

Units of measurement as required aspects to communicate

(because they give the full context to the measurements).

Scope came-up on the call briefly, and this is probably

more critical for the Processor and Memory metrics.



Q. Do we need to report both usage and utilization for CPU? Or is one enough? 
"On the completion of a measurement interval, the measured times shall be 
summed and the usage and utilization shall be reported. "

[ACM]

In this last sentence of section 6.7, "and" becomes "and/or" .



Q. "Interface Speed: the nominal frequency of the physical interface bit clock 
in Hz, which governs the rate that the interface operates. Virtual interfaces 
may not have a meaningful value for this parameter. " in Hz? Or in Mb/s?

[ACM]

Let's simplify this one.

We'll use bits per second, and allow an appropriate

prefix multiplier (M for Mega, etc.), in section 7.3.



I can't find a way of retrieving the interface speed in HZ, should it be HZ or 
Mb/s

sudo ethtool enp134s0 | grep Speed

Speed: 1000Mb/s



cat /sys/class/net/enp134s0/speed

1000



Q. "Interface: the name of a single interface where communication metrics are 
monitored " --> what about uuid or id - some interfaces aren't identified by 
name

[ACM]

Good catch, this can be clarified as "name (or other identifier)".

I added: "...and shall be unique within the Scope of measurement"



Q. "Interface Status: the operational state of the interface indicating 
readiness for use, usually expressed as "up"or "down" " --> is the parameter to 
be sent with the metric? Interface status would be interesting of its own right?

[ACM]

Since this is a Parameter, it represents the desired admin state

which has been configured up or down, and should be

reported/communicated like other parameters (at the start or after change).



Q. " here are four fundamental metrics of memory utilization:

1) Memory buffered

2) Memory Cached

3) Memory free

4) Memory Slab

These four metrics comprise the total of used 
memory. Therefore, the sum of these metrics can be subtracted from the Total 
Memory to obtain the current value of free memory"



Memory free - is a typo I think with the sentence that follows.

[ACM]

It turns out that this confusing info was supposed to represent this:

mem_used = mem_total - (mem_free + mem_buffered + mem_cached + mem_slab_total);

from https://github.com/collectd/collectd/blob/master/src/memory.c#L325



So, These four metrics comprise the total of used memory

is the sentence in error (free is not used),

and should say,

These four metrics comprise memory unoccupied by *user processes*?

(not sure about *user processes*, maybe another term would be better)

The second sentence should describe the calculation of *used memory*.





Q.   "The following parameters shall be supported for these four 
metrics:

* Measurement time: the point in time when the values were read 
(time and date).

* Total Memory: the Random Access Memory, RAM, available to the 
compute node measured

* Swap space: the configured memory available for processes to 
share through swapping "



Would total memory not be a stat on its own?

[ACM]

I took the position that Total was configured and not measured.

but

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-proc-meminfo.html

seems to indicate that MemTotal is measured,

and gives the definition as total RAM excluding

 a number of reserved bits and the kernel binary code.



But these definitions need to work for both physical and virtual

compute environments. It's physical in the end, but the virtual

view is a view of shared resources...



Other notes:

*   

Re: [opnfv-tech-discuss] [opnfvdocs] OPNFV doc workflow for E release

[Alec Hothan (ahothan)]

Hi Sofia,

Can you provide a quick status on the documentation workflow for the E release. 
Is it same as D  release or was that changed?
I’m asking in the context of a new project which already has a lot of 
readthedoc-ready content and was wondering how to cutover to the OPNFV doc.

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] [StorPerf] Weekly Meeting

[Beierl, Mark]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Eastern Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Beierl, Mark":MAILTO:mark.bei...@emc.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
DESCRIPTION;LANGUAGE=en-US:When: Wednesday\, July 12\, 2017 10:00 AM-11:00 
 AM. (UTC-05:00) Eastern Time (US & Canada)\nWhere: https://meet.emc.com/ma
 rk.beierl/69MEZFLU\n\n*~*~*~*~*~*~*~*~*~*\n\nThis is an invite to the next
  StorPerf weekly meeting.\n\nAgenda:\n\nhttps://wiki.opnfv.org/display/mee
 tings/StorPerf+2017-07-12+Meeting+Notes\n\n...
 ..
 \nhttps://meet.emc.com/mark.beierl/69MEZFL
 U\n\nJoin by Phone\nUnited States International direct: +1 857 2074204\nFi
 nd a local number \n\nConfer
 ence ID: 58108948 | Video ID: 25978949\n\nFirst online meeting? \n
 ..
 ...\n\n\n\n\n
SUMMARY;LANGUAGE=en-US:[StorPerf] Weekly Meeting
DTSTART;TZID=Eastern Standard Time:20170712T10
DTEND;TZID=Eastern Standard Time:20170712T11
UID:F2206C56-CE54-4067-9825-DC27C2812763
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20170711T202010Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:https://meet.emc.com/mark.beierl/69MEZFLU
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:2115459921
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT5M
END:VALARM
END:VEVENT
END:VCALENDAR
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] reply: [dovetail] weekly meeting agenda

[Cooper, Trevor]

Hi Hongbo

I think we agreed that getting the CVP addendum in shape is top priority and 
it’s clear from comments received so far that we have some ways to go. I think 
it would help to spend time discussing the comments on a call and I am pretty 
sure this will take more than an hour. Can we extend this week’s call to 2 hrs 
or setup an additional slot. I think are all feeling the urgency to make faster 
progress on this.

Thanks

Trevor





From: Tianhongbo [mailto:hongbo.tianhon...@huawei.com]
Sent: Monday, July 10, 2017 5:53 PM
To: Cooper, Trevor ; Wenjing Chu 
; TECH-DISCUSS OPNFV 

Subject: reply: [dovetail] weekly meeting agenda

Hi Trevor:

Thanks for your effort. That helps a lot.

I will put that on the agenda.

Best regards

hongbo

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Cooper, Trevor
发送时间: 2017年7月11日 6:53
收件人: Wenjing Chu; TECH-DISCUSS OPNFV
主题: Re: [opnfv-tech-discuss] [dovetail] weekly meeting agenda

I have made a list of our recent discussion topics and things we are actively 
working on to make sure we are not neglecting or losing topics. If agreed we 
can use this to prioritize weekly meeting agenda and track things that need 
attention but are not currently progressing. Please review and add what I have 
missed. Do you think this is useful to update weekly?

https://wiki.opnfv.org/display/dovetail/Open+Topics+for+Dovetail

/Trevor



From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Wenjing Chu
Sent: Wednesday, June 28, 2017 7:59 PM
To: TECH-DISCUSS OPNFV 
>
Subject: [opnfv-tech-discuss] [dovetail] weekly meeting agenda

Hi Dovetailers

I propose we cover the most urgent topics this week:

-  Review the feedbacks from tsc members

-  Examine remaining work items required for first release and decide 
how to close them

-  Quick new status updates
For the first two topics, can everyone do homework ahead of time so we can hope 
to actually produce a good list?
Any other suggestions? Would also be good to share time availability info 
during the summer months when it happens to be crunch time for us.

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

Re: [opnfv-tech-discuss] [dovetail] Use-cases for Dovetail Danube Release

[Wenjing Chu]

Hi Trevor

I'm not sure if your email is a follow-up of a previous message or not. I 
couldn't find another email so I'm assuming this is a new thread. Let me know 
if I'm mistaken.

First of all, we did receive detailed feedbacks from EUAG as far back as Feb 
and most recently during the Summit in June. So additional feedbacks are 
welcome but we are not waiting/gating on anything from EUAG at this time. As 
part of action items during the Summit when CVP was discussed with the EUAG, we 
agreed to set up a wiki in EUAG for tracking additional feedbacks. It's under 
the EUAG wiki page and just follow the link for cvp feedbacks.

I personally use the term "use case approach" in the context of CVP to mean 
that for a given SUT, we identify common use patterns, and develop automated 
test cases to exercise such patterns. I agree with Bryan's comment in 
yesterday's c call that applications like VOLTE and vCPE are too complex for 
our purposes - it won't be easy to separate issues of the application's 
implementation from the issues of SUT (the latter is what we wish to identify). 
A better approach is abstract the common design patterns out of a complex 
application, and develop test cases around those common patterns that have more 
general applicability to all similar applications.

For example, vPING is a common pattern of "2 virtual machines with virtual 
network connectivity between them". This can be seen as the simplest use 
pattern. Another use pattern may be multiple virtual machines load balancing to 
provide a common service. vCPE, if narrowly defined, can be a pattern of secure 
gateway between two network domains. I personally think this space between 
simplicity of a vPING to a well understood gateway function may be the most 
productive area we can focus on.

Many of OPNFV projects can contribute these use pattern test cases, by 
abstracting and by clarifying what the test intention is, in some cases. This 
is a great area of 'low hanging fruit' during the E release cycle.

Regards
Wenjing

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Cooper, Trevor
Sent: Monday, July 10, 2017 4:50 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [dovetail] Use-cases for Dovetail Danube Release

My notes on the "use-case approach" with VOLTE and vCPE ... capture that EUAG 
supports the approach and will get back with some suggestions. Are we still 
waiting on the EUAG to get back? If yes what are our expectations for receiving 
guidance? Can we try to define the "use-case approach" better ... e.g. meld 
this with our current approach to say identify gaps/deficiencies with the test 
cases? What approach should we take for identifying and organizing VOLTE and 
vCPE capabilities and their relevant test-cases?

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

Re: [opnfv-tech-discuss] [release][danube] Danube release status for TSC call July 11

[David McBride]

Summary of scenarios that currently fail to deploy

*Scenario*

*Installer*

*Released with D1/ D2*

*Notes*

os-nosdn-kvm-noha

Apex

yes

os-odl_l2-sfc-noha

Apex

no

withdrawn

os-nosdn-fdio-noha

Apex

yes

trozet says that fail is related to installer

os-onos-nofeature-ha

Apex

no

withdrawn

os-nosdn-nofeature-ha

Compass

yes

failure tied to build server

os-odl_l2-nofeature-ha

Compass

yes

failure tied to build server

os-odl_l3-nofeature-ha

Compass

yes

failure tied to build server

os-onos-sfc-ha

Compass

no

failure tied to build server

os-nosdn-openo-ha

Compass

yes

failure tied to build server

os-nosdn-nofeature-noha

JOID

yes

failure tied to build server

k8-nosdn-nofeature-noha

JOID

yes

failure tied to build server

k8-nosdn-lb-noha

JOID

yes

failure tied to build server


All of the scenarios that were previously released in D1 or D2 have valid
explanations for why they are currently failing that are unrelated to the
scenario, itself, with one exception: os-nosdn-kvm-noha.  So, I would say
that is the one regression from previous releases in Danube.

Yes, the plan is to release every scenario that has been previously
released, as well as any scenarios that are new, as of D3.

David

On Tue, Jul 11, 2017 at 1:00 AM, Ulrich Kleber 
wrote:

> Hi David,
>
> thank you for this summary.
>
>
>
> However, I have a question about the scenarios failing to deploy now.
> Could you summarize, which of those scenarios were part of Danube 1.0 or
> 2.0?
>
> Our goal was to include 1.0 and 2.0 contents also in 3.0. What is your
> proposal?
>
>
>
> Cheers,
>
> Uli
>
>
>
>
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *David McBride
> *Sent:* Tuesday, 11 July, 2017 02:12
> *To:* TSC OPNFV
> *Cc:* TECH-DISCUSS OPNFV
> *Subject:* [opnfv-tech-discuss] [release][danube] Danube release status
> for TSC call July 11
>
>
>
> TSC members,
>
>
>
> Please find slides attached with Danube 3 summary.  Reminder that the
> release is scheduled for Friday, July 14.  We will be discussing status and
> voting on the release on the call tomorrow (July 11).
>
>
>
> David
>
>
>
> --
>
> *David McBride*
>
> Release Manager, OPNFV
>
> Mobile: +1.805.276.8018
>
> Email/Google Talk: dmcbr...@linuxfoundation.org
>
> Skype: davidjmcbride1
>
> IRC: dmcbride
>



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

Re: [opnfv-tech-discuss] OPNFV Danube SFC physical scenario deployment doubts

[Manuel Buil]

Hi Andres,

I reply inline.

Regards,
Manuel

On Tue, 2017-07-11 at 16:00 +0200,
andres.sanchez.ra...@estudiant.upc.edu wrote:
> Manuel,
> 
> Thank you for your proposal it has been very helpful, i have
> already  
> deployed the Openstack environment and it looks good, it passed the  
> health check made by fuel, i also deployed a VM and connected to it  
> successfully and have ODL up and running.
> 
> I am having a problem to make the functest because i am doing it  
> inside a workstation that does not have access to the Openstack  
> management network, it is located inside the public network. I am
> not  
> sure which is the best way to proceed:
> 
> A) if I give the workstation an IP address inside the management  
> network will it work? or maybe IP tables are configured to reject
> that.

iptables should be ok, you need to make sure that the route is correct.

Let me understand this, you have three physical machines:

1 - Runs OpenStack
2 - Runs FUEL
3 - Workstation where you want to run functest
??

> B) Do the functest from my Fuel master (it is a PC that only runs
> Fuel).
> 
> I read the posts in your blog that you sent Rosa and found them  
> extremely interesting, it has been very educative. I have some  
> questions regarding that scenario that you built (If you have no  
> problem answering them):
> - What OS and application do you use for deploying the SF? do you use
> OVS?

We have a qcow2 image that we use as SF: http://artifacts.opnfv.org/sfc
/images/sfc_nsh_danube.qcow2

That one has a tool which reads nsh packets and pushes them back to the
SFF. Try to understand the different tests we have in the SFC-OPNFV
repo and you will see how we do that. For example this one:

https://github.com/opnfv/sfc/blob/master/sfc/tests/functest/sfc_one_cha
in_two_service_functions.py

Which is explained here:

https://wiki.opnfv.org/display/sfc/Functest+SFC-ODL+-+Test+2

> - Once you deploy a SFC does tacker pushes the configuration to ODL  
> via REST? or do you configure the SFF and SF manually on ODL?

tacker pushes all the config, you don't have to mess with ODL Rest API

> - Do you have any more tutorials or videos similar?

We did one last year:
https://www.youtube.com/watch?v=QknJMX83q1k=345s

And maybe these ones help you understand things better:
https://www.youtube.com/watch?v=b2xjpllQ7d8
https://www.youtube.com/watch?v=KKKqvXFRJZ0


> - I have read that OVS+NSH implementation that you use is developed
> by  
> OPNFV and is not mainstream in OVS. Is it possible to use that
> OVS+NSH  
> on a physical device running openWRT?

The patch which provides NSH to OVS is not only used in OPNFV.
Hopefully, it will get upstreamed by OVS2.8 (~September).

I am not sure if the patch is supported by that architecture. Please
ask his maintainer: yi.y.y...@intel.com

> 
> I ask all this questions because we are interested in setting up a  
> similar scenario!
> 
> Thank you in advance for your response.
> 
> Best regards,
> 
> Quoting "Manuel Buil" :
> 
> > 
> > Hi Andres,
> > 
> > Please find my answers below.
> > 
> > Try to run the environment which is supported and after that you
> > can
> > add stuff like ceilometer. Having a base that works should be your
> > target right now, later you can add stuff to that base.
> > 
> > Regards,
> > Manuel
> > 
> > On Mon, 2017-07-10 at 13:51 +0200,
> > andres.sanchez.ra...@estudiant.upc.edu wrote:
> > > 
> > > Hello Manuel,
> > > 
> > > Thank you for your quick response! you are right that scenario is
> > > not  
> > > supported sorry for that! I am trying to set up a NFV
> > > environment  
> > > (using SFC) with the ability to monitor cloud resources using  
> > > Openstack APIs, and according to what i have been able to read  
> > > ceilometer provides that information!
> > > 
> > > Ok since no SFC chains are supposed to be declared i am guessing
> > > i
> > > am  
> > > close to deploying the scenario correctly, but i am having
> > > these  
> > > issues (let me know if you how to address them):
> > > 
> > > - Once I create a VM I am not being able to access them (ping
> > > fails).
> > 
> > If you list the VM with 'nova list', does it say it is active? Does
> > it
> > list an ip? Check that it receives an IP lease from the server with
> > nova console-log
> > 
> > 
> > > 
> > > - When I restart a compute node it will take an IP address from
> > > my  
> > > public network and after that I cannot ssh into the node.
> > 
> > Strange... but why do you reboot a compute? Are you trying to test
> > some
> > HA behaviour?
> > 
> > > 
> > > 
> > > I have the following doubts regarding the deployment options
> > > being
> > > set  
> > > up in fuel:
> > > 
> > > - When creating the environment in fuel what networking option
> > > should  
> > > i choose: Neutron with ML2 plugin & Neutron with tunneling  
> > > segmentation or OpenDaylight with tunneling segmentation?
> > 
> > If you want to try SFC, you should use OpenDaylight
> > 
> > > 
> > > - 

[opnfv-tech-discuss] [OPNFV] [Infra] [Testing) Stress/resiliency Testing evolution in OPNFV (draft)

[morgan.richomme]

Hi Infra group,

I got an action point this afternoon during the TSC meeting after the 
presentation on the behalf of the testing working group on our vizion of 
test evolution 
(https://wiki.opnfv.org/download/attachments/9568526/testing%20evolution%20v1_3.pptx?version=2=1499788745000=v2)


We would like to run more stress/resiliency tests on "stable" releases.

This raises several questions:

 * POD/resources
 * capability to manage OPNFV releases

TSC would like to get a_concrete proposal it can vote on_ regarding this 
topic.


We will discuss it tomorrow during the testing group meeting tomorrow 
(APAC slot)


I imagine something like that (just a proposal), feel free to 
comment/amend/modify



--


*Need*: be able to run stress/robustness/resiliency testing on OPNFV

People observed that unstability may occur on OPNFV releases after some 
days or due to the repetition of basic tests.


Stress tests developed for Danube showed also that OPNFV solutions can 
be crashed relatively easily...


These problems cannot be found when running systematically test suite 
only once after on a fresh installation


Regarding current release pipeline, it is not possible to plan such 
testing on OPNFV candidate release (stable solution ready for such tests 
shortly before the release date)


*Benefit for the community*: Address EUAG pain point, contribute to 
improve  "Telco Grade" aspects, consolidate the confidence in the release



_*short term proposal (Danube/Euphrates transition)*_

once Danube 3.0 is over, use existing resources to reinstall an 
os-nosdn-nofeature-ha scenario on


 * lf-pod1  / apex
 * huawei-pod2 / compass
 * ericsson-pod1 / fuel
 * intel-pod5 / joid

Use these pods for stress/robusteness tests until resources are 
realocated for Euphrates: 14th of July to mid August ~ 1 month?


 * main goal: run bottlenecks 2 scenarios developed for Danube
 * optional (if time): planned slots for Storperf, VSPERF, qtip,
   yardstick, functest

_Benefit:_

 * get official feedback on the stress tests done for Danube (part of
   Danube priorities) on what we really released
 * almost no impact on resources (just stop re-installing + grant
   access  for troubleshooting on existing resources)
 * Possibility to perform resiliency/stress on any "released" scenario
   (even if it is theoretical as no test suites on K8s today)

_Drawback_

 * if bug detected...bug will be reported to the installers but not
   sure it could be fixed
 * need lots of resources: PODs and people (at least 1 POD per installer)

_*mid term proposal (beyond Euphrates)*_

Allocate 1 pod for such activity based on OSA tagged version

 * Intel-18 / OSA os-nosdn-nofeature-ha (tagged Pike)

The mid term solution will allow the testing community to work closed to 
upstream independantly from the installers

detected bugs will be reported (and hopefully fixed) upstream

_Benefit:_

 * bugs reported upstream
 * 1 single source / no dependencies towards installers
 * Need only 1 POD (Testing group shall self-organize the timeslot
   allocation)
 * Keep aligned on the target version (no real // testing, release
   validation and stress tests done on the target release)
 * Possibility to leverage test promotion

_Drawback:_

 * Stress/resiliency test not directly related to
   scenarios/installer..what we are releasing
 * OpenStack centric

Note if you think mid term is achievable  now (installation of an OSA 
tagged Ocata on Intel-18) and people are fine with the approach we can 
probably skip the short term


/Morgan



_

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

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

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

Re: [opnfv-tech-discuss] [OPNFV] Draft support for presentation to TSC

[Dave Neary]

Hi Morgan,

Coming back to this old thread after the TSC discussion today.

My feeling is that the argument that we have to do stress testing on the
N-1 release because the installers are not available early in the cycle
is an argument for changing the release process (or converting it to a
continuous delivery model where the tip of master is always more or less
releasable).

Based on the conversation earlier, I think that we should not be
attempting to backport fixes at all in OPNFV if we can avoid it - if
operators and vendors want to fix issues that we have identified and
fixed in the tip of master, then the back-porting is their job, not
OPNFV's - and I do not think that this is a sufficient reason to break
the "gold standard" of no fork, upstream first which has been the OPNFV
mantra since its creation.

If we can get towards a rolling release of tip-of-master in OPNFV, I
think that this is what provides the greatest value to feature and
testing projects, operators, and vendors. Features will be tested as
integrated upstream, operators should get a higher cadence for new
features, and in general we will not be expending extra effort in a
community project back-porting fixes or features to N-1, or maintaining
patches against N-1 to fix resiliency issues.

Thanks,
Dave.

On 06/23/2017 02:39 AM, morgan.richo...@orange.com wrote:
> Hi
> 
> as discussed yesterday during the weekly meeting, I prepared a slide
> deck for the discussion with the TSC (I tried to summarize our
> discussion and hope it reflects the wiki pages we created on the topic).
> 
> Feel free to comment/complete/criticize/modify
> @Gabriel: would you be OK to present the beginning? (stress tests
> created for Danube + wiki page and email thread)
> 
> I already booked a slot for the meeting next week
> https://wiki.opnfv.org/display/meetings/TSC
> the agenda looks already pretty busy not sure we will have time, we will
> see
> 
> /Morgan
> 
> 
> 
> _
> 
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme
> ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> Thank you.
> 
> 
> 
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
> 

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] TSC vote requested for Danube 3.0 release

[Raymond Paik]

All,

After checking with several scenarios owners during the Release call today,
there was a consensus that people were ready to tag for the Danube 3.0
release on July 14th.  There were some scenarios with degradation compared
to 1.0 or 2.0 releases, but they would be explained in documentations (e.g.
due to upstream bug).

So, I'd like to ask the TSC members to vote on the following by 5pm Pacific
Time July 12th.

"Does the TSC approve the Danube 3.0 release date of July 14?  (+1, 0, -1)"

Thanks,

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

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

[Jose Lausuch]

More inline

From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Tuesday, July 11, 2017 16:40 PM
To: Jose Lausuch ; Fatih Degirmenci 
; Beierl, Mark 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Inline…

From: Jose Lausuch >
Date: Tuesday, July 11, 2017 at 4:27 AM
To: Fatih Degirmenci 
>, "Beierl, 
Mark" >, "Alec Hothan 
(ahothan)" >
Cc: 
"opnfv-tech-discuss@lists.opnfv.org" 
>
Subject: RE: [opnfv-tech-discuss] Multiple docker containers from one project

Hi,

We excluded incremental tags because we overflooded our docker repos (I had to 
remove ~300 tags manually once in Functest docker repo). For projects that 
merge patches almost every day, that approach is unmaintainable.

This is what we are currently following:

latest:
built from latest master. It is used in CI master jenkins jobs --> 
Continuous Delivery

[Alec]
Does latest always refer to the “current development release” – e.g. it would 
be Euphrates as of today?
How about latest for Danube?
[Jose]
More or less, but Euphrates is not released yet. So it is latest-master, which 
will become Euphrates in the end.
latest for Danube = stable tag


stable:
built from “latest” patch of stable branch. It doesn’t change so 
frequently but it contains latest bugfixes from stable branches. It is used in 
CI Danube jenkins jobs.
[Alec]
What is defined as the “stable branch”? Is it the danube branch as of today?
Is it needed to have a stable for euphrates or for Colorado?
[Jose]
Yes. Stable tag refers to the latest state of stable/danube currently and 
stable/euphrates once we branch the repos. This is meant for CI testing. The 
released image won’t be called “stable”.

danube.X.0
built once the project is ready for release. It must be done manually 
by the PTL or Jenkins admin. Not tested directly in CI, but it should be the 
same image as stable tag at the end of the release cycle.

[Alec]
Is there a manifest per project somewhere that indicates what artifacts go into 
a release for that project?
This along with a project list for the release will provide exactly the full 
content of a release.
[Jose]
Not explicitly
In Functest case, everything is in our Dockerfile and requirements.txt. That 
will conform the content of the Functest release (a docker image). I guess it’s 
applicable for other projects.


A few of the questions I raised in a previous email:

  *   do force every project to have a git tag that matches the container tag ( 
this obviously does not apply to non unique container tags such as “stable” or 
“latest”)? Without that, it is very difficult to track a container version to a 
git repo commit.
[Jose] I can talk only for Functest, and we try to do it, but we need all the 
repos to be tagged when we build the image.


  *   How are incremental versions supported for a given release (e.g. when 
danube 3.0 comes out, how can a project push out a new maintenance release of a 
container say 2 days after the danube 3.0 was released), we can’t just 
overwrite the “danube.3.0” container
[Jose] Good point.. maybe we should create danube.3.1



For the concern:
“As for the git clone issue, or pip install from git, there is no tag provided. 
 This is a concern that I have with the way there is a separation of docker 
build (in releng) and git clone.  We cannot actually rebuild from a label at 
this time.”
If you are doing a git clone of your repository to be installed by pip. You can 
setup arguments in your Dockerfile. Example:

   ARG BRANCH=master
   RUN git clone --depth 1 -b $BRANCH 
https://gerrit.opnfv.org/gerrit/storperf

BRANCH argument can be overwritten by the docker build command (default is 
‘master’ in this example) and it’s exactly what the jenkins job is doing.

[Alec]
That’s good but we still have to solve the resulting container tag 
appropriately ;-)


Thanks,

/Alec






Regards,
Jose


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Fatih 
Degirmenci ARG BRANCH=master
Sent: Monday, July 10, 2017 18:24 PM
To: Beierl, Mark >; Alec 
Hothan (ahothan) >
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Hi,

About the tagging question; in the past we 

Re: [opnfv-tech-discuss] [test-wg] docker container versioning

[Fatih Degirmenci]

+1 to "Can we work on a proposal and get every project that deals with 
containers involved?"

It is mainly test projects who use containers so I again let testing community 
to take the lead and point you to where/how the conversation started.

We can then try to generalize it later on.

/Fatih

On 11 Jul 2017, at 17:16, Alec Hothan (ahothan)  wrote:

Can we work on a proposal and get every project that deals with containers 
involved?
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [test-wg] docker container versioning

[Alec Hothan (ahothan)]

Hi Fatih,


From: Fatih Degirmenci 
Date: Monday, July 10, 2017 at 2:04 PM
To: "Alec Hothan (ahothan)" , "Beierl, Mark" 

Cc: "opnfv-tech-discuss@lists.opnfv.org" , 
"test...@lists.opnfv.org" 
Subject: Re: [test-wg] docker container versioning

Hi Alec,

Your understanding about the docker image tags seem correct to me (latest vs 
stable) but I let someone from test projects answer to that.

[Alec] I’m still a bit confused after reading Jose’s email

When it comes to artifact versioning in general; you are asking really good 
questions. Let me go back in time and summarize what plans we had (ie what we 
haven't been able to implement fully) with regards to it.

The questions you ask about tagging docker images is not limited to them. We 
have similar issues with other artifacts we produce (rpms, isos , etc.), maybe 
not on the same level as the docker images but we have them.

[Alec]
Containers generally have a much faster cycle than rpms and isos, it is not 
unreasonable to see multiple versions of a container being created for any 
given opnfv release. But you’re right that tracking the version is needed for 
all artifacts.


In order to achieve some level of traceability and reproducibility, we record 
the metadata for the artifacts (rpms, isos, etc.) we build so we can go back to 
source and find out exact version (commit) that was used for building the 
artifact in question. [1]
We also had plans to tag corresponding commits in our git repos but we haven't 
managed to fix that. [2] This includes docker images as well.

[Alec]
It is good that it is at least tracked. I’m a bit surprised that the community 
has not up voted this issue because it is a pretty serious one.


Apart from our own (OPNFV) repos, some of the artifacts we build include stuff 
from other sources, making it tricky to achieve full traceability and making 
the traceability even more important.
We had many discussions about how to capture this information in order to 
ensure we can go back to a specific commit in any upstream project we consume. 
(locking/pinning versions etc.)
But since we have different ways of doing things and different practices 
employed by different projects, this hasn't happened either. (I can talk about 
this for hours...)

[Alec]
It is indeed a pretty complex problem but can we perhaps limit the discussion 
to containers first? That will limit the scope and hopefully allow us to get 
containers in a good shape and perhaps we could leverage that work for the rest 
of the artifacts.

By the way, I am not saying we totally failed as some projects take care of 
this themselves but as OPNFV, we do not have common practice, except metadata 
files for ISOs and the docker tags that do not help at all.

Long story short, this can be achieved in different ways like you exemplified; 
if a tag is applied to a repo, we trigger a build automatically and store & tag 
produced artifact in artifact repo and/or if we are building periodically, we 
apply the tag to git repo once the artifact is built successfully.

[Alec]
Can we work on a proposal and get every project that deals with containers 
involved? Do you usually work on a text file reviewed in gerrit?
We would need to address the following:

  *   Opnfv containers versioning strategy (how to version, workflows and 
relationship with releases)
  *   How to produce and publish new container images
  *   Support for multiple images per project (although this can be addressed 
separately in the short term)

Thanks

  /Alec


No matter which way we go, we need to fix this so thank you for questioning 
things, hopefully resulting in improvements starting with test projects.

[1] http://artifacts.opnfv.org/apex/opnfv-2017-07-05.properties
[2] https://jira.opnfv.org/browse/RELENG-77

/Fatih

From: "Alec Hothan (ahothan)" 
Date: Monday, 10 July 2017 at 21:45
To: Fatih Degirmenci , "Beierl, Mark" 

Cc: "opnfv-tech-discuss@lists.opnfv.org" , 
"test...@lists.opnfv.org" 
Subject: [test-wg] docker container versioning


[ cc test-wg - was [opnfv-tech-discuss] Multiple docker containers from one 
project) ]


Hi Fatih

It is generally not easy to deal with container tags that do not include any 
information that links easily to a git repo commit (e.g. a “version” number 
increased by 1 for each build does not tell which git commit was used – might 
be one reason why this was removed)

For example, if we look at the published yardstick containers as of today:

“latest” is generally used to refer to the latest on master at the time of the 
build (so whoever does not care about the exact version and just wants the 
bleeding edge will pick “latest”) – apparently this container is not linked to 
any particular OPNFV release? 

[opnfv-tech-discuss] [opnfvdocs] Agenda for tomorrow's meeting

[Sofia Wallin]

Agenda,

· Danube 3.0 – Any issues or questions?

· Clarify the responsibilities between the docs team and release manager

· MS6 Preliminary documentation completed – Any clarification needed?


Welcome,
Sofia

___
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

[Alec Hothan (ahothan)]

Inline…

From: Jose Lausuch 
Date: Tuesday, July 11, 2017 at 4:27 AM
To: Fatih Degirmenci , "Beierl, Mark" 
, "Alec Hothan (ahothan)" 
Cc: "opnfv-tech-discuss@lists.opnfv.org" 
Subject: RE: [opnfv-tech-discuss] Multiple docker containers from one project

Hi,

We excluded incremental tags because we overflooded our docker repos (I had to 
remove ~300 tags manually once in Functest docker repo). For projects that 
merge patches almost every day, that approach is unmaintainable.

This is what we are currently following:

latest:
built from latest master. It is used in CI master jenkins jobs --> 
Continuous Delivery

[Alec]
Does latest always refer to the “current development release” – e.g. it would 
be Euphrates as of today?
How about latest for Danube?


stable:
built from “latest” patch of stable branch. It doesn’t change so 
frequently but it contains latest bugfixes from stable branches. It is used in 
CI Danube jenkins jobs.
[Alec]
What is defined as the “stable branch”? Is it the danube branch as of today?
Is it needed to have a stable for euphrates or for Colorado?





danube.X.0
built once the project is ready for release. It must be done manually 
by the PTL or Jenkins admin. Not tested directly in CI, but it should be the 
same image as stable tag at the end of the release cycle.

[Alec]
Is there a manifest per project somewhere that indicates what artifacts go into 
a release for that project?
This along with a project list for the release will provide exactly the full 
content of a release.

A few of the questions I raised in a previous email:

  *   do force every project to have a git tag that matches the container tag ( 
this obviously does not apply to non unique container tags such as “stable” or 
“latest”)? Without that, it is very difficult to track a container version to a 
git repo commit.
  *   How are incremental versions supported for a given release (e.g. when 
danube 3.0 comes out, how can a project push out a new maintenance release of a 
container say 2 days after the danube 3.0 was released), we can’t just 
overwrite the “danube.3.0” container



For the concern:
“As for the git clone issue, or pip install from git, there is no tag provided. 
 This is a concern that I have with the way there is a separation of docker 
build (in releng) and git clone.  We cannot actually rebuild from a label at 
this time.”
If you are doing a git clone of your repository to be installed by pip. You can 
setup arguments in your Dockerfile. Example:

   ARG BRANCH=master
   RUN git clone --depth 1 -b $BRANCH 
https://gerrit.opnfv.org/gerrit/storperf

BRANCH argument can be overwritten by the docker build command (default is 
‘master’ in this example) and it’s exactly what the jenkins job is doing.

[Alec]
That’s good but we still have to solve the resulting container tag 
appropriately ;-)


Thanks,

/Alec






Regards,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Fatih 
Degirmenci ARG BRANCH=master
Sent: Monday, July 10, 2017 18:24 PM
To: Beierl, Mark ; Alec Hothan (ahothan) 

Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Hi,

About the tagging question; in the past we tagged all the images we built and 
stored on Docker hub. The tags for the intermediate versions were set 
incrementally and applied automatically by the build job and release tag was 
applied manually for the release.
But then (some of the) test projects decided not to do that and got rid of 
that. (I don't exactly remember who, why and so on.)

We obviously failed to flag this at that time. This should be discussed by Test 
WG and fixed.

/Fatih

From: 
>
 on behalf of "Beierl, Mark" >
Date: Monday, 10 July 2017 at 18:10
To: "Alec Hothan (ahothan)" >
Cc: 
"opnfv-tech-discuss@lists.opnfv.org" 
>
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Sorry, Alec, for not responding.  I'm not a releng committer so I thought 
someone from there would have replied.  You are correct that the tag is 
provided by the person running the job in Jenkins and passed through to 
opnfv-docker.sh.

As for the git clone issue, or pip install from git, there is no tag provided.  
This is a concern that I have with the way there is a separation of docker 
build (in releng) and git clone.  We cannot actually rebuild from a label at 
this 

[opnfv-tech-discuss] OPNFV Cross Community CI (XCI) Meeting

[Fatih Degirmenci]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Fatih Degirmenci:MAILTO:fatih.degirme...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=Markos Ch
 andras:MAILTO:mchand...@suse.de
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=Yolanda M
 ota:MAILTO:yrobl...@redhat.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=Jack Morg
 an:MAILTO:jack.mor...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=Juan Vida
 l ALLENDE:MAILTO:juan.vidal.alle...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=Manuel Bu
 il:MAILTO:mb...@suse.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=wutianwei
 :MAILTO:wutianw...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=Nikolas H
 ermanns:MAILTO:nikolas.herma...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=BLAISONNE
 AU RD-CORE-LAN:MAILTO:david.blaisonn...@orange.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=mardim@in
 tracom-telecom.com:MAILTO:mar...@intracom-telecom.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Bob Monk
 man':MAILTO:bob.monk...@arm.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=zhang.jun
 3...@zte.com.cn:MAILTO:zhang.ju...@zte.com.cn
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=fangfang 
 (C):MAILTO:fangfa...@huawei.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=opnfv-tec
 h-disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
DESCRIPTION;LANGUAGE=en-GB:Hi\,\n\n\n\nWelcome to OPNFV Cross Community CI 
 (XCI) Meeting!\n\n\n\nYou can see the agenda for the upcoming meeting on h
 ttps://etherpad.opnfv.org/p/xci-meetings\n\n\n\nPlease note that this is a
 n IRC-only meeting on #opnfv-pharos channel held on a bi-weekly basis.\n\n
 Please let me know in case if you want to have meeting with voice/screen s
 haring to discuss/demo things in advance so I can fix GTM for that meeting
 .\n\n\n\nXCI @ OPNFV Wiki: https://wiki.opnfv.org/pages/viewpage.action?pa
 geId=8687635\n\nXCI @ OPNFV Jenkins: https://build.opnfv.org/ci/view/OPNFV
 %20XCI/\n\n\n\n/Fatih\n
RRULE:FREQ=WEEKLY;UNTIL=20171018T13Z;INTERVAL=2;BYDAY=WE;WKST=SU
UID:580EB2B8-73C8-440B-9F2D-6CF66601334A
SUMMARY;LANGUAGE=en-GB:OPNFV Cross Community CI (XCI) Meeting
DTSTART;TZID=W. Europe Standard Time:20170719T15
DTEND;TZID=W. Europe Standard Time:20170719T16
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20170711T143550Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-GB:IRC-only (#opnfv-pharos on freenode)
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:2115460920
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DISALLOW-COUNTER:TRUE
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [barometer] TST008 analysis

[Tahhan, Maryam]

Hi Al
I've gone through TST 008 and have a few questions:



Q. Parameters to metrics, are these intended to be sent as part of the metric 
being reported, or can they be sent as information themselves, link status 
being the example I would pick on :)



Q. Do we need to report both usage and utilization for CPU? Or is one enough? 
"On the completion of a measurement interval, the measured times shall be 
summed and the usage and utilization shall be reported. "



Q. "Interface Speed: the nominal frequency of the physical interface bit clock 
in Hz, which governs the rate that the interface operates. Virtual interfaces 
may not have a meaningful value for this parameter. " in Hz? Or in Mb/s?



I can't find a way of retrieving the interface speed in HZ, should it be HZ or 
Mb/s

sudo ethtool enp134s0 | grep Speed

Speed: 1000Mb/s



cat /sys/class/net/enp134s0/speed

1000



Q. "Interface: the name of a single interface where communication metrics are 
monitored " --> what about uuid or id - some interfaces aren't identified by 
name



Q. "Interface Status: the operational state of the interface indicating 
readiness for use, usually expressed as "up"or "down" " --> is the parameter to 
be sent with the metric? Interface status would be interesting of its own right?



Q. " here are four fundamental metrics of memory utilization:

1) Memory buffered

2) Memory Cached

3) Memory free

4) Memory Slab

These four metrics comprise the total of used 
memory. Therefore, the sum of these metrics can be subtracted from the Total 
Memory to obtain the current value of free memory"



Memory free - is a typo I think with the sentence that follows.



Q.   "The following parameters shall be supported for these four 
metrics:

* Measurement time: the point in time when the values were read 
(time and date).

* Total Memory: the Random Access Memory, RAM, available to the 
compute node measured

* Swap space: the configured memory available for processes to 
share through swapping "



Would total memory not be a stat on its own?



Other notes:

· Clock ticks are missing from the CPU readings --> can add this to 
metadata

· The measurement interval for the collectd cpu plugin is based on the 
read interval https://github.com/collectd/collectd/blob/master/src/cpu.c#L591 - 
can also add to metadata? But it's available in the  interval info - so I just 
need to double check that this is sent by publishing plugins.

· "Processor usage results shall be reported as time in seconds," --> 
at the moment this is in nanoseconds... but we can add an option to the cpu 
plugin.

· "and utilization shall be reported as the ratio of total time in one 
or more execution contexts to the total time in the measurement interval, 
expressed as a percentage". --> done



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

[opnfv-tech-discuss] 答复: [multisite]stepping down from PTL

[Chigang (Justin)]

Hi Joe,

I was impressed by multisite Demo in OPNFV summit, that brings a high 
availability VNF solution across multiple cloud. Thanks your contribution for 
multisite.

Regards
Justin

发件人: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Zhipeng Huang
发送时间: 2017年7月10日 14:14
收件人: joehuang
抄送: opnfv-tech-discuss
主题: Re: [opnfv-tech-discuss] [multisite]stepping down from PTL

Thanks Joe,

You have lead an incredible effort in building the multisite project and it was 
a great journey for people like us who were among the first participants.



On Mon, Jul 10, 2017 at 9:04 AM, joehuang 
> wrote:

Hello,



Nice to work with you in Multi-site and OPNFV from 2015, there are still lots 
of interesting staff to do in multi-site area, just as what we discussed in the 
thread "multi-site next 
step?"(https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-June/016733.html).



Unfortunately, I am not able to continue multi-site PTL role, due to my time is 
occupied mostly by non-open source activities. I would like to say thanks to 
all of you, and step down from multi-site PTL.



Just as what we discussed in the thread "multi-site next step?", the inital 
goal of multi-site project is to identify and fill the gaps in OpenStack to 
fullfill multi-site requirements, most of them have been covered by respective 
projects, especially we have solution to support mission critical application 
high availability in multi-site (across multiple OpenStack cloud) through the 
help of Tricircle project, though the integration in OPNFV can be done by 
succedded contributions.



PTL candidates are welcome to continue the project, if there is no PTL 
candidate stepping up in two weeks, it's fine to ask for the termination of 
multi-site project, becasue the project has reached its initial goal.



New project or installer projects can do the integration and test for various 
multi-site requirements, I'll try my best to review multi-site relative patches 
if needed, especially if you need help for Tricircle integration, or you can 
ask for help from Tricircle team in OpenStack community.




Best Regards
Chaoyi Huang (joehuang)

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



--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

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

[Jose Lausuch]

Hi,

We excluded incremental tags because we overflooded our docker repos (I had to 
remove ~300 tags manually once in Functest docker repo). For projects that 
merge patches almost every day, that approach is unmaintainable.

This is what we are currently following:

latest:
built from latest master. It is used in CI master jenkins jobs --> 
Continuous Delivery

stable:
built from “latest” patch of stable branch. It doesn’t change so 
frequently but it contains latest bugfixes from stable branches. It is used in 
CI Danube jenkins jobs.

danube.X.0
built once the project is ready for release. It must be done manually 
by the PTL or Jenkins admin. Not tested directly in CI, but it should be the 
same image as stable tag at the end of the release cycle.


For the concern:
“As for the git clone issue, or pip install from git, there is no tag provided. 
 This is a concern that I have with the way there is a separation of docker 
build (in releng) and git clone.  We cannot actually rebuild from a label at 
this time.”
If you are doing a git clone of your repository to be installed by pip. You can 
setup arguments in your Dockerfile. Example:

   ARG BRANCH=master
   RUN git clone --depth 1 -b $BRANCH 
https://gerrit.opnfv.org/gerrit/storperf

BRANCH argument can be overwritten by the docker build command (default is 
‘master’ in this example) and it’s exactly what the jenkins job is doing.


Regards,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Fatih 
Degirmenci ARG BRANCH=master
Sent: Monday, July 10, 2017 18:24 PM
To: Beierl, Mark ; Alec Hothan (ahothan) 

Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Hi,

About the tagging question; in the past we tagged all the images we built and 
stored on Docker hub. The tags for the intermediate versions were set 
incrementally and applied automatically by the build job and release tag was 
applied manually for the release.
But then (some of the) test projects decided not to do that and got rid of 
that. (I don't exactly remember who, why and so on.)

We obviously failed to flag this at that time. This should be discussed by Test 
WG and fixed.

/Fatih

From: 
>
 on behalf of "Beierl, Mark" >
Date: Monday, 10 July 2017 at 18:10
To: "Alec Hothan (ahothan)" >
Cc: 
"opnfv-tech-discuss@lists.opnfv.org" 
>
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Sorry, Alec, for not responding.  I'm not a releng committer so I thought 
someone from there would have replied.  You are correct that the tag is 
provided by the person running the job in Jenkins and passed through to 
opnfv-docker.sh.

As for the git clone issue, or pip install from git, there is no tag provided.  
This is a concern that I have with the way there is a separation of docker 
build (in releng) and git clone.  We cannot actually rebuild from a label at 
this time.

Perhaps this is a bigger issue that needs to be discussed before we can 
properly address multiple docker builds.

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 Jul 10, 2017, at 11:34, Alec Hothan (ahothan) 
> wrote:


Projects that do not have pyPI packages (or the right version of PyPI package 
published) might prefer to do a git clone instead and either install it 
directly or using pip install from the clone in the container.
Some Dockerfile may prefer to directly install from the current (cloned) repo 
(and avoid a git clone) but this might accidentally (or purposely) include 
local patches into the built container.
There are many valid ways to skin the cat…

I did not get any feedback on a previous question I had on container 
versioning/tagging.
The container versioning currently used is based on the branch name followed by 
a release name (e.g. “danube.3.0”) with the addition of latest, stable and 
master.

From opnfv-docker.sh:

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

BUILD_BRANCH=$BRANCH

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

if [[ -n "${COMMIT_ID-}" && -n "${RELEASE_VERSION-}" ]]; then
   DOCKER_TAG=$RELEASE_VERSION
BUILD_BRANCH=$COMMIT_ID
fi

If branch is master, the tag is master, if 

Re: [opnfv-tech-discuss] [dovetail][CI]How to create a dovetail CI weekly job?

[吴之惠]

HI Matthew,

Thanks for your reply. Let's discuss it on that patch.

Best regards,

Zhihui

Lijun (Matthew) 于2017年7月11日周二 下午4:29写道：

> hi Zhihui
>
> there are some examples existed already, such as the compass ones. Since
> you mentioned it will be a weekly job and the pod name, as you know we run
> against Danube now to publish the Danube based release, so it should deploy
> Danube scenario. will put up a patch to add you to review, then we can
> comments more on the patch directly.
>
> best regards
> /MatthewLi
> *发件人：*吴之惠
> *收件人：*Motamary, Shabrinath via opnfv-tech-discuss,田红波
> *抄送：*serena.feng@gmail.com
> *时间：*2017-07-11 16:22:08
> *主题:*[opnfv-tech-discuss] [dovetail][CI]How to create a dovetail CI
> weekly job?
>
> Hi dovetail team,
>
> I would like to create a dovetail CI weekly job on ZTE pod1. The scenario
> is os-odl_l2-nofeature-ha and the installer is fuel.
> I read jjb template files about dovetail in releng. It is hard to find out
> which jjb template file I should modify.
> Would you kindly please give me some guidance? Thanks in advance.
>
> Best regards,
>
> Zhihui.Wu
>
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] 答复: [dovetail][CI]How to create a dovetail CI weekly job?

[Lijun (Matthew)]

hi Zhihui

there are some examples existed already, such as the compass ones. Since you 
mentioned it will be a weekly job and the pod name, as you know we run against 
Danube now to publish the Danube based release, so it should deploy Danube 
scenario. will put up a patch to add you to review, then we can comments more 
on the patch directly.

best regards
/MatthewLi
发件人：吴之惠
收件人：Motamary, Shabrinath via opnfv-tech-discuss,田红波
抄送：serena.feng@gmail.com
时间：2017-07-11 16:22:08
主题:[opnfv-tech-discuss] [dovetail][CI]How to create a dovetail CI weekly job?

Hi dovetail team,

I would like to create a dovetail CI weekly job on ZTE pod1. The scenario is 
os-odl_l2-nofeature-ha and the installer is fuel.
I read jjb template files about dovetail in releng. It is hard to find out 
which jjb template file I should modify.
Would you kindly please give me some guidance? Thanks in advance.

Best regards,

Zhihui.Wu


___
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] [dovetail][CI]How to create a dovetail CI weekly job?

[吴之惠]

Hi dovetail team,

I would like to create a dovetail CI weekly job on ZTE pod1. The scenario
is os-odl_l2-nofeature-ha and the installer is fuel.
I read jjb template files about dovetail in releng. It is hard to find out
which jjb template file I should modify.
Would you kindly please give me some guidance? Thanks in advance.

Best regards,

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

Re: [opnfv-tech-discuss] [release][danube] Danube release status for TSC call July 11

[Ulrich Kleber]

Hi David,
thank you for this summary.

However, I have a question about the scenarios failing to deploy now. Could you 
summarize, which of those scenarios were part of Danube 1.0 or 2.0?
Our goal was to include 1.0 and 2.0 contents also in 3.0. What is your proposal?

Cheers,
Uli



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Tuesday, 11 July, 2017 02:12
To: TSC OPNFV
Cc: TECH-DISCUSS OPNFV
Subject: [opnfv-tech-discuss] [release][danube] Danube release status for TSC 
call July 11

TSC members,

Please find slides attached with Danube 3 summary.  Reminder that the release 
is scheduled for Friday, July 14.  We will be discussing status and voting on 
the release on the call tomorrow (July 11).

David

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

[opnfv-tech-discuss] [OPNFV] Testing group weekly meeting

[morgan.richomme]

Hi

reminder: this week => APAC meeting on Wednesday

we keep however the Thursday slot for an adhoc meeting with Bitergia

see agenda 
https://wiki.opnfv.org/display/meetings/Test+Working+Group+Weekly+Meeting


/Morgan


_

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

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

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