Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

[David McBride]

UPDATE Oct 13, 2017

*Scenario Summary*

Total (listed on scenario status page and found in Jenkins) 52
Pass Deploy 63%
Fail Deploy 19%
Not Running 17%
Functest results 69%
YardStick results 58%

*UPDATE on Issues:*

   1. *Chinese National Holiday.  *The Huawei lab is back online and Joid,
   Compass, and Yardstick Jenkins jobs are running again.
   2. *Intel lab firewall reconfiguration.*  The workaround implemented by
   the release engineering tea was successful and the lab resources are once
   again available for use in CI.
   3. *Docker builds.*  See RELENG-315
   .  This issue was mitigated by
   applying additional resources, as well as changes to the script.



On Mon, Oct 2, 2017 at 5:33 PM, David McBride 
wrote:

> Updated installer and scenario data after the weekend:
>
> *Installer Summary (changes in red)*
>
>
>
> *DEPLOY ON EUPHRATES *
>
> *FUNCTEST DASHBOARD ON EUPHRATES*
>
> *YARDSTICK DASHBOARD ON EUPHRATES*
>
> *APEX*
>
> yes
>
> yes
>
> yes
>
> *COMPASS*
>
> yes
>
> *yes*
>
> yes
>
> *DAISY*
>
> yes
>
> yes
>
> n/a
>
> *FUEL (X86)*
>
> yes
>
> yes
>
> no
>
> *FUEL (AARCH64)*
>
> yes
>
> yes
>
> no
>
> *JOID*
>
> yes
>
> yes
>
> yes
>
> *Scenario Summary*
>
> Total (listed on scenario status page and found in Jenkins) 45
> Pass Deploy 58%
> Fail Deploy 36%
> Not Running 9%
> Functest results 58%
> YardStick results 42%
>
>
> On Fri, Sep 29, 2017 at 7:50 PM, David McBride <
> dmcbr...@linuxfoundation.org> wrote:
>
>> TSC Members,
>>
>> As you know, the Euphrates release is scheduled for Oct 6.  In advance of
>> the next TSC meeting, here is the status of the release. Let me know if you
>> have questions or comments.
>>
>> *Installer Summary*
>>
>>
>>
>> *deploy on euphrates *
>>
>> *Functest dashboard on euphrates*
>>
>> *yardstick dashboard on euphrates*
>>
>> *Apex*
>>
>> yes
>>
>> yes
>>
>> yes
>>
>> *Compass*
>>
>> yes
>>
>> no
>>
>> no
>>
>> *daisy*
>>
>> yes
>>
>> yes
>>
>> n/a
>>
>> *fuel (x86)*
>>
>> yes
>>
>> yes
>>
>> no
>>
>> *fuel (aarch64)*
>>
>> yes
>>
>> no
>>
>> no
>>
>> *Joid*
>>
>> yes
>>
>> yes
>>
>> yes
>>
>>
>> *Scenario Summary*
>>
>> Total (listed on scenario status page and found in Jenkins) 45
>> Pass Deploy 47%
>> Fail Deploy 42%
>> Not Running 11%
>> Functest results 49%
>> YardStick results 38%
>> *Major Issues*
>>
>>1. *Chinese National Holiday.  *There is a Chinese holiday from Oct 1
>>- 8.  During this period, there will be power maintenance in the
>>building where the Huawei lab is located and the pods will be offline.
>>(https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-S
>>eptember/018333.html) This will impact the Compass and JOID
>>installers, as well as all of the projects that depend on those 
>> installers. The
>>Yardstick project will also be impacted by the Huawei lab outage.
>>2. *Intel lab firewall reconfiguration.*  The status remains
>>unchanged.  In the mean time, the LF release engineering team has
>>identified a workaround which could be in place by Monday or Tuesday.
>>The main impact has been that the Apex, Compass, and JOID installers have
>>had to shift builds to an alternate POD, thereby reducing capacity.  In
>>addition, the VSPerf and KVM4NFV projects are without CI support.
>>3. *Docker builds.*  See RELENG-315
>>.  With the increase of the
>>number of docker jobs in Euphrates, there have been a lot of failures due
>>to timeouts.  This has been partially resolved with additional capacity 
>> and
>>improvements to the script, but remains an open issue.  This affects any
>>project that requires docker builds, such as StorPerf.
>>
>>
>> --
>> *David McBride*
>> Release Manager, OPNFV
>> Mobile: +1.805.276.8018
>> Email/Google Talk: dmcbr...@linuxfoundation.org
>> Skype: davidjmcbride1
>> IRC: dmcbride
>>
>
>
>
> --
> *David McBride*
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>



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

[opnfv-tech-discuss] [IPv6] Project Meeting #70

[HU, BIN]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="HU, BIN":MAILTO:bh5...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
DESCRIPTION;LANGUAGE=en-US:https://global.gotomeeting.com/join/819733085\n+
 1 (312) 757-3126 / Access Code: 819-733-085\n\nHello team\,\n\nHere is the
  information of our IPv6 project meeting #70 to check the status update.\n
 \n-   When: Friday 8:00-9:00 PDT (15:00-16:00 UTC) October 27th\, 2017
 \no   Your local time\n-   Bridge: GoTo Meeting:\n
 o   Web Conferencing: https://global.gotomeeting.com/join/819733085\no
Dial-in only:\n•   United States (Long distance): +1 (312) 75
 7-3126 / Access Code: 819-733-085\n•   More phone numbers: https://g
 lobal.gotomeeting.com/819733085/numbersdisplay.html\n-   Meeting page:
  https://wiki.opnfv.org/display/meetings/ipv6 for agenda and minutes\n-   
 Project wiki page: https://wiki.opnfv.org/display/ipv6/IPv6+Home for a
 ll information and resources related to IPv6 project\n\nLook forward to wo
 rking with everyone.\n\nThanks\nBin\n\n\n
SUMMARY;LANGUAGE=en-US:[IPv6] Project Meeting #70
DTSTART;TZID=Pacific Standard Time:20171027T08
DTEND;TZID=Pacific Standard Time:20171027T09
UID:04008200E00074C5B7101A82E008E03786364E44D301000
 01000B61BC658DE63ED49856F03C830FAC48C
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20171014T010803Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US: +1 (312) 757-3126 / Access Code: 819-733-085
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:1879943137
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] new project proposal: clover

[Wenjing Chu]

Hi OPNFV TSC, and community

To better support cloud native computing for NFV use cases, we are proposing a 
new project "clover" for the OPNFV community. We've put the project proposal on 
the wiki:
https://wiki.opnfv.org/display/PROJ/Clover.

We are scheduling a discussion at the OPNFV tech discussion meeting next week 
on Oct 19 and TSC review agenda 2 weeks from now. Your thoughts/ideas are 
greatly appreciated.

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

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

[Cedric OLLIVIER]

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

Cédric



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

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

[Cedric OLLIVIER]

Hello,

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

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

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

Cédric

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

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

[Alec Hothan (ahothan)]

