[opnfv-tech-discuss] Discussion Topics for Weekly Technical Discussion this Thursday 09/28

[HU, BIN]

Hello community,

Please let me know if you have any topics or issues that need to be discussed 
at our weekly technical discussion this Thursday 09/28.

If no issues or topics, we may cancel the discussion this week.

Thanks
Bin

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

Re: [opnfv-tech-discuss] [OPNFV] [OpenStack] cross collaboration on testing activities

[Mark Voelker]

I think I should be able to make this as well—just need to juggle my schedule a 
little bit. =)  See you there!

At Your Service,

Mark T. Voelker
OpenStack Architect



> On Sep 25, 2017, at 11:33 AM, Andrea Frittoli  
> wrote:
> 
> Hi Morgan, Ildikó,
> 
> the schedule is fine for me.
> 
> I guess we won't be able to answer the questions from the agenda in the 
> allocated time, but it should be enough to get the conversation started; we 
> can the follow up over other communication channels (IRC? Else?).
> 
> Andrea
> 
> On Sun, Sep 24, 2017 at 5:01 PM Ildiko Vancsa  wrote:
> Hi Morgan,
> 
> Thank you for the proposal.
> 
> I agree that we have several areas within testing where it would makes sense 
> to start a closer collaboration.
> 
> I added Mark to the thread as well, he’s the co-chair of our Interoperability 
> Working Group and he’s one of drivers of having coverage for NFV as well in 
> our interoperability tests and certification program.
> 
> I know that we have plans on resiliency and robustness testing as an 
> extension to our current framework. Ghanshyam and Andrea are the main 
> contacts regarding those activities. Ghanshyam is in Japan, which means that 
> we will need to find other forums as well to discuss these topics than the 
> meeting slot next week to be able to involve everyone.
> 
> @Mark @Andrea: Will you be available to attend the meeting on the 28th?
> 
> As for the agenda, I think it looks good as starting point to touch base on 
> the key topics, but I let our experts to voice their opinions as well. :)
> 
> Thanks and Best Regards,
> Ildikó
> 
> 
> > On 2017. Sep 21., at 3:44,  
> >  wrote:
> >
> > Hi,
> >
> > I discussed with Georg on the opportunity to formalize a possible cross 
> > collaboration on testing between OpenStack and OPNFV.
> > He attended the PTG last week and it seems there are possibly more 
> > synergies between the 2 groups.
> >
> > I booked a slot for the next Testing group meeting planned on September 
> > 28th 3 PM UTC (https://global.gotomeeting.com/join/819733085)
> > As agenda 
> > (https://wiki.opnfv.org/display/meetings/Test+Working+Group+Weekly+Meeting) 
> > , I suggest (feel free to amend):
> >
> > Cross collaboration with OpenStack
> >   • OPNFV testing activities overview 5'
> >   • OpenStack NFV testing activities overview 5'
> >   • What could/should be upstreamed? 10'
> >   • Long duration/resiliency/robustness strategy 10'
> >   • Plugfest: common activities? 5'
> > Jose added a topic on XCI, our long duration testing activites are also 
> > linked to XCI and then connected to OpenStack.
> >
> > What is your view?
> > feel free to forward to whom it may concern.
> >
> > /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] [announce] 2018 OPNFV release names

[Yujun Zhang (ZTE)]

+1 for Fraser 

I agree that it could be problematic if we name the release after something
difficult to find in map.

On Tue, Sep 26, 2017 at 12:25 AM Raymond Paik 
wrote:

> All:
>
> Thanks for voting on the release naming poll.
>
> First, for G-release the winner is Gambia (the first African river for
> OPNFV).
>
> For the F-release, the top vote getter was Fenix in Argentina.  However,
> after some research it looks this is a tributary of another river (Deseado
> ), and I wasn't able to find
> photos of Fenix River on the web (or even find it on Google Maps).
>
> I talked to LF marketing colleagues as we've been using river images for
> release marketing, and they do have concerns about going with a river that
> is not well known.  The second choice was Fraser
>  in Canada (the longest river
> in British Columbia) and I suggest going with Fraser as the F-release
> name.  Although Fenix sounds cool, I think it's problematic if you can't
> find it on a map.
>
> Let me know if you have any questions.
>
> Ray
> ___
> 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

Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed

[Yujun Zhang (ZTE)]

I had a quick look at the wiki page and try to understand the rationale
behind proposal.

If I understand it correctly, it is like

- *opnfv-x.y.z* to sync with OPNFV official releasing cycle, i.e. Danube,
Euphrates (opnfv-5.y.z).
- *(optional) x.y.z* for project intermediate release which is managed by
each project.

Please correct me if anything wrong. I would vote +1 based on the
understanding above.

On Tue, Sep 26, 2017 at 3:34 AM Alec Hothan (ahothan) 
wrote:

>
>
> I would like to get a quick vote from any person that works directly or
> indirectly with code in OPNFV
>
>
>
> Please reply with -1, 0 +1
>
>
>
> For using prefixed git tags for the Euphrates release: “opnfv-5.0.0”
>
>
>
> This is a slight change to the plan on record (which was to use “5.0.0”).
> This does NOT impact euphrates deliverables for participating OPNFV
> projects (git tags on stable/euphrates are applied by releng).
>
> The only externally visible effect is the naming of container tags for 
> *Euphrates
> official images* in DockerHub will be named accordingly (e.g.
> “opnfv/functest:opnfv-5.0.0”).
>
> Everything else remains the same.
>
>
>
> If you’d like to know more, the rationale is described here:
> https://wiki.opnfv.org/display/releng/OPNFV+projects+and+OPNFV+release+versioning
> (thanks for Fatih, David, Frank, Tapio for reviewing)
>
> In a nutshell, this adjustment is needed to prepare the path for proper
> continuous delivery support by projects.
>
> Any clarification/questions/discussion can be done over email or at the
> TSC or release meetings tomorrow.
>
>
>
> Thank You.
>
>
>
>   Alec
>
>
>
>
> ___
> 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

Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed

[David McBride]

I plan to devote a large portion of the release meeting to this topic
tomorrow.  Please come prepared with your questions for Alec.  I think that
this change puts us on the path which will eventually lead toward a
consolidated release process that incorporates the quickly evolving XCI
system.  I would like to see that we have sufficient discussion and review
to ensure that we don't inadvertently disturb the Euphrates release, which
is just next week.

David

On Mon, Sep 25, 2017 at 12:33 PM, Alec Hothan (ahothan) 
wrote:

>
>
> I would like to get a quick vote from any person that works directly or
> indirectly with code in OPNFV
>
>
>
> Please reply with -1, 0 +1
>
>
>
> For using prefixed git tags for the Euphrates release: “opnfv-5.0.0”
>
>
>
> This is a slight change to the plan on record (which was to use “5.0.0”).
> This does NOT impact euphrates deliverables for participating OPNFV
> projects (git tags on stable/euphrates are applied by releng).
>
> The only externally visible effect is the naming of container tags for 
> *Euphrates
> official images* in DockerHub will be named accordingly (e.g.
> “opnfv/functest:opnfv-5.0.0”).
>
> Everything else remains the same.
>
>
>
> If you’d like to know more, the rationale is described here:
> https://wiki.opnfv.org/display/releng/OPNFV+projects+
> and+OPNFV+release+versioning (thanks for Fatih, David, Frank, Tapio for
> reviewing)
>
> In a nutshell, this adjustment is needed to prepare the path for proper
> continuous delivery support by projects.
>
> Any clarification/questions/discussion can be done over email or at the
> TSC or release meetings tomorrow.
>
>
>
> Thank You.
>
>
>
>   Alec
>
>
>
>
>



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

Re: [opnfv-tech-discuss] Many failed docker builds

[Aric Gardner]

Hi, Alec, thanks for the feedback.
Can we track this in https://jira.opnfv.org/browse/RELENG-315
-Aric

On Mon, Sep 25, 2017 at 4:49 PM, Alec Hothan (ahothan)
 wrote:
>
>
> This all ties into the versioning of artifacts since you can’t have
> concurrent builds of the same repo (for example from 2 distinct gerrit
> triggers on different patchsets) without proper tagging of the artifacts
> (you can’t just tag them with “latest”)
>
>
>
> I think it would make sense to allow only 1 build at a time per repo but to
> support multiple concurrent container builds from different repos. Timing
> out and the part of the script that checks in a loop if another build is
> ongoing should be removed IMHO since the max concurrency is better checked
> at the Jenkins level.
>
>
>
> Given hardware nowadays have a lot of cores, it would be good to allow
> multiple queues (or slaves) per hardware (up to 1 per core).
>
> Repos that build more than 1 container should have a way to provide the
> build order if they require one.
>
>
>
>
>
> Alec
>
>
>
>
>
>
>
>
>
> From:  on behalf of "Beierl,
> Mark" 
> Date: Monday, September 25, 2017 at 11:47 AM
> To: "opnfv-tech-discuss@lists.opnfv.org"
> 
> Subject: [opnfv-tech-discuss] Many failed docker builds
>
>
>
> Hello,
>
>
>
> Not sure who can help with this.  Right now there are 4 or more executor
> slots than can execute any given opnfv-docker.sh script.  The problem is
> with so many docker jobs being introduced in Euphrates, we are getting a lot
> of failures due to timeouts.  For example, on arm-build4, 4 docker builds
> can start in parallel, but only one will pass the build in progress check.
> The other 3 jobs will wait for the first build to complete, and then the
> next will start.  If the total wait time for any of the builds exceeds 30
> minutes, we get a failure.
>
>
>
> This is happening more frequently.  There are a couple options that I can
> see:
>
>
>
> *  Reduce the number of executors to 1.  This might have unintended
> side-effects on build times for other jobs.
>
> *  Reduce the number of executors to 1 and add more slaves for the given
> hardware (both ARM and x86)
>
> *  Fix the opnfv-docker.sh script so that it can allow more than one docker
> build to execute simultaneously.  I don't know what this would encompass.
>
>
>
> I would really love to hear other's opinions on what can be done.
>
>
>
> Regards,
>
> Mark
>
>
>
> Mark Beierl
>
> SW System Sr Principal Engineer
>
> Dell EMC | Office of the CTO
>
> mobile +1 613 314 8106
>
> mark.bei...@dell.com
>
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Many failed docker builds

[Alec Hothan (ahothan)]

This all ties into the versioning of artifacts since you can’t have concurrent 
builds of the same repo (for example from 2 distinct gerrit triggers on 
different patchsets) without proper tagging of the artifacts (you can’t just 
tag them with “latest”)

I think it would make sense to allow only 1 build at a time per repo but to 
support multiple concurrent container builds from different repos. Timing out 
and the part of the script that checks in a loop if another build is ongoing 
should be removed IMHO since the max concurrency is better checked at the 
Jenkins level.

Given hardware nowadays have a lot of cores, it would be good to allow multiple 
queues (or slaves) per hardware (up to 1 per core).
Repos that build more than 1 container should have a way to provide the build 
order if they require one.


Alec




From:  on behalf of "Beierl, Mark" 

Date: Monday, September 25, 2017 at 11:47 AM
To: "opnfv-tech-discuss@lists.opnfv.org" 
Subject: [opnfv-tech-discuss] Many failed docker builds

Hello,

Not sure who can help with this.  Right now there are 4 or more executor slots 
than can execute any given opnfv-docker.sh script.  The problem is with so many 
docker jobs being introduced in Euphrates, we are getting a lot of failures due 
to timeouts.  For example, on arm-build4, 4 docker builds can start in 
parallel, but only one will pass the build in progress check.  The other 3 jobs 
will wait for the first build to complete, and then the next will start.  If 
the total wait time for any of the builds exceeds 30 minutes, we get a failure.

This is happening more frequently.  There are a couple options that I can see:

*  Reduce the number of executors to 1.  This might have unintended 
side-effects on build times for other jobs.
*  Reduce the number of executors to 1 and add more slaves for the given 
hardware (both ARM and x86)
*  Fix the opnfv-docker.sh script so that it can allow more than one docker 
build to execute simultaneously.  I don't know what this would encompass.

I would really love to hear other's opinions on what can be done.

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com


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

[opnfv-tech-discuss] Quick update on the upcoming Plugfest

[Raymond Paik]

All,

We've had a couple of bi-weekly planning calls for the Plugfest, so this is
for people who have not been able to join the meeting in the past several
weeks.  (You can find the meeting logistics on the main Euphrates Plugfest
page  and
the meeting agenda/minutes can be found here
).

First, we have a daughter page for proposed topics here
.  This is
based on conversations we've had in meetings and also offline with various
community members.  I want to encourage people to add yourself to topics
you're interested in and also add new topics/activities that you'd be
interested in leading.  The Testing WG has also started an etherpad
 to iterate on their
Plugfest activities so I expect new items would be added to Plugfest topics
page...

Next if you haven't already, please register for the event at
https://www.regonline.com/OPNFVPlugfestDec2017

Thanks,

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

[opnfv-tech-discuss] urgent euphrates git tags vote needed

[Alec Hothan (ahothan)]

I would like to get a quick vote from any person that works directly or 
indirectly with code in OPNFV

Please reply with -1, 0 +1

For using prefixed git tags for the Euphrates release: “opnfv-5.0.0”

This is a slight change to the plan on record (which was to use “5.0.0”). This 
does NOT impact euphrates deliverables for participating OPNFV projects (git 
tags on stable/euphrates are applied by releng).
The only externally visible effect is the naming of container tags for 
Euphrates official images in DockerHub will be named accordingly (e.g. 
“opnfv/functest:opnfv-5.0.0”).
Everything else remains the same.

If you’d like to know more, the rationale is described here: 
https://wiki.opnfv.org/display/releng/OPNFV+projects+and+OPNFV+release+versioning
 (thanks for Fatih, David, Frank, Tapio for reviewing)
In a nutshell, this adjustment is needed to prepare the path for proper 
continuous delivery support by projects.
Any clarification/questions/discussion can be done over email or at the TSC or 
release meetings tomorrow.

Thank You.

  Alec


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

Re: [opnfv-tech-discuss] [announce] 2018 OPNFV release names

[Frank Brockners (fbrockne)]

Ray,

while there are not a ton of river “Fenix” photos, there are some, e.g 
http://www.soberaniachile.cl/archivosdeimagenes/fenix.jpg and 
http://photo500x500.mnstatic.com/f11c1c363de24a0a5ad44bb39046e2da/rio-fenix-grande.jpg
 – there are wiki entries such as… 
https://es.wikipedia.org/wiki/Desv%C3%ADo_del_r%C3%ADo_F%C3%A9nix and 
https://es.wikipedia.org/wiki/R%C3%ADo_F%C3%A9nix_Grande

If you want better photos, do we have any friends in Argentina that fancy a 
trip to lago Buenos Aires? 
http://viento.com.ar/wp-content/uploads/2015/09/desvio-rio-fenix.jpg

Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Montag, 25. September 2017 18:25
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [announce] 2018 OPNFV release names

All:

Thanks for voting on the release naming poll.

First, for G-release the winner is Gambia (the first African river for OPNFV).

For the F-release, the top vote getter was Fenix in Argentina.  However, after 
some research it looks this is a tributary of another river 
(Deseado), and I wasn't able to 
find photos of Fenix River on the web (or even find it on Google Maps).

I talked to LF marketing colleagues as we've been using river images for 
release marketing, and they do have concerns about going with a river that is 
not well known.  The second choice was 
Fraser in Canada (the longest river 
in British Columbia) and I suggest going with Fraser as the F-release name.  
Although Fenix sounds cool, I think it's problematic if you can't find it on a 
map.

Let me know if you have any questions.

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

[opnfv-tech-discuss] Many failed docker builds

[Beierl, Mark]

Hello,

Not sure who can help with this.  Right now there are 4 or more executor slots 
than can execute any given opnfv-docker.sh script.  The problem is with so many 
docker jobs being introduced in Euphrates, we are getting a lot of failures due 
to timeouts.  For example, on arm-build4, 4 docker builds can start in 
parallel, but only one will pass the build in progress check.  The other 3 jobs 
will wait for the first build to complete, and then the next will start.  If 
the total wait time for any of the builds exceeds 30 minutes, we get a failure.

This is happening more frequently.  There are a couple options that I can see:

*  Reduce the number of executors to 1.  This might have unintended 
side-effects on build times for other jobs.
*  Reduce the number of executors to 1 and add more slaves for the given 
hardware (both ARM and x86)
*  Fix the opnfv-docker.sh script so that it can allow more than one docker 
build to execute simultaneously.  I don't know what this would encompass.

I would really love to hear other's opinions on what can be done.

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com

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

Re: [opnfv-tech-discuss] PDF feedback and questions from our experience with Fuel

[Alexandru Avadanii]

Hi,
The part about net_config was confusing because it was not (yet) part of the 
official PDF spec.
After today’s infra meeting, and some more discussion on IRC, it looks like 
net_config will become part of the spec, but we need to sort out some network 
naming issues first.

However, ‚admin’, ‚mgmt’ & co network names are not inline with the PDF idea of 
describing strictly the hardware, so they will most likely need to be mapped 
using the installer descriptor file companion for now.
I updated [9] to reflect this decision. It makes things a little bit more 
complicated for the installer adapters, but I think keeping PDF clean (with no 
higher-level specifics) is a good idea overall.

Sections C and D in my first mail still need to be sorted out, but they are 
mostly minor quirks or deviations from the spec, so they are not blocking the 
release of PDF.

BR,
Alex


From: david.blaisonn...@orange.com [mailto:david.blaisonn...@orange.com]
Sent: Monday, September 25, 2017 12:11 PM
To: Alexandru Avadanii; opnfv-tech-discuss@lists.opnfv.org
Cc: jack.mor...@intel.com; Guillermo Herrero
Subject: Re: PDF feedback and questions from our experience with Fuel


Hi Alexandru,

thanks for this big set of patches and a sum up of our last pdf discussions.

The part about net_config is quite confuse, specially because you sum up many 
problems already solved by net_config, but talking about PDF not having it, 
then talking about what add net_config... but it is a hard job to summerize 
those evolution and point that we would better understand each one by using PDF 
version id, and work on a reference model.

Generally it will be +1 :)

