Re: [opnfv-tech-discuss] Fuel/Armband ODL scenario rename in Functest test results dashboard

[vvenkat]

Hi Alex,
While your question is answered, 
Request you to clarify :  This is also exported to Yardstick, Functest
accordingly. I should feed there as os-odl-nofeature-ha say as an example or
still os-odl_l3-nofeature-ha ??

Thanks
-Venkat

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Alexandru
Avadanii
Sent: Wednesday, September 13, 2017 4:50 AM
To: RICHOMME Morgan IMT/OLN 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] Fuel/Armband ODL scenario rename in Functest
test results dashboard

Hi,
Fuel and Armband projects renamed the ODL-L3 scenario to simply ODL, and
dropped the ODL-L2 scenarios, as described in [1].
I noticed that the Functest results dashboard pages [2, 3] still use the old
naming scheme, although the new scenario is also listed.
Would it be possible to cleanup obsolete scenarios?

Thank you,
Alex

[1] https://jira.opnfv.org/browse/FUEL-279
[2]
http://testresults.opnfv.org/reporting/master/functest/status-f...@x86.html
[3]
http://testresults.opnfv.org/reporting/master/functest/status-fuel@aarch64.h
tml

___
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] 答复: [onap-discuss] 答复: [Auto] Error when create onap pods using kubernetes

[huangxiangyu]

Roger, Thanks. The config pod shows no error now

发件人: Roger Maitland [mailto:roger.maitl...@amdocs.com]
发送时间: 2017年9月11日 20:53
收件人: huangxiangyu ; Michael O'Brien 
; Tina Tsou 
抄送: onap-disc...@lists.onap.org; opnfv-tech-discuss@lists.opnfv.org
主题: RE: [onap-discuss] 答复: [opnfv-tech-discuss] [Auto] Error when create onap 
pods using kubernetes

Hi Harry,

A significant improvement to OOM was pushed on Friday, see the attached email.  
This new error refers to missing values in the 
/oom/kubernetes/config/onap-parameters.yaml configuration file.

Cheers,
Roger

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of huangxiangyu
Sent: Monday, September 11, 2017 3:42 AM
To: Michael O'Brien; Tina Tsou
Cc: onap-disc...@lists.onap.org; 
opnfv-tech-discuss@lists.opnfv.org
Subject: [onap-discuss] 答复: [opnfv-tech-discuss] [Auto] Error when create onap 
pods using kubernetes

Michael

Those two nginx containers are created manually for test purpose. I’m afraid 
that I don’t have any Ubuntu 16 environment right now so I have to continue 
test with Ubuntu 14. I just pull the oom repo today and there is new error 
appears when running ./createConfig.sh -n onap.
kubectl logs:
Validating onap-parameters.yaml has been populated
Error: OPENSTACK_UBUNTU_14_IMAGE must be set in onap-parameters.yaml

However It’s not always successful when I creating the config pod even before I 
pulled the oom repo. Usually, this config pod stays at creating state and never 
be completed. I ran the deleteAll.bash and delete /dockerdata-nfs just as wiki 
instructed. So am I missing any step ?

Thanks
Harry

发件人: Michael O'Brien [mailto:frank.obr...@amdocs.com]
发送时间: 2017年9月8日 11:59
收件人: huangxiangyu >; 
Tina Tsou >
抄送: 
opnfv-tech-discuss@lists.opnfv.org; 
onap-disc...@lists.onap.org
主题: RE: [opnfv-tech-discuss] [Auto] Error when create onap pods using kubernetes

Harry,
   Hi, some comments.
   The nginx containers – we are not deploying these, since they are in the 
default namespace they don’t look part of a normal rancher setup as well – I am 
curious where these 2 pods came from and why you would need a reverse proxy – 
also verify you are running rancher on 8880 to avoid 80/8080 conflicts with 
these.
I am suspicious of this reverse proxy – I would expect your forwarding 
issues stem from these 2 servers – normally used to manage a private subnet – 
they might not be handling IPV6 traffic (I remember an issue with this in 
general from a couple years ago)

default   nginx-deployment-431080787-6chxv   1/1   Running  
  0  1d
default   nginx-deployment-431080787-9nswb   1/1   Running  
  0  1d

I would recommend you run on Ubuntu 16.04 not 14 – may work OK but all our 
examples assume 16 and we have not tested 14 (note that I had issues with 17).
In a build before last Saturday – I did see the same 3 pods fail to come up 
vnc-portal, sdc-be and sdc-fe – make sure you have pulled from master this week 
- (try a git pull) – then reset your config pod via the following if any new 
content comes in.
https://wiki.onap.org/display/DW/ONAP+on+Kubernetes#ONAPonKubernetes-Delete/Rerunconfig-initcontainerfor/dockerdata-nfsrefresh

The aai-gremlin pod is not required and can be ignored for now – but it 
normally starts up – see the OOM-Kubernetes status section on

https://wiki.onap.org/display/DW/ONAP+master+branch+Stabilization#ONAPmasterbranchStabilization-20170907:OOMKubernetes

 thank you
 /michael



From: huangxiangyu [mailto:huangxiang...@huawei.com]
Sent: Thursday, September 7, 2017 22:56
To: Michael O'Brien >; 
Tina Tsou >
Cc: 
opnfv-tech-discuss@lists.opnfv.org; 
onap-disc...@lists.onap.org
Subject: 答复: [opnfv-tech-discuss] [Auto] Error when create onap pods using 
kubernetes

Hi Michael

Here the environment info：
Distributor ID: Ubuntu
Description:Ubuntu 14.04.5 LTS
Release:14.04
Codename:   trusty

I didn’t check the pod status after I saw the Error message. Seems this ipv6 
error didn't stop pod creating process maybe this error only leads to no ipv6 
address for every pod.
Here the pods status:
NAMESPACE NAME   READY STATUS   
  RESTARTS   AGE
default   nginx-deployment-431080787-6chxv   1/1   Running  
  0  1d
default   

[opnfv-tech-discuss] [Bottlenecks] Minutes of Bottlenecks Discussion on Sept. 13th, 2017

[Yuyang (Gabriel)]

Minutes of Bottlenecks Discussion on Sept. 13th, 2017

  *   Date and Time
 *   Thursday at 
0300-0400
 UTC, Sept. 13th, 2017
 *   Thursday at 1100-1200 Beijing, Sept. 13th, 2017
 *   Wednesday at 0800-0900 PDT, Sept. 12th, 2017
  *   Minutes
 *   Yang Yu
  *   Participants (8 peoples):
 *   Ross
 *   Ace Lee
 *   Amit
 *   Rutuja
 *   Kubi
 *   Jing Lv
 *   Manoj Nirania