I would prefer limiting the number of container images because we’re going to 
have a lot more image versions for some projects (to tackle versioned XCI/CD)
So option 2 does not look great for me.
I’d vote for option 1.

Have you guys looked at support for multi-arch docker images?
I find it really interesting and removes the need for an arch specific tag.

http://container-solutions.com/multi-arch-docker-images/

If we could implement this, that would be even better.

   Alec


From:  on behalf of Alexandru 
Avadanii 
Date: Friday, October 13, 2017 at 10:04 AM
To: TECH-DISCUSS OPNFV 
Subject: [opnfv-tech-discuss] Arch-specific Docker tags

Hi,
Cédric pointed out that Docker uses DEB/kernel format for describing the 
architecture of a Docker container.
To align with this, the Functest Docker tags were updated from 
"x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest".

Although the arch-naming convention is not enforced to this format (as long as 
the manifest points for a specific architecture to a specific tag, that tag can 
be named however we want), we agreed that aligning with the Docker internal 
format would be a good idea.

My personal preference would be to duplicate the tags, and have both 
"x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest" 
point to the same image.

Anyway, I think we should agree on a format at the OPNFV-project level, and try 
to use it for all our projects.

So, for multiarch projects that push Docker images, we have at least 3 options:
1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently used 
by Functest);
2. "amd64" + "x86_64" / "arm64" + "aarch64";
3. "x86_64" / "aarch64" (currently used by Storperf);

Note that if the project provides a manifest, arch-specific tags are more or 
less hidden from the end-user, and a simple `docker pull 
opnfv/functest-core:latest' (or without a tag) will fetch the image for the 
current system arch automatically (amd64-latest or arm64-latest for Functest).

Thank you, Cédric, for handling this for Functest on such short notice!

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

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

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

[Alexandru Avadanii]

Hi,
Cédric pointed out that Docker uses DEB/kernel format for describing the 
architecture of a Docker container.
To align with this, the Functest Docker tags were updated from 
"x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest".

Although the arch-naming convention is not enforced to this format (as long as 
the manifest points for a specific architecture to a specific tag, that tag can 
be named however we want), we agreed that aligning with the Docker internal 
format would be a good idea.

My personal preference would be to duplicate the tags, and have both 
"x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest" 
point to the same image.

Anyway, I think we should agree on a format at the OPNFV-project level, and try 
to use it for all our projects.

So, for multiarch projects that push Docker images, we have at least 3 options:
1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently used 
by Functest);
2. "amd64" + "x86_64" / "arm64" + "aarch64";
3. "x86_64" / "aarch64" (currently used by Storperf);

Note that if the project provides a manifest, arch-specific tags are more or 
less hidden from the end-user, and a simple `docker pull 
opnfv/functest-core:latest' (or without a tag) will fetch the image for the 
current system arch automatically (amd64-latest or arm64-latest for Functest).

Thank you, Cédric, for handling this for Functest on such short notice!

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

Re: [opnfv-tech-discuss] [barometer] Vote for new barometer PTL

[Tahhan, Maryam]

Congrats to Aaron, our new barometer PTL! :)

BR
Maryam

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Tahhan, Maryam
Sent: Wednesday, October 11, 2017 5:13 PM
To: MORTON, ALFRED C (AL) ; Foley, Emma L 
; Gherghe, Calin ; Aaron Smith 

Cc: opnfv-...@lists.opnfv.org; Mcmahon, Tony B ; 
Verrall, Timothy ; Power, Damien 
; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [barometer] Vote for new barometer PTL

+ 1 from me too.
Thanks everyone.

From: MORTON, ALFRED C (AL) [mailto:acmor...@att.com]
Sent: Wednesday, October 11, 2017 5:10 PM
To: Foley, Emma L >; 
Gherghe, Calin >; 
Tahhan, Maryam >; Aaron 
Smith >
Cc: Verrall, Timothy 
>; Power, Damien 
>; Mcmahon, Tony B 
>; 
opnfv-...@lists.opnfv.org; 
opnfv-tech-discuss@lists.opnfv.org; 
Aaron Smith >
Subject: RE: [barometer] Vote for new barometer PTL

+1, thanks for stepping-up, Aaron

Al

From: Foley, Emma L [mailto:emma.l.fo...@intel.com]
Sent: Wednesday, October 11, 2017 11:30 AM
To: Gherghe, Calin; Tahhan, Maryam; MORTON, ALFRED C (AL); Aaron Smith
Cc: Verrall, Timothy; Power, Damien; Mcmahon, Tony B; 
opnfv-...@lists.opnfv.org; 
opnfv-tech-discuss@lists.opnfv.org; 
Aaron Smith
Subject: RE: [barometer] Vote for new barometer PTL

+1

Sorry for duplicates, I'll keep this to one thread.


From: Gherghe, Calin
Sent: Wednesday, October 11, 2017 4:25 PM
To: Tahhan, Maryam >; 
'MORTON, ALFRED C (AL)' >; Foley, 
Emma L >; Aaron Smith 
>
Cc: Verrall, Timothy 
>; Power, Damien 
>; Mcmahon, Tony B 
>; 
opnfv-...@lists.opnfv.org; 
opnfv-tech-discuss@lists.opnfv.org; 
Aaron Smith >
Subject: RE: [barometer] Vote for new barometer PTL

+1

From: Tahhan, Maryam
Sent: Wednesday, October 11, 2017 8:21 AM
To: 'MORTON, ALFRED C (AL)' >; Foley, 
Emma L >; Gherghe, Calin 
>; Aaron Smith 
>
Cc: Verrall, Timothy 
>; Power, Damien 
>; Mcmahon, Tony B 
>; Tahhan, Maryam 
>; 
opnfv-...@lists.opnfv.org; 
opnfv-tech-discuss@lists.opnfv.org; 
Aaron Smith >
Subject: [barometer] Vote for new barometer PTL

Barometer committers ...

There have been no further nominations for the Barometer PTL position ... 
therefore Aaron Smith is the sole candidate. To provide a record of this and 
acknowledgement from Barometer committers please respond here indicating your 
approval/disapproval (+1, -1) for Aaron to take over as PTL effective from the 
Euphrates release.

Thanks!

Maryam


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Tahhan, Maryam
Sent: Monday, September 25, 2017 11:30 AM
To: opnfv-...@lists.opnfv.org; 
opnfv-tech-discuss@lists.opnfv.org; 
Aaron Smith >
Cc: Verrall, Timothy 
>; Power, Damien 
>; Mcmahon, Tony B 
>
Subject: [opnfv-tech-discuss] [barometer] Stepping down as barometer PTL post E 
release.


Hi folks,



After much 

[opnfv-tech-discuss] [OPNFV] xci /functest

[morgan.richomme]

Hi

we made some tests using Functest (opnfv/functest-healthcheck and 
functest-smoke - eupĥrates) on xci-baremetal in our labs.