BR

David



--

David BLAISONNEAU

NFV platforms DevOPS - OPNFV contributor

Orange - IMT / OLN / CNC / NCA / SINA



tel: +33 (0)2 96 07 27 93

email: david.blaisonn...@orange.com

2, avenue Pierre Marzin 22307 LANNION Cedex - France
Le 25/09/2017 à 00:21, Alexandru Avadanii a écrit :

Hi,



A. Current Fuel PDF integration status



Fuel and Armband teams have been working on moving to the new PDF as a single 
input configuration file.

We have proposed a new installer adapter template for Fuel in Pharos [1], as 
well as new PDFs in securedlab for the PODs Fuel uses:

- lf-pod2 [2];

- arm-pod5 has been around for a while;

- ericsson-pod1 and zte-pod1 already have PDFs, but might require smalls 
updates to work with the Fuel installer adapter;



While working on the PDFs, we proposed some patches that should improve/extend 
the verify job for securedlab, use the Pharos git repo for PDF parsing, 
respectively some minor cleanup/code folding:

- securedlab verify job should switch to using Pharos installer adapters and 
generate_config [3];

- yamllint fixes and code folding for existing PDFs [4];

- add verify job summary, run the whole test matrix instead of bailing on the 
first error [5];

- extend verify with yamllint runs for PDF files, as well as output yaml 
file(s) generated by check_jinja2 [6];