Agenda:

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

1.  IRC Minutes

  *   
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-bottlenecks/2017/opnfv-bottlenecks.2017-09-13-03.03.html

2.  Action Items

  *   Ross make python file for the super template
  *   Ace will ask Deepak if Vacl need the support of DPDK multiqueue.
  *   Rutuja to investigate Collectd and Node metrics
  *   Ace to discuss with deepak for vACL scale up
  *   gabriel provide Manoj with useful links ragarding projects and VNF testing

3.  Work Plan Review

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

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



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

[opnfv-tech-discuss] [mano-wg] Meeting #45 Focus VNF Onboarding and Orchestration using Heat

[Prakash Ramchandran]

Hi all,
Please refer to this Wednesday's  mano-wg agenda.
Agenda - Refer link https://wiki.opnfv.org/pages/viewpage.action?pageId=6827111
Meeting Details

Meeting Times: Every  Wednesday (7.00 am PST)  at 14.00 UTC, Other  Ad-hoc 
meeting as per Project requests

For IRC can use can use http://webchat.freenode.net/

IRC#opnfv-mano (meetbot is set for meeting minutes )

OPNFV MNAO WG Meeting

GOTOMEETING

1. Please join my meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/391235029
(in case of GTM fails join IRC using webchat link above and get the new GTM 
link/ meeting number)

2. Use your microphone and speakers (VoIP) - a headset is recommended.  Or, 
call in using your telephone.

United States (Toll Free): 1 877 309 2073
United States: +1 (312) 757-3136
Notes:
Agenda - Refer link https://wiki.opnfv.org/pages/viewpage.action?pageId=6827111

We have OPNFV Release Euphrates(E) settling on MS6 of feature freeze to deliver 
by MS10 on October 6/2017
Unnamed yet F scheduled announced at TCT tentatively  for April 20/2108.

Now is time to consolidate what we did in VNF Onboarding and Orchestration in 
OPNFV. Start with a peak into Heat in OpenStack as what it has in store for us.
We will look at other events in upstream MNAO  like ONAP, OpenBaton, OSM and 
Service provider and EUAG promotions.

So look forward to new and views to see what can be accomplished in E  as we 
see acceleration in this space.

Here is the link to GTM and agenda for meeting #45 -All are welcome to attend 
and participate in debate and plans. Thanks Prakash

Thanks
Prakash

Schedules  for next meetings:

Sept 13, Wednesday : 14.00 UTC /7.00 PDT  Meeting #45

1.Agenda Bashing

2. VNF On-boarding and orchestration with 
Heat
 for vIMS  / How about 
ICE
 and VNF Validation 
kit in ONAP -  (30 
minutes)

3. Template based VNF Orchestration  best practices and testing status review   
 (15 minutes)

  *   Template based VNF Orchestration  and  
Clearwater-vIMS-Testing
  as use case- Prakash/Trinath (FUNCTEST/ Rake test and Ruby 1.9.3 issues?)
  *   Opera: Approach to testing via snaps-oo for VNFs  to be reviewed - 
Opera - Yingjun Li/Prakash - 
(snap-oo extensions?)
  *   EUAG and XCI:  Auto - workload and Edge 
Cloud - Tina / Prasad /Trinath 
(elastic workload how without POD Resources?)
  *   Any new developments to note from OPNFV or upstream - community - Verizon 
ONAP & OSM? What's the latest news?

4. VNF Life cycle Management best practices & testing status review (15 minutes)

  *   Impact of Pharos POD  configurations for VNF scaling  - Prakash/Narinder 
(discussed for vIMS - should it be moved to XCI debate?)
  *   Orchestra:  No Clearwater  Live test in E.0.0 will it move that to F.0.0? 
- Orchestra -( Unit-test + Mock) - 
Michael/Giuseppe (To conclude)
  *   test-wg follow-up: Suggests MANO vIMS tests to be in OPNFV F-release 
-Prakash/Michael - (Any objections from Orchestra team?)
  *   Any new developments to note from OPNFV or upstream -community - Brief 
review of OpenDev related to VNF at Edge - (Attendees)

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

[opnfv-tech-discuss] Fuel/Armband ODL scenario rename in Functest test results dashboard

[Alexandru Avadanii]

Hi,
Fuel and Armband projects renamed the ODL-L3 scenario to simply ODL, and 
dropped the ODL-L2 scenarios, as described in [1].
I noticed that the Functest results dashboard pages [2, 3] still use the old 
naming scheme, although the new scenario is also listed.
Would it be possible to cleanup obsolete scenarios?

Thank you,
Alex

[1] https://jira.opnfv.org/browse/FUEL-279
[2] http://testresults.opnfv.org/reporting/master/functest/status-f...@x86.html
[3] 
http://testresults.opnfv.org/reporting/master/functest/status-f...@aarch64.html

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

[opnfv-tech-discuss] [vsperf] Agenda for VSPERF weekly meeting - 13 Sep 2017

[Cooper, Trevor]

Proposed agenda topics ...



-  Project description for Euphrates messaging and announcement 
materials

-  Documentation updates for Euphrates

-  Status update related to CI test results

-  Jira scrub

-  Multi-flow test configurations

-  Representation of VSPERF results on reporting page

-  DPDK/OVS/VPP/QEMU versions

-  vSwitch metrics





For the first agenda topic please review this and suggest improvements/edits ...



VSPERF is a mature project that provides an automated test-framework and 
comprehensive test suite based on industry standards for measuring data-plane 
performance which includes switching technologies with physical and virtual 
network interfaces. The VSPERF architecture is switch and traffic generator 
agnostic and test cases can be customized. The vSwitch and other software 
component versions and configurations are controlled by VSPERF as is the 
network topology. VSPERF is useful for development of switching technologies as 
well as for evaluation and optimization of the data-path.





Meeting minutes from the last meeting ... ww35 
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-vswitchperf/2017/opnfv-vswitchperf.2017-08-30-15.03.html



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

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

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

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

[opnfv-tech-discuss] [Auto] Use Case Diagrams

[Tina Tsou]

Dear Bryan,

Would you add the use case diagrams here, as we discussed in last meeting?

https://wiki.opnfv.org/display/AUTO/Auto+Use+Cases#AutoUseCases-UseCaseDiagrams


Thank you,
Tina Tsou
Enterprise Architect
Arm
tina.t...@arm.com
+1 (408)931-3833

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

Re: [opnfv-tech-discuss] Canceled: [barometer] Weekly Call

[MORTON, ALFRED C (AL)]