we have reproducible results and would like to discuss with xci group
I did not see xci/functest recent logs on our Jenkins, do I miss something?
As far as I remember, results that look pretty similar to what we show 
on xci/virtual


- opnfv/functest-healthcheck: 3 tests PASS

- opnfv/functest-smoke:
  * vping_ssh: PASS
  * vping_userdata: PASS
  * tempest_smoke_serial: FAIL (success rate: 88% / expected 100%)
  * raly_sanity: FAIL (success rate: 67% / expected 100%)
  * refstack: FAIL (success rate: 92% /expected 100%)
  * snaps_smoke: PASS

tempest_smoke_serial & refstack: the issues are mainly dealing with volume

_tempest_sm__oke_
tempest.api.network.*test_**networks.NetworksIpV6Test.**test_external_network_visibility* 
... fail [0.232s]
tempest.api.network.*test_networks.NetworksTest.test_external_network_visibility* 
... fail [0.240s]

tempest.api.*volume.test_volumes_actions.VolumesV1ActionsTest* ... fail
tempest.api.*volume.test_volumes_actions.VolumesV2ActionsTest* ... fail
tempest.api.volume.*test_volumes_get.VolumesV1GetTest.test_volume_create_get_update_delete* 
... fail [2.072s]
tempest.api.volume.*test_volumes_get.VolumesV1GetTest.test_volume_create_get_update_delete_from_image* 
... fail [1.999s]
tempest.api.volume.*test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete* 
... fail [1.927s]
tempest.api.volume.*test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete_from_image* 
... fail [1.857s]

tempest.api.volume.*test_volumes_list.VolumesV1ListTestJSON* ... fail
tempest.api.volume.*test_volumes_list.VolumesV2ListTestJSON* ... fail
tempest.scenario.*test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops* 
... fail [29.493s]
tempest.scenario.*test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern* 
... fail [3.325s]
tempest.scenario.*test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern* 
... fail [3.328s]


_refstack_
tempest.api.compute.*volumes.test_attach_volume.AttachVolumeTestJSON.test_list_get_volume_attachments* 
[9.194552s] ... FAILED
tempest.api.volume.test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete 
[2.017406s] ... FAILED
tempest.api.volume.*test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete_as_clone* 
[1.461944s] ... FAILED
tempest.api.volume.test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete_from_image 
[2.079463s] ... FAILED


some tests are run in refstack and tempest_smoke_serial and are FAIL in 
both cases of course

the errors on network_visibility are surely due to lab configuration

Rally: errors in Cinder (volume again), Nova (Live migration impacted by 
volume) and Ceilometer (even if service is here, did not look precisely 
at the error)



As Ceph is not supported yet in xci virtual/baremetal but I saw a patch 
recently addressing this.
Anyway, I assume the feedback is valuable all the more as it can be 
confirmed on xci/virtual


So far, regarding test criteria, all the functest smoke runs will be FAIL

I would be interested by any pointer on functest tests on xci in jenkins 
and your view on the test results and the way we manage it (shall we 
exclude some cases/suites)


/Morgan


_

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

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

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

Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Jose Lausuch]

Hi Tim,

My only concern is that by implementing this function inside the test case, we 
might run into exceptions raised if there is a problem with SSH keys or 
whatever other problem accessing the nodes. 

Collecting logs when the test fails makes sense, but it doesn’t harm if we 
collect it when it passes as well. Anyway, if we do it only when having 
failures, I imagine that logic could also be implemented post-job by checking 
the "criteria": “FAIL" value on the DB and executing some j-job to collect the 
logs. This logs could be uploaded to artifact repo for further analysis as we 
do for the Functest logs.

Regards,
Jose





> On 13 Oct 2017, at 09:27, Tim Irnich  wrote:
> 
> Jose, 
>  
> I see the point of avoiding log collection in the code for test execution to 
> avoid false negatives in case something with the log collection itself goes 
> wrong (although I’m wondering a bit if that cannot also be handled by 
> carefully implementing the test pass/fail criteria). 
>  
> There are however cases where we’ll want to collect logs only if a test 
> fails, in order to enable a first tier of offline troubleshooting. You’ll 
> remember the gather_logs function Niko implemented for the bgpvpn tests – 
> that is one example. Can that effectively be handled if we separate things as 
> you suggest?
>  
> Regards, Tim
>  
>  
> From: opnfv-tech-discuss-boun...@lists.opnfv.org 
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
> Sent: Friday, October 13, 2017 09:16
> To: xudan (N) ; Morgan, Jack 
> Cc: opnfv-tech-discuss@lists.opnfv.org
> Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
> installer dependent information in the test tools
>  
> Hi,
>  
> When it comes to log collection, I strongly believe it should be done 
> post-job in our CI pipeline, not as part of the test case. Users can always 
> collect logs manually regardless of the installer tools they use… 
>  
> And regarding making it automated in OPNFV after Functest/Yardstick 
> execution, would it make sense to re-use the PDF (Pod Descriptor File)? 
> Otherwise, we are duplicating config files like pod.yaml or new files with 
> information about the servers… 
> @Jack: is there a possibility to include login information in the PDF (user, 
> password, path to private key, …) of the nodes already deployed?
>  
> Regards,
> Jose
>  
>  
>  
> 
>  
> On 12 Oct 2017, at 03:50, xudan (N)  > wrote:
>  
> Hi Srikanth,
>  
> I have one question. Are the paths of all these log files constant for 
> different environment (Apex, Fuel and commercial deployments)?
> If all paths for different deployments are the same, then using config file 
> to login and getting files can work.
> If not, there will be some errors even though it can login with the config 
> file.
>  
> One more question, what logs do SDNVPN get from all nodes? Are they useful 
> for users? If not, can we have an option to disable it?
>  
> Thanks
> Dan Xu
>  
> From: opnfv-tech-discuss-boun...@lists.opnfv.org 
>  
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org 
> ] On Behalf Of limingjiang
> Sent: Thursday, October 12, 2017 9:24 AM
> To: Srikanth Vavilapalli
> Cc: opnfv-tech-discuss@lists.opnfv.org 
> 
> Subject: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing 
> installer dependent information in the test tools
>  
> Hi Srikanth,
>  
> Yardstick can use a global pod.yaml for test cases.
> Since each test case default use the “pod.yaml” located in 
> “/etc/yardstick/pod.yaml”. so if you put “pod.yaml” here, it can apply to 
> each test case.
> The picture you show below is how yardstick test suite customize the input 
> parameters, so it also support each test case with different “pod.yaml”
> if you give each test case different “pod.yaml”
>  
> BR,
> Rex
>  
> +---+
> 
> + Mingjiang Li (Rex) Mobile: +86 13761275017
> + Shanghai Institute, Huawei
> + No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
> +---+
>  
> 发件人: opnfv-tech-discuss-boun...@lists.opnfv.org 
>  
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org 
> ] 代表 Srikanth Vavilapalli
> 发送时间: 2017年10月12日 9:03
> 收件人: Jose Lausuch; Georg Kunz
> 抄送: opnfv-tech-discuss@lists.opnfv.org 
> 
> 主题: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
> installer dependent information in the test tools
>  
> Thanks everyone for your inputs. 
>  
> So if 

