[openstack-dev] [TripleO] Re-defining network templates/isolation
Hello, I wanted to get thoughts about re-thinking how users configure and create new networks with OOO. The current way to configure network settings for a deployment requires creating nic + network environment templates, and updating the network isolation resource registry. I think a better approach could consolidate all of the network settings for a deployment into a single yaml file, and then parse that information to create the appropriate nic and network env templates. We do that in OPNFV Apex with a combination of python and jinja2 using this unified template format: https://github.com/opnfv/apex/blob/master/config/network/network_settings.yaml Furthermore consider cdefining new networks in OOO. Think about how much is involved in creating a new network, subnet, port definition + net_ip_map for that network, VIP. If you look at the tht/network directory, almost all of the templates for ports and networks have the exact same format. I think you could make the example above dynamic so that a user could define any new network there and the corresponding port, network + subnet template files could be created on the fly. I think this creates a much more simple interface for users by exposing networking configuration they need, but also hiding redundant OOO/heat template syntax they don't necessarily care about. Thoughts? Tim Rozet Red Hat SDN Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tacker] [networking-sfc] Removing required port-id from classifier
Thanks Igor! Anil and I can help test out real NSH support when we have the
networking-odl driver finished. That would be a good way to exercise that side
of networking-sfc code. Will look at these patches.
Tim Rozet
Red Hat SDN Team
- Original Message -
From: "Duarte Cardoso, Igor"
To: "OpenStack Development Mailing List (not for usage questions)"
, "Cathy Zhang"
Sent: Wednesday, October 5, 2016 6:06:02 AM
Subject: Re: [openstack-dev] [tacker] [networking-sfc] Removing required
port-idfrom classifier
Hi Tim,
Just about the second part of your email:
> how are IETF SFC/NSH related API/plugin changes going?
I'm essentially finished with NSH encap support [1], just have to fix a few
bugs and write the tests. Then I will work on connecting port-chains together
so we can have SFC graphs, kind of like IETF's branching/reclassification "SFC
Encapsulation" chains (described with higher detail in the NSH draft).
> Can we expect to have attributes like path-id, encap type soon?
The NSH patch I mentioned above will allow NSH encap to be specified for both
port-chains and port-pairs and, if port-pairs do not support the port-chain's
encapsulation, it's up to the driver to SFC-Proxy the traffic accordingly (OVS
will install SFC-proxy flows, just like it does today by default, for MPLS).
Regarding the path-id, I was working on a patch to facilitate that [2], but we
ended up merging one focused only on enabling the path-id ("chain_id") [3]. So
we have both attributes now.
[1] https://review.openstack.org/#/c/373465
[2] https://review.openstack.org/#/c/346175
[3] https://review.openstack.org/#/c/355336
Best regards,
Igor.
-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com]
Sent: Tuesday, October 4, 2016 6:07 PM
To: OpenStack Development Mailing List (not for usage questions)
; Cathy Zhang
Subject: [openstack-dev] [tacker] [networking-sfc] Removing required port-id
from classifier
Hi Cathy,
I recall a while back discussing removing the required neutron port-id from the
classifier. We just finished up implementing VNFFG in Tacker and are hitting
this while testing. What is the plan to remove this requirement? Also, how
are IETF SFC/NSH related API/plugin changes going? Can we expect to have
attributes like path-id, encap type soon?
Thanks,
Tim Rozet
Red Hat SDN Team
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Removing required port-id from classifier
Responses inline. Thanks, Tim Rozet Red Hat SDN Team - Original Message - From: "Cathy Zhang" To: "Tim Rozet" , "OpenStack Development Mailing List (not for usage questions)" Cc: "Sridhar Ramaswamy" , "Sripriya Seetharam" Sent: Tuesday, October 4, 2016 1:54:04 PM Subject: RE: Removing required port-id from classifier Hi Tim, Please see inline. Thanks, Cathy -Original Message- From: Tim Rozet [mailto:tro...@redhat.com] Sent: Tuesday, October 04, 2016 10:07 AM To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang Cc: Sridhar Ramaswamy; Sripriya Seetharam Subject: [tacker] [networking-sfc] Removing required port-id from classifier Hi Cathy, I recall a while back discussing removing the required neutron port-id from the classifier. Cathy> Do you mean logical source port here? trozet> yeah the neutron_source_port seems required. We just finished up implementing VNFFG in Tacker and are hitting this while testing. What is the plan to remove this requirement? Also, how are IETF SFC/NSH related API/plugin changes going? Can we expect to have attributes like path-id, encap type soon? Cathy> The API already provides a way for specifying "path-id" and encap type (currently only MPLS encap type is supported since OVS does not support NSH yet). As to NSH support, the code patch is being worked on, not completed yet. We are also tracking the NSH work in OVS and hope OVS will support NSH soon so that when networking-sfc integrates with that new version of OVS, NSH can be supported properly. trozet> OK good. Anil is close (demoed at ODL summit) a networking-odl driver for networking-sfc that supports NSH. Can you link the patches or point me to who is working on the NSH support for the API/plugin DB layer? Thanks, Tim Rozet Red Hat SDN Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tacker] [networking-sfc] Removing required port-id from classifier
Hi Cathy, I recall a while back discussing removing the required neutron port-id from the classifier. We just finished up implementing VNFFG in Tacker and are hitting this while testing. What is the plan to remove this requirement? Also, how are IETF SFC/NSH related API/plugin changes going? Can we expect to have attributes like path-id, encap type soon? Thanks, Tim Rozet Red Hat SDN Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc
Hi Cathy, I haven't done this in openstack before, but what I believe the statement is referring to is that you need to make sure you tag a merged commit, if the topic branch had diverged from master and had to be merged into your master trunk. For example: commit f01595f801e1d78f84b43c111f2955f67573e263 Merge: 04a7bf2 4b84887 Author: Tim Rozet Date: Wed Aug 31 01:40:12 2016 + Merge "Adds ability to power off nodes in clean" commit 4b84887ed2322db6b04924bdee7b44d3dcf7c32d Author: Tim Rozet Date: Tue Aug 30 13:06:33 2016 -0400 Adds ability to power off nodes in clean Now if an inventory file is provided to clean, those nodes will be powered off. JIRA: APEX-250 Change-Id: I2d78285717726c3d1c9d7d88c38e706d4617e337 Signed-off-by: Tim Rozet In this situation I want to tag f01595f801e, because it is the merged commit (and not 4b84887). To create a tag you can do this: git checkout git tag -am "" git push origin Hope that helps, Tim Rozet Red Hat SDN Team - Original Message - From: "Cathy Zhang" To: "Ihar Hrachyshka" , "Armando M." , "Cathy Zhang" Cc: "OpenStack Development Mailing List (not for usage questions)" Sent: Thursday, September 1, 2016 3:03:13 PM Subject: Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc Thanks for all your response. We would like to have the stable branch pulled from a git commit. Shall we use the git hash of that commit for the intended git hash in the release request? I am confused about the following statement in the release guide. "You need to be careful when picking a git commit to base new releases on. In most cases, you’ll want to tag the merge commit that merges your last commit in to the branch. This bug shows an instance where this mistake was caught. Notice the difference between the incorrect commit and the correct one which is the merge commit. git log 6191994..22dd683 --oneline shows that the first one misses a handful of important commits that the second one catches. This is the nature of merging to master." What is meant by " tag the merge commit"? How do we tag a git commit on our master branch? Thanks, Cathy -Original Message- From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] Sent: Thursday, September 01, 2016 4:22 AM To: Armando M. Cc: Cathy Zhang; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc Armando M. wrote: > > > On 31 August 2016 at 17:31, Cathy Zhang wrote: > CC OpenStack alias. > > > > From: Cathy Zhang > Sent: Wednesday, August 31, 2016 5:19 PM > To: Armando Migliaccio; Ihar Hrachyshka; Cathy Zhang > Subject: need help on requesting release for networking-sfc > > > > Hi Armando/Ihar, > > > > I would like to submit a request for a networking-sfc release. I did > this for previous branch release by submitting a bug request in > launchpad before. I see that other subproject, such as L2GW, did this > in Launchpad for mitaka release too. > > But the Neutron stadium link > http://docs.openstack.org/developer/neutron/stadium/sub_project_guidel > ines.html#sub-project-release-process > states that “A sub-project owner proposes a patch to > openstack/releases repository with the intended git hash. The Neutron > release liaison should be added in Gerrit to the list of reviewers for the > patch”. > > > > Could you advise which way I should go or should I do both? > > > Consider the developer documentation the most up to date process, so > please go ahead with a patch against the openstack/releases repo. Right. There was a recent change to the process that streamlined release requests and hopefully made them a tad easier for both subproject owners as well as release liaison. Please stick to the latest version of the process as described in devref in master branch of neutron repo. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
Hey Paul, ODL uses OVS as its dataplane (but is also not limited to just OVS), and ODL already supports IETF SFC today in the ODL SFC project. My point was Neutron is no longer in scope of managing OVS, since it is managed by ODL. I think your comments echo the 2 sides of this discussion - whether or not OVS is in scope of a protocol implementation in Neutron networking-sfc. In my opinon it is if you consider OVS driver support, but it is not if you consider a different networking-sfc driver. You can implement IETF NSH in the networking-sfc API/DB Model, without caring if it is actually supported in OVS (when using ODL as a driver) because all networking-sfc cares about should be if it's driver correctly supports SFC. To that end, if you are using ODL as your SFC driver, then absolutely you should verify it is an IETF SFC compliant API/model. However, outside of that scope, it is not networking-sfc's responsibility to care what ODL is using as it's dataplane backend or for that matter it's version of OVS. It is now up to ODL to manage that for networking-sfc, and networking-sfc just needs to ensure it can talk to ODL. I think this is a pragmatic way to go, since networking-sfc doesn't yet support an ODL driver and we are in the process of adding one. We could leave the networking-sfc OVS driver alone, add support for NSH to the networking-sfc plugin, and then only allow API calls that use NSH to work if ODL networking driver is the backend. That way we allow for some experimental NSH support in networking-sfc without officially supporting it in the OVS driver until it is officially supported in OVS. Tim Rozet Red Hat SDN Team - Original Message - From: "Paul Carver" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Monday, May 30, 2016 10:12:34 PM Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC On 5/25/2016 13:24, Tim Rozet wrote: > In my opinion, it is a better approach to break this down into plugin vs > driver support. There should be no problem adding support into > networking-sfc plugin for NSH today. The OVS driver however, depends on OVS > as the dataplane - which I can see a solid argument for only supporting an > official version with a non-NSH solution. The plugin side should have no > dependency on OVS. Therefore if we add NSH SFC support to an ODL driver in > networking-odl, and use that as our networking-sfc driver, the argument about > OVS goes away (since neutron/networking-sfc is totally unaware of the > dataplane at this point). We would just need to ensure that API calls to > networking-sfc specifying NSH port pairs returned error if the enabled driver > was OVS (until official OVS with NSH support is released). > Does ODL have a dataplane? I thought it used OvS. Is the ODL project supporting its own fork of OvS that has NSH support or is ODL expecting that the user will patch OvS themself? I don't know the details of why OvS hasn't added NSH support so I can't judge the validity of the concerns, but one way or another there has to be a production-quality dataplane for networking-sfc to front-end. If ODL has forked OvS or in some other manner is supporting its own NSH capable dataplane then it's reasonable to consider that the ODL driver could be the first networking-sfc driver to support NSH. However, we still need to make sure that the API is an abstraction, not implementation specific. But if ODL is not supporting its own NSH capable dataplane, instead expecting the user to run a patched OvS that doesn't have upstream acceptance then I think we would be building a rickety tower by piling networking-sfc on top of that unstable base. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
In my opinion, it is a better approach to break this down into plugin vs driver support. There should be no problem adding support into networking-sfc plugin for NSH today. The OVS driver however, depends on OVS as the dataplane - which I can see a solid argument for only supporting an official version with a non-NSH solution. The plugin side should have no dependency on OVS. Therefore if we add NSH SFC support to an ODL driver in networking-odl, and use that as our networking-sfc driver, the argument about OVS goes away (since neutron/networking-sfc is totally unaware of the dataplane at this point). We would just need to ensure that API calls to networking-sfc specifying NSH port pairs returned error if the enabled driver was OVS (until official OVS with NSH support is released). Thoughts? Tim Rozet Red Hat SDN Team - Original Message - From: "Armando M." To: "OpenStack Development Mailing List (not for usage questions)" Cc: "Tim Rozet" Sent: Wednesday, May 25, 2016 12:33:16 PM Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC On 24 May 2016 at 21:53, Elzur, Uri wrote: > Hi Tim > > Sorry for the delay due to travel... > > This note is very helpful! > > We are in agreement that the team including the individuals cited below > are supportive. We also agree that SFC belongs in the networking-SFC > project (with proper API adjustment) > > It seems networking-sfc still holds the position that without OvS > accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying to > get a clear read on where is this stated as requirement > I think the position here is as follows: if a technology is not mainstream, i.e. readily available via distros and the various channels, it can only be integrated via an experimental path. No-one is preventing anyone from posting patches and instructions to compile kernels and kernel modules, but ultimately as an OpenStack project that is suppose to produce commercial and production grade software, we should be very sensitive in investing time and energy in supporting a technology that may or may not have a viable path towards inclusion into mainstream (Linux and OVS in this instance). One another clear example we had in the past was DPDK (that enabled fast path processing in Neutron with OVS) and connection tracking (that enabled security groups natively build on top of OVS). We, as a project have consistently avoided endorsing efforts until they mature and show a clear path forward. > Like you, we are closely following the progress of the patches and > honestly I have hard time seeing OpenStack supporting NSH in production > even by the end of 2017. I think this amounts to slowing down the market... > > I think we need to break the logjam. > We are not the ones (Neutron) you're supposed to break the logjam with. I think the stakeholders here go well beyond the Neutron team alone. > > I've reviewed ( > https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified) > and found nowhere a guideline suggesting that before a backend has fully > implemented and merged upstream a technology (i.e. another project outside > of OepnStack!), OpenStack Neutron can't make any move. ODL is working >2 > years to support NSH using patches, yet to be accepted into Linux Kernel > (almost done) and OvS (preliminary) - as you stated. Otherwise we create a > serialization, that gets worse and worse over time and with additional > layers. > > No one suggests the such code needs to be PRODUCTION, but we need a way to > roll out EXPERIMENTAL functions and later merge them quickly when all > layers are ready, this creates a nice parallelism and keeps a decent pace > of rolling out new features broadly supported elsewhere. > I agree with this last statement; this is for instance what is happening with OVN which, in order to work with Neutron, needs patching and stay close to trunk etc. The technology is still maturing and the whole Neutron integration is in progress, but at least there's a clear signal that the it will eventually become mainstream. If it did not, I would bet that priorities would be focused elsewhere. You asked in a previous email whether Neutron wanted to kept itself hostage of OVS. My answer to you is NO: we have many technology stack options we can rely on in order to realize abstractions so long as they are open, and have a viable future. > > Thx > > Uri (“Oo-Ree”) > C: 949-378-7568 > > -Original Message- > From: Tim Rozet [mailto:tro...@redhat.com] > Sent: Friday, May 20, 2016 7:01 PM > To: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org>; Elzur, Uri > Cc: Cathy Zhang > Subject: Re: [openstack-dev] [Neutron] support
Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
Hi Uri, I originally wrote the Tacker->ODL SFC NSH piece and have been working with Tacker and networking-sfc team to bring it upstream into OpenStack. Cathy, Stephen, Louis and the rest of the networking-sfc team have been very receptive to changes specific to NSH around their current API and DB model. The proper place for SFC to live in OpenStack is networking-sfc, while Tacker can do its orchestration job by rendering ETSI MANO TOSCA input like VNF Descriptors and VNF Forwarding Graph Descriptors. We currently have a spec in netwoking-odl to migrate my original driver for ODL to do IETF NSH. That driver will be supported in networking-sfc, along with some changes to networking-sfc to account for NSH awareness and encap type (like VXLAN+GPE or Ethernet). The OVS work to support NSH is coming along and patches are under review. Yi Yang has built a private OVS version with these changes and we can use that for now to test with. I think it is all coming together and will take a couple more months before all of the pieces (Tacker, networking-sfc, networking-odl, ovs) are in place. I don't think networking-sfc is holding up any progress. Thanks, Tim Rozet Red Hat SDN Team - Original Message - From: "Uri Elzur" To: "OpenStack Development Mailing List (not for usage questions)" , "Cathy Zhang" Sent: Friday, May 20, 2016 8:37:26 PM Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC Hi Armando, Cathy, All First I apologize for the delay, returning from a week long international trip. (yes, I know, a lousy excuse on many accounts…) If I’m attempting to summarize all the responses, it seems like · A given abstraction in Neutron is allowed (e.g. in support of SFC), preferably not specific to a given technology e.g. NSH for SFC · A stadium project is not held to the same tests (but we do not have a “formal” model here, today) and therefore can support even a specific technology e.g. NSH (definitely better with abstractions to meet Neutron standards for future integration) However, · There still is a chicken and egg phenomenon… how can a technology become main stream with OPEN SOURCE support if we can’t get an OpenStack to support the required abstractions before the technology was adopted elsewhere?? o Especially as Stadium, can we let Neutron to lead the industry, given broad enough community interest? · BTW, in this particular case, there originally has been a direct ODL access as a NSH solution (i.e. NO OpenStack option), then we got Tacker (now an Neutron Stadium project, if I get it right) to support SFC and NSH, but we are still told that networking-sfc (another Neutron Stadium project ) can’t do the same…. · Also regarding the following comment made on another message in this thread, “ As to OvS features, I guess the OvS ml is a better place, but wonder if the Neutron community wants to hold itself hostage to the pace of other projects who are reluctant to adopt a feature ”, what I mean is again, that chicken and egg situation as above. Personally, I think OpenStack Neutron should allow mechanisms that are of interest / value to the networking community at large, to “ experiment with the abstraction” as you stated, independent of other organizations/projects … SOOO, is the bottom line that we agree that supporting NSH explicitly in networking-sfc can be added now? Thx Uri (“Oo-Ree”) C: 949-378-7568 From: Armando M. [mailto:arma...@gmail.com] Sent: Friday, May 13, 2016 5:14 PM To: Cathy Zhang Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC On 13 May 2016 at 16:01, Cathy Zhang < cathy.h.zh...@huawei.com > wrote: Hi Uri, Current networking-sfc API allows the user to specify the data path SFC encapsulation mechanism and NSH could be one of the encapsulation options. But since OVS release has not supported the NSH yet, we have to wait until NSH is added into OVS and then start to support the NSH encapsulation mechanism in the data path. One can support NSH whichever way they see fit. NSH in OVS is not something Neutron can do anything about. Neutron is about defining abstractions that can apply to a variety of technologies and experiment with what open source component is available on the shelves. Anyone can take the abstraction and deliver whatever technology stack they want with it and we'd happily gather any feedback to iterate on the abstraction to address more and more use case. AFAIK, it is the position of Neutron to have any OVS related new features developed inside the OVS community. Thanks, Cathy From: Elzur, Uri [mailto: uri.el...@intel.com ] Sent: Friday, May 13, 2016 3:02 PM To: OpenStack Development Mailing List (not for usage questions); Armando M Subject: [openstack-dev] [
Re: [openstack-dev] [Tacker] Invalid command sfc-create
Hi Victor, You can use the local.conf thats in the sfc-random repo. The sfc functionality is not in upstream Tacker yet. It is here: https://github.com/trozet/sfc-random/blob/master/local.conf#L2 Tim Rozet Red Hat SDN Team - Original Message - From: "Victor Mehmeri" To: openstack-dev@lists.openstack.org Sent: Wednesday, April 13, 2016 4:38:10 PM Subject: [openstack-dev] [Tacker] Invalid command sfc-create Hi all, I am trying to follow this walkthrough here: https://github.com/trozet/sfc-random/blob/master/tacker_sfc_walkthrough.txt But when I get to this point: tacker sfc-create --name mychain --chain testVNF1, I get the error: Invalid command u'sfc-create --name' ‘tacker help’ doesn’t even list any command related to sfc. My devstack local.conf file has this line: enable_plugin tacker https://git.openstack.org/openstack/tacker stable/liberty is the reason that I don’t have sfc-related commands that I am pointing to the liberty version? Should I point to master and rerun stack.sh? Thanks in advance, Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