Hi Maryam,
I still have the Invite, just got the reminder @15 minutes…
Al

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Tahhan, Maryam
Sent: Tuesday, September 12, 2017 11:41 AM
To: Aaron Smith; Juan Vidal ALLENDE
Cc: SULLIVAN, BRYAN L (BRYAN L); Foley, Emma L; serkant.ulude...@argela.com.tr; 
j.javier.ar...@gmail.com; Power, Damien; pavan.gu...@calsoftinc.com; Campbell, 
Wesley; daniel.par...@intel.com; Mcmahon, Tony B; Scott Mansfield; 
opnfv-tech-discuss@lists.opnfv.org; ola.liljed...@arm.com; 
schaga...@versa-networks.com; Gherghe, Calin; manish.ja...@cavium.com; Sun, 
Ning; yangya...@chinamobile.com; Duignan, Andrew; kand...@us.ibm.com; Murthy, 
Krishna J; Reddy, Raghuveer; Ray, Bj; mario.rodrig...@arm.com; Chornyi, TarasX
Subject: Re: [opnfv-tech-discuss] Canceled: [barometer] Weekly Call

Hi Aaron
The barometer call is still scheduled for this evening with the Prometheus 
integration overview. I’m not sure what Juan was cancelling. Please let me know 
if you still have the invitation.

BR
Maryam

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Aaron Smith
Sent: Tuesday, September 12, 2017 3:27 PM
To: Juan Vidal ALLENDE 
>
Cc: Foley, Emma L >; 
serkant.ulude...@argela.com.tr; 
ola.liljed...@arm.com; Power, Damien 
>; 
pavan.gu...@calsoftinc.com; Campbell, Wesley 
>; 
daniel.par...@intel.com; Mcmahon, Tony B 
>; Scott Mansfield 
>; 
mario.rodrig...@arm.com; 
opnfv-tech-discuss@lists.opnfv.org; 
j.javier.ar...@gmail.com; 
schaga...@versa-networks.com; Gherghe, 
Calin >; 
manish.ja...@cavium.com; Sun, Ning 
>; 
yangya...@chinamobile.com; Duignan, Andrew 
>; 
kand...@us.ibm.com; Murthy, Krishna J 
>; Reddy, 
Raghuveer >; Ray, 
Bj >; 
bs3...@att.com; Chornyi, TarasX 
>
Subject: Re: [opnfv-tech-discuss] Canceled: [barometer] Weekly Call

Will the Prometheus discuss be rescheduled for the call next week?

Aaron

On Tue, Sep 12, 2017 at 4:24 AM, Juan Vidal ALLENDE 
> wrote:
Updated the goto meeting


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



--

AARON SMITH

SENIOR PRINCIPAL SOFTWARE ENGINEER, NFVPE

Red Hat



314 Littleton Rd, Westford, MA 01886