Re: [opnfv-tech-discuss] [HA] OPNFV HA test case evolution

[Georg Kunz]

Awesome, thank you!

Cheers,
Georg

From: Fu Qiao [mailto:fuq...@chinamobile.com]
Sent: Friday, October 13, 2017 11:05 AM
To: Georg Kunz ; 'Yamei Fan' 
Cc: 'Gaoliang (kubi)' ; 'Brattain, Ross B' 
; 'Yin Tony' <14_...@tongji.edu.cn>; 'juan_qiu' 
; 'wucaifu' ; 'lansizhong' 
; Srikanth Vavilapalli 
; opnfv-tech-discuss@lists.opnfv.org
Subject: 答复: [HA] OPNFV HA test case evolution

Sure. I will update the agenda to include this. I will check with Yamei to see 
if she can still make next week’s call. If not, we will arrange another meeting 
the week after the next.

发件人: Georg Kunz [mailto:georg.k...@ericsson.com]
发送时间: 2017年10月13日 16:49
收件人: Fu Qiao >; 'Yamei 
Fan' >
抄送: 'Gaoliang (kubi)' 
>; 'Brattain, Ross B' 
>; 'Yin Tony' 
<14_...@tongji.edu.cn>; 'juan_qiu' 
>; 'wucaifu' 
>; 'lansizhong' 
>; Srikanth 
Vavilapalli 
>; 
opnfv-tech-discuss@lists.opnfv.org
主题: [HA] OPNFV HA test case evolution

Hi,

[Adding the mailing list, so that everyone interested in this topic can follow.]

Well, I wouldn’t mind starting the conversation earlier, but if Yamei is out of 
office, we can of course move the meeting. Just a thought: maybe we can have a 
first call next week to get started. We could briefly talk about the plans of 
the OpenStack QA community they discussed at the last OpenStack PTG.

Georg

From: Fu Qiao [mailto:fuq...@chinamobile.com]
Sent: Friday, October 13, 2017 10:17 AM
To: Georg Kunz >; 
'Yamei Fan' >
Cc: 'Gaoliang (kubi)' 
>; 'Brattain, Ross B' 
>; 'Yin Tony' 
<14_...@tongji.edu.cn>; 'juan_qiu' 
>; 'wucaifu' 
>; 'lansizhong' 
>; Srikanth 
Vavilapalli 
>
Subject: 答复: OPNFV HA test case evolution

Hi, Georg and all. I just heard from Yamei that she will be out of office the 
whole week next week. Is it possible that we move this call to the week after 
the next, which is Oct. 25th?


发件人: Georg Kunz [mailto:georg.k...@ericsson.com]
发送时间: 2017年10月13日 15:14
收件人: Yamei Fan >; 'Fu 
Qiao' >
抄送: 'Gaoliang (kubi)' 
>; 'Brattain, Ross B' 
>; 'Yin Tony' 
<14_...@tongji.edu.cn>; 'juan_qiu' 
>; 'wucaifu' 
>; 'lansizhong' 
>; Srikanth 
Vavilapalli 
>
主题: RE: OPNFV HA test case evolution

Hi all,

Great, thanks a lot. Looking forward to talking to you, folks.

Cheers
Georg

From: Yamei Fan [mailto:fanya...@chinamobile.com]
Sent: Friday, October 13, 2017 9:11 AM
To: 'Fu Qiao' >; Georg 
Kunz >
Cc: 'Gaoliang (kubi)' 
>; 'Brattain, Ross B' 
>; 'Yin Tony' 
<14_...@tongji.edu.cn>; 'juan_qiu' 
>; 'wucaifu' 
>; 'lansizhong' 
>; Srikanth 
Vavilapalli 
>
Subject: 答复: OPNFV HA test case evolution

Yeah, I will prepare some slides.

发件人: Fu Qiao [mailto:fuq...@chinamobile.com]
发送时间: 2017年10月13日 14:44
收件人: 'Georg Kunz' >
抄送: 

[opnfv-tech-discuss] High availability project meeting

[Fu Qiao]

BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 16.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:China Standard Time
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;CN="Georg Kunz";RSVP=TRUE:mailto:georg.k...@ericsson.com
ATTENDEE;CN="'Fan Yamei'";RSVP=TRUE:mailto:fanya...@chinamobile.com
ATTENDEE;CN='wucaifu';RSVP=TRUE:mailto:wuca...@chinamobile.com
ATTENDEE;CN='lansizhong';RSVP=TRUE:mailto:lansizh...@chinamobile.com
ATTENDEE;CN="Tony Yin";RSVP=TRUE:mailto:14_...@tongji.edu.cn
ATTENDEE;CN='juan_qiu';RSVP=TRUE:mailto:juan_...@tongji.edu.cn
ATTENDEE;CN="'Jolliffe, Ian'";RSVP=TRUE:mailto:ian.jolli...@windriver.com
ATTENDEE;CN="'Waines, Greg'";RSVP=TRUE:mailto:greg.wai...@windriver.com
ATTENDEE;CN="'Stefan Arntzen'";RSVP=TRUE:mailto:stefan.arnt...@huawei.com
ATTENDEE;CN="'Yue Yuan'";RSVP=TRUE:mailto:yuan@zte.com.cn
ATTENDEE;CN=opnfv-tech-discuss@lists.opnfv.org;RSVP=TRUE:mailto:opnfv-tech-
	disc...@lists.opnfv.org
ATTENDEE;CN="Bob Monkman";ROLE=OPT-PARTICIPANT;RSVP=TRUE:mailto:Bob.Monkman
	@arm.com
ATTENDEE;CN=Tianhongbo;ROLE=OPT-PARTICIPANT;RSVP=TRUE:mailto:hongbo.tianhon
	g...@huawei.com
ATTENDEE;CN="Canio Cillis";ROLE=OPT-PARTICIPANT;RSVP=TRUE:mailto:canio.cill
	i...@de.ibm.com
CLASS:PUBLIC
CREATED:20171013T090608Z
DESCRIPTION:\nNext Meeting on 13:00-14:00 UTC\, Wednesday\, Oct. 18\n\n\nht
	tps://global.gotomeeting.com/join/391235029  \n\n \n\nToll free NO.\n\nUSA: +1 (571) 317-3116\n\n \n\
	nMeeting ID: 391-235-029\n\n\nAgenda:\n\n\nplans of the OpenStack QA commu
	nity-- Georg Kunz \n\nHA test case plan for F release – Kanglin\n\nHA te
	st case in China Mobile – Fan Yamei (TBD)\n\n \n\n