- fix missing IPMI credentials for lf-pod4 (caught by linting the output yaml 
described above) [7];

- (unrelated to PDF, Fuel cleanup) remove old Fuel configuration files we no 
longer use [8];



B. PDF specification limitations for Fuel



Tbh, I have a hard time summarizing this, but I'll try.

Currently, we have some PDFs that define a 'net_config' section (global per 
PDF), while the spec and most PDFs don't.

This resulted from:

- the need to support multiple VLANs over the same physical interface;

- installers expecting a network-centric mapping between existing/to-be-created 
networks and available interfaces;

Looking at what Fuel expects as input, we'd like to be able to easily map IPs 
in a certain network (e.g. admin, mgmt, private, public) to a particular 
interface name.

But the PDF does not allow specifying interface names directly, as those depend 
not only on target OS, but also on OS config (e.g. net.ifnames=0 biosdevname=1 
vs net.ifnames=1 biosdevname=0).

Indexing interfaces is also fragile, as a bios upgrade might change PCI layout 
and therefore the NIC ordering (quite rare, but still).

What happens if we add a new interface that ends up at index 1, between 
existing interfaces 0 and 2?

The 'net_config' section is a compromise that solves part of the problem, but 
still does not provide a solid solution for the physical interface name 
mapping, as it also relies on interface index.