aasm...@redhat.comM: 
617.877.4814
[https://www.redhat.com/files/brand/email/sig-redhat.png]


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

Re: [opnfv-tech-discuss] Canceled: [barometer] Weekly Call

[Tahhan, Maryam]

Hi Aaron
The barometer call is still scheduled for this evening with the Prometheus 
integration overview. I’m not sure what Juan was cancelling. Please let me know 
if you still have the invitation.

BR
Maryam

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Aaron Smith
Sent: Tuesday, September 12, 2017 3:27 PM
To: Juan Vidal ALLENDE 
Cc: Foley, Emma L ; serkant.ulude...@argela.com.tr; 
ola.liljed...@arm.com; Power, Damien ; 
pavan.gu...@calsoftinc.com; Campbell, Wesley ; 
daniel.par...@intel.com; Mcmahon, Tony B ; Scott 
Mansfield ; mario.rodrig...@arm.com; 
opnfv-tech-discuss@lists.opnfv.org; j.javier.ar...@gmail.com; 
schaga...@versa-networks.com; Gherghe, Calin ; 
manish.ja...@cavium.com; Sun, Ning ; 
yangya...@chinamobile.com; Duignan, Andrew ; 
kand...@us.ibm.com; Murthy, Krishna J ; Reddy, 
Raghuveer ; Ray, Bj ; 
bs3...@att.com; Chornyi, TarasX 
Subject: Re: [opnfv-tech-discuss] Canceled: [barometer] Weekly Call

Will the Prometheus discuss be rescheduled for the call next week?

Aaron

On Tue, Sep 12, 2017 at 4:24 AM, Juan Vidal ALLENDE 
> wrote:
Updated the goto meeting


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



--

AARON SMITH

SENIOR PRINCIPAL SOFTWARE ENGINEER, NFVPE

Red Hat



314 Littleton Rd, Westford, MA 01886

aasm...@redhat.comM: 
617.877.4814
[https://www.redhat.com/files/brand/email/sig-redhat.png]


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

[opnfv-tech-discuss] [Infra] Infra JIRA project issue clean up

[Jack Morgan]

OPNFV,

The Infra work group has a 2 month rotation for Infra project (pharos, 
releng, octopus, security) PTLs to lead the Infra WG meeting. Part of 
the rotation includes clean up the JIRA issues in the Infra JIRA 
project. We have several JIRA issues that are resolved but not closed. 
Since I'm currently leading the meeting, I will be closing older JIRA 
issues that I believe are done. If they are not completed, please feel 
free to re-open the JIRA issue. Please let me know if you have a strong 
objection to this work flow and we can discuss it at our next Infra WG 
meeting.



thanks,

--
Jack Morgan
OPNFV Pharos Intel Lab

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

Re: [opnfv-tech-discuss] Canceled: [barometer] Weekly Call

[Aaron Smith]

Will the Prometheus discuss be rescheduled for the call next week?

Aaron

On Tue, Sep 12, 2017 at 4:24 AM, Juan Vidal ALLENDE <
juan.vidal.alle...@ericsson.com> wrote:

> Updated the goto meeting
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>


-- 

AARON SMITH

SENIOR PRINCIPAL SOFTWARE ENGINEER, NFVPE

Red Hat



314 Littleton Rd, Westford, MA 01886

aasm...@redhat.comM: 617.877.4814

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

Re: [opnfv-tech-discuss] [yardstick] Yardstick results showing Null or Error

[Gaoliang (kubi)]

HI Venkat,

Sorry for the delay in responding.

Some comments in line.

Regards,
Kubi
发件人: vven...@codeaurora.org [mailto:vven...@codeaurora.org]
发送时间: 2017年9月12日 21:26
收件人: Gaoliang (kubi) ; 
opnfv-tech-discuss@lists.opnfv.org; opnfv-us...@lists.opnfv.org; 'Alexandru 
Avadanii' 
主题: RE: [opnfv-tech-discuss] [yardstick] Yardstick results showing Null or Error

Hi Kubi, Alex(ARMBand)

Any inputs/clarifications on the below mail please ?

Thanks for your help.
-Venkat

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of 
Venkateshwarlu Vangala
Sent: Saturday, September 9, 2017 4:12 PM
To: Gaoliang (kubi) 
>; 
opnfv-tech-discuss@lists.opnfv.org; 
opnfv-us...@lists.opnfv.org
Subject: [opnfv-tech-discuss] [yardstick] Yardstick results showing Null or 
Error


Hi Kubi and Yardstick team,

Thanks for your information on the yardstick earlier.
I just collected the old results from Grafana by going through each of the 
tests for a specific date range as suggested. Below is the table. Intel C 
release below points based on the Yardstick report.
Request you to please clarify the below questions and Sorry for many questions 
as this may be useful for others as wel.


  1.  Why some of the results of the test cases are showing either error or 
null if I query them as shown below as NA/error ?
[Kubi] I believe there should be some test date in influxdb during the time 
range. I will  give you the root cause after I check with the influxdb and 
grafana config. It should be related to the “Mean”  of Grafana function.

  1.  Is SLA to be defined for some cases ?
[Kubi] we have give some reference SLA for some test case. But that is not a 
standard. Just give by yardstick developer based on some testing experience. As 
I said, we will try to analyze the result by the Tool, then give some more 
reasonable SLA in future release.

  1.  For a particular test, the test runs for multiple iterations say on a 
specific day. How is the single number achieved ? Is it average of those 
multiple iterations on a specific day and how is Grafana picking the average of 
those multiple iterations ?
[Kubi] yes, It is average of those multiple iterations on a specific day, 
Grafana provide the Mean function for the data. It need admin root to config 
that with each graph.


  1.  How about other test cases as default only these test cases run say for 
os-nosdn-nofeature-noha ? Is it based on the scenarios ?
[Kubi]   we have different test suites for each scenario. Please check the 
below link
https://git.opnfv.org/yardstick/tree/tests/opnfv/test_suites
As the maximum time for each CI job is 3 hours,  we didn’t put all test cases 
into one scenario.  Only find some typical test cases to make them with CI jobs.

Please help in answering the questions.

Thanks
-Venkat






May 2,2017 to Aug 30,2017 tests conducted
















arm-pod1


Linux Foundation-pod2

/huawei-pod (Intel)


SLA


Intel

C-Release


Units


OPNFV_YARDSTICK_TC002_NETWORK LATENCY


1.26


1.08


10


0.55


ms


OPNFV_YARDSTICK_TC005_STORAGE PERFORMANCE


217.2


137.29


400


200


MB/s


OPNFV_YARDSTICK_TC010_MEMORY LATENCY


NA


1.61


30


1.2


ns


OPNFV_YARDSTICK_TC011_PACKET DELAY VARIATION BETWEEN VMs


0.1193


0.0133


 NA


0.0067


ms


OPNFV_YARDSTICK_TC012_MEMORY BANDWIDTH


3.7


19.8


15


17.6


GB/s


OPNFV_YARDSTICK_TC014_PROCESSING SPEED


610


3827


 NA


3150


score


OPNFV_YARDSTICK_TC037_LATENCY


NA(error)


NA(error)


 NA


15


ms


OPNFV_YARDSTICK_TC037_CPU LOAD


NA(error)


NA(error)


 NA


2


%


OPNFV_YARDSTICK_TC037_THROUGHPUT


NA(error)


NA(error)


 NA


433000


pps


OPNFV_YARDSTICK_TC037_PACKET LOSS


NA(error)


NA(error)


 NA


550


packets


OPNFV_YARDSTICK_TC069_Memory Bandwidth


13


29.4


6


20.45


GB/s


OPNFV_YARDSTICK_TC070_Memory Utilization


NA


NA


 NA


235


MB


OPNFV_YARDSTICK_TC071_Cache Utilization


NA


NA


 NA


208


MB


OPNFV_YARDSTICK_TC072_Network Utilization


NA


NA


 NA


200


KPPS


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

Re: [opnfv-tech-discuss] [yardstick] Yardstick results showing Null or Error

[vvenkat]

Hi Kubi, Alex(ARMBand) 

 

Any inputs/clarifications on the below mail please ?

 

Thanks for your help.

-Venkat

 

From: opnfv-tech-discuss-boun...@lists.opnfv.org
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of
Venkateshwarlu Vangala
Sent: Saturday, September 9, 2017 4:12 PM
To: Gaoliang (kubi) ;
opnfv-tech-discuss@lists.opnfv.org; opnfv-us...@lists.opnfv.org
Subject: [opnfv-tech-discuss] [yardstick] Yardstick results showing Null or
Error

 

 

Hi Kubi and Yardstick team,

 

Thanks for your information on the yardstick earlier. 

I just collected the old results from Grafana by going through each of the
tests for a specific date range as suggested. Below is the table. Intel C
release below points based on the Yardstick report. 

Request you to please clarify the below questions and Sorry for many
questions as this may be useful for others as wel.

 

1.  Why some of the results of the test cases are showing either error
or null if I query them as shown below as NA/error ?
2.  Is SLA to be defined for some cases ?
3.  For a particular test, the test runs for multiple iterations say on
a specific day. How is the single number achieved ? Is it average of those
multiple iterations on a specific day and how is Grafana picking the average
of those multiple iterations ?
4.  How about other test cases as default only these test cases run say
for os-nosdn-nofeature-noha ? Is it based on the scenarios ?

 

Please help in answering the questions.

 

Thanks

-Venkat

 

 


 

May 2,2017 to Aug 30,2017 tests conducted 

 

 

 

 


 

arm-pod1

Linux Foundation-pod2

/huawei-pod (Intel)

SLA

Intel

C-Release

Units


OPNFV_YARDSTICK_TC002_NETWORK LATENCY

1.26

1.08

10

0.55

ms


OPNFV_YARDSTICK_TC005_STORAGE PERFORMANCE

217.2

137.29

400

200

MB/s


OPNFV_YARDSTICK_TC010_MEMORY LATENCY

NA

1.61

30

1.2

ns


OPNFV_YARDSTICK_TC011_PACKET DELAY VARIATION BETWEEN VMs

0.1193

0.0133

 NA

0.0067

ms


OPNFV_YARDSTICK_TC012_MEMORY BANDWIDTH

3.7

19.8

15

17.6

GB/s


OPNFV_YARDSTICK_TC014_PROCESSING SPEED

610

3827

 NA

3150

score


OPNFV_YARDSTICK_TC037_LATENCY

NA(error)

NA(error)

 NA

15

ms


OPNFV_YARDSTICK_TC037_CPU LOAD

NA(error)

NA(error)

 NA

2

%


OPNFV_YARDSTICK_TC037_THROUGHPUT

NA(error)

NA(error)

 NA

433000

pps


OPNFV_YARDSTICK_TC037_PACKET LOSS

NA(error)

NA(error)

 NA

550

packets


OPNFV_YARDSTICK_TC069_Memory Bandwidth

13

29.4

6

20.45

GB/s


OPNFV_YARDSTICK_TC070_Memory Utilization

NA

NA

 NA

235

MB


OPNFV_YARDSTICK_TC071_Cache Utilization

NA

NA

 NA

208

MB


OPNFV_YARDSTICK_TC072_Network Utilization

NA

NA

 NA

200

KPPS

 

___
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-users] [Pharos] Pharos lab for ARM band

[vvenkat]

Hi Alex,

 

Good to see the complete POD is ARM architecture based.

 

-Venkat

 

From: opnfv-users-boun...@lists.opnfv.org
[mailto:opnfv-users-boun...@lists.opnfv.org] On Behalf Of Alexandru Avadanii
Sent: Friday, September 8, 2017 8:53 PM
To: Srikanth Lingala ;
opnfv-us...@lists.opnfv.org; opnfv-tech-discuss@lists.opnfv.org
Cc: svc-armband ; Gorja Gorja ;
Shai Tsur ; Trinath Somanchi ;
Veera.reddy B 
Subject: Re: [opnfv-users] [Pharos] Pharos lab for ARM band

 

Hi,

We don't have such patches, nor do we plan to support old Fuel any more.

We actually don't intend to mix architectures for the new Fuel either, at
least not in the near future.

 

If you want to support this use-case, you will have to implement it
yourself.

I do think the new Fuel is friendlier to this scenario, but again, we never
looked into it.

 

BR,

Alex

 

 

From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com] 
Sent: Friday, September 08, 2017 4:21 PM
To: Alexandru Avadanii; opnfv-us...@lists.opnfv.org
 ; opnfv-tech-discuss@lists.opnfv.org
 