DTEND;TZID="China Standard Time":20171018T22
DTSTAMP:20171013T090608Z
DTSTART;TZID="China Standard Time":20171018T21
LAST-MODIFIED:20171013T090608Z
ORGANIZER;CN="Fu Qiao":mailto:fuq...@chinamobile.com
PRIORITY:5
SEQUENCE:1
SUMMARY;LANGUAGE=zh-cn:High availability project meeting
TRANSP:OPAQUE
UID:04008200E00074C5B7101A82E00840C1F9CB3344D301000
	01000843484FCFCFAC54EBA4671A27C50507A
X-ALT-DESC;FMTTYPE=text/html:http://schemas.microsoft.com/office/2004/12/omml; xmlns="http://ww
	w.w3.org/TR/REC-html40">
	Next Meeting on 13:00-14:00 UTC\, Wedn
	esday\, Oct. 18https://global.gotomeeting.com/join/391
	235029">https://global.gotomeeting.com/join
	/391235029\;Toll free NO.USA
	: +1 (571) 

[opnfv-tech-discuss] 答复: [HA] OPNFV HA test case evolution

[Fu Qiao]

Sure. I will update the agenda to include this. I will check with Yamei to see 
if she can still make next week’s call. If not, we will arrange another meeting 
the week after the next.

 

发件人: Georg Kunz [mailto:georg.k...@ericsson.com] 
发送时间: 2017年10月13日 16:49
收件人: Fu Qiao ; 'Yamei Fan' 
抄送: 'Gaoliang (kubi)' ; 'Brattain, Ross B' 
; 'Yin Tony' <14_...@tongji.edu.cn>; 'juan_qiu' 
; 'wucaifu' ; 'lansizhong' 
; Srikanth Vavilapalli 
; opnfv-tech-discuss@lists.opnfv.org
主题: [HA] OPNFV HA test case evolution

 

Hi,

 

[Adding the mailing list, so that everyone interested in this topic can follow.]

 

Well, I wouldn’t mind starting the conversation earlier, but if Yamei is out of 
office, we can of course move the meeting. Just a thought: maybe we can have a 
first call next week to get started. We could briefly talk about the plans of 
the OpenStack QA community they discussed at the last OpenStack PTG.

 

Georg

 

From: Fu Qiao [mailto:fuq...@chinamobile.com] 
Sent: Friday, October 13, 2017 10:17 AM
To: Georg Kunz  >; 
'Yamei Fan'  >
Cc: 'Gaoliang (kubi)'  >; 'Brattain, Ross B' 
 >; 'Yin Tony' 
<14_...@tongji.edu.cn  >; 'juan_qiu' 
 >; 'wucaifu' 
 >; 'lansizhong' 
 >; Srikanth 
Vavilapalli  >
Subject: 答复: OPNFV HA test case evolution

 

Hi, Georg and all. I just heard from Yamei that she will be out of office the 
whole week next week. Is it possible that we move this call to the week after 
the next, which is Oct. 25th?

 

 

发件人: Georg Kunz [mailto:georg.k...@ericsson.com] 
发送时间: 2017年10月13日 15:14
收件人: Yamei Fan  >; 
'Fu Qiao'  >
抄送: 'Gaoliang (kubi)'  >; 'Brattain, Ross B' 
 >; 'Yin Tony' 
<14_...@tongji.edu.cn  >; 'juan_qiu' 
 >; 'wucaifu' 
 >; 'lansizhong' 
 >; Srikanth 
Vavilapalli  >
主题: RE: OPNFV HA test case evolution

 

Hi all,

 

Great, thanks a lot. Looking forward to talking to you, folks.

 

Cheers

Georg

 

From: Yamei Fan [mailto:fanya...@chinamobile.com] 
Sent: Friday, October 13, 2017 9:11 AM
To: 'Fu Qiao'  >; Georg 
Kunz  >
Cc: 'Gaoliang (kubi)'  >; 'Brattain, Ross B' 
 >; 'Yin Tony' 
<14_...@tongji.edu.cn  >; 'juan_qiu' 
 >; 'wucaifu' 
 >; 'lansizhong' 
 >; Srikanth 
Vavilapalli  >
Subject: 答复: OPNFV HA test case evolution

 

Yeah, I will prepare some slides.

 

发件人: Fu Qiao [mailto:fuq...@chinamobile.com] 
发送时间: 2017年10月13日 14:44
收件人: 'Georg Kunz'  >
抄送: 'Gaoliang (kubi)'  >; 'Brattain, Ross B' 
 >; 'Yin Tony' 
<14_...@tongji.edu.cn  >; 'juan_qiu' 
 >; 'Fan Yamei' 
 >; 'wucaifu' 
 >; 'lansizhong' 
 >; 'Srikanth 
Vavilapalli'  >
主题: 答复: OPNFV HA test case evolution

 

Sure, we can use the HA project meeting slot.

@Kanglin & Qiujuan, are you available at 9pm-10pm Next Wednesday? 

@Yamei, would you please provide a brief 

[opnfv-tech-discuss] [HA] OPNFV HA test case evolution

[Georg Kunz]

Hi,

[Adding the mailing list, so that everyone interested in this topic can follow.]

Well, I wouldn’t mind starting the conversation earlier, but if Yamei is out of 
office, we can of course move the meeting. Just a thought: maybe we can have a 
first call next week to get started. We could briefly talk about the plans of 
the OpenStack QA community they discussed at the last OpenStack PTG.

Georg

From: Fu Qiao [mailto:fuq...@chinamobile.com]
Sent: Friday, October 13, 2017 10:17 AM
To: Georg Kunz ; 'Yamei Fan' 
Cc: 'Gaoliang (kubi)' ; 'Brattain, Ross B' 
; 'Yin Tony' <14_...@tongji.edu.cn>; 'juan_qiu' 
; 'wucaifu' ; 'lansizhong' 
; Srikanth Vavilapalli 

Subject: 答复: OPNFV HA test case evolution

Hi, Georg and all. I just heard from Yamei that she will be out of office the 
whole week next week. Is it possible that we move this call to the week after 
the next, which is Oct. 25th?


发件人: Georg Kunz [mailto:georg.k...@ericsson.com]
发送时间: 2017年10月13日 15:14
收件人: Yamei Fan >; 'Fu 
Qiao' >
抄送: 'Gaoliang (kubi)' 
>; 'Brattain, Ross B' 
>; 'Yin Tony' 
<14_...@tongji.edu.cn>; 'juan_qiu' 
>; 'wucaifu' 
>; 'lansizhong' 
>; Srikanth 
Vavilapalli 
>
主题: RE: OPNFV HA test case evolution

Hi all,

Great, thanks a lot. Looking forward to talking to you, folks.

Cheers
Georg

From: Yamei Fan [mailto:fanya...@chinamobile.com]
Sent: Friday, October 13, 2017 9:11 AM
To: 'Fu Qiao' >; Georg 
Kunz >
Cc: 'Gaoliang (kubi)' 
>; 'Brattain, Ross B' 
>; 'Yin Tony' 
<14_...@tongji.edu.cn>; 'juan_qiu' 
>; 'wucaifu' 
>; 'lansizhong' 
>; Srikanth 
Vavilapalli 
>
Subject: 答复: OPNFV HA test case evolution