What if the controller nodes have a different set of interfaces than the 
compute nodes have?

Adding 'net_config' to PODs aligned with the current spec is also problematic, 
as it'd duplicate the VLAN information, making the whole thing even more 
fragile.





Tl;dr I submited a proof of concept refactor of net_config, which triesto align 
more with the current PDF spec, although it is not 100% compatible (we can't 
model multiple VLANs on the same physical interface with the current spec) [9].

Observations wrt this change:

- 

[opnfv-tech-discuss] [Infra] Infra WG Meeting minutes - Sept. 25th

[Jack Morgan]

  
  
September 25th
Agenda:

  Experiences with PDF, David Blaisonneau, Guillermo Herrero, Alexandru Avadanii

  complete discussion from last week
  follow up on action items and status

  
  status of Pharos projects (LaaS and Dashboard)

  we need a long term solution to Dashboard per the issue
reported in INFRA-176
  what is the plan to integrate them? impact from OPNFV
board's recent decision on LaaS

  
  Review actions items
  Infra documentation on RTD - patch 40329 merged, what else?

Minutes (link)

  Experiences with PDF 

  AlexAvadanii provdes a summery of his
  email on PDF
  Link to his patch - https://gerrit.opnfv.org/gerrit/#/c/42893/ (PoC:
net_config refactor) 
  Lincoln mentions that we don't need to branch pharos-tools
at this point 
  AGREED: to
  not branch pharos-tools for now 
  jmorgan1 asks who should have access to
  securelab?
  aricg suggests each installer has their
  own repo to track installer specific items 
  jmorgan1 reminders everyone to review
  the patches in gerrit as the release is coming  

  
  LaaS and Pharos Dashboard 

  Licoln provides an update on the status
  of this effort 
  Lincoln is working on scoping next
  steps particularly with board decision to move forward
  with LaaS 

  
  Review action items 

  Julien-zte has received response from
  Arm and Daisy installer projects 
  Link to patch https://gerrit.opnfv.org/gerrit/42893 updated
according to the discussion  

  

Closed
Actions:

  Clarify how Compass creates installer VM instances Ulrich Kleber
  Attend test working group, for feedback on
their specific elements in releng Trevor Bramwell
  Track down status of PDF, talk to David about
patches and invite for next meeting Jack Morgan
  Share collected
  information on PODs and Scenarios Bryan Sullivan, Ulrich Kleber
  Contact
test-wg to confirm names and final repos for releng
  repo split Trevor Bramwell
  Create
stable/euphrates for securedlab Trevor Bramwell


New Actions:

  Clean up non-active Pharos
committers Jack Morgan

  Submit patches to add lab owners
and others to Pharos repo Aric Gardner
  Reach out to lab owners to
collect feedback on including username and password in PDF Jack Morgan
  Reach out to Luke Hinds to security
projects input on passwords in PDF Aric Gardner
  Reach out to Jose on status of
who owns Dashboard effort Jack Morgan
  Create wiki page to track next
steps and features for Laas/dashboard effort Lincoln Lavoie
  Reach out to Joid, Apex and
Compass need to provide a contact for PDF effort julien zhang

-- 
Jack Morgan
OPNFV Pharos Intel Lab
  

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

Re: [opnfv-tech-discuss] [OPNFV] [OpenStack] cross collaboration on testing activities

[Andrea Frittoli]

Hi Morgan, Ildikó,

the schedule is fine for me.

I guess we won't be able to answer the questions from the agenda in the
allocated time, but it should be enough to get the conversation started; we
can the follow up over other communication channels (IRC? Else?).

Andrea

On Sun, Sep 24, 2017 at 5:01 PM Ildiko Vancsa  wrote:

> Hi Morgan,
>
> Thank you for the proposal.
>
> I agree that we have several areas within testing where it would makes
> sense to start a closer collaboration.
>
> I added Mark to the thread as well, he’s the co-chair of our
> Interoperability Working Group and he’s one of drivers of having coverage
> for NFV as well in our interoperability tests and certification program.
>
> I know that we have plans on resiliency and robustness testing as an
> extension to our current framework. Ghanshyam and Andrea are the main
> contacts regarding those activities. Ghanshyam is in Japan, which means
> that we will need to find other forums as well to discuss these topics than
> the meeting slot next week to be able to involve everyone.
>
> @Mark @Andrea: Will you be available to attend the meeting on the 28th?
>
> As for the agenda, I think it looks good as starting point to touch base
> on the key topics, but I let our experts to voice their opinions as well. :)
>
> Thanks and Best Regards,
> Ildikó
>
>
> > On 2017. Sep 21., at 3:44,  <
> morgan.richo...@orange.com> wrote:
> >
> > Hi,
> >
> > I discussed with Georg on the opportunity to formalize a possible cross
> collaboration on testing between OpenStack and OPNFV.
> > He attended the PTG last week and it seems there are possibly more
> synergies between the 2 groups.
> >
> > I booked a slot for the next Testing group meeting planned on September
> 28th 3 PM UTC (https://global.gotomeeting.com/join/819733085)
> > As agenda (
> https://wiki.opnfv.org/display/meetings/Test+Working+Group+Weekly+Meeting)
> , I suggest (feel free to amend):
> >
> > Cross collaboration with OpenStack
> >   • OPNFV testing activities overview 5'
> >   • OpenStack NFV testing activities overview 5'
> >   • What could/should be upstreamed? 10'
> >   • Long duration/resiliency/robustness strategy 10'
> >   • Plugfest: common activities? 5'
> > Jose added a topic on XCI, our long duration testing activites are also
> linked to XCI and then connected to OpenStack.
> >
> > What is your view?
> > feel free to forward to whom it may concern.
> >
> > /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

[opnfv-tech-discuss] [announce] 2018 OPNFV release names

[Raymond Paik]

All:

Thanks for voting on the release naming poll.

First, for G-release the winner is Gambia (the first African river for
OPNFV).

For the F-release, the top vote getter was Fenix in Argentina.  However,
after some research it looks this is a tributary of another river (Deseado
), and I wasn't able to find
photos of Fenix River on the web (or even find it on Google Maps).

I talked to LF marketing colleagues as we've been using river images for
release marketing, and they do have concerns about going with a river that
is not well known.  The second choice was Fraser
 in Canada (the longest river
in British Columbia) and I suggest going with Fraser as the F-release
name.  Although Fenix sounds cool, I think it's problematic if you can't
find it on a map.

Let me know if you have any questions.

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

Re: [opnfv-tech-discuss] [barometer] Stepping down as barometer PTL post E release.

[MORTON, ALFRED C (AL)]

+1 Bryan, "Thank You" and "Well Done" doesn't say enough...

best wishes in *all* your endeavors, Maryam!

Thank you for your willingness to step-up, Aaron!

Al

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

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
And thanks to you, Maryam, for your excellent work as PTL. I'm sure over the 
last couple of releases the team picked up some great pointers from you on how 
to do this job right, so we should be in good hands.

Thanks,
Bryan Sullivan | AT

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 3: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 consideration, I have decided to step down as the PTL for barometer 
after the E release. I have really enjoyed my time as the PTL and the support 
of a great team. I and the team would like to remain involved/stay on as a 
project committers and contributors. But I think it's the right time to give 
someone else the chance to lead a great project. With that, I would like to 
nominate Aaron Smith as the next barometer PTL.



Thank you for the experience and great journey :)

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

[opnfv-tech-discuss] OpenDaylight DDF

[Casey Cain]

Hello, OPNFV Community!

OpenDaylight will be holding it's Oxygen Developer Design Forum in Santa
Clara, CA on October 9th and 10th.
We would like to invite interested members from the OPNFV Community to join
us.  If you wish to host a topic or view currently submitted topics
please visit
this wiki page .

If you wish to register for the event (It's free!), please click here
.

Best,
Casey Cain
Technical Program Manager
Linux Foundation
_
IRC - CaseyODL
Skype - wrathwolfk
WeChat - okaru6
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Canceled: SampleVNF Weekly meeting

[S, Deepak]

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:India Standard Time
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+0530
TZOFFSETTO:+0530
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+0530
TZOFFSETTO:+0530
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="S, Deepak":MAILTO:deepa...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='opnfv-tec
 h-disc...@lists.opnfv.org':MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Jindal, So
 nika":MAILTO:sonika.jin...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Jyoti, Ana
 nd B":MAILTO:anand.b.jy...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='fbrockne@
 cisco.com':MAILTO:'fbroc...@cisco.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='shang.xia
 od...@zte.com.cn':MAILTO:'shang.xiaod...@zte.com.cn'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Deepak S 
 (Intel,'":MAILTO:deepa...@linux.intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Rudramuni,
  Vishwesh M":MAILTO:vishwesh.m.rudram...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Narayan, B
 indya":MAILTO:bindya.nara...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Gunaseela
 n Venkatachary (HCL,'":MAILTO:gunaseel...@hcl.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Anandaram
 an Viswanathan (HCL,'":MAILTO:anandaram...@hcl.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Rajaraman
  Balasubramanian (HCL,'":MAILTO:rajarama...@hcl.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Ramia, Kan
 nan Babu":MAILTO:kannan.babu.ra...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Vasantha 
 kumar Godithi (HCL,'":MAILTO:vasanthakum...@hcl.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Bob Monkm
 an':MAILTO:bob.monk...@arm.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Elzur, Uri"
 :MAILTO:uri.el...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Vul, Alex":
 MAILTO:alex@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Marco Var
 lese':MAILTO:marco.varl...@suse.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Andrew Ve
 itch':MAILTO:andrew.vei...@netcracker.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Kedalagudd
 e, Meghashree Dattatri":MAILTO:meghashree.dattatri.kedalagu...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Shai Tsur
 ':MAILTO:shai.t...@arm.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Lawrence 
 Lamers':MAILTO:ljlam...@vmware.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Maria Toe
 roe':MAILTO:maria.toe...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'GUPTA, AL
 OK'":MAILTO:ag1...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Pierre Ly
 nch':MAILTO:ply...@ixiacom.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Cathy Zha
 ng':MAILTO:cathy.h.zh...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Canio Cil
 lis':MAILTO:canio.cil...@de.ibm.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Seiler, Gl
 enn (Wind River)":MAILTO:glenn.sei...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ahmed Elb
 ornou (amaged)':MAILTO:ama...@cisco.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Gabor Hal
 ász':MAILTO:gabor.hal...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Alan McNa
 mee':MAILTO:alan...@openet.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='yunchao h
 u':MAILTO:yunchao...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Shobhan A
 yyadevaraSesha (sayyadev)':MAILTO:sayya...@cisco.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Carlos Br
 avo':MAILTO:carlos.br...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Bathula, N
 avyaX":MAILTO:navyax.bath...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Nadathur, 
 Sundar":MAILTO:sundar.nadat...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Paladugula
 , ShravaniX":MAILTO:shravanix.paladug...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Yerrumsett
 y, RajithaX":MAILTO:rajithax.yerrumse...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Gundarapu,
  ReddyX":MAILTO:reddyx.gundar...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=pavan.gupt
 

[opnfv-tech-discuss] [Auto] More RAM for Auto

[Tina Tsou]

Dear Lincoln,

So far Auto got 16G RAM x86 based pod from LaaS at UNH LoL. Since it is ONAP 
verifications onto OPNFV, it needs more memory. Would you add some more memory 
to it?

The Arm based pod needs a couple of weeks before final arrival, because of the 
lead time.


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

Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

[Srikanth Lingala]

Hi Manuel,
I am able to run the usecase ‘sfc_two_chains_SSH_and_HTTP.py’. The issue is 
with the sequence of executing commands.
First SFC Classifier flows are not adding in Compute Node, if we have two 
active Service Function Chains. So, I created SFC1 and added required 
classifiers with that chain. And then, I created another chain SFC2, and added 
classifiers with SFC2. I don’t know whether that’s a BUG in ODL/tacker or not. 
With that sequence, I am able to run the usecase successfully.

Thanks for all the help.

Regards,
Srikanth.



From: Manuel Buil [mailto:mb...@suse.com]
Sent: Monday, September 25, 2017 1:25 PM
To: Srikanth Lingala ; 
sfc-...@lists.opendaylight.org; opnfv-tech-discuss@lists.opnfv.org; 
opnfv-us...@lists.opnfv.org
Cc: Gorja Gorja 
Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

Hey Srikanth,

You are not getting any classification rule because it can't find an RSP, which 
means it was not able to create the chain. There is something fishy going on 
and it should not be there if you do a complete restart of ODL. To completely 
restart ODL, you must stop it, remove the directories: snapshot, instances and 
journal. Then, you should restart the OVSs (removing their conf.db database). 
If you are using neutron v2, you must also restart neutron completely (database 
included) because it keeps a journal and what breaks ODL, will again be 
executed as soon as neutron detects that ODL is up.

Regards,
Manuel

On Fri, 2017-09-22 at 12:57 +, Srikanth Lingala wrote:
Hi Manuel,
I started ODL cleanly. But, I observe the same issue. SFC Classifier flows are 
adding, only when we have single Chain.
I wonder how functests are passing with the SFC usecase 
‘sfc_two_chains_SSH_and_HTTP.py’ in different OPNFV labs.

And also, now after cleaning up ODL, SFC flows are NOT adding with table id 150 
– 158. Those SFC flows are adding to table id 10.
I observe no ERROR logs in ODL, but few WARNING logs.

Following are the ODL logs:
While creating first chain ‘mychain1’: tacker sfc-create --name mychain1 
--chain testVNF1
https://pastebin.com/JXDgitXD

While creating second chain ‘mychain2’: tacker sfc-create --name mychain2 
--chain testVNF2
https://pastebin.com/CYaxYvtZ

While creating first classifier ‘myclass1’: tacker sfc-classifier-create --name 
myclass1 --chain mychain1 --match source_port=0,dest_port=80,protocol=6
https://pastebin.com/Ly4Y2aSb
Here, Classifier flow is NOT adding with tcp and dest_port=80.

While creating first classifier ‘myclass2’: tacker sfc-classifier-create --name 
myclass2 --chain mychain2 --match source_port=0,dest_port=22,protocol=6
https://pastebin.com/iJJ2me1Y
Here, Classifier flow is adding with tcp and dest_port=22.

Regards,
Srikanth.

From: Manuel Buil [mailto:mb...@suse.com]
Sent: Friday, September 22, 2017 4:50 PM
To: Srikanth Lingala 
>; 
sfc-...@lists.opendaylight.org; 
opnfv-tech-discuss@lists.opnfv.org; 
opnfv-us...@lists.opnfv.org
Cc: Gorja Gorja >
Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

Yes. You need to stop it, remove instances/ journal/ and snapshots/ and start 
it with bin/start clean. If I remember well, ODL Boron had an issue when 
restarting it and connecting old OVS, so you might need to restart also the OVS 
switches before starting ODL again.

Regards,
Manuel

On Fri, 2017-09-22 at 10:30 +, Srikanth Lingala wrote:
Hi Manuel,
So, If I restart the ODL and then add SFC and SFC Classifiers may fix this 
issue?

Regards,
Srikanth.

From: Manuel Buil [mailto:mb...@suse.com]
Sent: Friday, September 22, 2017 3:52 PM
To: Srikanth Lingala 
>; 
sfc-...@lists.opendaylight.org; 
opnfv-tech-discuss@lists.opnfv.org; 
opnfv-us...@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

Hello Srikanth,

Danube is using ODL Boron which had some issues when removing the 
classification rules. Unfortunately, those rules are not correctly removed and 
that creates a small mess which results in problems when creating new rules. 
You should not see this problem if you have a clean ODL but if you have created 
several classifiers and tried to remove them, you might see it.

Do you see any error in ODL logs when creating the classifier

Regards,
Manuel

On Fri, 2017-09-22 at 07:28 +, Srikanth Lingala wrote:
Hi,
I am using OPNFV Danube 3.0. I deployed one Openstack Controller with ODL & 
Tacker and Openstack Compute through Fuel.
I am trying to execute the usecase: sfc_two_chains_SSH_and_HTTP
When I create two chains, Classifier 

Re: [opnfv-tech-discuss] [barometer] Stepping down as barometer PTL post E release.

[SULLIVAN, BRYAN L (BRYAN L)]

And thanks to you, Maryam, for your excellent work as PTL. I'm sure over the 
last couple of releases the team picked up some great pointers from you on how 
to do this job right, so we should be in good hands.

Thanks,
Bryan Sullivan | AT

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 3: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 consideration, I have decided to step down as the PTL for barometer 
after the E release. I have really enjoyed my time as the PTL and the support 
of a great team. I and the team would like to remain involved/stay on as a 
project committers and contributors. But I think it's the right time to give 
someone else the chance to lead a great project. With that, I would like to 
nominate Aaron Smith as the next barometer PTL.



Thank you for the experience and great journey :)

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

[opnfv-tech-discuss] [barometer] Stepping down as barometer PTL post E release.

[Tahhan, Maryam]

Hi folks,



After much consideration, I have decided to step down as the PTL for barometer 
after the E release. I have really enjoyed my time as the PTL and the support 
of a great team. I and the team would like to remain involved/stay on as a 
project committers and contributors. But I think it's the right time to give 
someone else the chance to lead a great project. With that, I would like to 
nominate Aaron Smith as the next barometer PTL.



Thank you for the experience and great journey :)

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

Re: [opnfv-tech-discuss] PDF feedback and questions from our experience with Fuel

[david.blaisonneau]

Hi Alexandru,

thanks for this big set of patches and a sum up of our last pdf discussions.

The part about net_config is quite confuse, specially because you sum up 
many problems already solved by net_config, but talking about PDF not 
having it, then talking about what add net_config... but it is a hard 
job to summerize those evolution and point that we would better 
understand each one by using PDF version id, and work on a reference model.


Generally it will be +1 :)

BR

David

--
David BLAISONNEAU
NFV platforms DevOPS - OPNFV contributor
Orange - IMT / OLN / CNC / NCA / SINA

tel: +33 (0)2 96 07 27 93
email:david.blaisonn...@orange.com
2, avenue Pierre Marzin 22307 LANNION Cedex - France

Le 25/09/2017 à 00:21, Alexandru Avadanii a écrit :

Hi,

A. Current Fuel PDF integration status

Fuel and Armband teams have been working on moving to the new PDF as a single 
input configuration file.
We have proposed a new installer adapter template for Fuel in Pharos [1], as 
well as new PDFs in securedlab for the PODs Fuel uses:
- lf-pod2 [2];
- arm-pod5 has been around for a while;
- ericsson-pod1 and zte-pod1 already have PDFs, but might require smalls 
updates to work with the Fuel installer adapter;

While working on the PDFs, we proposed some patches that should improve/extend 
the verify job for securedlab, use the Pharos git repo for PDF parsing, 
respectively some minor cleanup/code folding:
- securedlab verify job should switch to using Pharos installer adapters and 
generate_config [3];
- yamllint fixes and code folding for existing PDFs [4];
- add verify job summary, run the whole test matrix instead of bailing on the 
first error [5];
- extend verify with yamllint runs for PDF files, as well as output yaml 
file(s) generated by check_jinja2 [6];
- fix missing IPMI credentials for lf-pod4 (caught by linting the output yaml 
described above) [7];
- (unrelated to PDF, Fuel cleanup) remove old Fuel configuration files we no 
longer use [8];

B. PDF specification limitations for Fuel

Tbh, I have a hard time summarizing this, but I'll try.
Currently, we have some PDFs that define a 'net_config' section (global per 
PDF), while the spec and most PDFs don't.
This resulted from:
- the need to support multiple VLANs over the same physical interface;
- installers expecting a network-centric mapping between existing/to-be-created 
networks and available interfaces;
Looking at what Fuel expects as input, we'd like to be able to easily map IPs 
in a certain network (e.g. admin, mgmt, private, public) to a particular 
interface name.
But the PDF does not allow specifying interface names directly, as those depend 
not only on target OS, but also on OS config (e.g. net.ifnames=0 biosdevname=1 
vs net.ifnames=1 biosdevname=0).
Indexing interfaces is also fragile, as a bios upgrade might change PCI layout 
and therefore the NIC ordering (quite rare, but still).
What happens if we add a new interface that ends up at index 1, between 
existing interfaces 0 and 2?
The 'net_config' section is a compromise that solves part of the problem, but 
still does not provide a solid solution for the physical interface name 
mapping, as it also relies on interface index.
What if the controller nodes have a different set of interfaces than the 
compute nodes have?
Adding 'net_config' to PODs aligned with the current spec is also problematic, 
as it'd duplicate the VLAN information, making the whole thing even more 
fragile.



Tl;dr I submited a proof of concept refactor of net_config, which triesto align 
more with the current PDF spec, although it is not 100% compatible (we can't 
model multiple VLANs on the same physical interface with the current spec) [9].
Observations wrt this change:
- network-centric approach, installer-friendly;
- physical interface to virtual interface mapping is NOT 1:1 (multiple VLANs on 
same physical NIC);
- virtual inteface to network mapping is 1:1;
- network to IP mapping is 1:1;
- networks are global for the POD (including network to virtual network);
- network to physical inteface mapping is NOT global per POD, and should be 
overrideable on a per-node basis;
- features and speed params were silently discarded during net_config addition, 
bring them back for the physical intefaces;
- converting from current spec-compatible PDF to this proposed format should be 
trivial for PDF files, and should require very little work on the installer 
adapters;
Etc.

Please take some time to review this and let's come up with a better solution 
if we can find one, or at least align our current PDFs to one format or another.
The PoC does not solve the interface indexing issue, but at least it provides a 
mechanism that makes it per-node configurable.

C. PDF current implementation issues

This section covers some divergent aspects in the current PDFs in securedlab. 
The PDF spec is quite clear on some of these, so I don't understand why there 
are so many mutations in the wild.
If parsing the PDF is hard / 

Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

[Manuel Buil]

Hey Srikanth,

You are not getting any classification rule because it can't find an
RSP, which means it was not able to create the chain. There is
something fishy going on and it should not be there if you do a
complete restart of ODL. To completely restart ODL, you must stop it,
remove the directories: snapshot, instances and journal. Then, you
should restart the OVSs (removing their conf.db database). If you are
using neutron v2, you must also restart neutron completely (database
included) because it keeps a journal and what breaks ODL, will again be
executed as soon as neutron detects that ODL is up.

Regards,
Manuel

On Fri, 2017-09-22 at 12:57 +, Srikanth Lingala wrote:
> 
> 
> Hi Manuel,
> > I started ODL cleanly. But, I observe the same issue. SFC Classifier
flows are adding, only when we have single Chain.
> > I wonder how functests are passing with the SFC usecase
‘sfc_two_chains_SSH_and_HTTP.py’ in different OPNFV labs.
>  
> > And also, now after cleaning up ODL, SFC flows are NOT adding with
table id 150 – 158. Those SFC flows are adding to table id 10.
> I observe no ERROR logs in ODL, but few WARNING logs.
>  
> Following are the ODL logs:
> While creating first chain ‘mychain1’: 
> tacker sfc-create --name mychain1 --chain testVNF1
> https://pastebin.com/JXDgitXD
>  
> While creating second chain ‘mychain2’: 
> tacker sfc-create --name mychain2 --chain testVNF2
> https://pastebin.com/CYaxYvtZ
>  
> While creating first classifier ‘myclass1’: 
> > tacker sfc-classifier-create --name myclass1 --chain mychain1 --match 
source_port=0,dest_port=80,protocol=6
> https://pastebin.com/Ly4Y2aSb
> Here, Classifier flow is NOT adding with tcp and dest_port=80.
>  
> While creating first classifier ‘myclass2’: 
> > tacker sfc-classifier-create --name myclass2 --chain mychain2 --match 
source_port=0,dest_port=22,protocol=6
> https://pastebin.com/iJJ2me1Y
> Here, Classifier flow is adding with tcp and dest_port=22.
>  
> Regards,
> Srikanth.
>  
> 
> 
> > From: Manuel Buil [mailto:mb...@suse.com] 
> 
> Sent: Friday, September 22, 2017 4:50 PM
> 
> > > > > To: Srikanth Lingala ; sfc-dev@lists.openda
ylight.org; opnfv-tech-discuss@lists.opnfv.org; opnfv-us...@lists.opn
fv.org
> 
> > Cc: Gorja Gorja 
> 
> > Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two
SFC's
> 
> 
> 
> 
>  
> 
> > > Yes. You need to stop it, remove instances/ journal/ and snapshots/
and start it with bin/start clean. If I remember well, ODL Boron had
an issue when restarting it and
> >  connecting old OVS, so you might need to restart also the OVS
switches before starting ODL again.
> 
> 
> 
>  
> 
> 
> 
> Regards,
> 
> 
> 
> Manuel
> 
> 
> 
>  
> 
> 
> 
> On Fri, 2017-09-22 at 10:30 +, Srikanth Lingala wrote:
> 
> 
> 
> Hi Manuel,
> > So, If I restart the ODL and then add SFC and SFC Classifiers may fix
this issue?
>  
> Regards,
> Srikanth.
>  
> 
> 
> > From: Manuel Buil [mailto:mb...@suse.com]
> 
> 
> Sent: Friday, September 22, 2017 3:52 PM
> 
> > To: Srikanth Lingala ;
> sfc-...@lists.opendaylight.org;
> opnfv-tech-discuss@lists.opnfv.org;
> opnfv-us...@lists.opnfv.org
> 
> > Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two
SFC's
> 
> 
> 
> 
>  
> 
> Hello Srikanth,
> 
> 
> 
>  
> 
> 
> 
> > > Danube is using ODL Boron which had some issues when removing the
classification rules. Unfortunately, those rules are not correctly
removed and that creates a small mess
> > >  which results in problems when creating new rules. You should not
see this problem if you have a clean ODL but if you have created
several classifiers and tried to remove them, you might see it.
> 
> 
> 
>  
> 
> 
> 
> Do you see any error in ODL logs when creating the classifier
> 
> 
> 
>  
> 
> 
> 
> Regards,
> 
> 
> 
> Manuel
> 
> 
> 
>  
> 
> 
> 
> On Fri, 2017-09-22 at 07:28 +, Srikanth Lingala wrote:
> 
> 
> 
> Hi,
> > I am using OPNFV Danube 3.0. I deployed one Openstack Controller with
ODL & Tacker and Openstack Compute through Fuel.
> I am trying to execute the usecase: sfc_two_chains_SSH_and_HTTP
> > When I create two chains, Classifier flow is missing in the compute
node.
> I executed below commands:
>  
> #> tacker vnfd-create --vnfd-file test-vnfd-1.yaml
> #> tacker vnfd-create --vnfd-file test-vnfd-2.yaml
> #> tacker vnf-create --name testVNF1 --vnfd-name test-vnfd-1
> #> tacker vnf-create --name testVNF2 --vnfd-name test-vnfd-2
> #> tacker sfc-create --name mychain1 --chain testVNF1
> #> tacker sfc-create --name mychain2 --chain testVNF2
> > #> tacker sfc-classifier-create --name myclass1 --chain mychain1 --
match source_port=0,dest_port=80,protocol=6
>  
> > > When I execute the above command, I am not able to see classifier
flow in the compute node. The flow should be something similar to
below:
> # ovs-ofctl dump-flows br-int -O Openflow13 | grep tcp
> > > > > > cookie=0x1110010005970255, duration=121.077s, table=11, n_packets=0,

Re: [opnfv-tech-discuss] VxLAN workaround for OPNFV Danube 3.0

[Manuel Buil]

Hi Srikanth,

It is still required.

Regards,
Manuel

On Sat, 2017-09-23 at 14:04 +, Srikanth Lingala wrote:
> 
> 
> Hi,
> > I am trying to implement SFC with Opendaylight is OPNFV Danube 3.0
release.
> > Is “VxLAN Workaround in Compute node” still required in OPNFV Danube
3.0 release also? Or ODL will take care of it.
> Anyone please confirm.
>  
> Regards,
> Srikanth.
> 
> 
> 
> 
> ___
> 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