Cc: svc-armband; Bob Monkman; Shai Tsur; Gorja Gorja; Trinath Somanchi;
Veera.reddy B
Subject: RE: [Pharos] Pharos lab for ARM band

 

OK.So, If I apply some patches to Fuel and rebuild Fuel ISO, can I deploy
with mixed (x86 and aarch64) targets in Pharos POD?

If so, can you please point me to those patches?

 

Regards,

Srikanth.

 

From: Alexandru Avadanii [mailto:alexandru.avada...@enea.com] 
Sent: Friday, September 08, 2017 5:54 PM
To: Srikanth Lingala  >; opnfv-us...@lists.opnfv.org
 ; opnfv-tech-discuss@lists.opnfv.org
 
Cc: svc-armband  >; Bob
Monkman  >; Shai Tsur
 >; Gorja Gorja
 >; Trinath Somanchi
 >; Veera.reddy B
 >
Subject: RE: [Pharos] Pharos lab for ARM band

 

Hi,

That is correct, everything is now AArch64 in our PODs.

 

BR,

Alex

 

 

From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com] 
Sent: Friday, September 08, 2017 11:48 AM
To: Alexandru Avadanii; opnfv-us...@lists.opnfv.org
 ; opnfv-tech-discuss@lists.opnfv.org
 
Cc: svc-armband; Bob Monkman; Shai Tsur; Gorja Gorja; Trinath Somanchi;
Veera.reddy B
Subject: RE: [Pharos] Pharos lab for ARM band

 

Hi Alex,

Thanks for the details.

I viewed the following link for reference:

https://wiki.opnfv.org/display/pharos/Enea+Hosting
 

 

So, in the current ENEA Pharos lab, you are using ARM based machines as OS
Controller nodes, Compute nodes and even Jump Host node. Not using any
hybrid POD (with combination of x86 and ARM machines as nodes). Right?

 

Regards,

Srikanth.

 

From: Alexandru Avadanii [mailto:alexandru.avada...@enea.com] 
Sent: Friday, September 08, 2017 12:49 AM
To: Srikanth Lingala  >; opnfv-us...@lists.opnfv.org
 ; opnfv-tech-discuss@lists.opnfv.org
 
Cc: svc-armband  >; Bob
Monkman  >; Shai Tsur
 >
Subject: RE: [Pharos] Pharos lab for ARM band

 

Hi, Srikanth,

I'm glad to hear about new AArch64 hardware joining OPNFV.

 

First, note that Pharos specs require 5 nodes, which depending on the
scenario can be used as 3 controllers + 2 computes, or 1 controller +
computes.

This makes it hard to mix x86 and ARM targets in a Pharos POD. Therefore,
this is not supported by OPNFV Danube 3.0 Fuel - it is not impossible, but
it is out of our current scope.

To add some complexity to that, we have the additional jump server host,
which used to be x86 up to and including the Danube release cycle; starting
with the E release, Armband only support all-AArch64 PODs, including the
jump host.

 

Also note that the old Fuel (used up to and including Danube) was replaced
by the new Fuel, based on Mirantis Cloud Platform (MCP), which on its own
means a lot of changes in 

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

[Cedric OLLIVIER]

Alec,

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

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

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

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

Cédric

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

Re: [opnfv-tech-discuss] [VSPERF] E Release DPDK/OVS/VPP/QEMU versions

[Christian Trautman]

Thank you for the update Martin 

I will keep my document patch for the tunings staged for now locally until we 
can get past this and have you verify the tunings on the CI pod. 

-Christian, 


- Original Message -

From: "MartinX Klozik"  
To: "Christian Trautman"  
Cc: opnfv-tech-discuss@lists.opnfv.org 
Sent: Tuesday, September 12, 2017 3:00:54 AM 
Subject: RE: [opnfv-tech-discuss] [VSPERF] E Release DPDK/OVS/VPP/QEMU versions 



Hi Christian, 



unfortunately I was not able to run CI runs with updated version of vsperf’s 
toolset. The reason is, that all PODs hosted by Intel are not reachable from 
Jenkins running at build.opnfv.org. This situation is caused by update of 
firewall at Intel side and it is not solved yet. 



Thus we won’t be able to properly verify possible update of toolset before the 
fork of stable branch. I suggest to update toolset versions in unfrozen master 
branch after the fork and if vsperf proves itself stable enough, we can discuss 
a possibility to merge these changes to the stable/Euphrates branch afterwards. 