Yeah, I will prepare some slides.

发件人: Fu Qiao [mailto:fuq...@chinamobile.com]
发送时间: 2017年10月13日 14:44
收件人: 'Georg Kunz' >
抄送: 'Gaoliang (kubi)' 
>; 'Brattain, Ross B' 
>; 'Yin Tony' 
<14_...@tongji.edu.cn>; 'juan_qiu' 
>; 'Fan Yamei' 
>; 'wucaifu' 
>; 'lansizhong' 
>; 'Srikanth 
Vavilapalli' 
>
主题: 答复: OPNFV HA test case evolution

Sure, we can use the HA project meeting slot.
@Kanglin & Qiujuan, are you available at 9pm-10pm Next Wednesday?
@Yamei, would you please provide a brief introduction about the HA related 
testcases in our specification, which we plan to automate in the yardstick 
project?
Thank you!

发件人: Georg Kunz [mailto:georg.k...@ericsson.com]
发送时间: 2017年10月12日 17:05
收件人: Fu Qiao >
抄送: 'Gaoliang (kubi)' 
>; 'Brattain, Ross B' 
>; 'Yin Tony' 
<14_...@tongji.edu.cn>; 'juan_qiu' 
>; 'Fan Yamei' 
>; 'wucaifu' 
>; 'lansizhong' 
>; Srikanth 
Vavilapalli 
>
主题: RE: OPNFV HA test case evolution

Hi all,

Thanks a lot for the information. I am for sure interested in having a 
conversation about this. Maybe we can use the HA meeting timeslot next week. 
Just a proposal – I wouldn’t mind discussing this earlier, too. I also 

Re: [opnfv-tech-discuss] [xci] xci - aio installation failed on a ubuntu 16.04 VM

[Markos Chandras]

On 12/10/17 19:33, Srikanth Vavilapalli wrote:
> Hi Markos
> 
> The following is the error I get when I start the opnfv domain. It says 
> "cannot allocate memory". I have 4GB RAM assigned to my vagrant VM where I am 
> bringing up the XCI. May I know what are minimum RAM needs fro XCI AIO flavor?
> 
> vagrant@xci:~$ sudo virsh start opnfv
> error: Failed to start domain opnfv
> error: internal error: early end of file from monitor, possible problem: 
> 2017-10-12T18:29:50.649458Z qemu-system-x86_64: cannot set up guest memory 
> 'pc.ram': Cannot allocate memory
> 
> vagrant@xci:~$ free -m
>   totalusedfree  shared  buff/cache   
> available
> Mem:   3951 6561853  361441
> 2958
> Swap:   511  19 492
> vagrant@xci:~$

The AIO requirements are listed here

https://git.opnfv.org/releng-xci/tree/xci/config/aio-vars

The opnfv VM will need 8G of RAM so your vagrant box has to have more
than that.

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

[Alexandru Avadanii]

Hi, Jack,
No problem, thank you very much for fixing it so fast!

BR,
Alex

From: chenjiankun [mailto:chenjiank...@huawei.com]
Sent: Friday, October 13, 2017 4:40 AM
To: Alexandru Avadanii
Cc: opnfv-project-leads; TSC OPNFV; TECH-DISCUSS OPNFV; Michail Polenchuk; 
David McBride
Subject: RE: [opnfv-tech-discuss] [release][euphrates] Euphrates status

Hi, Alex,

Sorry for causing trouble, since the criteria field in DB has been changed 
yesterday , so the result is not accurate.
And I have done a quick fix in testresults.opnfv.org, see:
 
http://testresults.opnfv.org/reporting/euphrates/yardstick/status-f...@x86.html

For the history data, we still need more days to see the trend.

BR,
Jack Chan

发件人: Alexandru Avadanii [mailto:alexandru.avada...@enea.com]
发送时间: 2017年10月13日 3:42
收件人: David McBride; chenjiankun
抄送: opnfv-project-leads; TSC OPNFV; TECH-DISCUSS OPNFV; Michail Polenchuk
主题: RE: [opnfv-tech-discuss] [release][euphrates] Euphrates status

Hi, David,
Michael is currently on vacation.
The results were looking good yesterday, but meanwhile the history seems to 
have been cleared, probably by a recent change in the script.
I will try to identify the rootcause and ping the proper audience.

BR,
Alex


From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Thursday, October 12, 2017 7:01 PM
To: chenjiankun
Cc: opnfv-project-leads; TSC OPNFV; TECH-DISCUSS OPNFV; Alexandru Avadanii; 
Michail Polenchuk
Subject: Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

+Michail

Thanks, Jack.

I see the test results pages, but no results.  When do you think that we'll see 
results populating the pages?

Also, the deploy results for fuel@x86 do not look very good:

os-nosdn-nofeature-noha

Fuel/MCP

Michael Polenchuk

link

not running

os-nosdn-nofeature-ha

Fuel/MCP

Michael Polenchuk

link

fail

os-nosdn-ovs-noha

Fuel/MCP

Michael Polenchuk

link

not running

os-nosdn-ovs-ha

Fuel/MCP

Michael Polenchuk

[opnfv-tech-discuss] [dovetail][test-wg] Feedback from Dovetail to Test WG

[Georg Kunz]

Hi,

Including the tech-discuss mailing list for better visibility.

Cheers
Georg

From: Georg Kunz
Sent: Thursday, October 12, 2017 1:06 PM
To: Tianhongbo ; Georg Kunz 
; Wenjing Chu ; Cooper, Trevor 
; 'z...@redhat.com' ; 
'lylav...@iol.unh.edu' ; Wanglei (Grakiss) 
; 'fuq...@chinamobile.com' 
; xudan (N) ; Tim Irnich 
; Christopher Price 
Subject: Feedback from Dovetail to Test WG

Hi Dovetailers,

In last week's test WG meeting, we talked about the relationship between 
Dovetail and the test WG in the context of the Dovestack proposal. Prakash was 
not on the call, but there was rather uniform agreement that the test WG is the 
forum for driving the evolution of test cases and test coverage in OPNFV - in 
particular for consumption by Dovetail/CVP.

In general, the interaction between the test WG and Dovetail can still be 
improved. Morgan hence proposed to collect feedback from Dovetail towards the 
test WG and present it to the test WG next week. I have started to put my 
thoughts on this matter in an etherpad:
https://etherpad.opnfv.org/p/dovetail-testwg-feedback-collaboration

I'd like to ask you to add your own thoughts and feedback to the etherpad. 
Hopefully, we can briefly talk about this in tomorrow's call as well.

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

Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Tim Irnich]

Jose,

I see the point of avoiding log collection in the code for test execution to 
avoid false negatives in case something with the log collection itself goes 
wrong (although I’m wondering a bit if that cannot also be handled by carefully 
implementing the test pass/fail criteria).

