Hi,
The Nokia lab architecture is on
https://wiki.opnfv.org/display/pharos/Nokia+Hosting.
You can run TRex on the jump host unless you want to do some custom
installation. The NICs are standard Intel 82599's aka Niantics, so dpdk should
just work.
I do not know how TRex works but I have had some difficulties with Moongen with
the ToR switches. Moongen uses timing packets and these do not go cleanly
through the ToRs, but everything works with a direct connection. Let me know if
you need something unusual.
-Tapio
________________________________________
From: Alec Hothan (ahothan) <ahot...@cisco.com>
Sent: Thursday, March 29, 2018 12:25:00 AM
To: Yuyang (Gabriel); 'Fatih Degirmenci'; 'cedric.olliv...@orange.com';
Tallgren, Tapio (Nokia - FI/Espoo); 'Tim Irnich'; 'BLAISONNEAU David IMT/OLN';
'sridhar....@spirent.com'; 'ross.b.bratt...@intel.com'; 'mark.bei...@emc.com';
'Jose Lausuch'; 'Georg Kunz'
Cc: 'trevor.coo...@intel.com'; Kosonen, Juha (Nokia - FI/Espoo);
'acmor...@att.com'; Wangwulin (Linda); 'rp...@linuxfoundation.org';
'opnfv-tech-discuss@lists.opnfv.org'; 'test...@lists.opnfv.org'
Subject: Re: LDT breakout session summary //Re: ONS Discussion //RE: NFVbench
requirements //RE: check xci pike tags //RE: Update on long duration test
Just want to add the ETA for getting bare metal installation automated by
script would have to be before this summer – which is not that far away (3
months).
To avoid any last minute surprise and further delay, it would be great if Tapio
could identify which jump host to use to run Trex and whether/when it will have
the proper NIC by then. Also note that we should be able to verify the proper
connectivity from TRex to the TOR and back without requiring a bare metal
openstack installation.
Once we get Trex operational, we will be able to run any test that relies on
Trex.
Thanks
Alec
From: "Yuyang (Gabriel)" <gabriel.yuy...@huawei.com>
Date: Tuesday, March 27, 2018 at 7:07 PM
To: "Alec Hothan (ahothan)" <ahot...@cisco.com>, 'Fatih Degirmenci'
<fatih.degirme...@ericsson.com>, "'cedric.olliv...@orange.com'"
<cedric.olliv...@orange.com>, "'Tallgren, Tapio (Nokia - FI/Espoo)'"
<tapio.tallg...@nokia.com>, 'Tim Irnich' <tim.irn...@ericsson.com>,
'BLAISONNEAU David IMT/OLN' <david.blaisonn...@orange.com>,
"'sridhar....@spirent.com'" <sridhar....@spirent.com>,
"'ross.b.bratt...@intel.com'" <ross.b.bratt...@intel.com>,
"'mark.bei...@emc.com'" <mark.bei...@emc.com>, 'Jose Lausuch'
<jalaus...@suse.com>, 'Georg Kunz' <georg.k...@ericsson.com>
Cc: "'trevor.coo...@intel.com'" <trevor.coo...@intel.com>, "'Kosonen, Juha
(Nokia - FI/Espoo)'" <juha.koso...@nokia.com>, "'acmor...@att.com'"
<acmor...@att.com>, "Wangwulin (Linda)" <wangwu...@huawei.com>,
"'rp...@linuxfoundation.org'" <rp...@linuxfoundation.org>,
"'opnfv-tech-discuss@lists.opnfv.org'" <opnfv-tech-discuss@lists.opnfv.org>,
"'test...@lists.opnfv.org'" <test...@lists.opnfv.org>
Subject: LDT breakout session summary //Re: ONS Discussion //RE: NFVbench
requirements //RE: check xci pike tags //RE: Update on long duration test
Hi,
It is really nice to have us gather around and to move things forward!
I have made a brief summary of our discussion today. Please find it below and
comment if there is anything missing or misleading, thanks!
Brief summary LDT breakout discussion
1. SUT deployment
a) We should have a transition solution for SUT deployment, so that
test projects could adapt their test cases
i. Currently,
deploy xci-virtual first on another POD
ii. It could be
triggered through jenkin
iii. Gabriel send the
name list to Fatih to gain access of the deployment
b) It would best to have a script for deploy xci baremetal, so that we
can manually do deployment on Nokia POD
2. LDT CI requirements and set-up
a) For transition solution, we only support job triggering
b) For all the Jenkins requirements, Fatih will come with a solution
later
3. Hardware configurations for Traffic generator
a) NFVbench need bare metal deployment
b) Need to confirm with Tapio about the support for traffic generators
For yesterday’s presentation, please refer to
https://wiki.opnfv.org/display/testing/Long+Duration+Testing.
Thanks,
Gabriel
发件人: Yuyang (Gabriel)
发送时间: 2018年3月16日 10:07
收件人: Alec Hothan (ahothan) <ahot...@cisco.com>; Fatih Degirmenci
<fatih.degirme...@ericsson.com>; cedric.olliv...@orange.com; Tallgren, Tapio
(Nokia - FI/Espoo) <tapio.tallg...@nokia.com>; Tim Irnich
<tim.irn...@ericsson.com>; BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com>; sridhar....@spirent.com;
ross.b.bratt...@intel.com; mark.bei...@emc.com; Jose Lausuch
<jalaus...@suse.com>; Georg Kunz <georg.k...@ericsson.com>
抄送: trevor.coo...@intel.com; Kosonen, Juha (Nokia - FI/Espoo)
<juha.koso...@nokia.com>; acmor...@att.com; Wangwulin (Linda)
<wangwu...@huawei.com>; rp...@linuxfoundation.org;
'opnfv-tech-discuss@lists.opnfv.org' <opnfv-tech-discuss@lists.opnfv.org>;
test...@lists.opnfv.org
主题: ONS Discussion //RE: NFVbench requirements //RE: check xci pike tags //RE:
Update on long duration test
Hi,
Thanks for the suggestion. I agree we should have discussion w.r.t. timeline,
clarifications, etc., according the newly changes.
In the Infra group meeting, it’s discussed that Fatih will help us with the
requirements of long duration CI.
As our POD is provided by Nokia, I think Tapio could help us with hardware
requirements for traffic generators.
The only thing that is not clear is when could we have xci-bare metal deployed.
It would be the best we have a round table F2F meeting about how to move it
forward as you suggested, based on which we could also have our report ready
for TSC and the community.
Best,
Gabriel
From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Thursday, March 15, 2018 10:47 PM
To: Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>; Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>;
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; Tallgren, Tapio
(Nokia - FI/Espoo) <tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>;
Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>;
BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>; Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Kosonen, Juha
(Nokia - FI/Espoo) <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: Re: NFVbench requirements //RE: check xci pike tags //RE: Update on
long duration test
I am not seeing any movement on this front and was expecting questions from the
owners/admin of the long duration test lab… Should we (test wg) actively engage
the lab owners to check for hardware requirements?
I personally have no urgency to get NFVbench working on that particular testbed
but it is more for the long duration test planning 😉 I think it would be good
to put some timeline in place (even tentative) and secure participation from
the lab owners.
I will be at the ONS summit dev forum in 2 weeks, perhaps we should have a
discussion about how to move this forward?
Thanks
Alec
From: "Yuyang (Gabriel)"
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>
Date: Wednesday, February 21, 2018 at 7:43 PM
To: "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>>,
Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>,
"cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>"
<cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>>, "Tallgren,
Tapio (Nokia - FI/Espoo)"
<tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>, Tim Irnich
<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>, BLAISONNEAU David
IMT/OLN <david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>,
"sridhar....@spirent.com<mailto:sridhar....@spirent.com>"
<sridhar....@spirent.com<mailto:sridhar....@spirent.com>>,
"ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>"
<ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>>,
"mark.bei...@emc.com<mailto:mark.bei...@emc.com>"
<mark.bei...@emc.com<mailto:mark.bei...@emc.com>>, Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>, Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: "trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>"
<trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>>, "Kosonen, Juha
(Nokia - FI/Espoo)" <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>,
"acmor...@att.com<mailto:acmor...@att.com>"
<acmor...@att.com<mailto:acmor...@att.com>>, "Wangwulin (Linda)"
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>,
"rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>"
<rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>>
Subject: RE: NFVbench requirements //RE: check xci pike tags //RE: Update on
long duration test
Hi,
I have summarized our discussion in
https://wiki.opnfv.org/display/testing/Long+Duration+Testing.
Please take a look at it to check if there is something missing or incorrect.
Best,
Gabriel
From: Yuyang (Gabriel)
Sent: Tuesday, February 06, 2018 4:43 PM
To: 'Alec Hothan (ahothan)' <ahot...@cisco.com<mailto:ahot...@cisco.com>>;
Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>;
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; Tallgren, Tapio
(Nokia - FI/Espoo) <tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>;
Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>;
BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>; Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Kosonen, Juha
(Nokia - FI/Espoo) <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: RE: NFVbench requirements //RE: check xci pike tags //RE: Update on
long duration test
Okay then, thanks!
I will try my best summarizing the requirements/actions first and send it out
for further review/modification.
Best,
Gabriel
From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Tuesday, February 06, 2018 2:39 AM
To: Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>; Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>;
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; Tallgren, Tapio
(Nokia - FI/Espoo) <tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>;
Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>;
BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>; Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Kosonen, Juha
(Nokia - FI/Espoo) <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: Re: NFVbench requirements //RE: check xci pike tags //RE: Update on
long duration test
The main impediment to any traffic generation (VSPERF or NFVbench) is the
proper hardware configuration and wiring.
From what I have seen the PDF does not address any of the config related to
data plane connectivity to outside the pod.
For the short term, we should focus on this particular pod and try to nail down
the HW setup so we can pass traffic. I can also deploy the NFVbench container
on the jump host manually (and worry about Jenkins deployment later).
I added the instructions/requirements in the etherpad and those should be a
sufficient for the admin of that pod to get going – in case of any question,
please contact me.
The tech talk for vsperf/nfvbench is just my suggestion since a lot of people
have questions on vsperf and nfvbench (will see with Trevor/Sridhar).
The testing-wg meeting is not an easy time slot for me which is why I can’t
make it every week (7am PST – I may be blocked in traffic)
Thanks
Alec
From: "Yuyang (Gabriel)"
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>
Date: Sunday, February 4, 2018 at 7:17 PM
To: "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>>,
Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>,
"cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>"
<cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>>, "Tallgren,
Tapio (Nokia - FI/Espoo)"
<tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>, Tim Irnich
<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>, BLAISONNEAU David
IMT/OLN <david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>,
"sridhar....@spirent.com<mailto:sridhar....@spirent.com>"
<sridhar....@spirent.com<mailto:sridhar....@spirent.com>>,
"ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>"
<ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>>,
"mark.bei...@emc.com<mailto:mark.bei...@emc.com>"
<mark.bei...@emc.com<mailto:mark.bei...@emc.com>>, Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>, Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: "trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>"
<trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>>, "Kosonen, Juha
(Nokia - FI/Espoo)" <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>,
"acmor...@att.com<mailto:acmor...@att.com>"
<acmor...@att.com<mailto:acmor...@att.com>>, "Wangwulin (Linda)"
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>,
"rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>"
<rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>>
Subject: RE: NFVbench requirements //RE: check xci pike tags //RE: Update on
long duration test
Hi Alec,
Thanks a lot for the clarification, really appreciate it! It’s much more clear
now.
In the meantime, since NFVbench, VSPERF and Storperf share a time slot for 3
weeks, how we can schedule these tests properly.
I see Mark suggested that run VSPERF first, then Storperf, then both at the
same time. That is before NFVbench joining in.
Is it simply adding NFVbench into the sequence enough, i.e., VSPERF -> NFVbench
-> Storperf -> VSPERF&NFVbench&Storperf
It is great that you are planning a lighting talk for VSPERF and NFVbench.
Could you also present this talk in Testperf meeting as input or part of the
discussion for the long duration CI. Thanks in advance!
Please my other comments inline
From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Sunday, February 04, 2018 12:47 AM
To: Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>; Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>;
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; Tallgren, Tapio
(Nokia - FI/Espoo) <tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>;
Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>;
BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>; Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Kosonen, Juha
(Nokia - FI/Espoo) <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: Re: NFVbench requirements //RE: check xci pike tags //RE: Update on
long duration test
Hi Gabriel,
In a nutshell, NFVbench is a traffic generator wrapper that has extra features
to facilitate the measurement of NFV type of data plane workloads on any
OpenStack based NFVi platform.
It has the particularity to be self-contained (does not need an external
traffic generator), portable (docker container), relatively efficient and
trivial to use.
It is targeting a completely different use case than VSPERF in that it
considers the NFVi stack to measure as a black box. We could probably have a
session on that comparison in one of the coming OPNFV lightning talk by VSPRF
and NFVbench teams.
See inline…
From: "Yuyang (Gabriel)"
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>
Date: Friday, February 2, 2018 at 10:35 PM
To: "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>>,
Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>,
"cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>"
<cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>>, "Tallgren,
Tapio (Nokia - FI/Espoo)"
<tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>, Tim Irnich
<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>, BLAISONNEAU David
IMT/OLN <david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>,
"sridhar....@spirent.com<mailto:sridhar....@spirent.com>"
<sridhar....@spirent.com<mailto:sridhar....@spirent.com>>,
"ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>"
<ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>>,
"mark.bei...@emc.com<mailto:mark.bei...@emc.com>"
<mark.bei...@emc.com<mailto:mark.bei...@emc.com>>, Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>, Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: "trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>"
<trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>>, "Kosonen, Juha
(Nokia - FI/Espoo)" <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>,
"acmor...@att.com<mailto:acmor...@att.com>"
<acmor...@att.com<mailto:acmor...@att.com>>, "Wangwulin (Linda)"
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>,
"rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>"
<rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>>
Subject: RE: NFVbench requirements //RE: check xci pike tags //RE: Update on
long duration test
Hi Alec,
Thanks for feed backing your requirements. I have some questions which are
elaborated below.
1. I see you mentioned that duration of NFVbench test could be configured
as long as needed. In our current testing, apart from supporting long duration
traffic, all the long duration tests have their purpose. For example, for
VSPERF has defined its tests for Max Forwarding Rate stability under different
settings and etc.:
https://gerrit.opnfv.org/gerrit/#/c/50951/4/docs/testing/developer/devguide/requirements/vswitchperf_ltd.rst;
For Bottlenecks&Yardstick, it tests for the capabilities of management plane,
data plane, etc.:
https://wiki.opnfv.org/display/bottlenecks/Stress+Testing+over+OPNFV+Platform;
for Functest, it tests for the repeatability of the functions of SUT and
validate the functionality of SUT under long term usage. Could you provide some
pointers that documents the purpose of long duration tests in NFVbench? So that
we could better introduce our tests to the community.
[Alec]
NFVbench supports 2 modes of measurements: drop rate measurement at fixed rate
throughput, and NDR/PDR measurement. In the first mode, you specify the
parameters of the traffic (rate, frame size, flow profile…), duration and it
will measure the drop rate during that run.
In the second mode, you provide the drop rate thresholds and it will measure
the highest throughput achievable within that drop rate threshold.
When you issue any measurement request, a lot of things happen behind the
scenes that you as a user do not have to worry about: loading a VM image to
glance, creating the necessary neutron networks, launching the VM image in the
appropriate number of instances, configuring the embedded traffic generator,
verifying packets are passing in both directions, starting the traffic
generation, then collect all the stats and dispose all resources at the end of
the run.
For NFVbench a “long duration test” would generally mean that you run say 1Mpps
at 64B for 1 hour, then at the end of the hour, it will tell you exactly how
many packets were sent, received along with the drop rate and latency.
It would be very easy to combine an NFVbench run with some other activity
running concurrently (e.g. storage perf, control plane) and measure the impact
(you might see more drops or different latency). I believe the bottleneck
project was designed for orchestrating such combined test?
[Gabriel]
Thanks Alec! It is very clear now.
It would be better you also present the lightning talk in Testperf meeting for
some details. In addition, orchestrating tests from NFVbench for Bottlenecks is
a great idea too ☺.
2. I also notice that there are hardware requirements that 2 available
10G links connected to the TOR from jump server and the 2 links must be
configured as trunk port. Do you mean the 2 links are all connected to the
internal network? According to
https://wiki.opnfv.org/display/pharos/Nokia+Hosting, only 1 internal link (P3)
connected to jumber server (P5 is for storage). Could @Tapio elaborate more on
the physical connections from jump server to TOR? Thanks
[Alec]
Well it looks like the jump host has 4x10G links (which could be an Intel X710
NIC), In general 1 of the port would be used for management purpose so it would
be great if we could reserve 2 of the unused ports for traffic generation.
The 2 ports just need to be wired to the TOR and the VLAN switching will take
care of directing the traffic to the right compute node/VM.
You can have a look at the entire packet path in the packet path diagrams in
the NFVbench documentation, they show clearly the 2 phys interfaces connecting
the traffic generator and the TOR switch
http://docs.opnfv.org/en/latest/submodules/nfvbench/docs/testing/user/userguide/readme.html#supported-packet-paths
The current version of NFVbench only supports VLAN based tenant networks (which
is the most widely deployed neutron configuration) and can be easily extended
to support VLAN based provider network (in case the deployed pod does not
support tenant networks which is unlikely). Overlays such as VxLAN are not
currently supported.
[Gabriel]
I guess we should ask for @Tapio for help here.
3. There is a requirement about DPDK. However, currently, we only
consider os-nosdn-nofeature-ha scenario for xci-baremetal. I do not know if
xci-baremetal support DPDK yet. Could @david.blaisonneau provide some
informations ? If DPDK is not supported, you probably need to install DPDK-OVS
by yourself. However, this is not recommended unless you could make it a
automation. Does NFVbench has long duration tests aiming only for OVS?
[Alec]
As mentioned above, the system under test is a black box for NFVbench. As such,
it does not care about the exact Neutron mechanism driver used, it does not
care about how the data plane wiring is done on the compute nodes, all it cares
is that Neutron uses VLAN as the encapsulation.
So any NFVi platform based on VLAN will work: OVS, OVS-DPDK, VPP… You can run
it on an OVS based NFVi, it will just show you that packets will start to drop
at a much lower rate than a DPDK based NFVi. You can still run long duration on
OVS, you just use a lower rate (well you could also blast at full line rate on
an OVS system – just don’t expect many packets to come back).
The DPDK requirement is solely on the jump host because the embedded traffic
generator (TRex) requires a DPDK interface to send/receive packets.
That is why the NIC on the jump host must support DPDK.
[Gabriel]
As to the DPDK on jump server, it seems like a one time job. Should NFVbench
team take care of this?
- if you do not have the priviledge to install DPDK after you get the access to
the POD, we should resort to Tapio then
Moreover, as to my knowledge, VSPERF will install DPDK before tests. If
NFVbench run after VSPERF, it probably does not to need install DPDK again.
Thanks
Alec
Thanks,
Gabriel
From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Friday, February 02, 2018 11:53 PM
To: Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>; Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>;
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; Tallgren, Tapio
(Nokia - FI/Espoo) <tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>;
Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>;
BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>; Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Kosonen, Juha
(Nokia - FI/Espoo) <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: Re: NFVbench requirements //RE: check xci pike tags //RE: Update on
long duration test
I have added the requirements for NFVbench. The only thing new compared to
other testing tools is that we’re spec’ing for data plane traffic injection so
there will be some hardware requirements (see etherpad) on the jump host (where
the NFVbench container runs) and on the TOR (configuration of the ports used
for traffic injection).
I’m not sure if testing tool containers deployments are inside VM? As discussed
previously with Fatih, NFVbench must run natively on bare metal because it
needs to access the NIC card using DPDK. So the deployment of NFVbench
container might be different than the other testing tools.
Thanks
Alec
From: "Yuyang (Gabriel)"
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>
Date: Thursday, February 1, 2018 at 5:14 PM
To: "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>>,
Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>,
"cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>"
<cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>>, "Tallgren,
Tapio (Nokia - FI/Espoo)"
<tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>, Tim Irnich
<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>, BLAISONNEAU David
IMT/OLN <david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>,
"sridhar....@spirent.com<mailto:sridhar....@spirent.com>"
<sridhar....@spirent.com<mailto:sridhar....@spirent.com>>,
"ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>"
<ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>>,
"mark.bei...@emc.com<mailto:mark.bei...@emc.com>"
<mark.bei...@emc.com<mailto:mark.bei...@emc.com>>, Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>, Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: "trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>"
<trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>>, "Kosonen, Juha
(Nokia - FI/Espoo)" <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>,
"acmor...@att.com<mailto:acmor...@att.com>"
<acmor...@att.com<mailto:acmor...@att.com>>, "Wangwulin (Linda)"
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>,
"rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>"
<rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>>
Subject: NFVbench requirements //RE: check xci pike tags //RE: Update on long
duration test
Hi Alec,
Please find etherpad link below for inputting NFVbench requirements according
to yesterday's meeting.
https://etherpad.opnfv.org/p/long_duration_ci
Best,
Gabriel
-----Original Message-----
From: Yuyang (Gabriel)
Sent: Tuesday, January 30, 2018 4:41 PM
To: 'Fatih Degirmenci'
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>;
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; Tallgren, Tapio
(Nokia - FI/Espoo) <tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>;
Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>;
BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>; Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Kosonen, Juha
(Nokia - FI/Espoo) <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: RE: check xci pike tags //RE: Update on long duration test
Hi Fatih,
Thanks for the explanation!
I guess we could try to run tests over Queen first to see if there is any gap.
After all, our tests should be adaptive regarding at least a few latest
versions of OpenStack and be able to find bugs timely.
Thanks,
Gabriel
-----Original Message-----
From: Fatih Degirmenci [mailto:fatih.degirme...@ericsson.com]
Sent: Tuesday, January 30, 2018 4:28 PM
To: Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>;
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; Tallgren, Tapio
(Nokia - FI/Espoo) <tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>;
Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>;
BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>; Georg Kunz
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Kosonen, Juha
(Nokia - FI/Espoo) <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: Re: check xci pike tags //RE: Update on long duration test
Hi Gabriel,
We don't have a tag on XCI repo pointing to Pike since it was released at the
very early phases of XCI development.
We intend to start tagging the repo once we have Functest running as part of CI
and will definitely have a tag pointing to Queens in few weeks when it gets
released by OpenStack and tested by XCI.
But you can still deploy Pike by changing one variable - it is important to
highlight that this is not officially supported. If something doesn't work, we
might not be able to support you.
http://docs.opnfv.org/en/latest/submodules/releng-xci/docs/xci-user-guide.html#how-to-use
See the advanced usage section. If you set OPENSTACK_OSA_VERSION to stable/pike
before starting the deployment, you should get stable/pike.
/Fatih
On 2018-01-26, 05:59, "Yuyang (Gabriel)"
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>> wrote:
Hi Fatih,
As discussed in the Testperf meeting yesterday, we want to know that if XCI
has tags for Pike release already.
Since our testing projects are still based on Pike, we probably stick to
Pike when XCI bump into Queen.
Thanks,
Gabriel
-----Original Message-----
From: Yuyang (Gabriel)
Sent: Thursday, January 25, 2018 5:26 PM
To: 'Fatih Degirmenci'
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>;
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>; Tallgren, Tapio
(Nokia - FI/Espoo) <tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>;
Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>;
BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Kosonen, Juha
(Nokia - FI/Espoo) <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: RE: Update on long duration test
Hi,
I also agree that it make sense to use the latest stable versions as the
SUT.
Just to add that, our initial plan is for os-nosdn-nofeature scenario and
do not have test cases that need to be run several weeks. Only the ones that
will run hours, or 1 or 2 days (correct me if I am wrong).
So bugs that found by our tests might be able to be feedback in time.
However, if the tests could run for weeks or even months, that's the part I
am not sure if the bug could be feedback to upstream effectively for the target
stable version.
Thanks,
Gabriel
-----Original Message-----
From: Fatih Degirmenci [mailto:fatih.degirme...@ericsson.com]
Sent: Thursday, January 25, 2018 4:43 PM
To: cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>;
Tallgren, Tapio (Nokia - FI/Espoo)
<tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>>; Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>; Tim Irnich
<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>; BLAISONNEAU David
IMT/OLN <david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Kosonen, Juha
(Nokia - FI/Espoo) <juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: Re: Update on long duration test
Hi,
Here is how I think things could work and this is just a quick thought and
you are welcomed to disagree.
As we all know, XCI aims to work against the master since we have many
other ways to get stable versions of the platform.
But this doesn't mean XCI is not useful for the purposes you've been
discussing; long duration test, feature/test project support, and so on.
The way I see this is that, while we continue chasing master on XCI, we
will hit the official versions on the way when they happen.
For example, we will bump XCI to Queens release around the end of February,
when OpenStack releases it.
We will take those versions in to XCI like any other version and test them
as usual with all the scenarios/features we either support or work on
supporting. (os-nosdn-nofeature, os-odl-nofeature, os-odl-sfc, os-odl-bgpvpn,
congress, promise/blazar, ha/masakari and anything else that might be ready by
then.) We will promote/tag versions that use official Queens if/once they pass
our testing and continue as usual, bumping to later versions when we deem
needed.
But XCI moving on doesn't mean you won't be able to use XCI. You will have
possibility to specify certain versions/tags of XCI Framework and scenarios to
deploy and test, for example the tags that correspond to the Queens which gives
you stable release of OpenStack.
At the same time makes it possible for you to provide feedback to upstream
which might be incorporated to Rocky development. (we will not support Queens
maintenance release in XCI obviously.)
/Fatih
On 2018-01-25, 09:31,
"cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>"
<cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>> wrote:
Hello,
I fully agree it makes sense to deploy via XCI the latest stable
versions of OpenStack.
As discussed Portland, it would allow improving OPNFV by introducing
Functional gating via the referent platform (at least in case of Functest).
Then this platform should be ready from day 0 of the next OPNFV release
(stable/pike for F release).
My point is still to create a referent platform (such as devstack for
OpenStack) what XCI could be.
Then XCI could target master but we could (at least) freeze versions
according to OpenStack releases.
Cédric
-----Message d'origine-----
De : Tallgren, Tapio (Nokia - FI/Espoo)
[mailto:tapio.tallg...@nokia.com]
Envoyé : jeudi 25 janvier 2018 08:26
À : Yuyang (Gabriel); Tim Irnich; BLAISONNEAU David IMT/OLN;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>; OLLIVIER Cédric
IMT/OLN; ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
Cc : trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Fatih
Degirmenci; Kosonen, Juha (Nokia - FI/Espoo);
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda);
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Objet : Re: Update on long duration test
Hi,
I would like to understand better the idea of running XCI on long-term
testing and with feature projects. First of all, it makes sense to test feature
projects with XCI, but I am not sure how far that is. So the first step would
be to run feature projects on latest OpenStack on XCI with short-term testing
(which is probably what you meant).
What do we do if something fails after one week of testing with
OpenStack? It does not make sense to make the long-term testing as part of the
gating process, which means that it is always an old version of master that has
failed. Who will analyze the results and report the errors to upstream? Would
it make more sense to test with XCI the latest stable versions of OpenStack etc?
-Tapio
________________________________________
From: Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>
Sent: Thursday, January 25, 2018 4:29:08 AM
To: Tim Irnich;
david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>; Tallgren,
Tapio (Nokia - FI/Espoo);
sridhar....@spirent.com<mailto:sridhar....@spirent.com>; OLLIVIER Cédric
IMT/OLN; ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Fatih
Degirmenci; Kosonen, Juha (Nokia - FI/Espoo);
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda);
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: RE: Update on long duration test
Hi Tim,
Thanks for your suggestion!
In my mind, it’d be better we could report the progress and collect
comments/requirements to/from TSC within 3 weeks.
There is a big holiday (Spring Festival) in China from Feb. 15 – 21,
however, people tend to rest for more days (may be Feb. 13-23).
So I guess we need to initiate the discussion in TSC on Feb. 6 with the
basic set-ups:
1. XCI-Baremetal deployed on the POD
2. Projects adapt their tests over XCI-Baremetal preliminarily
3. Basic requirements collected for the long duration CI
Best,
Gabriel
From: Tim Irnich [mailto:tim.irn...@ericsson.com]
Sent: Wednesday, January 24, 2018 9:12 PM
To: Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com>>;
david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com>;
tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com>; OLLIVIER Cédric
IMT/OLN <cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com>; Jose Lausuch
<jalaus...@suse.com<mailto:jalaus...@suse.com>>
Cc: trevor.coo...@intel.com<mailto:trevor.coo...@intel.com>; Fatih
Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>;
juha.koso...@nokia.com<mailto:juha.koso...@nokia.com>;
acmor...@att.com<mailto:acmor...@att.com>; Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>;
rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>
Subject: RE: Update on long duration test
Hi Gabriel, all,
It would be helpful to bring this up in the TSC for information &
comments once the WG has homed in on how to move forward. When do you think
would be a good time to do this?
Btw, I’m including Jose’s new email address here as well.
Regards, Tim
From: Yuyang (Gabriel) [mailto:gabriel.yuy...@huawei.com]
Sent: Wednesday, January 24, 2018 03:07
To:
david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com><mailto:david.blaisonn...@orange.com>;
tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com><mailto:tapio.tallg...@nokia.com>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com><mailto:sridhar....@spirent.com>;
OLLIVIER Cédric IMT/OLN
<cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com><mailto:cedric.olliv...@orange.com><mailto:cedric.olliv...@orange.com%3e>>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com><mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com><mailto:mark.bei...@emc.com>;
jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com><mailto:jose.laus...@ericsson.com>
Cc:
trevor.coo...@intel.com<mailto:trevor.coo...@intel.com><mailto:trevor.coo...@intel.com>;
Fatih Degirmenci
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com><mailto:fatih.degirme...@ericsson.com><mailto:fatih.degirme...@ericsson.com%3e>>;
juha.koso...@nokia.com<mailto:juha.koso...@nokia.com><mailto:juha.koso...@nokia.com>;
acmor...@att.com<mailto:acmor...@att.com><mailto:acmor...@att.com>; Wangwulin
(Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com><mailto:wangwu...@huawei.com><mailto:wangwu...@huawei.com%3e>>;
Tim Irnich
<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com><mailto:tim.irn...@ericsson.com><mailto:tim.irn...@ericsson.com%3e>>
Subject: RE: Update on long duration test
HI Tapio,
I was on a travel and will start collecting requirements for the long
duration CI in the Testperf meeting and then our mailing list during the next 2
weeks.
Sorry for the delay!
Best,
Gariel
From:
david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com><mailto:david.blaisonn...@orange.com>
[mailto:david.blaisonn...@orange.com]
Sent: Monday, January 22, 2018 11:32 PM
To:
tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com><mailto:tapio.tallg...@nokia.com>;
sridhar....@spirent.com<mailto:sridhar....@spirent.com><mailto:sridhar....@spirent.com>;
Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com><mailto:gabriel.yuy...@huawei.com><mailto:gabriel.yuy...@huawei.com%3e>>;
OLLIVIER Cédric IMT/OLN
<cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com><mailto:cedric.olliv...@orange.com><mailto:cedric.olliv...@orange.com%3e>>;
ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com><mailto:ross.b.bratt...@intel.com>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com><mailto:mark.bei...@emc.com>;
jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com><mailto:jose.laus...@ericsson.com>
Cc:
trevor.coo...@intel.com<mailto:trevor.coo...@intel.com><mailto:trevor.coo...@intel.com>;
fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com><mailto:fatih.degirme...@ericsson.com>;
juha.koso...@nokia.com<mailto:juha.koso...@nokia.com><mailto:juha.koso...@nokia.com>;
acmor...@att.com<mailto:acmor...@att.com><mailto:acmor...@att.com>; Wangwulin
(Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com><mailto:wangwu...@huawei.com><mailto:wangwu...@huawei.com%3e>>;
tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com><mailto:tim.irn...@ericsson.com>
Subject: Re: Update on long duration test
Hi Tapio,
the patch allowing deployment on baremetal is still in
review/correction phase. I will use this pod as soon as the patch will be
stabilized (i hope at the end of the week or the next one)
BR
David
--
--
David BLAISONNEAU
NFV platforms - OPNFV and ONAP contributor Orange - IMT / OLN / CNC /
NCA / SINA
tel: +33 (0)2 96 07 27 93
email:
david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com><mailto:david.blaisonn...@orange.com>
2, avenue Pierre Marzin 22307 LANNION Cedex - France
Le lundi 22 janvier 2018 à 08:46 +0000, Tallgren, Tapio (Nokia -
FI/Espoo) a écrit :
Hi all,
Any updates on the Long Duration Testing? The pod seems to be pretty
vacant at the moment.
-Tapio
________________________________________
From:
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com><mailto:cedric.olliv...@orange.com>
<cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com><mailto:cedric.olliv...@orange.com><mailto:cedric.olliv...@orange.com%3e>>
Sent: Wednesday, November 29, 2017 6:36:22 PM
To: Sridhar Rao; BLAISONNEAU David IMT/OLN; Ross B' 'Brattain;
mark.beierl; Jose Lausuch; Yuyang (Gabriel)
Cc: Fatih Degirmenci; Tallgren, Tapio (Nokia - FI/Espoo); Kosonen, Juha
(Nokia - FI/Espoo); Wangwulin (Linda); MORTON, ALFRED C (AL); Tim Irnich;
Cooper, Trevor
Subject: RE: Update on long duration test
I confirm that we can't raise this side effects because the OpenStack
resource garbage collector mentioned had been updated then removed for tempest
based testcases.
Yes we can discuss on that topic next week.
Thank you,
Cédric
---- Yuyang (Gabriel) a écrit ----
Hi Cedric,
For the SUT, currently we choose XCI-baremetal.
As to each testing project, I don't recall we have emposed restrictions
on the branches.
I am opt to choose master since we are adding new features and in this
way we could avoid maintaining different branches.
Anyway, I would also suggest we could have a discussion on this during
plugfest due to different needs from projects.
Best,
Gabriel
发件人： cedric.ollivier
收件人： Sridhar
Rao<sridhar....@spirent.com<mailto:sridhar....@spirent.com><mailto:sridhar....@spirent.com><mailto:sridhar....@spirent.com>>;BLAISONNEAU<mailto:sridhar....@spirent.com%3e%3cmailto:sridhar....@spirent.com%3e%3e;BLAISONNEAU>
David
IMT/OLN<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com><mailto:david.blaisonn...@orange.com><mailto:david.blaisonn...@orange.com>>;Ross<mailto:david.blaisonn...@orange.com%3e%3cmailto:david.blaisonn...@orange.com%3e%3e;Ross>
B'
'Brattain<ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com><mailto:ross.b.bratt...@intel.com><mailto:ross.b.bratt...@intel.com>>;mark.beierl<mark.bei...@emc.com<mailto:mark.bei...@emc.com><mailto:mark.bei...@emc.com>>;Jose<mailto:ross.b.bratt...@intel.com%3e%3cmailto:ross.b.bratt...@intel.com%3e%3e;mark.beierl%3cmark.bei...@emc.com%3cmailto:mark.bei...@emc.com%3e%3cmailto:mark.bei...@emc.com%3e%3e;Jose>
Lausuch<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com><mailto:jose.laus...@ericsson.com><mailto:jose.laus...@ericsson.com>>;Yuyang<mailto:jose.laus...@ericsson.com%3e%3cmailto:jose.laus...@ericsson.com%3e%3e;Yuyang>
(Gabriel)<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com><mailto:gabriel.yuy...@huawei.com><mailto:gabriel.yuy...@huawei.com><mailto:gabriel.yuy...@huawei.com%3e%3cmailto:gabriel.yuy...@huawei.com%3e>>
抄送： Fatih
Degirmenci<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com><mailto:fatih.degirme...@ericsson.com><mailto:fatih.degirme...@ericsson.com>>;Tapio<mailto:fatih.degirme...@ericsson.com%3e%3cmailto:fatih.degirme...@ericsson.com%3e%3e;Tapio>
Tallgren, (Nokia -
FI/Espoo)<tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com><mailto:tapio.tallg...@nokia.com><mailto:tapio.tallg...@nokia.com>>;juha.kosonen<juha.koso...@nokia.com<mailto:juha.koso...@nokia.com><mailto:juha.koso...@nokia.com>>;Wangwulin<mailto:tapio.tallg...@nokia.com%3e%3cmailto:tapio.tallg...@nokia.com%3e%3e;juha.kosonen%3cjuha.koso...@nokia.com%3cmailto:juha.koso...@nokia.com%3e%3cmailto:juha.koso...@nokia.com%3e%3e;Wangwulin>
(Linda)<wangwu...@huawei.com<mailto:wangwu...@huawei.com><mailto:wangwu...@huawei.com><mailto:wangwu...@huawei.com>>;MORTON<mailto:wangwu...@huawei.com%3e%3cmailto:wangwu...@huawei.com%3e%3e;MORTON>,
ALFRED C
(AL)<acmor...@att.com<mailto:acmor...@att.com><mailto:acmor...@att.com><mailto:acmor...@att.com>>;'Tim<mailto:acmor...@att.com%3e%3cmailto:acmor...@att.com%3e%3e;'Tim>
Irnich'<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com><mailto:tim.irn...@ericsson.com><mailto:tim.irn...@ericsson.com>>;Cooper<mailto:tim.irn...@ericsson.com%3e%3cmailto:tim.irn...@ericsson.com%3e%3e;Cooper>,
Trevor<trevor.coo...@intel.com<mailto:trevor.coo...@intel.com><mailto:trevor.coo...@intel.com><mailto:trevor.coo...@intel.com><mailto:trevor.coo...@intel.com%3e%3cmailto:trevor.coo...@intel.com%3e>>
主题： RE: Update on long duration test
时间： 2017-11-29 15:28:59
Hello,
Both options are fine and allow running our functest-components
container multiple times in a row.
I would prefer the most challenging option and then to run functest +
bottlenecks + yardstick.
We rewrote our OpenStack resource garbage collector for E but we must
ensure that our tests can't raise side effects to the 2 other projects. I will
double check internally.
Could you please confirm we select E and/or master for long duration
tests?
Cédric
---- Yuyang (Gabriel) a écrit ----
Hi Cedric,
Thanks for the update. Currently each two projects share a 2-weeks time
slot, i.e., Bottlenecks and Yardstick share a time slot, Vsperf and Storperf
share a time slot.
For functest, I have 2 proposals: 1) functest could along have a time
slot with 1 week long; 2) Bottlenecks, Yardstick and Functest share a time slot
with 3 weeks’ long.
What do you think of it?
Thanks,
Gabriel
From:
cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com><mailto:cedric.olliv...@orange.com>
[mailto:cedric.olliv...@orange.com]
Sent: Tuesday, November 28, 2017 9:27 PM
To: Yuyang (Gabriel)
<gabriel.yuy...@huawei.com<mailto:gabriel.yuy...@huawei.com><mailto:gabriel.yuy...@huawei.com><mailto:gabriel.yuy...@huawei.com%3e>>;
Rao, Sridhar
<sridhar....@spirent.com<mailto:sridhar....@spirent.com><mailto:sridhar....@spirent.com><mailto:sridhar....@spirent.com%3e>>;
BLAISONNEAU David IMT/OLN
<david.blaisonn...@orange.com<mailto:david.blaisonn...@orange.com><mailto:david.blaisonn...@orange.com><mailto:david.blaisonn...@orange.com%3e>>;
'Brattain, Ross B'
<ross.b.bratt...@intel.com<mailto:ross.b.bratt...@intel.com><mailto:ross.b.bratt...@intel.com><mailto:ross.b.bratt...@intel.com%3e>>;
mark.bei...@emc.com<mailto:mark.bei...@emc.com><mailto:mark.bei...@emc.com>;
Jose Lausuch
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com><mailto:jose.laus...@ericsson.com><mailto:jose.laus...@ericsson.com%3e>>
Cc: 'Fatih Degirmenci'
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com><mailto:fatih.degirme...@ericsson.com><mailto:fatih.degirme...@ericsson.com%3e>>;
Tallgren, Tapio (Nokia - FI/Espoo)
<tapio.tallg...@nokia.com<mailto:tapio.tallg...@nokia.com><mailto:tapio.tallg...@nokia.com><mailto:tapio.tallg...@nokia.com%3e>>;
juha.koso...@nokia.com<mailto:juha.koso...@nokia.com><mailto:juha.koso...@nokia.com>;
Wangwulin (Linda)
<wangwu...@huawei.com<mailto:wangwu...@huawei.com><mailto:wangwu...@huawei.com><mailto:wangwu...@huawei.com%3e>>
Subject: RE: Update on long duration test
Hello,
About Functest, we could run tempest_smoke_serial (<30 minutes) several
times in a row and expect the same good result.
If the duration is quite long, we could also consider the components
suites (> 4 hours) which includes full rally and tempest testcases.
https://wiki.opnfv.org/display/functest/Run+Alpine+Functest+containers
By the way, it could be interesting to disable the Functest garbage
collector to check if they are remaining OpenStack resources after all runs.
Cédric
De : Yuyang (Gabriel) [mailto:gabriel.yuy...@huawei.com]
Envoyé : lundi 27 novembre 2017 02:27
À : Rao, Sridhar; BLAISONNEAU David IMT/OLN; 'Brattain, Ross B';
OLLIVIER Cédric IMT/OLN;
mark.bei...@emc.com<mailto:mark.bei...@emc.com><mailto:mark.bei...@emc.com><mailto:mark.bei...@emc.com<mailto:mark.bei...@emc.com%3e%3cmailto:mark.bei...@emc.com>>;
Jose Lausuch
Cc : 'Fatih Degirmenci'; Tallgren, Tapio (Nokia - FI/Espoo);
juha.koso...@nokia.com<mailto:juha.koso...@nokia.com><mailto:juha.koso...@nokia.com><mailto:juha.koso...@nokia.com<mailto:juha.koso...@nokia.com%3e%3cmailto:juha.koso...@nokia.com>>
Objet : Update on long duration test
Hi,
It’s been 4 weeks since we got the POD from Nokia for the long duration
test.
We’d better make an update on the progress/info for Infra group. i.e.,
in Infra meeting.
According to https://jira.opnfv.org/browse/INFRA-154, only David and I
have got the credentials. Please apply for the access if you don’t.
Another information regarding the test cases should be updated.
Bottlenecks currently plans 2-3 test cases for the long duration test,
regarding the capability of the SUT simultaneously creates/destroy/verification
stacks/VMs, long duration traffic for co-existing stacks/VMs, limit testing for
baseline traffic for NIC/ovs…
Is there any update/plan on the test cases from
vsperf/storperf/yardstick/functest?
I also expect that we could have a short discussion on the XCI
deployment and CI chain set-up in the meeting as base for plugfest.
Thanks,
Gabriel
_________________________________________________________________________________________________________________________
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.
_________________________________________________________________________________________________________________________
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.
_________________________________________________________________________________________________________________________
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.
_________________________________________________________________________________________________________________________
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.
_________________________________________________________________________________________________________________________
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