Broken CI is also preventing us to evaluate an impact of your CI tuning tips, 
because CI is not running since 31 st of August. I followed your tips provided 
in Jira to tune CI node (pod12-node3) at Friday 1 st of September and manual TC 
execution looked promising. At first I thought, that broken connection between 
node3 and Jenkins was caused by node configuration changes and reboot, but 
finally I’ve found that it is a generic issue. So for proper evaluation of 
results and fine tuning of vpserf configuration, we have to wait until CI will 
be up again. 



Let’s hope, that Intel will be able to open accidently forbidden port in 
firewall soon. 



Best Regards, 

Martin 


From: Christian Trautman [mailto:ctrau...@redhat.com] 
Sent: Thursday, August 31, 2017 4:49 PM 
To: Klozik, MartinX  
Cc: opnfv-tech-discuss@lists.opnfv.org 
Subject: Re: [opnfv-tech-discuss] [VSPERF] E Release DPDK/OVS/VPP/QEMU versions 





Hi Martin, 





I've tested QEMU 2.9 on some internal tests as well and saw no issues. 





I think moving OVS to 2.7 is a good idea. 2.8.0 is still too new. 





DPDK 17.05 should work fine. I've used it inside guests for some time now 
without issues. I haven't checked it against OVS 2.7 though. 





I think running some tests with the agreed newer versions and giving the green 
light would be a good approach. We should move up a bit for E release if 
possible. 





-Christian, 






- Original Message -



From: "MartinX Klozik" < martinx.klo...@intel.com > 
To: opnfv-tech-discuss@lists.opnfv.org 
Sent: Thursday, August 31, 2017 7:41:15 AM 
Subject: [opnfv-tech-discuss] [VSPERF] E Release DPDK/OVS/VPP/QEMU versions 





Hi vsperf community, 



as of now, vsperf uses following versions of DPDK/OVS/VPP respectively: 





DPDK_TAG ?= v17.02 

OVS_TAG ?= cc3a32f3b6891168cee98812e8f5e3d8a5a52c98 (in general compatible with 
DPDK v17.02, so about 6 months old) 

VPP_TAG ?= v17.04 


QEMU_TAG ?= v2.5.0 




Do we want to keep it as it is for E release? 



In general vsperf is able to run with: 

1) DPDK v17.05 & compatible OVS (cca 2-3 months old where support for 17.05 was 
merged) - which is known to have issues with MULTIQUEUES in the GUESTs, so 
v17.05.1 have to be enforced; However this tag can be installed by standard 
vsperf build scripts, as it is not present in DPDK git repository – in a 
nutshell I would rather avoid this buggy version 

2) DPDK v17.08 & OVS (current master works just fine) – if we would like to 
upgrade – this would be the proper candidate 

3) VPP v17.07 

4) QEMU 2.8.0 (I’ve tested it some time ago) and probably also QEMU 2.9.0 (can 
be easily tested) 





In case there will be an interest to include newer DPDK/OVS/VPP/DPDK versions 
in E release, I can run a several CI runs with selected versions to verify its 
performance and stability and we can take a decision next week, if newer set of 
tools should be used or not. 



Overall, it is just a matter of modification of 

src/package-list.mk 



In case we will keep current DPDK/OVS/VPP/QEMU versions for E release. Then I 
suggest to switch to recent versions in master branch after the fork of 
Euphrates stable branch. 



Please advise, 

Martin 

-- 
Intel Research and Development Ireland Limited 
Registered in Ireland 
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare 
Registered Number: 308263 

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies. 


___ 
opnfv-tech-discuss mailing list 
opnfv-tech-discuss@lists.opnfv.org 

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

[Yuyang (Gabriel)]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Australia Standard Time
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Yuyang (Gabriel):MAILTO:gabriel.yuy...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -discuss:MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Brattain, 
 Ross B":MAILTO:ross.b.bratt...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'S, Deepak
 '":MAILTO:deepa...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Rutuja Sur
 ve:MAILTO:rutuja.r.su...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=AMIT KUMAR
  JAISWAL:MAILTO:amitkumarj...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Manuel Reb
 ellon:MAILTO:mrebel...@sandvine.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=wangyaogua
 ng (A):MAILTO:sunshine.w...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=liyin (F):
 MAILTO:liyi...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Manoj Nira
 nia:MAILTO:manojnira...@gmail.com
DESCRIPTION;LANGUAGE=zh-CN:Hi\,\n\nThe Bottlenecks weekly meeting will be h
 eld at 3:00-4:00 UTC\, Wednesday\, 11:00-12:00 Beijing Time\, Wednesday\, 
 PDT 8:00-9:00 Tuesday.\nWelcome to join our discussion. Details of this me
 eting are shown below.\nAgenda:\n   1.   Intern Reports\na
 ) Monitoring Stress tests - Rutuja\nb) Life-cycle Throughputs Test
  - Amit\n   2.   Yardstick Cooperation on VNF Scale up/out Tests\n
3.   Bottlenecks E Rel. Discussion & Stress testing Discussion\
 n   4.   Action Item Review\n\nMeeting Resources\nPlease join the 
 meeting from your computer\, tablet or smartphone.\nhttps://global.gotomee
 ting.com/join/391235029\n\n\n
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=WE;WKST=SU
SUMMARY;LANGUAGE=zh-CN:[Bottlenecks] Weekly Call
DTSTART;TZID=W. Australia Standard Time:20170913T11
DTEND;TZID=W. Australia Standard Time:20170913T12
UID:04008200E00074C5B7101A82E00870DC4D9EEE2BD301000
 01000F7D55A7BBC8CE14A988141BEC13AB886
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20170912T095114Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=zh-CN:https://global.gotomeeting.com/join/391235029
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:-1578330143
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:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-P1D
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] Canceled: [barometer] Weekly Call