There are however cases where we’ll want to collect logs only if a test fails, 
in order to enable a first tier of offline troubleshooting. You’ll remember the 
gather_logs function Niko implemented for the bgpvpn tests – that is one 
example. Can that effectively be handled if we separate things as you suggest?

Regards, Tim


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Friday, October 13, 2017 09:16
To: xudan (N) ; Morgan, Jack 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi,

When it comes to log collection, I strongly believe it should be done post-job 
in our CI pipeline, not as part of the test case. Users can always collect logs 
manually regardless of the installer tools they use…

And regarding making it automated in OPNFV after Functest/Yardstick execution, 
would it make sense to re-use the PDF (Pod Descriptor File)? Otherwise, we are 
duplicating config files like pod.yaml or new files with information about the 
servers…
@Jack: is there a possibility to include login information in the PDF (user, 
password, path to private key, …) of the nodes already deployed?

Regards,
Jose




On 12 Oct 2017, at 03:50, xudan (N) 
> wrote:

Hi Srikanth,

I have one question. Are the paths of all these log files constant for 
different environment (Apex, Fuel and commercial deployments)?
If all paths for different deployments are the same, then using config file to 
login and getting files can work.
If not, there will be some errors even though it can login with the config file.

One more question, what logs do SDNVPN get from all nodes? Are they useful for 
users? If not, can we have an option to disable it?

Thanks
Dan Xu

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of limingjiang
Sent: Thursday, October 12, 2017 9:24 AM
To: Srikanth Vavilapalli
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi Srikanth,

Yardstick can use a global pod.yaml for test cases.
Since each test case default use the “pod.yaml” located in 
“/etc/yardstick/pod.yaml”. so if you put “pod.yaml” here, it can apply to each 
test case.
The picture you show below is how yardstick test suite customize the input 
parameters, so it also support each test case with different “pod.yaml”
if you give each test case different “pod.yaml”

BR,
Rex

+---+

+ Mingjiang Li (Rex) Mobile: +86 13761275017
+ Shanghai Institute, Huawei
+ No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
+---+

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Srikanth Vavilapalli
发送时间: 2017年10月12日 9:03
收件人: Jose Lausuch; Georg Kunz
抄送: 
opnfv-tech-discuss@lists.opnfv.org
主题: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Thanks everyone for your inputs.

So if Yardstick based approach is the preferred one, then I am thinking of 
extending the existing Deployment Factory class with a new generic INSTALLER 
type (something like “config-file” or so) which will provide the same interface 
as other adapters (ApexAdapter, FuelAdapter…etc), but instead reads from the a 
configured pod.yaml file to provide Node information. Plz let me know if you 
see any issues with this approach.

One quick question on Yardstick: Looks like Yardstick accepts the custom 
pod.yaml file on a per test case basis as shown in the below example. Can it 
also accept a global pod.yaml file that can be applied to all or a group of 
test cases.
-
file_name: opnfv_yardstick_tc043.yaml
   constraint:
  installer: xxx
  pod: xxx-pod1
   task_args:
  xxx-pod1: '{"pod_info": "etc/yardstick/.../pod.yaml",
  "host": "node1.LF","target": "node2.LF"}'

Thanks
Srikanth

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 

Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Jose Lausuch]

Hi,

When it comes to log collection, I strongly believe it should be done post-job 
in our CI pipeline, not as part of the test case. Users can always collect logs 
manually regardless of the installer tools they use… 

And regarding making it automated in OPNFV after Functest/Yardstick execution, 
would it make sense to re-use the PDF (Pod Descriptor File)? Otherwise, we are 
duplicating config files like pod.yaml or new files with information about the 
servers… 
@Jack: is there a possibility to include login information in the PDF (user, 
password, path to private key, …) of the nodes already deployed?

Regards,
Jose





> On 12 Oct 2017, at 03:50, xudan (N)  wrote:
> 
> Hi Srikanth,
>  
> I have one question. Are the paths of all these log files constant for 
> different environment (Apex, Fuel and commercial deployments)?
> If all paths for different deployments are the same, then using config file 
> to login and getting files can work.
> If not, there will be some errors even though it can login with the config 
> file.
>  
> One more question, what logs do SDNVPN get from all nodes? Are they useful 
> for users? If not, can we have an option to disable it?
>  
> Thanks
> Dan Xu
>  
> From: opnfv-tech-discuss-boun...@lists.opnfv.org 
>  
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org 
> ] On Behalf Of limingjiang
> Sent: Thursday, October 12, 2017 9:24 AM
> To: Srikanth Vavilapalli
> Cc: opnfv-tech-discuss@lists.opnfv.org 
> 
> Subject: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing 
> installer dependent information in the test tools
>  
> Hi Srikanth,
>  
> Yardstick can use a global pod.yaml for test cases.
> Since each test case default use the “pod.yaml” located in 
> “/etc/yardstick/pod.yaml”. so if you put “pod.yaml” here, it can apply to 
> each test case.
> The picture you show below is how yardstick test suite customize the input 
> parameters, so it also support each test case with different “pod.yaml”
> if you give each test case different “pod.yaml”
>  
> BR,
> Rex
>  
> +---+
> 
> + Mingjiang Li (Rex) Mobile: +86 13761275017
> + Shanghai Institute, Huawei
> + No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
> +---+
>  
> 发件人: opnfv-tech-discuss-boun...@lists.opnfv.org 
>  
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org 
> ] 代表 Srikanth Vavilapalli
> 发送时间: 2017年10月12日 9:03
> 收件人: Jose Lausuch; Georg Kunz
> 抄送: opnfv-tech-discuss@lists.opnfv.org 
> 
> 主题: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
> installer dependent information in the test tools
>  
> Thanks everyone for your inputs. 
>  
> So if Yardstick based approach is the preferred one, then I am thinking of 
> extending the existing Deployment Factory class with a new generic INSTALLER 
> type (something like “config-file” or so) which will provide the same 
> interface as other adapters (ApexAdapter, FuelAdapter…etc), but instead reads 
> from the a configured pod.yaml file to provide Node information. Plz let me 
> know if you see any issues with this approach.
>  
> One quick question on Yardstick: Looks like Yardstick accepts the custom 
> pod.yaml file on a per test case basis as shown in the below example. Can it 
> also accept a global pod.yaml file that can be applied to all or a group of 
> test cases. 
> -
> 
> file_name: opnfv_yardstick_tc043.yaml
> 
>constraint:
> 
>   installer: xxx
> 
>   pod: xxx-pod1
> 
>task_args:
> 
>   xxx-pod1: '{"pod_info": "etc/yardstick/.../pod.yaml",
> 
>   "host": "node1.LF","target": "node2.LF"}'
> 
>  
> Thanks
> Srikanth
>  
> From: opnfv-tech-discuss-boun...@lists.opnfv.org 
>  
> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org 
> ] On Behalf Of Jose Lausuch
> Sent: Wednesday, October 11, 2017 10:45 AM
> To: Georg Kunz >
> Cc: opnfv-tech-discuss@lists.opnfv.org 
> 
> Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
> installer dependent information in the test tools
>  
> Hi,
>  
> I would vote for having something similar to Yardstick [1] but centralized in 
> Releng with an easy python lib that enables functions like SCP things to/from 
> the deployed nodes.
>  
> For your third point, log collection shouldn’t be done at test case level. It 
> should 