[Juan Vidal ALLENDE]

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:UTC
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+
TZOFFSETTO:+
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+
TZOFFSETTO:+
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Juan Vidal ALLENDE:MAILTO:juan.vidal.alle...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=damien.pow
 e...@intel.com:MAILTO:damien.po...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=tony.b.mcm
 a...@intel.com:MAILTO:tony.b.mcma...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=wesley.cam
 pb...@intel.com:MAILTO:wesley.campb...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=bj.ray@int
 el.com:MAILTO:bj@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=andrew.dui
 g...@intel.com:MAILTO:andrew.duig...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=daniel.par
 k...@intel.com:MAILTO:daniel.par...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=emma.l.fol
 e...@intel.com:MAILTO:emma.l.fo...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=pavan.gupt
 a...@calsoftinc.com:MAILTO:pavan.gu...@calsoftinc.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=romanx.kor
 ynkev...@intel.com:MAILTO:romanx.korynkev...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Mario.Rodr
 ig...@arm.com:MAILTO:mario.rodrig...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=tarasx.cho
 r...@intel.com:MAILTO:tarasx.chor...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=ag1367@att
 .com:MAILTO:ag1...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=acmorton@a
 tt.com:MAILTO:acmor...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=ljlamers@v
 mware.com:MAILTO:ljlam...@vmware.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=sayyadev@c
 isco.com:MAILTO:sayya...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=glenn.seil
 e...@windriver.com:MAILTO:glenn.sei...@windriver.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Scott Mans
 field:MAILTO:scott.mansfi...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=daniel.ber
 n...@bell.ca:MAILTO:daniel.bern...@bell.ca
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=canio.cill
 i...@de.ibm.com:MAILTO:canio.cil...@de.ibm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=lorenzo.to
 mas...@fokus.fraunhofer.de:MAILTO:lorenzo.tomas...@fokus.fraunhofer.de
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=schaganti@
 versa-networks.com:MAILTO:schaga...@versa-networks.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Laurent.La
 po...@sprint.com:MAILTO:laurent.lapo...@sprint.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ola.Liljed
 a...@arm.com:MAILTO:ola.liljed...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Manish.Jag
 g...@cavium.com:MAILTO:manish.ja...@cavium.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Gabor Hal
 ász:MAILTO:gabor.hal...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=yangyanyj@
 chinamobile.com:MAILTO:yangya...@chinamobile.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=bs3131@att
 .com:MAILTO:bs3...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=andrew.vei
 t...@netcracker.com:MAILTO:andrew.vei...@netcracker.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=dd5826@att
 .com:MAILTO:dd5...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=j.javier.a
 r...@gmail.com:MAILTO:j.javier.ar...@gmail.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=prodip.sen
 @hpe.com:MAILTO:prodip@hpe.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=alanmcn@op
 enet.com:MAILTO:alan...@openet.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=meghashree
 .dattatri.kedalagu...@intel.com:MAILTO:meghashree.dattatri.kedalagudde@int
 el.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=calin.gher
 g...@intel.com:MAILTO:calin.gher...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=krishna.j.
 mur...@intel.com:MAILTO:krishna.j.mur...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=PLynch@ixi
 acom.com:MAILTO:ply...@ixiacom.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=ning.sun@i
 

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

[Juan Vidal ALLENDE]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:UTC
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+
TZOFFSETTO:+
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+
TZOFFSETTO:+
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Juan Vidal ALLENDE:MAILTO:juan.vidal.alle...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=damien.pow
 e...@intel.com:MAILTO:damien.po...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=tony.b.mcm
 a...@intel.com:MAILTO:tony.b.mcma...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=wesley.cam
 pb...@intel.com:MAILTO:wesley.campb...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=bj.ray@int
 el.com:MAILTO:bj@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=andrew.dui
 g...@intel.com:MAILTO:andrew.duig...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=daniel.par
 k...@intel.com:MAILTO:daniel.par...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=emma.l.fol
 e...@intel.com:MAILTO:emma.l.fo...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=pavan.gupt
 a...@calsoftinc.com:MAILTO:pavan.gu...@calsoftinc.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=romanx.kor
 ynkev...@intel.com:MAILTO:romanx.korynkev...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Mario.Rodr
 ig...@arm.com:MAILTO:mario.rodrig...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=tarasx.cho
 r...@intel.com:MAILTO:tarasx.chor...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=ag1367@att
 .com:MAILTO:ag1...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=acmorton@a
 tt.com:MAILTO:acmor...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=ljlamers@v
 mware.com:MAILTO:ljlam...@vmware.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=sayyadev@c
 isco.com:MAILTO:sayya...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=glenn.seil
 e...@windriver.com:MAILTO:glenn.sei...@windriver.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Scott Mans
 field:MAILTO:scott.mansfi...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=daniel.ber
 n...@bell.ca:MAILTO:daniel.bern...@bell.ca
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=canio.cill
 i...@de.ibm.com:MAILTO:canio.cil...@de.ibm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=lorenzo.to
 mas...@fokus.fraunhofer.de:MAILTO:lorenzo.tomas...@fokus.fraunhofer.de
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=schaganti@
 versa-networks.com:MAILTO:schaga...@versa-networks.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Laurent.La
 po...@sprint.com:MAILTO:laurent.lapo...@sprint.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ola.Liljed
 a...@arm.com:MAILTO:ola.liljed...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Manish.Jag
 g...@cavium.com:MAILTO:manish.ja...@cavium.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Gabor Hal
 ász:MAILTO:gabor.hal...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=yangyanyj@
 chinamobile.com:MAILTO:yangya...@chinamobile.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=bs3131@att
 .com:MAILTO:bs3...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=andrew.vei
 t...@netcracker.com:MAILTO:andrew.vei...@netcracker.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=dd5826@att
 .com:MAILTO:dd5...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=j.javier.a
 r...@gmail.com:MAILTO:j.javier.ar...@gmail.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=prodip.sen
 @hpe.com:MAILTO:prodip@hpe.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=alanmcn@op
 enet.com:MAILTO:alan...@openet.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=meghashree
 .dattatri.kedalagu...@intel.com:MAILTO:meghashree.dattatri.kedalagudde@int
 el.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=calin.gher
 g...@intel.com:MAILTO:calin.gher...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=krishna.j.
 mur...@intel.com:MAILTO:krishna.j.mur...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=PLynch@ixi
 acom.com:MAILTO:ply...@ixiacom.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=ning.sun@i
 

Re: [opnfv-tech-discuss] [VSPERF] E Release DPDK/OVS/VPP/QEMU versions

[Klozik, MartinX]

Hi Christian,

unfortunately I was not able to run CI runs with updated version of vsperf’s 
toolset. The reason is, that all PODs hosted by Intel are not reachable from 
Jenkins running at build.opnfv.org. This situation is caused by update of 
firewall at Intel side and it is not solved yet.

Thus we won’t be able to properly verify possible update of toolset before the 
fork of stable branch. I suggest to update toolset versions in unfrozen master 
branch after the fork and if vsperf proves itself stable enough, we can discuss 
a possibility to merge these changes to the stable/Euphrates branch afterwards.

Broken CI is also preventing us to evaluate an impact of your CI tuning tips, 
because CI is not running since 31st of August. I followed your tips provided 
in Jira to tune CI node (pod12-node3) at Friday 1st of September and manual TC 
execution looked promising. At first I thought, that broken connection between 
node3 and Jenkins was caused by node configuration changes and reboot, but 
finally I’ve found that it is a generic issue. So for proper evaluation of 
results and fine tuning of vpserf configuration, we have to wait until CI will 
be up again.

Let’s hope, that Intel will be able to open accidently forbidden port in 
firewall soon.

Best Regards,
Martin
From: Christian Trautman [mailto:ctrau...@redhat.com]
Sent: Thursday, August 31, 2017 4:49 PM
To: Klozik, MartinX 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [VSPERF] E Release DPDK/OVS/VPP/QEMU versions

Hi Martin,

I've tested QEMU 2.9 on some internal tests as well and saw no issues.

I think moving OVS to 2.7 is a good idea. 2.8.0 is still too new.

DPDK 17.05 should work fine. I've used it inside guests for some time now 
without issues. I haven't checked it against OVS 2.7 though.

I think running some tests with the agreed newer versions and giving the green 
light would be a good approach. We should move up a bit for E release if 
possible.

-Christian,



From: "MartinX Klozik" 
>
To: 
opnfv-tech-discuss@lists.opnfv.org
Sent: Thursday, August 31, 2017 7:41:15 AM
Subject: [opnfv-tech-discuss] [VSPERF] E Release DPDK/OVS/VPP/QEMU versions

Hi vsperf community,

as of now, vsperf uses following versions of DPDK/OVS/VPP respectively:

DPDK_TAG ?= v17.02
OVS_TAG ?= cc3a32f3b6891168cee98812e8f5e3d8a5a52c98 (in general compatible with 
DPDK v17.02, so about 6 months old)
VPP_TAG ?= v17.04
QEMU_TAG ?= v2.5.0

Do we want to keep it as it is for E release?

In general vsperf is able to run with:

1)  DPDK v17.05 & compatible OVS (cca 2-3 months old where support for 
17.05 was merged) - which is known to have issues with MULTIQUEUES in the 
GUESTs, so v17.05.1 have to be enforced; However this tag can be installed by 
standard vsperf build scripts, as it is not present in DPDK git repository – in 
a nutshell I would rather avoid this buggy version

2)  DPDK v17.08 & OVS (current master works just fine) – if we would like 
to upgrade – this would be the proper candidate

3)  VPP v17.07

4)  QEMU 2.8.0 (I’ve tested it some time ago) and probably also QEMU 2.9.0 
(can be easily tested)


In case there will be an interest to include newer DPDK/OVS/VPP/DPDK versions 
in E release, I can run a several CI runs with selected versions to verify its 
performance and stability and we can take a decision next week, if newer set of 
tools should be used or not.

Overall, it is just a matter of modification of
src/package-list.mk

In case we will keep current DPDK/OVS/VPP/QEMU versions for E release. Then I 
suggest to switch to recent versions in master branch after the fork of 
Euphrates stable branch.

Please advise,
Martin

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

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

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the 

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

[Alec Hothan (ahothan)]

Hi Cedric,

Inline…


From: Cedric OLLIVIER 
Date: Monday, September 11, 2017 at 10:31 PM
To: "Alec Hothan (ahothan)" 
Cc: "Beierl, Mark" , Alexandru Avadanii 
, opnfv-project-leads 
, "opnfv-tech-discuss@lists.opnfv.org" 
, Fatih Degirmenci 

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

Alec,

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


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

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

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

[Alec]
OK I think I understand what you mean now.
I see that the doctor git repo has quite a rocky tagging history, starting with 
2015.1.0, then using danube.3.0 notation and now having to change again on 
possibly a 5.0.0 notation.
I also see that setup.cfg currently sets the metadata version to 2017.9.0
I don’t want to pick on doctor project but this really shows the downside of 
trying to unify an overarching integration project release (in our case OPNFV 
release) and its constituents versioning.

As a side note, I personally prefer to omit the version field in setup.cfg and 
let pbr derive the version directly from the git tagging - but of course this 
requires you can tag your versions with “2017.9.0” which indeed would conflict 
with an hypothetical OPNFV “5.0.0” tag (pbr would not know which one to pick 
since both are semver syntax compliant).




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

[Alec]
How to manage dependencies across packages is an interesting and challenging 
problem but I’d like to focus on the OPNFV project versioning first – and 
hopefully find a good solution that works for everybody.


By the way, I think we can hardly compare OPNFV and FD.io as the last
one is java based (packaging and distributions are done via mvn).
[Alec]
Sorry I was merely pointing to the analogy of using a year and month as 
versioning.

But it's fine to compare with OpenStack projects as we are now
following quite their package rules.

[Alec]
I’m not familiar yet on who does what, are you part of the doctor team?
Would you agree to a solution that allows projects to tag their repo using 
their own semver versioning (such as 2017.9.0) and tag OPNFV releases using a 
prefix such as opnfv-5.0.0 (which will be conveniently ignored by pbr)?
That is what I am trying to get to with all these emails ;-)
I will also take it that you are not in favor of tagging OPNFV release with 
“5.0.0”.


Thanks

  Alec


Cédric

2017-09-11 23:53 GMT+02:00 Alec Hothan (ahothan) 
>:
Cedric,



How to tag is a completely separate discussion and I’m actually very glad
that you bring this up along with pbr ;-)



But I’m curious why you bring up the “2017.09” example as it is not a semver
tag and would not be recognized by pbr?

For example, FD.io/VPP uses year/month to tag their releases (e.g. 17.04)

OpenStack does not impose any tagging on constituent projects (that would
cause a revolt from component owners I can guarantee that)

Semver tagging has been so far always reserved to individual component
tagging.

I am currently feeling pretty uneasy with the looming E release and its
tagging implication which could put all of us in a hole.

If we don’t do anything, we will see “5.0.0” tags on every repo in OPNFV and
that should be a cause for concern for every project owner.

I am sorry to repeat myself but I don’t think everyone has grasped yet the
implication that has on how projects should version their code and how they
can manage their artifacts starting from Euphrates.



Let me clarify again, I am not questioning the lock-step versioning that is
in effect in Euphrates but a far more damaging decision would be to tie the
OPNFV release version to semver tagging and hijack semver tagging for the
purpose of OPNFV releases versioning (e.g. slap tags like “5.0.0” on every
repo).



I would prefer if we could keep an OPNFV prefix for the tags. That was
perfect pre E release (dabube-1.0.0…). For Euphrates, if we do not want to
see the release name (understandably as it is redundant to the release
version) at least keep an opnfv prefix in front of it for the tags (e.g.
“opnfv-5.0.0”) so that project owners can version