Re: [opnfv-tech-discuss] New PTL for VSPERF

[Yujun Zhang (ZTE)]

Congratulations, Sridhar Rao!

--
Yujun Zhang


On Fri, Oct 13, 2017 at 12:53 AM Singh, Gurpreet 
wrote:

> Congratulations Sridhar!
>
>
>  Original message 
> From: "Cooper, Trevor" 
> Date: 10/12/17 12:43 PM (GMT-05:00)
> To: opnfv-tech-discuss@lists.opnfv.org, opnfv-...@lists.opnfv.org
> Subject: [opnfv-tech-discuss] New PTL for VSPERF
>
> Congratulations to our new VSPERF PTL … Sridhar Rao from Spirent a leading
> supplier of Network Test Solutions.
>
>
>
>
>
> What is VSPERF? … VSPERF is an automated test-framework and test
> suite based on Industry Test Specifications for measuring data-plane
> performance of the virtual switch including physical and virtual network
> interfaces. The VSPERF architecture is switch and traffic generator
> agnostic and test cases can be easily customized. VSPERF is stand-alone
> i.e. independent of OpenStack so it sources, configures and deploys the
> device-under-test with component versions and network topology defined by
> the user. A new IETF benchmarking specification RFC8204 is based on VSPERF
> work and VSPERF is contributing to development of ETSI NFV test
> specifications.
>
>
>
> How is VSPERF used?   …VSPERF is used as a development tool for
> optimizing switching technologies, qualification of packet processing
> functions and for evaluation of data-path performance. It is also being
> used to study correlations between measured platform metrics and data-plane
> performance.
>
>
>
> What is new in Euphrates?…New test cases, flexibility in
> customizing test-cases, new results display options, improved tool
> resiliency, additional traffic generator support and VPP support.
>
>
>
> What do VSPERF users have to say?
>
>
>
> -  VSPERF provides a platform where the entire Industry can learn
> more about NFVI dataplane benchmarking, and try-out new techniques
> together.
>
>
>
> -  VSPERF CI testing has proven to be a valuable asset when
> examining the consistency and repeatability of the current LTD benchmarks
> with different deployment scenarios and vSwitches.
>
> -  We have found the tool invaluable for the upstream community
> to be able to determine what configuration they want to use for their
> environment
>
> -  Being able to independently quantify the overhead of
> switching, including being able to demonstrate the differences in
> acceleration technologies … is a key benefit
>
>
>
> -  Vswitch is a key element of NFV and … it is us critical to
> qualify the performance of such component and to get reference on testing
> on other PODs.
>
> -  Allow faster "hands-on" comparisons for people wanting to
> verify unbiased test results ... using an open-source tool, with
> open-source software traffic generators to quickly setup and automate tests
>
> -   vSwitch benchmarking is a must-to-do ... Vsperf has
> integrated popular software traffic generator, ready to use, no extra cost.
>
>
>
> /Trevor
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> 
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the taking of
> any action based upon reliance on the contents of this transmission is
> strictly forbidden. If you have received this message in error please
> notify the sender by return e-mail and delete it from your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676 <+44%201293%20767676>
> Fax No. +44 (0) 1293 767677 <+44%201293%20767677>
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300 <(818)%20676-2300>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] High availability project meeting

[Fu Qiao]

BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 16.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:China Standard Time
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;CN="Georg Kunz";RSVP=TRUE:mailto:georg.k...@ericsson.com
ATTENDEE;CN="'Fan Yamei'";RSVP=TRUE:mailto:fanya...@chinamobile.com
ATTENDEE;CN='wucaifu';RSVP=TRUE:mailto:wuca...@chinamobile.com
ATTENDEE;CN='lansizhong';RSVP=TRUE:mailto:lansizh...@chinamobile.com
ATTENDEE;CN="Tony Yin";RSVP=TRUE:mailto:14_...@tongji.edu.cn
ATTENDEE;CN='juan_qiu';RSVP=TRUE:mailto:juan_...@tongji.edu.cn
ATTENDEE;CN="'Jolliffe, Ian'";RSVP=TRUE:mailto:ian.jolli...@windriver.com
ATTENDEE;CN="'Waines, Greg'";RSVP=TRUE:mailto:greg.wai...@windriver.com
ATTENDEE;CN="'Stefan Arntzen'";RSVP=TRUE:mailto:stefan.arnt...@huawei.com
ATTENDEE;CN="'Yue Yuan'";RSVP=TRUE:mailto:yuan@zte.com.cn
ATTENDEE;CN=opnfv-tech-discuss@lists.opnfv.org;RSVP=TRUE:mailto:opnfv-tech-
	disc...@lists.opnfv.org
CLASS:PUBLIC
CREATED:20171013T065857Z
DESCRIPTION: \n\n
DTEND;TZID="China Standard Time":20171018T22
DTSTAMP:20171013T065858Z
DTSTART;TZID="China Standard Time":20171018T21
LAST-MODIFIED:20171013T065857Z
ORGANIZER;CN="Fu Qiao":mailto:fuq...@chinamobile.com
PRIORITY:5
SEQUENCE:0
SUMMARY;LANGUAGE=zh-cn:High availability project meeting
TRANSP:OPAQUE
UID:04008200E00074C5B7101A82E00840C1F9CB3344D301000
	01000843484FCFCFAC54EBA4671A27C50507A
X-ALT-DESC;FMTTYPE=text/html:http://schemas.microsoft.com/office/2004/
	12/omml" xmlns="http://www.w3.org/TR/REC-html40;>\;<
	/body>
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MS-OLK-AUTOSTARTCHECK:FALSE
X-MS-OLK-CONFTYPE:0
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:Reminder
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] [availability]High Availability Project meeting on Oct. 18

[Fu Qiao]

Hi, all. 

I would like to arrange a project meeting to start the discussion about HA
test cases development for F release and future releases. 

I would like to invite my colleague Fan Yamei to introduce the current high
availability test cases in our specification, which we also plan to develop
automation solutions and contribute to the community.

Would Kanglin and Qiujuan also give an brief introduction about your plan of
the HA testcases for F release?

We would also like to coordinate with the Dovetail team to see if the plan
can fit into the dovetail testing plan.

Detailed agenda is as below. Talk to you all at our regular time next
Wednesday.

 


Next Meeting on 13:00-14:00 UTC, Wednesday, Oct. 18


 
https://global.gotomeeting.com/join/391235029

 

Toll free NO.

USA: +1 (571) 317-3116

 

Meeting ID: 391-235-029


Agenda:


HA test case in China Mobile - Fan Yamei

HA test case plan for F release - Kanglin

 

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