[openstack-dev] [Neutron][ovn] networking-ovn-core updates
Hello, everyone. I'd like to welcome two new members to the networking-ovn-core team: Miguel Angel Ajo and Yamamoto Takashi. Miguel has been contributing to Neutron for a long time and was a past member of the neutron-core team. He has been focusing on OVN and its integration with Neutron for the past 6 months or so and has made a great impact to the project, both networking-ovn and OVN itself. He helped build L3 gateway HA support among other things. He has also been contributing to reviews for networking-ovn patches. Yamamoto Takashi is a long time contributor across several projects, including both Neutron and OVS. He's a member of neutron-core and more recently, neutron-drivers. He's also one of the Open vSwitch project committers. Yamamoto has been contributing some reviews to the networking-ovn repository. We are thankful for his time and expertise on the networking-ovn reviews and have added him to the core team. They join the existing core team of: Russell Bryant, Dong Jun, Han Zhou, Numan Siddique, and Lucas Alvares Gomes Martins. Thanks, -- Russell Bryant __ 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] [ovs-announce] CFP for OpenStack Open Source Days Sydney
On Wed, Sep 20, 2017 at 3:21 PM, Ben Pfaff <b...@ovn.org> wrote: > In May, the OpenStack Summit graciously offered Open vSwitch use of a > room for a day of talks, and it worked out great. For the OpenStack > Summit in Sydney, which will be held Nov. 6-8, they've again offered us > time for Open vSwitch related talks, although this time, we only have > have two 40-minute slots. > > If you're interested in speaking in Sydney, please send a title, list of > speakers, and a brief abstract to ovs...@openvswitch.org by Sept. 27 > (that's only one week away!). If we receive more quality proposals than > the two slots allow, we will consider subdividing them into 20-minute > pieces and we will prioritize talks that relate to OpenStack, > > Thanks, > > Ben. > ___ > announce mailing list > annou...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-announce > -- Russell Bryant __ 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] [openstack] [charms] Openstack with OVN
Just to make sure you saw it - here is the manual installation doc to help guide you through what needs to be implemented in a project like this. https://docs.openstack.org/networking-ovn/latest/install/index.html On Thu, Aug 31, 2017 at 3:39 PM, Aakash Kt <aakash...@gmail.com> wrote: > Hi James, > Thanks for the reply. This definitely cleared some thing up for me. > I would love to get started on this charm soon, and will be sure to drop > in weekly meeting or ask questions on IRC. > > Cheers, > Aakash > > > On Tue, Aug 29, 2017 at 1:56 PM, James Page <james.p...@ubuntu.com> wrote: > >> Hi Aakash >> >> On Tue, 29 Aug 2017 at 05:09 Aakash Kt <aakash...@gmail.com> wrote: >> >>> Hello all, >>> Resending this mail since I think there might have been some error >>> sending it the last time. >>> >>>I am looking to develop an openstack bundle which uses OVN as the >>> SDN. I have been reading : https://docs.openstack.org/c >>> harm-guide/latest/ >>> I have also read : https://docs.openstack.org/n >>> etworking-ovn/latest/install/index.html >>> >> >> Awesome; we chatted about this on IRC a few times but put off any >> concrete work until OVN 2.8.0 is released (soon). >> >> As far as I understand, this will require me to replace the >>> "neutron-openvswitch" charm in the openstack base bundle. However, I am not >>> able to exactly understand what all I will have to rewrite / replace to >>> make this work. >>> >> >> I think the new charm work is actually three charms (or maybe two) - >> neutron-ovn (replacing neutron-openvswitch alongside nova-compute >> deployments), neutron-api-ovn (providing the API only integration of the >> Neutron API to OVN), and probably an ovn charm for deployment of OVN >> itself, with relations <-> <-> for >> propagation of configuration in deployments. The ODL charm set is similar >> is high level design (neutron-api-odl, odl-controller, openvswitch-odl). >> >> >>> Specifically, I need to make neutron work only as an API instead of the >>> full blown SDN. Also, in the above doc, its mentioned that we have to run >>> some setup on "controller nodes". How does the term "controller node" map >>> to the charm? >>> >> >> Controller nodes are one option for the charms, however components of the >> controller nodes are deployed inside LXD containers to provide separation >> between services. For example, you can dedicated three physical servers >> and then deploy the nova-cloud-controller, neutron-api, glance, keystone, >> cinder, ceilometer, heat etc.. charms in LXD containers onto those physical >> machines. So in the case of OVN, we'd look to deploy the ovn charm on >> these same physical servers. >> >> Hope that helps explain things a bit; if you want to drop into >> #openstack-charms to ask more questions please do, or you can join one of >> our weekly meetings and we can discuss further. We'd normally start a >> piece of work like this with a spec (http://specs.openstack.org/op >> enstack/charm-specs/); this topic is something we could discuss in a bit >> more detail at the PTG in Denver (I'll add an item to the agenda for the >> charms room). >> >> Cheers >> >> James >> >> >> >> ______ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > -- Russell Bryant __ 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] Ocata - Ubuntu 16.04 - OVN does not work with DPDK
t; >> But I have no idea about how to use OpenvSwitch with this thing, >> however, if I can achieve DPDK-Like performance, without DPDK, using just >> plain Linux, I'm a 100% sure that I'll prefer it! >> >> I'm okay to give OpenvSwitch + DPDK another try, even knowing that it >> [OVS] STILL have serious problems (https://bugs.launchpad.net/ub >> untu/+source/openvswitch/+bug/1577088)... >> --- >> >> OpenStack on Ubuntu rocks! :-D >> >> Thanks! >> Thiago >> > > I just realized how cool IO Visor is! > > Sorry about mixing subjects, let's keep this one clear for OVN on top of > DPDK. > > I found a opened bug on RedHat's Bugzilla, I updated it with the info from > this e-mail: > > https://bugzilla.redhat.com/show_bug.cgi?id=1410565 > > Looks like that, OVN doc say that it is supported on top of any > OpenvSwitch Datapath but, it is not the case... Right? > > I would be happy to be able to use GENEVE on top of regular Linux > datapath, and only Provider Networks on top of DPDK but, it also doesn't > work. I'll post more details about this later. > > The primary limitation here is that the userspace (DPDK) datapath does not yet support NAT. See the datapath feature matrix here: http://docs.openvswitch.org/en/latest/faq/releases/ So, indeed, provider networks only is going to the configuration that works with DPDK. You could do Geneve networks + provider networks, assuming you set it up so that NAT is not used anywhere. -- Russell Bryant __ 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-l2gw] openstack vtep setup missing docs
On Thu, Mar 30, 2017 at 12:40 PM, Armando M. <arma...@gmail.com> wrote: > On 30 March 2017 at 08:47, Saverio Proto <saverio.pr...@switch.ch> wrote: > >> Hello, >> >> I am trying to use the neutron l2gw plugin, but I am not using a bare >> metal switch to bridge. >> >> I am using a server with Openvswitch. >> > > I am not aware of any effort to implement L2GW purely in software, in fact > this was one key missing pieces that prevented the project to have CI > solely dealt with the upstream infra resources. Perhaps OVN may come to the > rescue here, I recall at some point the team was looking at the L2GW API. > networking-ovn still does not support the networking-l2gw API. OVN itself does support two types of L2 gateways. 1) hardware_vtep based gateways. We do have this exposed through networking-ovn, but only via an undocumented custom binding:profile. The intention was to eventually support the networking-l2gw API, but it hasn't been prioritized. https://bugs.launchpad.net/networking-ovn/+bug/1457569 2) Software based L2 gateways. You can configure OVN to use any host as an L2 gateway. We haven't looked at Neutron integration of this at all. Perhaps it maps into the networking-l2gw API as well, though? I'm happy to provide pointers if anyone is interested in working in this area. -- Russell Bryant __ 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-*] Attention for upcoming refactoring
On Wed, Dec 21, 2016 at 10:50 AM, Anna Taraday <akamyshnik...@mirantis.com> wrote: > Hello everyone! > > I've got two changes with refactor of TypeDriver [1] and segments db [2] > which is needed for implementation new engine facade [3]. > > Reviewers of networking-cisco, networking-arista, networking-nec > <https://review.openstack.org/#/projects/openstack/networking-nec,dashboards/default> > , networking-midonet > <https://review.openstack.org/#/projects/openstack/networking-midonet,dashboards/default> > , networking-edge-vpn, networking-bagpipe, tricircle, group-based-policy - > pay attention for [4]. > > Also recently merged refactor of ml2/db.py [5]. Fixes > for networking-cisco, networking-cisco, networking-cisco - are on review > [6] > > [1] - https://review.openstack.org/#/c/398873/ > [2] - https://review.openstack.org/#/c/406275/ > [3] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch > [4] - https://review.openstack.org/#/q/topic:segmentsdb > [5] - https://review.openstack.org/#/c/404714/ > [6] - https://review.openstack.org/#/q/status:open++branch: > master+topic:refactor_ml2db > Thanks a lot for looking out for the various networking-* projects when working on changes like this. It's really great to see. -- Russell Bryant __ 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] [networking-ovn] OVN native gateway workflow
On Thu, Nov 17, 2016 at 4:23 AM, Michael Kashin <mmkas...@gmail.com> wrote: > Greetings, > I'm testing OVN integration with RDO Openstack. I can create tenant > networks and attach VMs to them with no issues. However I don't get how the > gateway scheduling works. It seems like whenever I create an external > provider network and attach it to my DLR, OVN should schedule a gateway > router and connect it to my DVR via an special transit network. However I > don't see that happening. > Hi, it looks like you posted this to two mailing lists. I answered over on the ovs-discuss mailing list, where I saw it first. Here's the thread: https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/042970.html -- Russell Bryant -- Russell Bryant __ 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] [tripleo] Is it time to reconsider how we configure OVS bridges in the overcloud?
On Thu, Nov 10, 2016 at 10:22 AM, Brent Eagles <beag...@redhat.com> wrote: > To something like: > (triple configured) > - eth0 > - br-ctl - used as br-ex is currently used except neutron knows nothing > about it. > - br-ex -patched to br-ctl - ostensibly for external traffic and this is > what neutron in the overcloud is configured to use > (neutron configured) > - br-int > - br-tun > > (In all cases, neutron configures patches, etc. between bridges *it knows > about* as needed. That is, in the second case, tripleo would configure the > patch between br-ctl and br-ex) > +1. I think this configuration makes more sense than the previous overlapping usage of br-ex. > At the cost of an extra bridge (ovs bridge to ovs bridge with patch ports > is allegedly cheap btw) we get: > Yes, it is cheap. I would not consider this a concern from a data path performance point of view. The separate bridges and patch ports only exist in userspace. They don't affect the fast path and the impact to the slow path is negligible. > 1. an independently configured bridge for overcloud traffic insulates > non-tenant node traffic against changes to neutron, including upgrades, > neutron bugs, etc. > 2. insulates neutron from changes to the underlying network that it > doesn't "care" about. > 3. In OVS only environments, the difference between a single nic > environment and one where there is a dedicated nic for external traffic is, > instead of a patch port from br-ctl to br-ex, it is directly connected to > the nic for the external traffic. > > Even without the issue that instigated this message, I think that this is > a change worth considering. > Nice writeup, Brent. -- Russell Bryant __ 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] [all] Embracing new languages in OpenStack
On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent <cdent...@anticdent.org> wrote: > On Tue, 8 Nov 2016, Ash wrote: > > I couldn't agree more. I don't like change for the sake of change (in any >> aspect of my life). So in my mind this would have to be a way to better >> bind us. >> > > Here, have some tortured metaphors: > > Something that feels like it gets under-emphasised in this conversation > is that change is coming whatever we do. As a community we can either > move quickly and stay ahead of the change and see it as a productive > development that we can surf or we can dilly dally and get drowned by a > wave that collapses over us. > > Ecosystems must evolve and change because the world evolves and changes. > If we try to control this stuff too much what we will be doing is taking > the oxygen out of the system and snuffing the flame of excitement and > innovation. > > As a community we don't want to be bound together by rules, we want > to be enabled by processes that support making and doing things > effectively. The things that we make and do is what binds us > together. > > The conversations about additional languages in this community have > been one our most alarmingly regressive and patronizing. They seem > to be bred out of fear rather than hope and out of lack of faith in > each other than in trust. We've got people who want to build stuff. > Isn't that the important part? > > Let's just get on with making stuff and work out the problems (and of > course there will be many, there always are) as they happen. That's > what we do. > Agreed, Chris. I think this topic has reflected quite poorly on OpenStack, so far. -- Russell Bryant __ 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] [ovn] [[l3-agent] connectivity to external network
On Thu, Nov 3, 2016 at 3:31 PM, Murali R <muralir...@gmail.com> wrote: > The scope of question is using neutron L3 services with OVN. The problem > is when a router created, there is no implicit internal interface created > between the router instance and the external bridge. > To be honest, support of the Neutron L3 agent was only a transitional thing while we bootstrapped OVN. It was only useful while the corresponding features were added to OVN. Once we merge [1], I don't see any reason to keep support of the L3 agent any longer and plan to remove support for it and the corresponding CI jobs. My suggestion would be to try to do what you need using OVN's L3 support. [1] https://review.openstack.org/#/c/346646/ -- Russell Bryant __ 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] [networking-ovn] restart failure to bring up ovn services
On Wed, Nov 2, 2016 at 6:48 PM, Murali R <muralir...@gmail.com> wrote: > Following the docs online (Newton), the installation was successful. > However when the VM that has the controller (and ovn-nb) restarted, it > fails to bring up ovs & ovn. This is ubuntu deployment using > python-networking-ovn and locally built ovn. Is this a deployment problem? > Is it possible to recover from here without losing the neutron DB sync? I > have not configured any networks that I need to save. > > NOTE: I did a reboot once before and the services came back fine at that > time. Not sure if there is a sequence to be followed while shutting down - > if so can I know what it would be? > > Nov 2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003 > 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn [-] OVS database connection > to OVN_Northbound failed with error: 'Could not retrieve schema from tcp: > 192.168.56.102:6641: Connection refused'. Verify that the OVS and OVN > services are available and that the 'ovn_nb_connection' and > 'ovn_sb_connection' configuration options are correct. > Nov 2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003 > 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn Traceback (most recent call > last): > Nov 2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003 > 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn File > "/usr/lib/python2.7/dist-packages/networking_ovn/ovsdb/impl_idl_ovn.py", > line 84, in __init__ > > > Nov 2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003 > 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn 'err': os.strerror(err)}) > Nov 2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003 > 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn Exception: Could not > retrieve schema from tcp:192.168.56.102:6641: Connection refused > Nov 2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003 > 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn > As you noted, it looks like the OVN services were not started. If you installed from source, you should run: $ sudo /usr/share/openvswitch/scripts/ovn-ctl start_northd The OVN packages install systemd units, so you can also start it that way and set it up to re-start after a reboot. $ sudo systemctl enable ovn-northd $ sudo systemctl start ovn-northd -- Russell Bryant __ 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] Neutron team social event in Barcelona
On Friday, October 14, 2016, Miguel Lavalle <mig...@mlavalle.com> wrote: > Dear Neutrinos, > > I am organizing a social event for the team on Thursday 27th at 19:30. > After doing some Google research, I am proposing Raco de la Vila, which is > located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu > is here: http://www.racodelavila.com/en/carta-racodelavila.htm > > It is easy to get there by subway from the Summit venue: > https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people > under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we > can get a final count. > > Here's some reviews: https://www.tripadvisor.com/ > Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_ > Vila-Barcelona_Catalonia.html > +1 -- Russell Bryant __ 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] [ovs-discuss] [ovn][neutron] networking-ovn 1.0.0 release (newton) -- port-security
On Tue, Oct 11, 2016 at 2:47 PM, Murali R <muralir...@gmail.com> wrote: > Hi, > > Please clarify if port security is required to be enabled with newton > release when installing OVN. The install.rst says it must be. In many of my > use cases I want to disable port security which is how I do currently with > devstack. I would like to know if either ovn or neutron will have > contentions if port-security disabled at neutron server. > You can disable it. There's no problem with that. It will just disable related features: L2 and L3 port security and security groups. -- Russell Bryant __ 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] [tripleo] Feature freeze exception for OVN
On Tue, Aug 30, 2016 at 11:51 AM, Steven Hardy <sha...@redhat.com> wrote: > On Tue, Aug 30, 2016 at 07:53:07PM +0530, Babu Shanmugam wrote: > > Hi, > > > > The THT patch for OVN [1] has no more dependencies with the recent > merging > > of [2]. The changes in heat templates does not have any impact on the > > existing templates as major of the changes are in new templates and will > be > > used only when OVN is enabled. > > > > It would be nice to have OVN templates for the upcoming release > considering > > that OVN's first official release is due shortly. I am sure [1] will have > > some review comments and is unlikely to get merged by today, but will > you be > > able to consider a freeze exception for this feature. > > Considering it's only one patch and disabled by default I think we can, but > please can you raise a launchpad blueprint for this feature? > > I've reviewed the patch previously, but it's slipped off my newton review > list because it's not tracked in launchpad. > Thanks, Steve. A blueprint was filed here: https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovn > > Thanks! > > Steve > > > > > > > Thank you, > > Babu > > > > > > [1] - https://review.openstack.org/307734 > > > > [2] - https://review.openstack.org/314875 > > __ > 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 > -- Russell Bryant __ 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off
On Thu, Jul 28, 2016 at 2:20 PM, Jay Pipes <jaypi...@gmail.com> wrote: > How would guidance from the TC about what it means for a repo to be "part > of the OpenStack tent" add clarity for repos that are not trying to be part > of the OpenStack tent? > > Just curious here... Related, Flavio asked about this earlier, and I don't think it was answered. Is the issue with the use of the Fuel name? Would the concern remain if the repository was called "pancakes-ccp" instead of "fuel-ccp"? -- Russell Bryant __ 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off
On Thu, Jul 28, 2016 at 10:52 AM, Flavio Percoco <fla...@redhat.com> wrote: > On 28/07/16 15:48 +0300, Vladimir Kozhukalov wrote: > >> 1. Alter the mission statement of fuel to match the reality being >>> >> >> published by the press and Mirantis's executive team >>> >> >> 2. Include these non-experimental repos in the projects.yaml governance >>> >> >> Repository >>> >> >> Frankly, I don’t understand what part of the press release contradicts >> with >> Fuel mission. >> >> Current Fuel mission is “To streamline and accelerate the process of >> deploying, testing and maintaining various configurations of OpenStack at >> scale.” which means we are not bound to any specific technology when >> deploying OpenStack. >> > > TBH, I also think this statement is broad enough to cover containers. > Unless the > request is to explicitly mention "containers" in the mission statement, I > think > there's no need to change it. I'd also be against having "containers" being > explicitly mentioned in Fuel's statement, FWIW. I don't think it'd be of > any > benefit/use. Unless I'm missing something fundamental here, of course. I agree that the current mission statement seems fine. > > At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel specific >> orchestration mechanism. We are not going to drop this approach >> immediately, it works quite well and we are working hard to make things >> better (including ability to upgrade). But we also keep in mind that >> technologies are constantly changing and we’d like to benefit of this >> progress. That is why we are now looking at Docker containers and >> Kubernetes. Our users know that it is not our first experience of trying >> to >> use containers. Fuel releases prior to 9.0 used to deploy Fuel services in >> containers on the Fuel admin node. >> >> Many of you know how difficult it is to upgrade OpenStack clusters. We >> hope >> that containers could help us to solve not all but some of problems that >> we >> encounter when upgrading cluster. Maintaining and hence upgrade of >> OpenStack clusters is a part of Fuel mission and we are just trying to >> find >> a way how to do things. >> >> Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by >> Mirantis. At Mirantis we deploy and maintain OpenStack. In attempts to >> find >> a way how to make OpenStack easily maintainable, some of Mirantis folks >> spent some time to contribute to Kolla and Mesos. But there were some >> concerns that were discussed several times (including this Kolla spec >> https://review.openstack.org/#/c/330575) that would make it not so easy >> to >> use Kolla containers for our use cases. Fuel-ccp is just an attempt to >> address these concerns. Frankly, I don’t see anything bad in having more >> than one set of container images (like we have more than one set of >> RPM/DEB >> distributions). >> > > ++ > I think the project seems fine. They are clearly aware of Kolla. If they don't want to use it (for whatever the reason), I don't think it matters. OpenStack deployment is far from a well solved problem. We have plenty of overlapping deployment related projects and I'm happy to see that continue. Ongoing experimentation with different approaches is a good thing here. To summarize, I see all actions taken so far by the Fuel team as fine. I see no need to change anything in governance. They are free to add it as an official deliverable if and when they choose to do so. Even if they have a vision of these things becoming official and supported in the future, that does not mean they must mark them that way today. -- Russell Bryant __ 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-ovn][networking-odl] Syncing neutron DB and OVN DB
On Wed, Jul 27, 2016 at 4:15 PM, Zhou, Han <hzh...@ebay.com> wrote: > > > On Wed, Jul 27, 2016 at 7:15 AM, Russell Bryant <rbry...@redhat.com> > wrote: > >> >> >> On Wed, Jul 27, 2016 at 5:58 AM, Kevin Benton <ke...@benton.pub> wrote: >> >>> > I'd like to see if we can solve the problems more generally. >>> >>> We've tried before but we very quickly run into competing requirements >>> with regards to eventual consistency. For example, asynchronous background >>> sync doesn't work if someone wants their backend to confirm that port >>> details are acceptable (e.g. mac isn't in use by some other system outside >>> of openstack). Then each backend has different methods for detecting what >>> is out of sync (e.g. config numbers, hashes, or just full syncs on startup) >>> that each come with their own requirements for how much data needs to be >>> resent when an inconsistency is detected. >>> >>> If we can come to some common ground of what is required by all of them, >>> then I would love to get some of this built into the ML2 framework. >>> However, we've discussed this at meetups/mid-cycles/summits and it >>> inevitably ends up with two people drawing furiously on a whiteboard, >>> someone crying in the corner, and everyone else arguing about the lack of >>> parametric polymorphism in Go. >>> >> >> Ha, yes, makes sense that this is really hard to solve in a way that >> works for everyone ... >> >> >> >>> Even between OVN and ODL in this thread, it sounds like the only thing >>> in common is a background worker that consumes from a queue of tasks in the >>> db. Maybe realistically the only common thing we can come up with is a >>> taskflow queue stored in the DB to solve the multiple workers issue... >>> >> >> To clarify, ODL has this background worker and the discussion was >> whether OVN should try to follow a similar approach. >> >> So far, my gut feeling is that it's far too complicated for the problems >> it would solve. There's one identified multiple-worker related race >> condition on updates, but I think we can solve that another way. >> >> > Russell, in fact I think this background worker is the good way to solve > both problems: > > Problem 1. When something failed when updating OVN DB in post-commit: With > the help of background worker, it can do the retries and the job state can > be tracked, and with the information proper actions can be taken against > failure jobs, e.g. cleanups. It is basically a declarative way of > implementation, which IMHO is a particularly good way in ML2 context, > because we cannot just rollback Neutron DB changes at failure because it is > shared by all mech-drivers. (Even in a monolithic plugin, handling the > partial failures and doing rollback is a big headache). > > Problem 2. Race condition because of lack of critical section between > Neutron DB transaction and post-commit: With the help of journal, the > ordering is ensured to be the same as DB transaction commits. Protection > against the journal processing between multiple background workers can be > properly enforced with the help of DB transaction. > > I think ODL and OVN are not the only ones facing these problems. They are > pretty general to most drivers if not all. It would be great to have a > common task flow mechanism in ML2, but I'd like to try it in OVN first (if > no better solution to the problems above). > I had another idea for problem 2, at least. I posted a more detailed description of the idea on the bug you posted [1]. This is unrelated to problem 1, though. I guess I was hoping we could just come up with a better way of doing rollbacks when necessary. I also had a long term dream of not using the Neutron DB at all, and only relying on the OVN database. That seems much less practical now that we've moved back to ML2. Maybe it was a crazy idea, anyway. :-) [1] https://bugs.launchpad.net/networking-ovn/+bug/1605089 -- Russell Bryant __ 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-ovn][networking-odl] Syncing neutron DB and OVN DB
On Wed, Jul 27, 2016 at 5:58 AM, Kevin Benton <ke...@benton.pub> wrote: > > I'd like to see if we can solve the problems more generally. > > We've tried before but we very quickly run into competing requirements > with regards to eventual consistency. For example, asynchronous background > sync doesn't work if someone wants their backend to confirm that port > details are acceptable (e.g. mac isn't in use by some other system outside > of openstack). Then each backend has different methods for detecting what > is out of sync (e.g. config numbers, hashes, or just full syncs on startup) > that each come with their own requirements for how much data needs to be > resent when an inconsistency is detected. > > If we can come to some common ground of what is required by all of them, > then I would love to get some of this built into the ML2 framework. > However, we've discussed this at meetups/mid-cycles/summits and it > inevitably ends up with two people drawing furiously on a whiteboard, > someone crying in the corner, and everyone else arguing about the lack of > parametric polymorphism in Go. > Ha, yes, makes sense that this is really hard to solve in a way that works for everyone ... > Even between OVN and ODL in this thread, it sounds like the only thing in > common is a background worker that consumes from a queue of tasks in the > db. Maybe realistically the only common thing we can come up with is a > taskflow queue stored in the DB to solve the multiple workers issue... > To clarify, ODL has this background worker and the discussion was whether OVN should try to follow a similar approach. So far, my gut feeling is that it's far too complicated for the problems it would solve. There's one identified multiple-worker related race condition on updates, but I think we can solve that another way. > On Tue, Jul 26, 2016 at 11:31 AM, Russell Bryant <rbry...@redhat.com> > wrote: > >> >> >> On Fri, Jul 22, 2016 at 7:51 AM, Numan Siddique <nusid...@redhat.com> >> wrote: >> >>> Thanks for the comments Amitabha. >>> Please see comments inline >>> >>> On Fri, Jul 22, 2016 at 5:50 AM, Amitabha Biswas <azbis...@gmail.com> >>> wrote: >>> >>>> Hi Numan, >>>> >>>> Thanks for the proposal. We have also been thinking about this use-case. >>>> >>>> If I’m reading this accurately (and I may not be), it seems that the >>>> proposal is to not have any OVN NB (CUD) operations (R operations outside >>>> the scope) done by the api_worker threads but rather by a new journal >>>> thread. >>>> >>>> >>> Correct. >>> >>> >>> >>>> If this is indeed the case, I’d like to consider the scenario when >>>> there any N neutron nodes, each node with M worker threads. The journal >>>> thread at the each node contain list of pending operations. Could there be >>>> (sequence) dependency in the pending operations amongst each the journal >>>> threads in the nodes that prevents them from getting applied (for e.g. >>>> Logical_Router_Port and Logical_Switch_Port inter-dependency), because we >>>> are returning success on neutron operations that have still not been >>>> committed to the NB DB. >>>> >>>> >>> I >>> ts a valid scenario and should be designed properly to handle such >>> scenarios in case we take this approach. >>> >> >> I believe a new table in the Neutron DB is used to synchronize all of >> the journal threads. >> >> Also note that OVN currently has no custom tables in the Neutron database >> and it would be *very* good to keep it that way if we can. >> >> >>> >>> >>> >>>> Couple of clarifications and thoughts below. >>>> >>>> Thanks >>>> Amitabha <abis...@us.ibm.com> >>>> >>>> On Jul 13, 2016, at 1:20 AM, Numan Siddique <nusid...@redhat.com> >>>> wrote: >>>> >>>> Adding the proper tags in subject >>>> >>>> On Wed, Jul 13, 2016 at 1:22 PM, Numan Siddique <nusid...@redhat.com> >>>> wrote: >>>> >>>>> Hi Neutrinos, >>>>> >>>>> Presently, In the OVN ML2 driver we have 2 ways to sync neutron DB and >>>>> OVN DB >>>>> - At neutron-server startup, OVN ML2 driver syncs the neutron DB and >>>>> OVN DB if sync mode is set to repair. >>>>> - Admin can run the "neutron-ov
Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB
On Fri, Jul 22, 2016 at 9:37 PM, Zhou, Han <hzh...@ebay.com> wrote: > However, I didn't figure out how errors are handled with this approach. > For example, a port is created in Neutron but ODL controller failed to > create it although the journal thread successfully sent the request to ODL. > And I didn't see how the port states (UP & DOWN) are handled (I didn’t see > any call to ProvisioningBlock, so does it mean it will just be UP from the > beginning?) It would be great if anyone can help answer this question. > Port state is up from the beginning in ODL. -- Russell Bryant __ 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-ovn][networking-odl] Syncing neutron DB and OVN DB
;> >>> >>> --- >>> >>> (1) >>> Sync threads created by networking-odl ML2 driver >>> -- >>> ODL ML2 driver creates 2 threads (threading.Thread module) at init >>> - Journal thread >>> - Maintenance thread >>> >>> Journal thread >>> >>> The journal module creates a new journal table by name >>> “opendaylightjournal” - >>> https://github.com/openstack/networking-odl/blob/master/networking_odl/db/models.py#L23 >>> >>> Journal thread will be in loop waiting for the sync event from the ODL >>> ML2 driver. >>> >>> - ODL ML2 driver resource (network, subnet, port) precommit functions >>> when called by the ML2 plugin adds an entry in the “opendaylightjournal” >>> table with the resource data and sets the journal operation state for this >>> entry to “PENDING”. >>> - The corresponding resource postcommit function of the ODL ML2 plugin >>> when called, sets the sync event flag. >>> - A timer is also created which sets the sync event flag when it >>> expires (the default value is 10 seconds). >>> - Journal thread wakes up, looks into the “opendaylightjournal” table >>> with the entries with state “pending” and runs the CRUD operation on those >>> resources in the ODL DB. Once done, it sets the state to “completed”. >>> >>> Maintenance thread >>> -- >>> Maintenance thread does 3 operations >>> - JournalCleanup - Delete completed rows from journal table >>> “opendaylightjournal”. >>> - CleanupProcessing - Mark orphaned processing rows to pending. >>> - Full sync - Re-sync when detecting an ODL "cold reboot”. >>> >>> >>> >>> Thanks >>> Numan >>> >>> >> __ >> 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 > > -- Russell Bryant __ 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] [puppet] Request to add puppet-dpdk module
On Thu, Jul 7, 2016 at 5:12 AM, Saravanan KR <skram...@redhat.com> wrote: > Hello, > > We are working on blueprint [1] to integrate DPDK with tripleo. In the > process, we are planning to add a new puppet module "puppet-dpdk" for the > required puppet changes. > > The initial version of the repository is at github [2]. Note that the > changes are > not > complete yet. It is in progress. > > Please let us know your views on including this new module. > > Regards, > Saravanan KR > > > [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk > [2] https://github.com/krsacme/puppet-dpdk > I took a quick look at Emilien's request. In general, including this functionality in the puppet openstack project makes sense to me. It looks like this is installing and configuring openvswitch-dpdk. Have you considered integrating DPDK awareness into the existing puppet-vswitch that configures openvswitch? Why is a separate puppet-dpdk needed? -- Russell Bryant __ 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-ovn] OVN vs. OpenDayLight
On Fri, Jun 10, 2016 at 11:11 AM, Oleg Bondarev <obonda...@mirantis.com> wrote: > Hi, > > [1] is a doc comparing OVN and ODL for Neutron. I wrote it in March so > some info might be stale. > Hope this can be useful, comments are welcome! > > [1] > https://docs.google.com/document/d/13K4Xpdu1IbRJDj5JTepDI4nwUkCDCu7IOnYwHkZtcMA/edit?usp=sharing > Nice work, Oleg. I'll comment on the doc for things that I know of that have changed since March. Thanks, -- Russell Bryant -- Russell Bryant __ 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] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)
On Mon, Apr 11, 2016 at 11:30 AM, Monty Taylor <mord...@inaugust.com> wrote: > On 04/11/2016 09:43 AM, Allison Randal wrote: > >> On Wed, Apr 6, 2016 at 1:11 PM, Davanum Srinivas <dava...@gmail.com> >>> wrote: >>> >>>> Reading unofficial notes [1], i found one topic very interesting: >>>> One Platform – How do we truly support containers and bare metal under >>>> a common API with VMs? (Ironic, Nova, adjacent communities e.g. >>>> Kubernetes, Apache Mesos etc) >>>> >>>> Anyone present at the meeting, please expand on those few notes on >>>> etherpad? And how if any this feedback is getting back to the >>>> projects? >>>> >>> >> It was really two separate conversations that got conflated in the >> summary. One conversation was just being supportive of bare metal, VMs, >> and containers within the OpenStack umbrella. The other conversation >> started with Monty talking about his work on shade, and how it wouldn't >> exist if more APIs were focused on the way users consume the APIs, and >> less an expression of the implementation details of each project. >> OpenStackClient was mentioned as a unified CLI for OpenStack focused >> more on the way users consume the CLI. (OpenStackSDK wasn't mentioned, >> but falls in the same general category of work.) >> >> i.e. There wasn't anything new in the conversation, it was more a matter >> of the developers/TC members on the board sharing information about work >> that's already happening. >> > > I agree with that - but would like to clarify the 'bare metal, VMs and > containers' part a bit. (an in fact, I was concerned in the meeting that > the messaging around this would be confusing because we 'supporting bare > metal' and 'supporting containers' mean two different things but we use one > phrase to talk about it. > > It's abundantly clear at the strategic level that having OpenStack be able > to provide both VMs and Bare Metal as two different sorts of resources > (ostensibly but not prescriptively via nova) is one of our advantages. We > wanted to underscore how important it is to be able to do that, and wanted > to underscore that so that it's really clear how important it is any time > the "but cloud should just be VMs" sentiment arises. > > The way we discussed "supporting containers" was quite different and was > not about nova providing containers. Rather, it was about reaching out to > our friends in other communities and working with them on making OpenStack > the best place to run things like kubernetes or docker swarm. Those are > systems that ultimately need to run, and it seems that good integration > (like kuryr with libnetwork) can provide a really strong story. I think > pretty much everyone agrees that there is not much value to us or the world > for us to compete with kubernetes or docker. > > So, we do want to be supportive of bare metal and containers - but the > specific _WAY_ we want to be supportive of those things is different for > each one. > I was there and agree with the summary provided by Allison and Monty. It's important to have some high level alignment on where we see our core strengths and where we see ourselves as complementary and not competitive. I don't think any of it was new information, but valuable to revisit nonetheless. -- Russell Bryant __ 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] [all][stackalytics] Gaming the Stackalytics stats
On Mon, Apr 11, 2016 at 6:48 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > Clint Byrum <cl...@fewbar.com> wrote: > > Excerpts from Morgan Fainberg's message of 2016-04-10 16:47:28 -0700: >> >>> On Sun, Apr 10, 2016 at 4:37 PM, Clint Byrum <cl...@fewbar.com> wrote: >>> >>> Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700: >>>> >>>>> There is also disincentive in +1ing a change that you don't understand >>>>> and is wrong and then a core comes along and -1s it (you get dinged for >>>>> the disagreement). And there is disincentive in -1ing a change for the >>>>> wrong reasons (silly nits or asking questions for understanding). I ask >>>>> a lot of questions in a lot of changes and I don't vote on those >>>>> because >>>>> it would be inappropriate. >>>>> >>>> >>>> Why is disagreement a negative thing? IMO, reviewers who agree too much >>>> are just part of the echo chamber. >>>> >>> There is no problem with disagreement IMHO. However, we track it as a >>> stat, >>> and people don't want to feel as though they are in disagreement with the >>> cores. I think this is just some level of psychology. >>> >>> I very, very rarely look at disagreement stat for anything (now or when I >>> was PTL). >>> >> >> Agreed, as a number, it can be highly misleading and is especially hard >> to compare to any of the other numbers. >> >> However, in meta-reviews, I found actual occurrences very useful to >> analyze how a reviewer handles confronting the other cores and how >> confident they are in their understanding of the code base. So it worries >> me that new people might be somehow discouraged from disagreement. >> >> So let me just say it here, disagreeing with the core reviewers when >> there is a valid reason _is what somebody who wants to be a core reviewer >> should be doing_. >> > > Amen to that! I find that people who have higher disagreement stats are > actually the people that add value to review process, since they obviously > look at patches from perspectives that are different from existing core > members. > > Now, I agree that if the disagreements are solely for nits in commit > messages or random misunderstandings, then it’s not of value. But if those > are legit concerns, that’s usually a good sign, not a bad one. > Note that the original definition of "disagreement" from reviewstats [1][2] paid particular attention to ordering. A disagreement is only when a -core team member votes against you, not the other way around. It was kind of an experimental thing to see if it could help expose overly eager +1 reviewers (lots of reviews for stats, missing lots of errors). Maybe it hasn't proved to be that valuable. I haven't looked at how stackalytics implements it, though. [1] http://git.openstack.org/cgit/openstack-infra/reviewstats [2] http://www.russellbryant.net/openstack-stats/ -- Russell Bryant __ 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] [all][elections] Results of the TC Election
On Fri, Apr 8, 2016 at 8:35 AM, Eoghan Glynn <egl...@redhat.com> wrote: > > > > > Please join me in congratulating the 7 newly elected members of the TC. > > > > > > <<<<<< REMOVE UNEEDED >>>>> > > > * Davanum Srinivas (dims) > > > * Flavio Percoco (flaper87) > > > * John Garbutt (johnthetubaguy) > > > * Matthew Treinish (mtreinish) > > > * Mike Perez (thingee) > > > * Morgan Fainberg (morgan)/(notmorgan) > > > * Thierry Carrez (ttx) > > > > > > Full results: > > > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a > > > > > > Thank you to all candidates who stood for election, having a good > group of > > > candidates helps engage the community in our democratic process. > > > > > > Thank you to all who voted and who encouraged others to vote. We need > to > > > ensure > > > your voice is heard. > > > > > > Thank you for another great round. > > > > > > Here's to Newton! > > > > Thanks Tony for efficiently running this election, congrats to > > the candidates who prevailed, and thanks to everyone who ran > > for putting themselves out there. > > > > It was the most open race since the pattern of TC 2.0 half- > > elections was established, which was great to see. > > > > However, the turnout continues to slide, dipping below 20% for > > the first time: > > > > Election | Electorate (delta %) | Votes | Turnout (delta %) > > === > > Oct '16 | 1106 | 342 | 30.92 > > Apr '14 | 1893 (+71.16) | 506 | 26.73 (-13.56) > > Apr '15 | 2169 (+14.58) | 548 | 25.27 (-5.48) > > Oct '15 | 2759 (+27.20) | 619 | 22.44 (-11.20) > > Apr '16 | 3284 (+19.03) | 652 | 19.85 (-11.51) > > Meh, I screwed up that table, not enough coffee yet today :) > > Should be: > > Election | Electorate (delta %) | Votes | Turnout (delta %) > === > Oct '13 | 1106 | 342 | 30.92 > Apr '14 | 1510 (+36.52) | 448 | 29.69 (-4.05) > Oct '14 | 1893 (+25.35) | 506 | 26.73 (-9.91) > Apr '15 | 2169 (+14.58) | 548 | 25.27 (-5.48) > Oct '15 | 2759 (+27.20) | 619 | 22.44 (-11.20) > Apr '16 | 3284 (+19.03) | 652 | 19.85 (-11.51) > It would also be interesting to know how the "long tail" of OpenStack has evolved over time, as well. https://twitter.com/tcarrez/status/710858829760598017 "A long tail: ~2500 devs are involved in #OpenStack Mitaka, but less than 200 devs produce more than 50% of changes" 652 contributors represents roughly 80% of the changes in Mitaka by eye-balling that graph. That doesn't sound as bad. -- Russell Bryant __ 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] OVSDB native interface as default in gate jobs
On Tue, Apr 5, 2016 at 12:57 PM, Assaf Muller <as...@redhat.com> wrote: > On Tue, Apr 5, 2016 at 12:35 PM, Sean M. Collins <s...@coreitpro.com> > wrote: > > Russell Bryant wrote: > >> because they are related to two different command line utilities > >> (ovs-vsctl vs ovs-ofctl) that speak two different protocols (OVSDB vs > >> OpenFlow) that talk to two different daemons on the system > (ovsdb-server vs > >> ovs-vswitchd) ? > > > > True, they influence two different daemons - but it's really two options > > that both have two settings: > > > > * "talk to it via the CLI tool" > > * "talk to it via a native interface" > > > > How likely is it to have one talking via native interface and the other > > via CLI? > > The ovsdb native interface is a couple of cycles more mature than the > openflow one, I see how some users would use one but not the other. and they use separate Python libraries, as well (ovs vs ryu). > > > > > Also, if the native interface is faster, I think we should consider > > making it the default. > > Definitely. I'd prefer to deprecate and delete the cli interfaces and > keep only the native interfaces in the long run. > +1. -- Russell Bryant __ 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] OVSDB native interface as default in gate jobs
On Mon, Apr 4, 2016 at 5:32 PM, Sean M. Collins <s...@coreitpro.com> wrote: > Inessa Vasilevskaya wrote: > > different configurations of of_interface and ovsdb_interface options > > (dsvm-fullstack [2] and rally tests are by now all I can think of). > > Wait, we have *two* different configuration options??? > > WHY WHY WHY > because they are related to two different command line utilities (ovs-vsctl vs ovs-ofctl) that speak two different protocols (OVSDB vs OpenFlow) that talk to two different daemons on the system (ovsdb-server vs ovs-vswitchd) ? With that said, I see no reason to keep two methods if one is clearly better. I just don't think combining them into one config option makes much sense. -- Russell Bryant __ 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-ovn] Changing OVN plugin release model for Newton
On Mon, Apr 4, 2016 at 12:22 PM, Kyle Mestery <mest...@mestery.com> wrote: > On Mon, Apr 4, 2016 at 8:15 AM, Russell Bryant <rbry...@redhat.com> wrote: > > Hello, everyone. > > > > While bootstrapping networking-ovn, the release model has been > > "release:independent" [1], though we haven't actually made any releases. > > This follows the state of OVN itself, which is still fast moving and > > developed in OVS master. > > > > On the OVN side, we're now targeting a first production release in time > for > > the OpenStack Newton release. We aim to branch OVS (which includes OVN) > in > > July and release by September or so. > > > > I think it's time to start making releases of the Neutron plugin. I > suggest > > we adopt "release:cycle-with-milestones" [2] to match the primary Neutron > > repositories. > > > > Thoughts? > > > +1, this makes sense to me. As you say, the eminent release of an OVN > release itself should trigger changes in the release model for the > plugin as well. > > Are you going to propose a governance patch to reflect this? > Thanks, Kyle. I just wanted to raise awareness of the proposed change first. https://review.openstack.org/301325 -- Russell Bryant __ 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] [Neutron][networking-ovn] Changing OVN plugin release model for Newton
Hello, everyone. While bootstrapping networking-ovn, the release model has been "release:independent" [1], though we haven't actually made any releases. This follows the state of OVN itself, which is still fast moving and developed in OVS master. On the OVN side, we're now targeting a first production release in time for the OpenStack Newton release. We aim to branch OVS (which includes OVN) in July and release by September or so. I think it's time to start making releases of the Neutron plugin. I suggest we adopt "release:cycle-with-milestones" [2] to match the primary Neutron repositories. Thoughts? [1] http://governance.openstack.org/reference/tags/release_independent.html [2] http://governance.openstack.org/reference/tags/release_cycle-with-milestones.html -- Russell Bryant __ 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] OVSDB native interface as default in gate jobs
On Tue, Mar 29, 2016 at 10:34 PM, Kevin Benton <ke...@benton.pub> wrote: > I'm not aware of any issues. Perhaps you can propose a patch to just > change the default in Neutron to that interface and people can -1 if there > are any concerns. > FWIW, the ovs Python library lacked Python 3 support until very recently. I finished it and have it all merged into ovs master, but it won't be in an official release until just before the Newton release (based on the current rough plan). In the meantime, there's a dev snapshot on PyPI that includes it (2.6.0.dev1). I'm not aware of any other problems. -- Russell Bryant __ 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] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)
On Mon, Mar 21, 2016 at 12:26 PM, Russell Bryant <rbry...@redhat.com> wrote: > On Thu, Mar 17, 2016 at 1:45 AM, Hong Hui Xiao <xiaoh...@cn.ibm.com> > wrote: > >> Hi Russell. >> >> Since the "ovn-bridge-mapping" will become accessible in OVN Southbound >> DB, do you meant that neutron plugin can read those bridge mappings from >> the OVN Southbound DB? I didn't think in that way because I thought >> networking-ovn will only transact data with OVN Northbound DB. >> > > You're right that networking-ovn currently only uses the OVN northbound > DB. This requirement crosses the line into physical space and needing to > know about some physical environment details, so reading from the > southbound DB for this info is acceptable. > > >> Also, do you have any link to describe the ongoing work in OVN to sync the >> "ovn-bridge-mapping" from hypervisor? > > > This patch introduces some new tables to the southbound DB: > > http://openvswitch.org/pipermail/dev/2016-March/068112.html > > I was thinking that we would be able to read the physical endpoints table > to get what we need, but now I'm thinking it may not fit our use case. > > The alternative would be to just store the bridge mappings as an > external_id on the Chassis record in the southbound database. How quickly > is this needed? > This is now ready. The Chassis table in OVN_Southbound now has 1) a hostname column 2) an external_ids column, including an ovn-bridge-mappings key. Between those two, I think the Neutron plugin has all of the info it needs. Let me know if you think of anything else that is missing. -- Russell Bryant __ 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] [docs] Our Install Guides Only Cover Defcore - What about big tent?
On Wed, Mar 23, 2016 at 11:06 AM, Mike Perez <thin...@gmail.com> wrote: > Hey all, > > I've been talking to a variety of projects about lack of install guides. > This > came from me not having a great experience with trying out projects in the > big > tent. > > Projects like Manila have proposed install docs [1], but they were rejected > by the install docs team because it's not in defcore. One of Manila's > goals of > getting these docs accepted is to apply for the operators tag > ops:docs:install-guide [2] so that it helps their maturity level in the > project > navigator [3]. > > Adrian Otto expressed to me having the same issue for Magnum. I think it's > funny that a project that gets keynote time at the OpenStack conference > can't > be in the install docs personally. > > As seen from the Manila review [1], the install docs team is suggesting > these > to be put in their developer guide. > > I don't think this is a great idea. Mainly because they are for developers, > operators aren't going to be looking in there for install information. > Also the > Developer doc page [4] even states "This page contains documentation for > Python > developers, who work on OpenStack itself". > > The install docs team doesn't want to be swamped with everyone in big tent > giving them their install docs, to be verified, and eventually likely to be > maintained by the install docs team. > > However, as an operator when I go docs.openstack.org under install guides, > I should know how to install any of the big tent projects. These are > accepted > projects by the Technical Committee. > > Lets consider the bigger picture of things here. If we don't make this > information accessible, projects have poor adoption and get less feedback > because people can't attempt to install them to begin reporting bugs. > > Proposal: if the install docs team doesn't want them in the install docs > repo > and instead to live in tree of the project itself before it's in defcore, > can > we at least make the install guides for all big tent projects accessible > at docs.openstack.org under install guides? > > > [1] - https://review.openstack.org/#/c/213756/ > [2] - > http://git.openstack.org/cgit/openstack/ops-tags-team/tree/descriptions/ops-docs-install-guide.rst > [3] - http://www.openstack.org/software/releases/liberty/components/manila > [4] - http://docs.openstack.org/developer/openstack-projects.html > FWIW, the same issue applies to other official docs. In particular, I'm thinking of the networking guide. http://docs.openstack.org/liberty/networking-guide/ The networking guide is *fantastic*, but it's limited to covering only ML2+OVS and ML2+LB. Coverage for other backends is currently considered out of scope, leaving no official place to put equivalent documentation except in dev docs. We got pushback on documenting OVN there, so we've been putting everything in our dev docs, instead. For example: http://docs.openstack.org/developer/networking-ovn/install.html http://docs.openstack.org/developer/networking-ovn/refarch.html It'd be nice to have somewhere else to publish these operator-oriented docs. -- Russell Bryant __ 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] [networking-ovn][ovn4nfv]
On Mon, Mar 21, 2016 at 5:18 PM, John McDowall < jmcdow...@paloaltonetworks.com> wrote: > All, > > As a VNF vendor we have been looking at ways to enable customers to simply > scale up (and down) VNF’s in complex virtual networks at scale. Our goal > is to help accelerate the deployment of SDN and VNF’s and more > specifically enable zero-trust security at scale for applications. This > requires the easy and fast deployment of Next Generation Firewalls (and > other VNF¹s) into the traffic path of any application. > Thanks a lot for your work on this! I see you posted the same message over on the OVS discuss mailing list. I think the current work is probably more relevant to that list, so I'm going to respond over there. -- Russell Bryant __ 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] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)
On Thu, Mar 17, 2016 at 1:45 AM, Hong Hui Xiao <xiaoh...@cn.ibm.com> wrote: > Hi Russell. > > Since the "ovn-bridge-mapping" will become accessible in OVN Southbound > DB, do you meant that neutron plugin can read those bridge mappings from > the OVN Southbound DB? I didn't think in that way because I thought > networking-ovn will only transact data with OVN Northbound DB. > You're right that networking-ovn currently only uses the OVN northbound DB. This requirement crosses the line into physical space and needing to know about some physical environment details, so reading from the southbound DB for this info is acceptable. > Also, do you have any link to describe the ongoing work in OVN to sync the > "ovn-bridge-mapping" from hypervisor? This patch introduces some new tables to the southbound DB: http://openvswitch.org/pipermail/dev/2016-March/068112.html I was thinking that we would be able to read the physical endpoints table to get what we need, but now I'm thinking it may not fit our use case. The alternative would be to just store the bridge mappings as an external_id on the Chassis record in the southbound database. How quickly is this needed? -- Russell Bryant __ 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] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)
On Tue, Mar 15, 2016 at 7:02 PM, Hong Hui Xiao <xiaoh...@cn.ibm.com> wrote: > Hi all. > > I did some investigation recently. And I think we can start some > discussion now. > > All below thinking is based on the current implementation of neutron. With > routed network, a subnet will be considered as a L2 domain. Things might > change. > > I think routed network in OVN can implement in this way: > User creates provider network. For example: > neutron net-create provider-101 --shared \ > --provider:physical_network providernet \ > --provider:network_type vlan \ > --provider:segmentation_id 101 > > These attributes "--provider:physical_network" will be recorded in the > external_ids of Logical_Switch in OVN_Northbound. > > > > To Russell: > I will expect OVN to do the following things. > 1) The OVN_Southbound will have the latest information of > "ovn-bridge-mappings" of each Chassis. > 2) After creating a new network with "provider:physical_network" set, the > OVN will update Logical_Switch in OVN_Northbound. > The Logical_Switch will have new key:value pair in external_ids. > neutron:available_hosts="compute-host1,compute-host2" > 3) When a compute host join/leave the OpenStack topology, or a compute > host just updates its ovn-bridge-mappings, OVN should updated > Logical_Switch with related physical_network. This is a bottom-up change, > which is similar to the port status change. > 4) networking-ovn should be able to catch the update of Logical_Switch in > 2) & 3) and update the SegmentHostMapping, which will be introduced in > [2]. > > I think 1) 2) & 3) need additional work in OVN code. And 4) need code > change in networking-ovn. > There's some work happening in OVN where the information currently in ovn-bridge-mappings on each hypervisor will become accessible in the OVN Southbound database. As a nice side effect, the Neutron plugin should be able to read those bridge mappings from the OVN database and have all of the information it needs. -- Russell Bryant __ 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] [Kuryr] Clarification of expanded mission statement
The Kuryr project proposed an update to its mission statement and I agreed to start a ML thread seeking clarification on the update. https://review.openstack.org/#/c/289993 The change expands the current networking focus to also include storage integration. I was interested to learn more about what work you expect to be doing. On the networking side, it's clear to me: a libnetwork plugin, and now perhaps a CNI plugin. What specific code do you expect to deliver as a part of your expanded scope? Will that code be in Kuryr, or be in upstream projects? If you don't know yet, that's fine. I was just curious what you had in mind. We don't really have OpenStack projects that are organizing around contributing to other upstreams, but I think this case is fine. -- Russell Bryant __ 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] [networking-ovn][devstack] devstack deoloyed with networking-ovn come accross error 'ovs-ofctl: br-int is not a bridge or a socket'
On Mon, Mar 14, 2016 at 4:36 AM, Wilence Yao <wilence@gmail.com> wrote: > Hello all, > > I am going to deploye devstakv with networking-ovn, and I am following > with the doc > http://docs.openstack.org/developer/networking-ovn/testing.html > > However, error occured in running stack.sh. > > Traceback below here: > > 2016-03-14 08:14:44.729 | cd datapath/linux && make modules_install > 2016-03-14 08:14:44.735 | make[1]: Entering directory > `/opt/stack/ovs/datapath/linux' > 2016-03-14 08:14:44.735 | make -C > /lib/modules/3.10.0-327.10.1.el7.x86_64/build > M=/opt/stack/ovs/datapath/linux modules_install > 2016-03-14 08:14:45.079 | make[2]: Entering directory > `/usr/src/kernels/3.10.0-327.10.1.el7.x86_64' > 2016-03-14 08:14:45.098 | INSTALL > /opt/stack/ovs/datapath/linux/openvswitch.ko > 2016-03-14 08:14:45.148 | Can't read private key > 2016-03-14 08:14:45.151 | INSTALL > /opt/stack/ovs/datapath/linux/vport-geneve.ko > 2016-03-14 08:14:45.183 | Can't read private key > 2016-03-14 08:14:45.186 | INSTALL > /opt/stack/ovs/datapath/linux/vport-gre.ko > 2016-03-14 08:14:45.218 | Can't read private key > 2016-03-14 08:14:45.220 | INSTALL > /opt/stack/ovs/datapath/linux/vport-lisp.ko > 2016-03-14 08:14:45.248 | Can't read private key > 2016-03-14 08:14:45.250 | INSTALL > /opt/stack/ovs/datapath/linux/vport-stt.ko > 2016-03-14 08:14:45.278 | Can't read private key > 2016-03-14 08:14:45.281 | INSTALL > /opt/stack/ovs/datapath/linux/vport-vxlan.ko > 2016-03-14 08:14:45.309 | Can't read private key > 2016-03-14 08:14:45.322 | DEPMOD 3.10.0-327.10.1.el7.x86_64 > 2016-03-14 08:14:45.668 | make[2]: Leaving directory > `/usr/src/kernels/3.10.0-327.10.1.el7.x86_64' > 2016-03-14 08:14:45.669 | depmod `sed -n 's/#define UTS_RELEASE > "\([^"]*\)"/\1/p' > /lib/modules/3.10.0-327.10.1.el7.x86_64/build/include/generated/utsrelease.h` > 2016-03-14 08:14:45.986 | make[1]: Leaving directory > `/opt/stack/ovs/datapath/linux' > 2016-03-14 08:14:46.007 | modprobe: FATAL: Module openvswitch is in use. > 2016-03-14 08:14:46.009 | Error on exit > 2016-03-14 08:14:46.487 | ovs-vsctl: > unix:/usr/local/var/run/openvswitch/db.sock: database connection failed (No > such file or directory) > 2016-03-14 08:14:46.498 | ovs-ofctl: br-int is not a bridge or a socket > 2016-03-14 08:14:46.508 | ovs-ofctl: br-tun is not a bridge or a socket > 2016-03-14 08:14:46.518 | ovs-ofctl: br-ex is not a bridge or a socket > 2016-03-14 08:14:46.529 | ovs-ofctl: br-int is not a bridge or a socket > 2016-03-14 08:14:46.540 | ovs-ofctl: br-tun is not a bridge or a socket > 2016-03-14 08:14:46.551 | ovs-ofctl: br-ex is not a bridge or a socket > > I know that in this process , stack.sh will install openvswitch when > processing neutron, then it will uninstall openvswitch and make && make > install openvswitch from ovs code source again. > Yes, I've wanted to figure out a way to prevent ovs from being installed by package, but haven't done it yet. We should probably file a bug on it against networking-ovn. > > Because of uninstalling of openvswitch, br-int and other brigeds loss from > ovs, so the new ovn process come accross the error that no bridges > br-int/br-ex/br-tun. > > Is this a networking-ovn bug or a devstack bug? > Please file a bug against networking-ovn for your error. The problem isn't clear, but we can track it there. I assume this is CentOS 7? I hvaen't tried with CentOS 7 in a long time, unfortunately. I use Fedora 23 regularly without issue. It also runs on Ubuntu 14.04 in OpenStack CI regularly. If it's not working on CentOS 7, we need to fix it. Ideally we should set up a CI job for it, as well. Some of your errors are a bit odd. I would not expect br-ex or br-tun to be created. Can you also share your devstack configuration? Was this system used for any other configuration before? If so, can you try a fresh environment? -- Russell Bryant __ 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] [tripleo] Logo for TripleO
On Fri, Mar 11, 2016 at 4:15 AM, Dmitry Tantsur <dtant...@redhat.com> wrote: > On 03/11/2016 06:32 AM, Jason Rist wrote: > >> Hey everyone - >> We've been working on a UI for TripleO for a few months now and >> we're >> just about to beg to be a part of upstream... and we're in need of a >> logo for the login page and header. >> >> In my evenings, I've come up with a logo. >> >> It's a take on the work that Dan has already done on the Owl idea: >> http://wixagrid.com/tripleo/tripleo_svg.html >> > > This is looking fantastic!! Big +1 to using it everywhere. > I love it. :-) > We also need to put somewhere both this Owl and ironic's Bear together :) > Don't forget Oslo's moose. https://github.com/openstack/oslo-incubator/tree/master/doc/source/_images -- Russell Bryant __ 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] [all] A proposal to separate the design summit
On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez <thie...@openstack.org> wrote: > Hi everyone, > > TL;DR: Let's split the events, starting after Barcelona. > This proposal sounds fantastic. Thank you very much to those that help put it together. -- Russell Bryant __ 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] Tacker VNFFG - SFC integration updates
On 02/16/2016 02:51 PM, Sridhar Ramaswamy wrote: > Hi folks, > > Based on the recent discussions in [1] & [2] we are proposing to > rearrange our tasks related to Tacker's VNFFG component integrating with > the lower level SFC APIs. We now plan to integrate with networking-sfc > APIs first. > > Our original plan, or rather the sequence of tasks, were, > > 1) Tacker VNFFG plugin (trozet) > 2) Tacker VNFFG plugin --> ODL/netvirtsfc driver backend (trozet) > 3) Tacker VNFFG plugin --> networking-sfc driver backend (s3wong) > 4) networking-sfc --> ODL/netvirtsfc driver backend (TBD) > > We now propose to alter the sequence of tasks to something like this, > > 1) Tacker VNFFG plugin (trozet) > 2) Tacker VNFFG plugin --> networking-sfc driver backend (s3wong) - > /that is, introduce this as the first driver backend for Tacker VNFFG > instead of direct ODL/netvirtsfc driver/ > 3) Use the code written by Tim (trozet) for Tacker's ODL/netvirtsfc > driver backend and help to further networking-sfc's ODL integration efforts. > > Quick note on (3) above, networking-sfc already has a driver for ONOS > SDN Controller [3]. So it should reasonably easy to bring in a ODL > driver for networking-sfc. This might be slightly longer than what we > ideally wanted for some short-term PoCs but it positions us to get the > eventual end goal faster. What other backends would you expect other than the networking-sfc backend? Is it none for now, but just leaving it open for an alternative Neutron API should one come up? -- Russell Bryant __ 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] Evolving the stadium concept
On 02/05/2016 10:36 AM, Neil Jerram wrote: > As some others have said, I see the current discussion as being about > the chain of accountability, from a stadium project, through Neutron, up > to the OpenStack TC and board. IIUC, Armando and other cores feel that > there is a gap there - because they can't reasonably understand and > vouch for all the stadium projects to the same standard they can for > core Neutron. Plus it seems (from the current > https://review.openstack.org/#/c/275888/9 text) that there is a desire > for strong core team overlap between openstack/neutron and all Neutron > stadium projects. > > As the lead of networking-calico, I think it's a reasonable call to say > that networking-calico (and similar projects) should therefore be > OpenStack big tent projects, rather than Neutron stadium, and hence the > reviews I've just left. Thanks, Neil. You've summarized this well. A more clear and accurate chain of accountability is indeed what we're trying to get to here. -- Russell Bryant __ 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] [all] [tc] "No Open Core" in 2016
On 02/05/2016 05:57 AM, Thierry Carrez wrote: > Hi everyone, > > Even before OpenStack had a name, our "Four Opens" principles were > created to define how we would operate as a community. The first open, > "Open Source", added the following precision: "We do not produce 'open > core' software". What does this mean in 2016 ? > > Back in 2010 when OpenStack was started, this was a key difference with > the other open source cloud platform (Eucalyptus) which was following an > Open Core strategy with a crippled community edition and an "enterprise > version". OpenStack was then the property of a single entity > (Rackspace), so giving strong signals that we would never follow such a > strategy was essential to form a real community. > > Fast-forward today, the open source project is driven by a non-profit > independent Foundation, which could not even do an "enterprise edition" > if it wanted to. However, member companies build "enterprise products" > on top of the Apache-licensed upstream project. And we have drivers that > expose functionality in proprietary components. So what does it mean to > "not do open core" in 2016 ? What is acceptable and what's not ? It is > time for us to refresh this. Nice summary. I agree that some clarification would be helpful given to match our current reality. > My personal take on that is that we can draw a line in the sand for what > is acceptable as an official project in the upstream OpenStack open > source effort. It should have a fully-functional, production-grade open > source implementation. If you need proprietary software or a commercial > entity to fully use the functionality of a project or getting serious > about it, then it should not be accepted in OpenStack as an official > project. It can still live as a non-official project and even be hosted > under OpenStack infrastructure, but it should not be part of > "OpenStack". That is how I would interpret "no open core" in OpenStack > 2016. > > Of course, the devil is in the details, especially around what I mean by > "fully-functional" and "production-grade". Is it just an API/stability > thing, or does performance/scalability come into account ? There will > always be some subjectivity there, but I think it's a good place to start. > > Comments ? > I agree with your take. I'm not too worried about coming up with a strict definition for what a reasonable open source backend is. We can throw in some desirable traits like you have done, and then leave it to the TC to evaluate. I think that's a reasonable part of the TC's job. -- Russell Bryant __ 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] Evolving the stadium concept
On 02/04/2016 05:36 PM, Assaf Muller wrote: > On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins <s...@coreitpro.com> wrote: >> On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote: >>> I understand you see 'Dragonflow being part of the Neutron stadium' >>> and 'Dragonflow having high visibility' as tied together. I'm curious, >>> from a practical perspective, how does being a part of the stadium >>> give Dragonflow visibility? If it were not a part of the stadium and >>> you had your own PTL etc, what specifically would change so that >>> Dragonflow would be less visible. >> >>> Currently I don't understand why >>> being a part of the stadium is good or bad for a networking project, >>> or why does it matter. >> >> >> I think the issue is of public perception. > > That's what I was trying to point out. But it must be something other > than perception, otherwise we could remove the inclusion list > altogether. A project would not be in or out. There has to be a list somewhere. That's how OpenStack governance works. We have project teams that work together to produce a set of deliverables, where each deliverable is made up of one or more git repositories. The ongoing issue is trying to find the right structure that matches how our teams are working and what they're willing to own. The current approach hasn't worked, so it's time for another iteration. -- Russell Bryant __ 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] Evolving the stadium concept
On 11/30/2015 07:56 PM, Armando M. wrote: > I would like to suggest that we evolve the structure of the Neutron > governance, so that most of the deliverables that are now part of the > Neutron stadium become standalone projects that are entirely > self-governed (they have their own core/release teams, etc). After thinking over the discussion in this thread for a while, I have started the following proposal to implement the stadium renovation that Armando originally proposed in this thread. https://review.openstack.org/#/c/275888 -- Russell Bryant __ 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] Testing Neutron with latest OVS
On 01/14/2016 08:04 PM, Jeremy Stanley wrote: > On 2016-01-14 22:14:09 + (+), Sean M. Collins wrote: > [...] >> The problem we have is - most operators are using Ubuntu according to >> the user survey. Most likely they are using LTS releases. We already get >> flack for our pace of releases and our release lifecycle duration, so >> if we were to move off LTS for our gate, we would be pushing operators >> to move to more frequent upgrades for their base operating system. Maybe >> that's a discussion that needs to be had, but it will be contentious. > > As a point of reference, the OpenStack Infrastructure team only uses > LTS distro releases to run production systems. We've also got a > modest sized OpenStack deployment on its way to production, again on > an LTS distro release. I agree that releasing server software which > is only well tested on "desktop" pace distro releases would be a > serious misstep for the project. > but are most people using that LTS release with cloud-archive enabled? -- Russell Bryant __ 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] Testing Neutron with latest OVS
On 01/13/2016 11:51 PM, Tony Breeds wrote: > The challenge for you guys is the kernel side of things but if I > understood correctly you can get the kenrel module from the ovs > source tree and just compile it against the stock ubuntu kernel > (assuming the kernel devel headers are available) is that right? It's kernel and userspace. There's multiple current development efforts that involve changes to OpenStack, OVS userspace, and the appropriate datapath (OVS kernel module or DPDK). The consensus I'm picking up roughly is that for those working on the features, testing with source builds seems to be working fine. It's just not something anyone wants to gate the main Neutron repo with. That seems quite reasonable. If the features aren't in proper releases yet, I don't see gating as that important anyway. -- Russell Bryant __ 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] Testing Neutron with latest OVS
On 01/14/2016 03:43 PM, Assaf Muller wrote: > On Thu, Jan 14, 2016 at 9:28 AM, Russell Bryant <rbry...@redhat.com> wrote: >> On 01/13/2016 11:51 PM, Tony Breeds wrote: >>> The challenge for you guys is the kernel side of things but if I >>> understood correctly you can get the kenrel module from the ovs >>> source tree and just compile it against the stock ubuntu kernel >>> (assuming the kernel devel headers are available) is that right? >> >> It's kernel and userspace. There's multiple current development >> efforts that involve changes to OpenStack, OVS userspace, and the >> appropriate datapath (OVS kernel module or DPDK). >> >> The consensus I'm picking up roughly is that for those working on the >> features, testing with source builds seems to be working fine. It's >> just not something anyone wants to gate the main Neutron repo with. >> That seems quite reasonable. If the features aren't in proper >> releases yet, I don't see gating as that important anyway. > > I want to have voting tests for new features. For the past year the > OVS agent ARP responder feature has been without proper coverage, and > now it's the upcoming OVS firewall driver. I think that as long as we > compile from a specific OVS patch (And not a moving target), I don't > see much of a difference between gating on OVS 2.0 and gating on, for > example, the current tip of the OVS 2.5 branch (But continuing to > gate on that patch, so when the OVS 2.5 branch gets backports we > won't gate on those, and we'll be able to move to a new tip in our > own pace). As long as we pick a patch to compile against and run the > functional tests a few times and verify that it works, I think it's > reasonable. We've been gating against OVS 2.0 for the past few years, > that to me seems unreasonable. We're gating against an OVS version > nobody is using in production anymore. I would agree that still using OVS 2.0 doesn't make any sense. -- Russell Bryant __ 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] Testing Neutron with latest OVS
On 01/14/2016 04:32 PM, Ben Pfaff wrote: > On Thu, Jan 14, 2016 at 09:30:03PM +, Sean M. Collins wrote: >> On Thu, Jan 14, 2016 at 03:13:16PM CST, Clark Boylan wrote: >>> Forgive my ignorance, but if we are gating on OVS 2.0 that is because it >>> is what is shipped with the distros that we test on. Are we saying that >>> no one uses the distro provided OVS packages to run Neutron? If not what >>> are they using? >> >> Right - this was my impression as well. > > Even Debian stable (jessie) has OVS 2.3, what distro has 2.0? Ubuntu 14.04 (latest LTS) -- Russell Bryant __ 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] Testing Neutron with latest OVS
On 01/13/2016 03:59 PM, Assaf Muller wrote: > On Wed, Jan 13, 2016 at 4:50 AM, Jakub Libosvar <jlibo...@redhat.com> wrote: >> Hi all, >> >> recently I was working on firewall driver [1] that requires latest >> features in OVS, specifically conntrack support. In order to get the >> driver tested, we need to have the latest OVS kernel modules on machines >> running tests but AFAIK there is no stable "2.5 like" release of OVS yet. >> >> Facing the same problem OVN did in the past, I decided to try to steal >> their solution and apply it in our Neutron repo [2]. Sean and Matthew >> rightfully expressed worries about this approach on review of [2]. >> >> So I'd like to bring this to a broader audience and ask for help or >> suggestion on how to test such Neutron features that require some newer >> versions. >> >> The first idea was to have an option to compile trunk ovs and use it in >> particular jobs like functional one. That would bring faster development >> of features going along with ovs features. > > I think we should use a newer OVS version that for the functional and > fullstack jobs at the very least. This will enable us to test the OVS > firewall driver you're working on, as well as the OVS ARP responder > (Which was merged a long time ago, but lacks proper testing because > it needs OVS 2.1+ and we gate using OVS 2.0). > > So, that's the problem. How we solve it is another manner - I was > under the impression that compiling it is our only option. Right now > OVN are compiling master, I think we should avoid that and compile a > specific git hash instead so the gate won't break every time OVS > breaks. Then, when OVS branch out 2.5, we can 'pin' on that. FWIW, a 2.5 branch already exists, but hasn't been released yet. It should only be receiving bug fixes at this point. https://github.com/openvswitch/ovs/tree/branch-2.5 We compile from master since OVN is under such active development in parallel, so that's really what we want. It also doesn't break anyone but networking-ovn if there's an ovs issue. I probably wouldn't do that for a more general voting neutron job. > At that point we could perhaps switch to a packaged OVS off some > sort of experimental repo. Note that just using OVS 2.5 isn't enough. You must also have kernel support for ovs+conntrack integration. That is in Linux 4.3+ or the openvswitch kernel module included in the ovs tree. networking-ovn's tempest job uses the openvswitch kernel module from ovs master, as well. That seems to be working on the devstack jenkins nodes just fine. -- Russell Bryant __ 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] [nova][neutron][os-vif] os-vif core review team membership
On 01/12/2016 10:15 AM, Daniel P. Berrange wrote: > So far myself & Jay Pipes have been working on the initial os-vif > prototype and setting up infrastructure for the project. Obviously > we need more then just 2 people on a core team, and after looking > at those who've expressed interest in os-vif, we came up with a > cross-section of contributors across the Nova, Neutron and NFV > spaces to be the initial core team: > > Jay Pipes > Daniel Berrange > Sean Mooney > Moshe Levi > Russell Bryant > Sahid Ferdjaoui > Maxime Leroy > > So unless anyone wishes to decline the offer, once infra actually add > me to the os-vif-core team I'll be making these people os-vif core, so > we can move forward with the work on the library... Thanks, I'm happy to help. -- Russell Bryant __ 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] [Devstack][OVN] ovs modprobe bug
On 12/16/2015 07:43 AM, Somanchi Trinath wrote: > Hi – > > > > When I try to install devstack+ovn, I get this error with OVS. > > > > make[2]: Leaving directory `/usr/src/linux-headers-3.13.0-32-generic' > > depmod `sed -n 's/#define UTS_RELEASE "\([^"]*\)"/\1/p' > /lib/modules/3.13.0-32-generic/build/include/generated/utsrelease.h` > > make[1]: Leaving directory `/opt/stack/ovs/datapath/linux' > > modprobe: FATAL: Module openvswitch is in use. The context here is that the ovn devstack plugin compiles and loads the openvswitch kernel module from the ovs source tree. It has to do this as OVN depends on openvswitch kernel features in upstream kernel version 4.3. Those features have been backported to the version of the module in the ovs tree which we can use on older kernels. This error occurs when the devstack plugin runs: sudo modprobe -r openvswitch Try: lsmod | grep openvswitch The far right column will list any other kernel modules that depend on the openvswitch module. Those have to be unloaded first. ovs-vswitchd shouldn't be running, as it should have been uninstalled earlier in devstack, but that's something to check for. If nothing else, if it's just a dev VM, try rebooting. -- Russell Bryant __ 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] Evolving the stadium concept
some piece of networking. networking-ale-omniswitch: networking-arista: networking-bgpvpn: networking-calico: networking-cisco: networking-fortinet: networking-hpe: networking-hyperv: networking-infoblox: networking-fujitsu: networking-lenovo: networking-midonet: networking-odl: networking-ofagent: networking-onos: networking-ovn: networking-plumgrid: networking-powervm: networking-vsphere: python-neutron-pd-driver: vmware-nsx: I haven't gone and looked at every one of these in detail, so maybe there's another category here. In any case, for those that fit this category, it seems most natural to consider these part of Neutron. They are completely useless without Neutron, and Neutron is useless without code from this category. My alternate, modified proposal would be to: a) Clarify the line of what should be included in Neutron and what shouldn't be. The categorization above is a straw man start. In that, categories 1 and 2 could be split, but 3 and 4 would stay. b) Break down what's actually causing pain and address it point by point. > As a result, there is quite an effort imposed on the PTL, the various > liaisons (release, infra, docs, testing, etc) and the core team to > help manage the existing relationships and to ensure that the picture > stays coherent over time. For example, you mention "release" here, though IIUC, Kyle is handling releases for all of these sub-projects, right? If so, Kyle, what do you think? What's causing pain and how can we improve? "infra" - I take it this is about the Neutron infra liaisons having to ack every infra patch for all of these repos. That does sound annoying. It'd be nice if the lead for each driver or whatever could act as the infra liaison for jobs that only affect that repo. > Sometimes the decision of being part of > this list is even presented before one can see any code, and that > defeats the whole point of the deliverable association. It makes sense to reject something if there's no code. That's in line with how the TC has been evaluating new projects. > I have experienced first hand that this has become a burden, How about delegating this to the neutron-drivers team? You already have a meeting with this group reviewing RFEs. You could spread the load some more by letting others take a look and make a recommendation. > and I fear that > the stadium might be an extra layer of governance/complexity that > could even interfere with the existing responsibilities of the TC and > of OpenStack infra. I'm not sure what this means. Can you elaborate? For the TC, do you mean that Neutron is making in/out decisions that the TC should make? That's probably true for certain categories (#1 above, especially, and maybe #2), but not for individual drivers, IMO at least. At the end of the day, it's mostly a governance technicality. I'm less concerned about what projects.yaml looks like and more concerned about what it implies about how our projects are operating. I think projects should take more ownership and responsibility for their associated drivers. No matter how limited the criteria and coordination is, it's better than none. Let's tackle the pain points instead of just blowing the whole thing up. -- Russell Bryant __ 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] Security Groups OVS conntrack support
On 11/23/2015 02:16 PM, Kevin Benton wrote: > Security groups already use connection tracking. It's just done via a > linux bridge right now because the versions of OVS shipped with most > distros have no native conntrack support. This post discusses it in the context of OVN, but gets down to showing what the flows look like. It also includes a link to a presentation about ovs+conntrack given at the OpenStack Summit in Vancouver. http://blog.russellbryant.net/2015/10/22/openstack-security-groups-using-ovn-acls/ The most recent talk on this topic was "The State of Stateful Services" at the OVS Conference last week: http://openvswitch.org/support/ovscon2015/16/1620-stringer.pdf https://www.youtube.com/watch?v=PV2rxxb6lwQ -- Russell Bryant __ 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] Deploying current networking-sfc
On 11/16/2015 01:42 PM, Sean M. Collins wrote: > On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote: >> This is a challenge. Personally, I haven't been able to get it all working >> yet. But we're in a dilemma because we want to get good reviews of the code >> before merging. Since the full functionality is quite a lot of code we >> wanted to chop it into more easily reviewable chunks. Unfortunately that >> makes it more difficult to pull it all in at once to test the whole thing >> prior to completing the review and merge. > > I would be concerned about that. I am sympathetic to the chicken and egg > problem of a new repo and new code, but I briefly looked at both of > those reviews and they both are quite large. 1K LOC is usually the upper > limit for a sane patch set. It may be worth trying to break into > smaller, more manageable pieces - even if the initial commits just > create some empty classes and stubbed methods, and then later start > introducing the actual method bodies in small pieces with good unit > tests for each one. Small pieces. Tiny steps. Another thing I've been thinking about is the difference between having a repo like networking-sfc where a sub-group is able to try out new things while also managing expectations with consumers of Neutron. How does someone know the difference between something a bit more experimental vs. when an API is established and can be considered stable and maintained with backwards copmatibility like any other OpenStack REST API? I think networking-sfc should be able to keep merging code, including the proposed API, but I think it should be clearly marked as experimental and subject to change. That's based on my experience so far studying this proposal, SFC more generally, and watching other efforts happening within Neutron that affect this. How can we manage these expectations more clearly? -- Russell Bryant __ 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] Regarding OVN project and integration with SFC
On 11/13/2015 07:30 PM, Cathy Zhang wrote: > Has the OVN code been released in Liberty? If not when is it planned for > release? No. OVN itself is still under heavy development within the OVS project. It's being developed in OVS master, but is not yet in any released version of OVS. You can try it out with Liberty, but there are some catches since it's sitll so new. You have to install OVS and OVN from OVS git master. You also need kernel support for OVS+conntract integration. That integration is in Linux 4.3, but there is also a backport of that integration that be compiled and loaded into older kernels. The networking-ovn devstack plugin does all of this automatically. The other major catch with using this with Liberty is that it still used Neutron's L3 agent, which is only temporary. L3 support is moving fast in OVN itself, but native NAT support in OVS is still a work in progress, but we should have something in the coming weeks. That's a long answer to say that it's available for dev and early testing now, but I think Mitaka is a more reasonable OpenStack release to expect a more complete release with all of OVN's native features integrated into OpenStack. > Will it replace existing OVS Driver and OVS Agent or it will provide an > alternative path of programming the OVS? The future there is not clear. There's certainly no official plan from the Neutron project perspective. OVN is an alternative to the existing OVS integration. It won't use the ovs agent, l3 agent, or DHCP agent. (The L3 and DHCP parts are partially there, but not complete today, though). I can say that from the OVN project's perspective, it's certainly our hope that we implement OVN well enough that Neutron (or other similar projects) *want* to use it over integrating with OVS directly. I don't think it will be much longer before we complete support for what I'd consider core features for the majority of use cases. However, the existing OVS integration does a lot. I'm not sure when we'll reach full feature parity, or if that even makes sense. There may be some features or deployment models that we don't feel are worth supporting in OVN. This is just going to be an ongoing conversation that evolves over time. > It is on the networking-sfc project roadmap to > support OVN integration with SFC. Great. To do that, we have to add SFC to OVN itself. That's what I've started looking at. I did an early prototype and have been talking to people, including networking-sfc devs :-), to get a better idea of what's required. I'm hoping we can have something in OVN during this development cycle. > We would like to work with you on adding an OVN driver and Agent to > integrate with the networking-sfc API. I don't expect there to be any agent. All of that will be taken care of by OVN. > How would you like to proceed with this integration work? As I mentioned above, the current work is getting SFC in OVN first. The design and implementation discussions for that will take place on the OVS dev mailing list. I'll try to post a pointer back to openstack-dev once there's some kind of design to review there. I'm not sure on the timeline right now, as I have my hands in several things at once. -- Russell Bryant __ 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] [networking-ovn] ovn-northd is a spof
On 11/10/2015 07:06 PM, gong_ys2004 wrote: > Regard this, I read some architecture doc of it, SPOF in OVN way exists > in two place: > 1. ovn-northd, I don't know if we can run multiple ones, but the arch > doc demos only one The idea is that we will make it so you can run multiple. We haven't done it yet, though. In the meantime, the expectation is that you can easily run it in active/passive HA mode. That will impact scale, though. A single ovn-northd is obviously not the longer term goal. > 2. north db and south db, currently it is a OVSDB respectively, I don't > think the distributed db layer can be easily and quickly solved. Someone is actually already looking at distributing ovsdb-server. If that doesn't work out, the project has been pretty clear from the beginning that the use of ovsdb-server was for convenience and if it doesn't work, we'll switch. I've been planning to write a FAQ in the networking-ovn documentation. Some comments about our plans around HA are part of it. I'll try to get that written this week. > curiously, why we adopt two dbs design at the beginning. why does not > the ovn neutron plugin interact with south db? We could write directly to the southbound db and cut ovn-northd and the northbound db off, but we'd have to implement all of the logic from ovn-northd in Neutron in that case. The northbound db is a much simpler model. -- Russell Bryant __ 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] Reminder: Team meeting on Monday at 2100 UTC
Where do you find this? I've been using Iceland, but this sounds more explicit. For me it makes me pick a country and then a TZ, so I'm not seeing the "GMT (no daylight saving)" option anywhere. -- Russell On 11/09/2015 02:39 PM, Ihar Hrachyshka wrote: > There is also 'GMT (no daylight saving)’ TZ available in Google Calendar > that is identical to UTC for all practical matters. > > Ihar > > Carl Baldwinwrote: > >> I've been using Iceland's TZ for this. Seems to work well and handle >> the TZ changes nicely. >> >> Carl >> >> On Sat, Nov 7, 2015 at 7:24 AM, Sean M. Collins >> wrote: >>> Learn from my mistake, check your calendar for the timezone if you've >>> created an event for the weekly meetings. Google makes it a hassle to >>> set things in UTC time, so I was caught by surprise by the FwaaS meeting >>> due to the DST change in the US of A. >>> >>> -- >>> Sean M. Collins >>> >>> __ >>> >>> 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 __ 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] API clarification questions
- Original Message - > Hi Russell, > > Please see my replies inline. > > Thanks, > Cathy > > -Original Message- > From: Russell Bryant [mailto:rbry...@redhat.com] > Sent: Wednesday, October 28, 2015 4:21 PM > To: OpenStack Development Mailing List; Cathy Zhang; Henry Fourie > Subject: [neutron][networking-sfc] API clarification questions > > I read through the proposed SFC API here: > > http://docs.openstack.org/developer/networking-sfc/api.html > > I'm looking at implementing what would be required to support this API in > OVN. I have a prototype, but I had to make some pretty big assumptions, so > I wanted to clarify the intent of the API. > > First, does it assume that all of the neutron ports in a chain are on the > same Neutron network? That keeps things simple. If its intended to allow a > chain of ports on different networks, is it just required that you pick > ports that all have addresses routable from one port to the next in the > chain? > > Cathy> It can allow a chain of ports on different networks as along it > belongs to the same tenant. Yes, it is required that you pick ports that all > have addresses routable from one port to the next in the chain. Thanks. I think it would be good to clarify this in the API doc, so it's clear what makes a valid set of ports in a chain. > An arbitrary set of ports can't always work, so there has to be some bounds > around what set of ports are valid to be in a chain. > > Second, where is it expected that the match is applied? The API for creating > a port chain doesn't associate the chain with a network, but just matching > "globally" doesn't make any sense. If all ports are expected to be on the > same network, is the match applied for any traffic entering that network > from any port? > > Cathy> As long as the ports are routable, they do not need to associated with > the same network. Let me rephrase the question ... where is the flow classifier applied? What traffic exactly? "All traffic on all networks accessible to the tenant who created the port chain" doesn't seem right to me, but the API doesn't seem to specify it. -- Russell __ 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] [neutron][networking-sfc] API clarification questions
I read through the proposed SFC API here: http://docs.openstack.org/developer/networking-sfc/api.html I'm looking at implementing what would be required to support this API in OVN. I have a prototype, but I had to make some pretty big assumptions, so I wanted to clarify the intent of the API. First, does it assume that all of the neutron ports in a chain are on the same Neutron network? That keeps things simple. If its intended to allow a chain of ports on different networks, is it just required that you pick ports that all have addresses routable from one port to the next in the chain? An arbitrary set of ports can't always work, so there has to be some bounds around what set of ports are valid to be in a chain. Second, where is it expected that the match is applied? The API for creating a port chain doesn't associate the chain with a network, but just matching "globally" doesn't make any sense. If all ports are expected to be on the same network, is the match applied for any traffic entering that network from any port? I'm in Tokyo this week, so if the group working on this would like to talk in person, that would be great too. -- Russell Bryant __ 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] API clarification questions
On 10/28/2015 05:14 PM, Giuseppe (Pino) de Candia wrote: > On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbry...@redhat.com > <mailto:rbry...@redhat.com>> wrote: > > I read through the proposed SFC API here: > > http://docs.openstack.org/developer/networking-sfc/api.html > > I'm looking at implementing what would be required to support this API > in OVN. I have a prototype, but I had to make some pretty big > assumptions, so I wanted to clarify the intent of the API. > > First, does it assume that all of the neutron ports in a chain are on > the same Neutron network? That keeps things simple. If its intended to > allow a chain of ports on different networks, is it just required that > you pick ports that all have addresses routable from one port to the > next in the chain? An arbitrary set of ports can't always work, so > there has to be some bounds around what set of ports are valid to be in > a chain. > > > Hi Russell, > > We have similarly been experimenting with a MidoNet implementation of > the SFC API. Great! It's nice to have multiple people looking at this with different implementations in mind. That should help us shake out these sorts of issues before the API is too locked down. Thanks for jumping in. :-) > I hope there's no restriction on the location of the Neutron ports in a > chain. Yes, that makes sense. Cathy's response seems to support that there isn't a limitation. We do need to clearly define it in the API reference though. Maybe something like ... All ports must: * be owned by the tenant. * have IP addresses such that the address of port N+1 in the chain is routable from port N in the chain. > In terms of addresses, I believe the API is lacking (or we use a > chain_parameter?) a way to indicate the service insertion model: > - L2 - The service can accept packets sent from any MAC (service NIC in > promiscuous mode). The MAC address may be used to identify where the > packet came from before it entered the chain. If the ports in the chain don't have to all be on the same L2 network, then it doesn't seem like you could use the source MAC address to know where the packet came from before it entered the chain. > - L3 - The service expects packets to be routed to it. So the > destination MAC of the packet must be set to the service's NIC's MAC. This seems to make more sense to me. You've got the "coorelation chain parameter" to know what chain the packet is in, and you use the source IP address to know where the packet came from originally before it entered the chain. > > > > Second, where is it expected that the match is applied? The API for > creating a port chain doesn't associate the chain with a network, but > just matching "globally" doesn't make any sense. If all ports are > expected to be on the same network, is the match applied for any traffic > entering that network from any port? > > > Here's what we were thinking for MidoNet: > > use the logical_source_port in the flow classifier: when we render the > SFC API in MidoNet's models we will associate the chain with the source > port. > > Our packet pipeline (for packets egressing the VM) is: > > 1. Port Mirroring > 2. Service Chaining > 3. Filtering (Port Security, anti-spoofing, Security Groups) OK, so it sounds like you're applying the "flow classifier" to packets as the come from a neutron port and enter a neutron network. That makes sense. Which ports' traffic do you apply the flow classifier to? That's the key piece I'm missing. If the flow classifier includes a logical-source-port match, then it's easy. You only check traffic from a specific Neutron port. The same seems to apply if you only specified a logical-destination port, since in that case you'd be matching on traffic ingressing the VM. If tenant A creates the port chain and both logical-source-port and logical-destination-port are not specified, then what packets do you apply the flow classifier to? > > > Do you think we can standardise on a single order in all > implementations? We'd be happy to change the order if it makes sense. I think we do need to standardize where we can, yes. We want the resulting network behavior from the end user perspective to be as close as possible to the same thing regardless of backend. > I'm in Tokyo this week, so if the group working on this would like to > talk in person, that would be great too. > > > I'd love to be included. OK, it's probably best that we try to keep it on the mailing list as much as possible. I really don't want to exclude anyone, and it's important that this stuff is written down anyway. There is an "NF
Re: [openstack-dev] [all] Recording little everyday OpenStack successes
On 10/09/2015 05:42 AM, Thierry Carrez wrote: > Hello everyone, > > OpenStack has become quite big, and it's easier than ever to feel lost, > to feel like nothing is really happening. It's more difficult than ever > to feel part of a single community, and to celebrate little successes > and progress. > > In a (small) effort to help with that, I suggested making it easier to > record little moments of joy and small success bits. Those are usually > not worth the effort of a blog post or a new mailing-list thread, but > they show that our community makes progress *every day*. > > So whenever you feel like you made progress, or had a little success in > your OpenStack adventures, or have some joyful moment to share, just > throw the following message on your local IRC channel: > > #success [Your message here] > > The openstackstatus bot will take that and record it on this wiki page: > > https://wiki.openstack.org/wiki/Successes > > We'll add a few of those every week to the weekly newsletter (as part of > the developer digest that we reecently added there). > > Caveats: Obviously that only works on channels where openstackstatus is > present (the official OpenStack IRC channels), and we may remove entries > that are off-topic or spam. > > So... please use #success liberally and record lttle everyday OpenStack > successes. Share the joy and make the OpenStack community a happy place. > This is *really* cool. I'm excited to use this and see all the things others record. Thanks!! -- Russell Bryant __ 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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 10/05/2015 04:28 PM, Murali R wrote: > Yes. So we can define multiple logical switches per network and ovn > keeps vlan maps that ovs agent used to maintain and do the tunneling. My > confusion was from lport-add command that did not have host info, so if > there is no neutron, the cms has to maintain the host to lport > association and we can't query from NB-DB. Makes sense. The host to lport mappings are maintained by ovn-controller in the Port Binding table of the OVN Southbound database. -- Russell Bryant __ 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] - deprecation of max_fixed_ips_per_port
On 10/02/2015 07:25 PM, Kevin Benton wrote: > Hi, > > There is an option in Neutron called max_fixed_ips_per_port that limits > the number of IP addresses that can be assigned to each port. It doesn't > appear to have a clear use case since we prevent users from setting IPs > on ports attached to networks they don't own (shared networks). I have > filed a bug[1] to deprecate it for removal in N. > > If you have a use case for max_fixed_ips_per_port that I am missing, > please provide feedback on the bug report. > > > 1. https://bugs.launchpad.net/neutron/+bug/1502356 +1 Another problem I see with this is that it doesn't seem to be discoverable by a user. I think resource limits should be discoverable in the API (like quotas are). -- Russell Bryant __ 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][ovn] New cycle started. What are you up to, folks?
On 10/01/2015 03:26 PM, Russell Bryant wrote: > On 10/01/2015 09:45 AM, Ihar Hrachyshka wrote: >> Hi all, >> >> I talked recently with several contributors about what each of us >> plans for the next cycle, and found it’s quite useful to share >> thoughts with others, because you have immediate yay/nay feedback, >> and maybe find companions for next adventures, and what not. So >> I’ve decided to ask everyone what you see the team and you >> personally doing the next cycle, for fun or profit. >> >> That’s like a PTL nomination letter, but open to everyone! :) No >> commitments, no deadlines, just list random ideas you have in mind >> or in your todo lists, and we’ll all appreciate the huge pile of >> awesomeness no one will ever have time to implement even if >> scheduled for Xixao release. >> >> To start the fun, I will share my silly ideas in the next email. > > Nice thread! > > Here's a rough cut of what I have in mind. My Neutron related > development time covers a few areas: Neutron, OVN itself, and the > networking-ovn plugin for Neutron. > > For Neutron: > > - general code reviews. I'm especially interested in reviewing the >design and implementation of any new APIs people are adding. Feel >free to add me to reviews you think I could help with and I'll take >a look. > > - plugin infrastructure. Ihar mentioned in one of his items that >there are features implemented as ML2 specific. That has started >to be a pain for networking-ovn. For example, the provider networks >extension is only implemented for ML2, and the data is only stored >in an ML2 specific db table. The db table and related code should >be reusable by other plugins. I'd like to help start to clean that >up for the sake of other plugins. > > For OVN and networking-ovn: > > First, for anyone not already familiar with OVN, it is an effort > within the Open vSwitch project to build a virtual networking control > plane for OVS. There are several projects that have implemented > something in this space (including Neutron). OVN is intended to be a > new, common implementation of this functionality that can be reused in > many contexts, including by Neutron. It includes a focus on > implementation of features taking advantage of the newest features of > OVS, including some still being added as we go. There was a > presentation about this in Vancouver [1] and we'll be doing another > one covering current status in Tokyo [2]. > > This plugin is developed in parallel with OVN itself. My time on each > changes week to week, depending on what I'm working on. The dev items > I expect in the near future (this release cycle at least) include: > > - security groups. This is being implemented using conntrack suport >in OVS. There's actually WIP code for this including kernel >changes, ovs userspace changes, OVN, and networking-ovn. This is a >complex stack of dependencies, but it's starting to fall into place. >Most of the kernel changes have been accepted, thought there's >another change being reviewed now. The OVS userspace changes have >been under review in the last few weeks and are close to being >merged. Once that's done, we can finish up testing the OVN and >networking-ovn patches. We expect this to be done by Tokyo. > > - provider networks. There's a lot of demand in OpenStack for >supporting direct connectivity to existing networks as a simpler >deployment model without any overlays. I've done most of the work >for both OVN and networking-ovn for this now and expect to have it >wrapped up in the next week or so. > > - L3. So far we've been using Neutron's L3 agent with networking-ovn. >OVN will have native L3 support (will no longer use the L3 agent) >and development on that has now started. We aim to at least have >initial distributed L3 support by Tokyo. Some of it will certainly >extend past that, though. For example, NAT will be implemented with >an OVS native solution, and that will likely not be ready by Tokyo. >We may be able to deliver an intermediary NAT solution quicker. > > - SFC. There's a ton of interest in SFC. I've been casually following >the networking-sfc project and the Neutron API they are proposing. >I've also been thinking about how to implement it in OVN. I think >OVN's logical flows abstraction is going to make it surprisingly easy >to implement. I think I have a good idea of what needs to be done, >but I'm not sure of when it will bubble up on my todo list. I hope >to work on it for this dev cycle though. I'd first be imp
Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 09/27/2015 04:18 PM, Russell Bryant wrote: > On 09/27/2015 06:50 AM, Kevin Benton wrote: >> Assuming it implements the normal provider networks API, you just >> specify the segmentation_id when you create the network. >> >> neutron net-create NET_NAME --provider:network_type vlan >> --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG > > Yes, the OVN plugin will implement the normal provider networks API. > It's a WIP. > > My first goal was to just implement support for "--provider:network_type > flat" end to end. I have the OVN side merged and now I'm working on the > Neutron plugin piece. Once that's done, I'll go back add add VLAN > support, which shouldn't be very difficult at that point. I'm aiming to > have all of that done by the Tokyo summit (among other things). Just as a brief follow-up here, I finished the VLAN provider network support for OVN here: https://github.com/openvswitch/ovs/commit/779e72cc57a106251cc9e6696e8c9aabb56d30b5 I also wrote an OVN tutorial this week. Examples 4 and 5 cover how provider networks are modeled in OVN. https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md I have the Neutron API patch posted here: https://review.openstack.org/#/c/228573/ I did the patch before I finished the VLAN support. Adding the VLAN bit will be a trivial update, though. -- Russell Bryant __ 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][ovn] New cycle started. What are you up to, folks?
On 10/02/2015 11:32 AM, Russell Bryant wrote: > On 10/01/2015 03:26 PM, Russell Bryant wrote: >> On 10/01/2015 09:45 AM, Ihar Hrachyshka wrote: >>> Hi all, >>> >>> I talked recently with several contributors about what each of us >>> plans for the next cycle, and found it’s quite useful to share >>> thoughts with others, because you have immediate yay/nay feedback, >>> and maybe find companions for next adventures, and what not. So >>> I’ve decided to ask everyone what you see the team and you >>> personally doing the next cycle, for fun or profit. >>> >>> That’s like a PTL nomination letter, but open to everyone! :) No >>> commitments, no deadlines, just list random ideas you have in mind >>> or in your todo lists, and we’ll all appreciate the huge pile of >>> awesomeness no one will ever have time to implement even if >>> scheduled for Xixao release. >>> >>> To start the fun, I will share my silly ideas in the next email. >> >> Nice thread! >> >> Here's a rough cut of what I have in mind. My Neutron related >> development time covers a few areas: Neutron, OVN itself, and the >> networking-ovn plugin for Neutron. >> >> For Neutron: >> >> - general code reviews. I'm especially interested in reviewing the >>design and implementation of any new APIs people are adding. Feel >>free to add me to reviews you think I could help with and I'll take >>a look. >> >> - plugin infrastructure. Ihar mentioned in one of his items that >>there are features implemented as ML2 specific. That has started >>to be a pain for networking-ovn. For example, the provider networks >>extension is only implemented for ML2, and the data is only stored >>in an ML2 specific db table. The db table and related code should >>be reusable by other plugins. I'd like to help start to clean that >>up for the sake of other plugins. >> >> For OVN and networking-ovn: >> >> First, for anyone not already familiar with OVN, it is an effort >> within the Open vSwitch project to build a virtual networking control >> plane for OVS. There are several projects that have implemented >> something in this space (including Neutron). OVN is intended to be a >> new, common implementation of this functionality that can be reused in >> many contexts, including by Neutron. It includes a focus on >> implementation of features taking advantage of the newest features of >> OVS, including some still being added as we go. There was a >> presentation about this in Vancouver [1] and we'll be doing another >> one covering current status in Tokyo [2]. >> >> This plugin is developed in parallel with OVN itself. My time on each >> changes week to week, depending on what I'm working on. The dev items >> I expect in the near future (this release cycle at least) include: >> >> - security groups. This is being implemented using conntrack suport >>in OVS. There's actually WIP code for this including kernel >>changes, ovs userspace changes, OVN, and networking-ovn. This is a >>complex stack of dependencies, but it's starting to fall into place. >>Most of the kernel changes have been accepted, thought there's >>another change being reviewed now. The OVS userspace changes have >>been under review in the last few weeks and are close to being >>merged. Once that's done, we can finish up testing the OVN and >>networking-ovn patches. We expect this to be done by Tokyo. >> >> - provider networks. There's a lot of demand in OpenStack for >>supporting direct connectivity to existing networks as a simpler >>deployment model without any overlays. I've done most of the work >>for both OVN and networking-ovn for this now and expect to have it >>wrapped up in the next week or so. >> >> - L3. So far we've been using Neutron's L3 agent with networking-ovn. >>OVN will have native L3 support (will no longer use the L3 agent) >>and development on that has now started. We aim to at least have >>initial distributed L3 support by Tokyo. Some of it will certainly >>extend past that, though. For example, NAT will be implemented with >>an OVS native solution, and that will likely not be ready by Tokyo. >>We may be able to deliver an intermediary NAT solution quicker. >> >> - SFC. There's a ton of interest in SFC. I've been casually following >>the networking-sfc project and the Neutron API they are proposing. >>
Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 10/02/2015 02:26 PM, Murali R wrote: > Hi Russell, > > Thank you these are really good. Had a quick question. When you create a > logical switch in your first script (line 23) - at what point is it > associated with br-int ? Is it on line 45? So I can create any switch > and when I associated logical port it associates logical switch ? Or is > there a different way we can associate logical-phy switches? I was > looking to get the logical associations during startup initialization. To clarify, I believe you're talking about the first script from the tutorial [1], which is: https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/setup.sh Most of that script is all configuring logical topology. OVN does nothing to the network until ovn-controller sees a port appear on br-int that maps to a logical port. This mapping is done by setting the "iface-id" to the name of the logical port. Once ovn-controller has mapped a port on br-int to a logical port, it can configure the switch appropriately for that port. Does that make sense? [1] https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md -- Russell Bryant __ 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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 09/30/2015 06:01 PM, Murali R wrote: > Yes, sfc without nsh is what I am looking into and I am thinking ovn can > have a better approach. > > I did an implementation of sfc around nsh that used ovs & flows from > custom ovs-agent back in mar-may. I added fields in ovs agent to send > additional info for actions as well. Neutron side was quite trivial. But > the solution required an implementation of ovs to listen on a different > port to handle nsh header so doubled the number of tunnels. The ovs code > we used/modified to was either from the link you sent or some other > similar impl from Cisco folks (I don't recall) that had actions and > conditional commands for the field. If we have generic ovs code to > compare or set actions on any configured address field was my thought. > But haven't thought through much on how to do that. In any case, with > ovn we cannot define custom flows directly on ovs, so that approach is > dated now. But hoping some similar feature can be added to ovn which can > transpose some header field to geneve options. Thanks for the detail of what you're trying to do. I'm not sure how much you've looked into how OVN works. OVN works by defining the network in terms of "logical flows". These logical flows look similar to OpenFlow, but it talks about network resources in the logical sense (not based on where they are physically located). I think we can implement SFC purely in the logical space. So, most of the work I think is in defining the northbound db schema and then converting that into the right logical flows. I looked at the API being proposed by the networking-sfc project, and that's giving me a pretty good idea of what the northbound schema could look like for OVN. https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/api.rst The networking-sfc API talks about a "chain parameter". That's where NSH could come in. The spec proposes "mpls" as something OVS can already support. Given a single VIF, we need a way to differentiate traffic associated with different chains. This is *VERY* similar to what OVN is already doing with parent/child ports, originally intended for the containers-in-VM use case. This same concept seems to fit here quite well. Today, we only support VLAN IDs for this, but we could extend it to support mpls, NSH, or whatever. Anyway, those are just my high level thoughts so far. I haven't tried to really dig into a detailed design yet. > I am trying something right now with ovn and will be attending ovs > conference in nov. I am skipping openstack summit to attend something > else in far-east during that time. But lets keep the discussion going > and collaborate if you work on sfc. I look forward to meeting you in November! :-) -- Russell Bryant __ 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][ovn] New cycle started. What are you up to, folks?
xpand it as necessary, and get an OVN backend for that API. - containers. OVN has had a focus on supporting container networking from the start. One way is that OVN can be used directly to build overlay networks independent of whatever infrastructure the container app is running on. This is conceptually similar to other things like Flannel. A major downside of overlay based container networking is the performance hit you get when you end up with an "overlays on overlays", where you can't take advantage of NIC offload support for overlay encapsulation. To address the performance issue, OVN includes abstractions to provide networking for a hybrid environment of bare metal, VMs, and containers. In the OpenStack case, containers running on bare metal or containers running inside of OpenStack VMs should all be able to talk to the Neutron API of the underlying OpenStack to provide the desired network topology. networking-ovn supports this already, but with a networking-ovn specific binding-profile: http://docs.openstack.org/developer/networking-ovn/containers.html I'd like to help ensure that the "VLAN aware VMs" spec gets reviewed and merged this cycle, as that API provides the proper Neutron abstraction for what's needed here. Once *that* is done, I'd really like to see some native Kubernetes integration to be able to talk to the Neutron API and set up the networking needed for container apps running in OpenStack VMs, but it seems unlikely that I'll get to that this cycle myself. - testing. We have a tempest job for networking-ovn that's passing. It skips a few tests for things we haven't finished implementing [3]. I'd like to get down to where we're not skipping anything. Since it's passing, I'd like to get to where we can run the job against Neutron patches, as well. I'd propose it as a non-voting job, but it would be running in OpenStack's infrastructure. Running against Neutron would get the job running much more frequently to help us shake out bugs and would also help us catch issues between Neutron and networking-ovn quicker. Finally, I'd also like to build a multi-node test job. - native DHCP support. Right now networking-ovn uses the existing Neutron DHCP agent. We plan to add native distributed DHCP support to OVN. Once someone gets around to it, the DHCP agent will no longer be used. I'm sure I've forgotten something, but this seems like a pretty good overview of what I expect to see this cycle. I'd love to hear any comments or questions you may have. We're also interested in any new contributors! Feel free to reach out to me for help getting started. [1] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/ovn-native-virtual-networking-for-open-vswitch [2] https://openstacksummitoctober2015tokyo.sched.org/event/89a27d6b5bab975a7a4f49ec57ee5210#.Vg2DmXUVhBc [3] http://git.openstack.org/cgit/openstack/networking-ovn/tree/devstack/devstackgaterc -- Russell Bryant __ 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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 09/30/2015 03:29 PM, Murali R wrote: > Russell, > > Are any additional options fields used in geneve between hypervisors at > this time? If so, how do they translate to vxlan when it hits gw? For > instance, I am interested to see if we can translate a custom header > info in vxlan to geneve headers and vice-versa. Yes, geneve options are used. Specifically, there are three pieces of metadata sent: a logical datapath ID (the logical switch, or network), the source logical port, and the destination logical port. Geneve is only used between hypervisors. VxLAN is only used between hypervisors and a VTEP gateway. In that case, the additional metadata is not included. There's just a tunnel ID in that case, used to identify the source/destination logical switch on the VTEP gateway. > And if there are flow > commands available to add conditional flows at this time or if it is > possible to extend if need be. I'm not quite sure I understand this part. Could you expand on what you have in mind? -- Russell Bryant __ 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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 09/30/2015 04:09 PM, Murali R wrote: > Russel, > > For instance if I have a nsh header embedded in vxlan in the incoming > packet, I was wondering if I can transfer that to geneve options > somehow. This is just as an example. I may have header other info either > in vxlan or ip that needs to enter the ovn network and if we have > generic ovs commands to handle that, it will be useful. If commands > don't exist but extensible then I can do that as well. Well, OVS itself doesn't support NSH yet. There are patches on the OVS dev mailing list for it, though. http://openvswitch.org/pipermail/dev/2015-September/060678.html Are you interested in SFC? I have been thinking about that and don't think it will be too hard to add support for it in OVN. I'm not sure when I'll work on it, but it's high on my personal todo list. If you want to do it with NSH, that will require OVS support first, of course. If you're interested in more generic extensibility of OVN, there's at least going to be one talk about that at the OVS conference in November. If you aren't there, it will be on video. I'm not sure what ideas they will be proposing. Since we're on the OpenStack list, I assume we're talking in the OpenStack context. For any feature we're talking about, we also have to talk about how that is exposed through the Neutron API. So, "generic extensibility" doesn't immediately make sense for the Neutron case. SFC certainly makes sense. There's a Neutron project for adding an SFC API and from what I've seen so far, I think we'll be able to extend OVN such that it can back that API. -- Russell Bryant __ 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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 09/27/2015 06:50 AM, Kevin Benton wrote: > Assuming it implements the normal provider networks API, you just > specify the segmentation_id when you create the network. > > neutron net-create NET_NAME --provider:network_type vlan > --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG Yes, the OVN plugin will implement the normal provider networks API. It's a WIP. My first goal was to just implement support for "--provider:network_type flat" end to end. I have the OVN side merged and now I'm working on the Neutron plugin piece. Once that's done, I'll go back add add VLAN support, which shouldn't be very difficult at that point. I'm aiming to have all of that done by the Tokyo summit (among other things). > On Sun, Sep 27, 2015 at 9:50 AM, WANG, Ming Hao (Tony T) > <tony.a.w...@alcatel-lucent.com <mailto:tony.a.w...@alcatel-lucent.com>> > wrote: > > Russell, > > Another question is about "localnet". It is a very useful feature. :-) > > Is it possible to assign which VLAN tag will be used for a specific > provider network? > In your example in > > https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905 > : "physnet1" is used as physical network, and br-eth1 is used as the > provider network OpenFlow switch. > If we can assign the VLAN tag of the provider network, is the VLAN > tag translation done by "br-int" or "br-eth1"? -- Russell Bryant __ 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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 09/27/2015 02:26 AM, WANG, Ming Hao (Tony T) wrote: > Russell, > > Thanks for your valuable information. > I understood Geneve is some kind of tunnel format for network virtualization > encapsulation, just like VxLAN. > But I'm still confused by the connection between Geneve and VTEP. > I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which should > be used for VxLAN only. > > Does it become some "common tunnel endpoint" in OVN, and can be also used as > a tunnel endpoint for Geneve? When using VTEP gateways, both the Geneve and VxLAN protocols are being used. Packets between hypervisors are sent using Geneve. Packets between a hypervisor and the gateway are sent using VxLAN. -- Russell Bryant __ 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] [all] -1 due to line length violation in commit messages
On 09/25/2015 12:15 PM, Fox, Kevin M wrote: > Another option... why are we wasting time on something that a > computer can handle? Why not just let the line length be infinite in > the commit message and have gerrit wrap it to here> length lines on merge? I don't think gerrit should mess with the commit message at all. Commit message formatting is often very intentional. -- Russell Bryant __ 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-ovn][vtep] Proposal: support for vtep-gateway in ovn
On 09/24/2015 01:17 AM, Amitabha Biswas wrote: > Hi everyone, > > I want to open up the discussion regarding how to support OVN > VTEP gateway deployment and its lifecycle in Neutron. Thanks a lot for looking into this! > In the "Life Cycle of a VTEP gateway" part in the OVN architecture > document (http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf), > step 3 is where the Neutron OVN plugin is involved. At a minimum, the > Neutron OVN plugin will enable setting the type as "vtep" and the > vtep-logical-switch and vtep-physical-switch options in the > OVN_Northbound database. I have the docs published there just to make it easier to read the rendered version. The source of that document is: https://github.com/openvswitch/ovs/blob/master/ovn/ovn-architecture.7.xml > There are 2 parts to the proposal/discussion - a short term solution and > a long term one: > > A short term solution (proposed by Russell Bryant) is similar to the > work that was done for container support in OVN - using a binding > profile http://networking-ovn.readthedocs.org/en/latest/containers.html. > A ovn logical network/switch can be mapped to a vtep logical gateway by > creating a port in that logical network and creating a binding profile > for that port in the following manner: > > neutron port-create --binding-profile > '{"vtep-logical-switch":"vtep_lswitch_key", > "vtep-physical-switch":"vtep_pswitch_key"}' private. > > Where vtep-logical-switch and vtep-physical-switch should have been > defined in the OVN_Southbound database by the previous steps (1,2) in > the life cycle. Yes, this sounds great to me. Since there's not a clear well accepted API to use, we should go this route to get the functionality exposed more quickly. We should also include in our documentation that this is not expected to be how this is done long term. The comparison to the containers-in-VMs support is a good one. In that case we used binding:profile as a quick way to expose it, but we're aiming to support a proper API. For that feature, we've identified the "VLAN aware VMs" API as the way forward, which will hopefully be available next cycle. > For the longer term solution, there needs to be a discussion: > > Should the knowledge about the physical and logical step gateway should > be exposed to Neutron - if yes how? This would allow a Neutron NB > API/extension to bind a “known” vtep gateway to the neutron logical > network. This would be similar to the workflow done in the > networking-l2gw extension > https://review.openstack.org/#/c/144173/3/specs/kilo/l2-gateway-api.rst > > 1. Allow the admin to define and manage the vtep gateway through Neutron > REST API. > > 2. Define connections between Neutron networks and gateways. This is > conceptually similar to Step 3 of the step gateway performed by the OVN > Plugin in the short term solution. networking-l2gw does seem to be the closest thing to what's needed, but it's not a small amount of work. I think the API might need to be extended a bit for our needs. A bigger concern for me is actually with some of the current implementation details. One particular issue is that the project implements the ovsdb protocol from scratch. The ovs project provides a Python library for this. Both Neutron and networking-ovn use it, at least. From some discussion, I've gathered that the ovs Python library lacked one feature that was needed, but has since been added because we wanted the same thing in networking-ovn. The networking-l2gw route will require some pretty significant work. It's still the closest existing effort, so I think we should explore it until it's absolutely clear that it *can't* work for what we need. > OR > > Should OVN pursue it’s own Neutron extension (including vtep gateway > support). I don't think this option provides a lot of value over the short term binding:profile solution. Both are OVN specific. I think I'd rather just stick to binding:profile as the OVN specific stopgap because it's a *lot* less work. Thanks again, -- Russell Bryant __ 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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 09/24/2015 10:37 AM, WANG, Ming Hao (Tony T) wrote: > Russell, > > Thanks for your detail explanation and kind help! > I have understand how container in VM can acquire network interfaces in > different neutron networks now. > For the connections between compute nodes, I think I need to study Geneve > protocol and VTEP first. > Any further question, I may need to continue consulting you. :-) OVN uses Geneve in conceptually the same way as to how the Neutron reference implementation (ML2+OVS) uses VxLAN to create overlay networks among the compute nodes for tenant overlay networks. VTEP gateways or provider networks come into play when you want to connect these overlay networks to physical, or "underlay" networks. Hope that helps, -- Russell Bryant __ 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-ovn][vtep] Proposal: support for vtep-gateway in ovn
On 09/24/2015 10:18 AM, Salvatore Orlando wrote: > One particular issue is that the project implements the ovsdb protocol > from scratch. The ovs project provides a Python library for this. Both > Neutron and networking-ovn use it, at least. From some discussion, I've > gathered that the ovs Python library lacked one feature that was needed, > but has since been added because we wanted the same thing in > networking-ovn. > > > My take here is that we don't need to use the whole implementation of > networking-l2gw, but only the APIs and the DB management layer it exposes. > Networking-l2gw provides a VTEP network gateway solution that, if you > want, will eventually be part of Neutron's "reference" control plane. > OVN provides its implementation; I think it should be possible to > leverage networking-l2gw either by pushing an OVN driver there, or > implementing the same driver in openstack/networking-ovn. >From a quick look, it seemed like networking-l2gw was doing 2 things. 1) Management of vtep switches themselves 2) Management of connectivity between Neutron networks and VTEP gateways I figured the implementation of #1 would be the same whether you were using ML2+OVS, OVN, (or whatever else). This part is not addressed in OVN. You point OVN at VTEP gateways, but it's expected you manage the gateway provisioning some other way. It's #2 that has a very different implementation. For OVN, it's just creating a row in OVN's northbound database. or did I mis-interpret what networking-l2gw is doing? > The networking-l2gw route will require some pretty significant work. > It's still the closest existing effort, so I think we should explore it > until it's absolutely clear that it *can't* work for what we need. > > > I would say that it is definitely not trivial but probably a bit less > than "significant". abhraut from my team has done something quite > similar for openstack/vmware-nsx [1] but specific to nsx. :( Does it look like networking-l2gw could be a common API for what's needed for NSX? > > > > OR > > > > Should OVN pursue it’s own Neutron extension (including vtep gateway > > support). > > I don't think this option provides a lot of value over the short term > binding:profile solution. Both are OVN specific. I think I'd rather > just stick to binding:profile as the OVN specific stopgap because it's a > *lot* less work. > > > I totally agree. The solution based on the binding profile is indeed a > decent one in my opinion. > If OVN cannot converge on the extension proposed by networking-l2gw then > I'd keep using the binding profile for specifying gateway ports. Great, thanks for the feedback! > [1] https://review.openstack.org/#/c/210623/ -- Russell Bryant __ 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-ovn][vtep] Proposal: support for vtep-gateway in ovn
On 09/24/2015 01:25 PM, Armando M. wrote: > > > > On 24 September 2015 at 09:12, Russell Bryant <rbry...@redhat.com > <mailto:rbry...@redhat.com>> wrote: > > On 09/24/2015 10:18 AM, Salvatore Orlando wrote: > > One particular issue is that the project implements the ovsdb > protocol > > from scratch. The ovs project provides a Python library for this. > Both > > Neutron and networking-ovn use it, at least. From some discussion, > I've > > gathered that the ovs Python library lacked one feature that was > needed, > > but has since been added because we wanted the same thing in > > networking-ovn. > > > > > > My take here is that we don't need to use the whole implementation of > > networking-l2gw, but only the APIs and the DB management layer it > exposes. > > Networking-l2gw provides a VTEP network gateway solution that, if you > > want, will eventually be part of Neutron's "reference" control plane. > > OVN provides its implementation; I think it should be possible to > > leverage networking-l2gw either by pushing an OVN driver there, or > > implementing the same driver in openstack/networking-ovn. > > From a quick look, it seemed like networking-l2gw was doing 2 things. > > 1) Management of vtep switches themselves > > 2) Management of connectivity between Neutron networks and VTEP > gateways > > I figured the implementation of #1 would be the same whether you were > using ML2+OVS, OVN, (or whatever else). This part is not addressed in > OVN. You point OVN at VTEP gateways, but it's expected you manage the > gateway provisioning some other way. > > It's #2 that has a very different implementation. For OVN, it's just > creating a row in OVN's northbound database. > > or did I mis-interpret what networking-l2gw is doing? > > > No, you did not misinterpret what the objective of the project were > (which I reinstate here): > > * Provide an API to OpenStack admins to extend neutron logical networks > into unmanaged pre-existing vlans. Bear in mind that things like address > collision prevention is left in the hands on the operator. Other aspects > like L2/L3 interoperability instead should be taken care of, at least > from an implementation point of view. > > * Provide a pluggable framework for multiple drivers of the API. > > * Provide an PoC implementation on top of the ovsdb vtep schema. This > can be implemented both in hardware (ToR switches) and software > (software L2 gateways). Thanks for clarifying the project's goals! > > The networking-l2gw route will require some pretty significant work. > > It's still the closest existing effort, so I think we should > explore it > > until it's absolutely clear that it *can't* work for what we need. > > > We may have fallen short of some/all expectations, but I would like to > believe than it is nothing that can't be fixed by iterating on, > especially if active project participation raises. > > I don't think there's a procedural mandate to make OVN abide by the l2gw > proposed API. As you said, it is not a clear well accepted API, but > that's only because we live in a brand new world, where people should be > allowed to experiment and reconcile later as community forces play out. > > That said, should the conclusion that "it (the API) *can't* work for > what OVN needs" be reached, I would like to understand/document why for > the sake of all us involved so that lessons will yield from our mistakes. My gut says we should be able to work together and make it work. I expect we'll talk in more detail in the next cycle. :-) -- Russell Bryant __ 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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?
e the traffic from each container even though its all going over the same network interface to/from the VM. That's where VLAN ids are used. It's used as a simple way to tag traffic as it goes over the VMs network interface. As it arrives in the VM, the tag is stripped and traffic sent to the right container. As it leaves the VM, the tag is stripped and then forwarded to the proper Neutron network (which could itself be a VLAN network, but the tags are not related, and the traffic would be re-tagged at that point). Does that make sense? > Thanks in advance, > Tony > > -Original Message- > From: Russell Bryant [mailto:rbry...@redhat.com] > Sent: Wednesday, September 23, 2015 12:46 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] Does neutron ovn plugin support to > setup multiple neutron networks for one container? > > On 09/22/2015 08:08 AM, WANG, Ming Hao (Tony T) wrote: >> Dear all, >> >> For neutron ovn plugin supports containers in one VM, My understanding is >> one container can't be assigned two network interfaces in different neutron >> networks. Is it right? >> The reason: >> 1. One host VM only has one network interface. >> 2. all the VLAN tags are stripped out when the packet goes out the VM. >> >> If it is True, does neutron ovn plugin or ovn has plan to support this? > > You should be able to assign multiple interfaces to a container on different > networks. The traffic for each interface will be tagged with a unique VLAN > ID on its way in and out of the VM, the same way it is done for each > container with a single interface. > > -- > Russell Bryant > > __ > 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 > -- Russell Bryant __ 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] [networking-ovn] Neutron-DVR feature on OVN/L3
On 09/22/2015 02:35 PM, Carl Baldwin wrote: > On Tue, Sep 22, 2015 at 10:42 AM, Russell Bryant <rbry...@redhat.com> wrote: >> The Neutron L3 agent is only used with networking-ovn temporarily while >> we work through the L3 design and implementation in OVN itself. OVN >> will not use the L3 agent (or DVR) quite soon. Some initial L3 design >> notes are being discussed on the ovs dev list now. L3 in OVN will be >> distributed. > > I'm curious when this is true, what models will be supported? Will it > use NAT as current Neutron reference implementation? Good questions. We're aiming to have at least some initial L3 support available by the Tokyo summit. That will be distributed, but likely won't include NAT at all. Someone is working on figuring out the best way to support NAT natively in OVS, and then we'll be using that. Similar to the way we're doing security groups, NAT will be using the new ovs conntrack integration, but details TBD. I copied Ben Pfaff in case he wants to provide some more insight. -- Russell Bryant __ 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] [networking-ovn] Neutron-DVR feature on OVN/L3
On 09/21/2015 04:47 PM, Sisir Chowdhury wrote: > Hi All - > > I have some proposal regarding ovn-networking project within Open-Stack. > > #1. Making Neutron-DVR feature intelligent enough so that we can > completely remove Network Node(NN). > > Right now even with DVR, the egress traffic originated from VMs > going outbound are SNAT'ed by the > Network Node but the Ingrerss traffic coming from Internet to > the VMs are directly going through the > Compute Node and DNAT'ed by the L3 Agent of the Compute Node. > > Any Thoughts/Comments ? The Neutron L3 agent is only used with networking-ovn temporarily while we work through the L3 design and implementation in OVN itself. OVN will not use the L3 agent (or DVR) quite soon. Some initial L3 design notes are being discussed on the ovs dev list now. L3 in OVN will be distributed. -- Russell Bryant __ 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] Does neutron ovn plugin support to setup multiple neutron networks for one container?
On 09/22/2015 08:08 AM, WANG, Ming Hao (Tony T) wrote: > Dear all, > > For neutron ovn plugin supports containers in one VM, My understanding is one > container can't be assigned two network interfaces in different neutron > networks. Is it right? > The reason: > 1. One host VM only has one network interface. > 2. all the VLAN tags are stripped out when the packet goes out the VM. > > If it is True, does neutron ovn plugin or ovn has plan to support this? You should be able to assign multiple interfaces to a container on different networks. The traffic for each interface will be tagged with a unique VLAN ID on its way in and out of the VM, the same way it is done for each container with a single interface. -- Russell Bryant __ 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] [glance] proposed priorities for Mitaka
On 09/14/2015 11:27 AM, Thierry Carrez wrote: > Doug Hellmann wrote: >> [...] >> 1. Resolve the situation preventing the DefCore committee from >>including image upload capabilities in the tests used for trademark >>and interoperability validation. >> >> 2. Follow through on the original commitment of the project to >>provide an image API by completing the integration work with >>nova and cinder to ensure V2 API adoption. >> [...] > > Thanks Doug for taking the time to dive into Glance and to write this > email. I agree with your top two priorities as being a good summary of > what the "rest of the community" expects the Glance leadership to focus > on in the very short term. +1 Thanks, Doug! and agreed with Thierry's response here. -- Russell Bryant __ 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-ovn][tempest] devstack: gate-tempest-dsvm-networking-ovn failures in Openstack CI
On 08/26/2015 04:25 PM, Amitabha Biswas wrote: With the recent commits it seems that the gate-tempest-dsvm-networking-ovn is succeeding more or less every time. The DBDeadlock issues still are seen on q-svc logs but are not frequent enough to cause ovsdb failures that were leading to the dsvm-networking failing before. \o/ Once in a while a test fails for e.g. tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_two_subnets that failed recently in Jenkins. But I am pretty sure it will succeed if the suite is re-run. Have you looked to see if the same test is failing for the regular neutron jobs? Or does it seem to be OVN specific? Should the gate-tempest-dsvm-networking-ovn become voting at this time, and re-run/re-check if it fails in the Jenkins check? That's a good question. Maybe we should put up a test patch and recheck it a bunch over the next few days to make sure it's as good as we think. If so, I'm all for making it voting asap. Would you like to create a test change for this? If anything new comes up later that causes us problems, the nice thing is that we can pretty quickly and easily disable tests by updating our devstackgaterc file in the networking-ovn repo. -- Russell Bryant __ 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-ovn][tempest] devstack: gate-tempest-dsvm-networking-ovn failures in Openstack CI
On 08/25/2015 03:02 PM, Assaf Muller wrote: On Tue, Aug 25, 2015 at 2:15 PM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 08/25/2015 01:26 PM, Amitabha Biswas wrote: Russell suggested removing the MYSQL_DRIVER=MySQL-python declaration from local.conf https://review.openstack.org/#/c/216413/which results in PyMySQL as the default. With the above change the above DB errors are no longer seen in my local setup, It's great to hear that resolved the errors you saw! 1. Is there any impact of using PyMySQL for the Jenkins check and gates. As Jeremy mentioned, this is what everything else is using (and what OVN was automatically already using in OpenStack CI). 2. Why is the gate-networking-ovn-python27**failing (the past couple of commits) in {0} networking_ovn.tests.unit.test_ovn_plugin.TestOvnPlugin.test_create_port_security [0.194020s] ... FAILED. Do we need another conversation to track this? This is a separate issue. The networking-ovn git repo has been pretty quiet the last few weeks and it seems something has changed that made our tests break. We inherit a lot of base plugin tests from neutron, so it's probably some change in Neutron that we haven't synced with yet. I haven't had time to dig into it yet. This patch was recently merged to Neutron: https://review.openstack.org/#/c/201141/ Looks like that unit test is trying to create a port with an invalid MAC address. I pushed a fix here: https://review.openstack.org/#/c/216837/ Thanks, Assaf! Much appreciated! :-) -- Russell Bryant __ 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][api] - attaching arbitrary key/value pairs to resources
On 08/25/2015 03:01 AM, Miguel Angel Ajo wrote: Doug Wiegley wrote: In general, the fight in Neutron *has* to be about common definitions of networking primitives that can be potentially implemented by multiple backends whenever possible. That's the entire point of Neutron. I get that it's hard, but that's the value Neutron brings to the table. I think that everyone agrees with you on this point. Including me. The tricky part comes when the speed of neutron adding to the api bottlenecks other things, or when the abstractions just aren’t there yet, because the technology in question isn’t mature enough. Do we provide relief valves, knowing they will be abused as much as help, or do we hold a hard line? These tags are a relief valve. I’m in favor of them, and I’m in favor of holding to the abstraction. It seems there has to be a middle ground. Thanks, doug Just thinking out loud: Probably trying to stem the tie, would it make sense to block api calls outside neutron core/api to grab such tags, with a big warning: if you try to circunvent this, you will harm interoperability of openstack, and your plugin will be blocked in next neutron releases.. They could go directly via SQL, but at least, they'd know they're doing the wrong thing, and risking a plugin ban, if that's a reasonable measure from our side. I don't think it's worth the effort or complexity to work too hard at actively preventing it, but anything that helps make it clear to people that it's considered private data (to anything but the API and DB) would be nice. We should be thinking of the people that are intending to play nice, and make it so they don't accidentally use something we don't intend to be used. That's something we can hash out during code review or follow-up patches. -- Russell Bryant __ 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-ovn][tempest] devstack: gate-tempest-dsvm-networking-ovn failures in Openstack CI
On 08/25/2015 01:26 PM, Amitabha Biswas wrote: Russell suggested removing the MYSQL_DRIVER=MySQL-python declaration from local.conf https://review.openstack.org/#/c/216413/which results in PyMySQL as the default. With the above change the above DB errors are no longer seen in my local setup, It's great to hear that resolved the errors you saw! 1. Is there any impact of using PyMySQL for the Jenkins check and gates. As Jeremy mentioned, this is what everything else is using (and what OVN was automatically already using in OpenStack CI). 2. Why is the gate-networking-ovn-python27**failing (the past couple of commits) in {0} networking_ovn.tests.unit.test_ovn_plugin.TestOvnPlugin.test_create_port_security [0.194020s] ... FAILED. Do we need another conversation to track this? This is a separate issue. The networking-ovn git repo has been pretty quiet the last few weeks and it seems something has changed that made our tests break. We inherit a lot of base plugin tests from neutron, so it's probably some change in Neutron that we haven't synced with yet. I haven't had time to dig into it yet. -- Russell Bryant __ 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][api] - attaching arbitrary key/value pairs to resources
On 08/25/2015 01:00 AM, Gal Sagie wrote: I agree with Doug and Kevin, i think it is very hard for Neutron to keep the pace in every area of Networking abstraction, and i prefer this solution on code patching. I agree with Russell on the definition of Neutron end goal, but what good can it provide if clouds stop using Neutron because it doesn't provide them the appropriate support or better yet start solving these problems in creative ways thats ends up missing the entire point of Neutron. (and then clouds stop using Neutron because they will blame it for the lack of interoperability) I think that this is a good enough middle solution and as Armando suggested in the patch it self, we should work in a separate task towards making the users/developers/operators understand (either with documentation or other methods) that the correct end goal would be to standardize things in the API. Implementing it like nova-tags seems to me like a good way to prevent too much abuse. And as i mentioned in the spec [1], there are important use cases for this feature in the API level that is transparent to the backend implementation (Multi site OpenStack and mixed environments (for example Kuryr)) To be clear, I support the feature as long as it's documented that it's opaque to Neutron backends. My argument is about the general idea of arbitrary pass-through to backends, which you don't seem to be proposing. -- Russell Bryant __ 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][api] - attaching arbitrary key/value pairs to resources
On 08/24/2015 09:25 AM, Kevin Benton wrote: Hi everybody! In Neutron the idea of adding tags to resources has come up several times this cycle alone.[1][2][3] The general concern that has led to them being rejected is that backends will leverage these tags to leak implementation details or backend-specific features (e.g. tags that control QoS features, security isolation, or other network behaviors). However, there are many use cases that make these nice for the users of the API to help organize resources (e.g. external DNS names on floating IPs, PCI compliance status of security groups, an emoticon describing the seriousness of the things on that network, etc). I'm beginning to think that it might be worth it for the usefulness it brings to the end users. But with all of the third-party plugins out-of-tree, we essentially have no way to stop them from using the tags to control the networking backend as well. So I'm looking for feedback from the API working group as well as other projects that have gone down this path. Should we just take the pythonic we're all adults approach and try to encourage backends not to use them for network behavior? Or does this carry too much risk of being abused as a shortcut to avoid developing proper API enhancements by backend devs? 1. https://bugs.launchpad.net/neutron/+bug/1460222 2. https://bugs.launchpad.net/neutron/+bug/1483480 3. https://review.openstack.org/#/c/216021/ If this is clearly documented as being a API consumer thing only, then I'm OK with it. Obviously it'll still be possible to be used by a backend, but it's also possible to patch the code or provide arbitrary API extensions, too. The plugins may be out of tree, but the ones officially a part of Neutron still are under oversight of the Neutron PTL/team. Using this in a way it's explicitly documented as not to be used would be an example of a case where they should be asked to change. We can't control what backends not a part of Neutron do, but that's not new. One example of another project doing something similar is this: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html Note this important line: The tag is an opaque string and is not intended to be interpreted or even read by the virt drivers. -- Russell Bryant __ 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][api] - attaching arbitrary key/value pairs to resources
On 08/24/2015 09:35 AM, Russell Bryant wrote: On 08/24/2015 09:25 AM, Kevin Benton wrote: Hi everybody! In Neutron the idea of adding tags to resources has come up several times this cycle alone.[1][2][3] The general concern that has led to them being rejected is that backends will leverage these tags to leak implementation details or backend-specific features (e.g. tags that control QoS features, security isolation, or other network behaviors). However, there are many use cases that make these nice for the users of the API to help organize resources (e.g. external DNS names on floating IPs, PCI compliance status of security groups, an emoticon describing the seriousness of the things on that network, etc). I'm beginning to think that it might be worth it for the usefulness it brings to the end users. But with all of the third-party plugins out-of-tree, we essentially have no way to stop them from using the tags to control the networking backend as well. So I'm looking for feedback from the API working group as well as other projects that have gone down this path. Should we just take the pythonic we're all adults approach and try to encourage backends not to use them for network behavior? Or does this carry too much risk of being abused as a shortcut to avoid developing proper API enhancements by backend devs? 1. https://bugs.launchpad.net/neutron/+bug/1460222 2. https://bugs.launchpad.net/neutron/+bug/1483480 3. https://review.openstack.org/#/c/216021/ If this is clearly documented as being a API consumer thing only, then I'm OK with it. Obviously it'll still be possible to be used by a backend, but it's also possible to patch the code or provide arbitrary API extensions, too. The plugins may be out of tree, but the ones officially a part of Neutron still are under oversight of the Neutron PTL/team. Using this in a way it's explicitly documented as not to be used would be an example of a case where they should be asked to change. We can't control what backends not a part of Neutron do, but that's not new. One example of another project doing something similar is this: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html Note this important line: The tag is an opaque string and is not intended to be interpreted or even read by the virt drivers. There's an updated version of that nova spec here: http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/tag-instances.html -- Russell Bryant __ 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][api] - attaching arbitrary key/value pairs to resources
On 08/24/2015 10:33 AM, Kevin Benton wrote: Obviously it'll still be possible to be used by a backend, but it's also possible to patch the code or provide arbitrary API extensions, too. Right, but vendor API extensions are the way that backend-specific features are supposed to be done. With an extension, it's explicit in the API via the extensions list that something non-standard is enabled. Patching code is currently pretty brittle and puts a lot of technical debt on a driver author's part so it's pretty obvious to the author that it's not the right way to go. Once we add these tags, they will be part of the API so they should be stable and will be tempting to use for lots of stuff. :) Totally agreed ... though I'd also argue that vendor API extensions are harmful and shouldn't be allowed going forward, either. -- Russell Bryant __ 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][api] - attaching arbitrary key/value pairs to resources
On 08/24/2015 01:58 PM, Jay Pipes wrote: On 08/24/2015 07:33 AM, Kevin Benton wrote: Obviously it'll still be possible to be used by a backend, but it's also possible to patch the code or provide arbitrary API extensions, too. Right, but vendor API extensions are the way that backend-specific features are supposed to be done. With an extension, it's explicit in the API via the extensions list that something non-standard is enabled. Patching code is currently pretty brittle and puts a lot of technical debt on a driver author's part so it's pretty obvious to the author that it's not the right way to go. Once we add these tags, they will be part of the API so they should be stable and will be tempting to use for lots of stuff. :) As Russell mentions, my idea of simple string tagging is that it is entirely user-driven (ala Launchpad's tagging of bugs -- there is no systemic collation or curation of tags). If you need system-defined and protected attributes, you should use a separate resource on the network or port, ala the port binding profile, which to date has been (ab)used for the purpose of communicating backend-specific metadata. Yeah, I think the port binding profile is a good example of something not to repeat. I took advantage of it to prototype a feature here: http://docs.openstack.org/developer/networking-ovn/containers.html It let me implement a backend specific feature quickly and expose it through the Neutron API. It would be very easy to just call it done and move on. However, the right thing to do is to define a proper Neutron API to express what is needed, so that other backends can implement the same thing. Luckily, it's being covered by the following effort and once it's in place, I can remove this prototype hack. http://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html -- Russell Bryant __ 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][api] - attaching arbitrary key/value pairs to resources
On 08/24/2015 05:25 PM, Doug Wiegley wrote: I took advantage of it to prototype a feature her That right there is the crux of the objections so far. Don’t get me wrong, I’d love this, and would abuse it within an inch of its life regularly. The alternative is sometimes even worse than a vendor extension or plugin. Take for example, wanting to add a new load balancing algorithm, like LEAST_MURDERED_KITTENS. The current list is hard-coded all over the dang place, so you end up shipping neutron patches or monkey patches. Opaque pass-through to the driver is evil from an interoperability standpoint, but in terms of extending code at the operators choosing, there are MUCH worse sins that are actively being committed. I don't think even worse code makes this what's proposed here seem any better. I'm not really sure what you're saying. Flavors covers this use case, but in a way that’s up to the operators to setup, and not as easy for devs to deal with. Whether the above sounds like it’s a bonus or a massive reason not to do this will entirely lie in the eye of the beholder, but the vendor extension use case WILL BE USED, no matter what we say. Interop really is a key part of this. If we look at this particular case, yes, I get that there are lots of LB algorithms out there and that it makes sense to expose that choice to users. However, I do think what's best for users is to define and document each of them very explicitly. The end user should know that if they choose algorithm BEST_LB_EVER, that it means the same thing on cloud A vs cloud B. The way to do that is to have it defined explicitly by Neutron and not punt. Maybe in practice the Neutron defined set is a subset of what's available overall, and the custom (vendor) ones can be clearly marked as such. In any case, I'm just trying to express what goal I think we should be striving for. In general, the fight in Neutron *has* to be about common definitions of networking primitives that can be potentially implemented by multiple backends whenever possible. That's the entire point of Neutron. I get that it's hard, but that's the value Neutron brings to the table. -- Russell Bryant __ 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] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
While this includes me, I'm really not taking this personally. I'm thinking about it in the general sense. On 08/14/2015 11:03 AM, Kyle Mestery wrote: I'd argue the system is built on a web of trust. If you trust me, and I trust Russell and Brandon, then you should likely trust Russell and Brandon as well. This is EXACTLY what the Lieutenant system was meant to convey, though I now feel like perhaps people missed this key ingredient of the new world we find ourselves in. This is a huge and important point. The N to N trust model we've been operating under doesn't scale. Neutron is trying to move to a different trust model that has proven to scale much further than we've been able to do within a single OpenStack project so far. If Kyle and others leading a section of Neutron trust me, I'm happy to jump in and do more reviews. If they trust me, I'd hope others not as familiar with me or my work can trust by proxy. The same applies to Brandon. I honestly don't know Brandon very well, but I have a high level of trust for Kyle. Kyle trusts him, so +1 from me. Kyle has a tough role here. It means he gives up some control, but it's the way the project will scale. Kyle doesn't have to develop a close trust relationship with everyone merging code into the main neutron repo, much less all the other repos. He can delegate some of that. It only works if everyone buys into this way of thinking. -- Russell Bryant __ 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] [PATCH v4 2/5] ovn: Add bridge mappings to ovn-controller.
I found a couple of problems in this one. I'll fix it in v5 in a few minutes. On 07/31/2015 10:52 AM, Russell Bryant wrote: Add a new OVN configuration entry in the Open_vSwitch database called ovn-bridge-mappings. This allows the configuration of mappings between a physical network name and an OVS bridge that provides connectivity to that network. For example, if you wanted to configure physnet1 to map to br-eth0 and physnet2 to map to br-eth1, the configuration would be: $ ovs-vsctl set open . \ external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1 Patch ports between these bridges and the integration bridge are automatically created and also removed if necessary when the configuration changes. Documentation for this configuration value is introduced in a later patch that makes use of this by introducing a localnet logical port type. Signed-off-by: Russell Bryant rbry...@redhat.com +static void +create_patch_port(struct controller_ctx *ctx, + const char *network, + const struct ovsrec_bridge *b1, + const struct ovsrec_bridge *b2) +{ +struct ovsrec_interface *iface; +struct ovsrec_port *port, **ports; +size_t i; +char *port_name; + +port_name = xasprintf(patch-%s-to-%s, b1-name, b2-name); + +ovsdb_idl_txn_add_comment(ctx-ovs_idl_txn, +ovn-controller: creating patch port '%s' from '%s' to '%s', +port_name, b1-name, b2-name); This will blow up if ctx-ovs_idl_txn is NULL, which happens under normal cirumstances. @@ -271,6 +495,10 @@ main(int argc, char *argv[]) const struct ovsrec_bridge *br_int = get_br_int(ctx.ovs_idl); const char *chassis_id = get_chassis_id(ctx.ovs_idl); +/* Map bridges to local nets from ovn-bridge-mappings */ +struct smap bridge_mappings = SMAP_INITIALIZER(bridge_mappings); +init_bridge_mappings(ctx, br_int, bridge_mappings); + This should make sure br_int isn't NULL first. -- Russell Bryant __ 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][upgrades] Potential issues when performing Neutron upgrades
On 07/13/2015 04:09 AM, Kevin Benton wrote: because you won't have to run Neutron agents on compute nodes anymore. How will upgrades work for OVN? We haven't written anything down yet, but here's what I expect. Right now we're still changing the db schema however is needed without messing with versioning. As we get to production ready, I expect we'll start being strict about only making backwards compatible ovsdb schema changes to make upgrades easier. There are 2 central components - ovn-northd and ovsdb-server - that would be upgraded first, which I would expect to be done at the same time as upgrading your Neutron control plane. As long as any ovsdb schema changes are backwards compatible, you could do rolling-upgrades of ovn-controller on compute or network nodes. -- Russell Bryant __ 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][upgrades] Potential issues when performing Neutron upgrades
On 07/13/2015 05:08 PM, Kevin Benton wrote: Thanks for the info. So the equivalent in neutron would be if we just ensure backward compatible AMQP APIs, right? There's a few parts: 1) Backwards compatibility with changes to the oslo.messaging APIs using API versioning (what you're referring to, I think). Neutron does this (though not tested in a mixed version mid-upgrade environment yet). 2) Compatibility of the data sent over those interfaces. This is where oslo.versionedobjects comes in. Breakage here is much easier to miss since it's not always obvious when you're modifying a data structure that's sent over the wire. There has been a ton of work in Nova to version the data sent over the wire and have the ability for a service (nova-conductor in nova's case) to be able to convert objects back to a version that an older service can understand. This is the most likely way Neutron will break rolling upgrades right now, especially since it's not tested. 3) DB schema. Depending on what services access the db directly and what the rolling upgrade strategy is, there may be some additional constraints on making sure the db schema is backwards copmatible, too. -- Russell Bryant On Mon, Jul 13, 2015 at 7:33 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 07/13/2015 04:09 AM, Kevin Benton wrote: because you won't have to run Neutron agents on compute nodes anymore. How will upgrades work for OVN? We haven't written anything down yet, but here's what I expect. Right now we're still changing the db schema however is needed without messing with versioning. As we get to production ready, I expect we'll start being strict about only making backwards compatible ovsdb schema changes to make upgrades easier. There are 2 central components - ovn-northd and ovsdb-server - that would be upgraded first, which I would expect to be done at the same time as upgrading your Neutron control plane. As long as any ovsdb schema changes are backwards compatible, you could do rolling-upgrades of ovn-controller on compute or network nodes. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ 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 -- Russell Bryant __ 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][upgrades] Potential issues when performing Neutron upgrades
On 07/09/2015 10:11 AM, Ihar Hrachyshka wrote: On 07/09/2015 09:01 AM, Artur Korzen wrote: Hi all, I've been researching the Neutron project as a part of work on Openstack rolling upgrades, my primary assignments included testing if there is no VM access downtime when performing upgrade. Are you aware of any issues that are present in Liberty release of Neutron, that may cause the VM access downtime and may stop ops to pick up newest versions of code? When talking about no VM access downtime during upgrade, the sensitive operations are: 1. ensure that even after neutron services is shutoff/uninstalled, the traffic can go into the VM 2. take care on neutron services startup/installation that existing configuration is preserved (routing tables, forwarding entries and security rules) 3. the underlying network technologies (OVS, linux bridges etc.) is working without distraction when upgrading neutron code: no dropping table flows or applying the traffic rules to drop the packages To be compatible between different versions of service talking to each other, the important areas are: 1. RPC API versioning 2. Objects exchanged between services via RPC 3. Database schema (bp [2]) and data migration I have researched the ML2 plugin with ovs agent, including the neutron-ovs-agent, dhcp-server, l3-agent, neutron-server. One of the VM access downtime during upgrade is addressed in [1], removing the flows in ovs after neutron agent restarts. Is Neutron ready to be upgradable with minimal downtime of services and no VM access downtime? As the ovs bug you refer to above, no, at least not in reference implementation. That's for data plane. As for other services, neutron-server online schema migration should help, and I hope to get it implemented in L (though there are some obstacles that may block us; we'll see). As for live data migration, neutron code base is not ready yet to reasonably require live data migration being implemented in all patches that need data moves in database. The very first obstacle for that is that there is no middleware layer between sqlalchemy and the rest of neutron that would allow us to hide migration details. Oslo.versionedobjects is such a middleware. See below. Are there any guidelines on using the oslo versionobjects and its priority in Liberty cycle? It's not a common priority for L, but we've started on this road inside feature/qos branch that will hopefully get into master some time after L-2. If interested, see: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects?h=f eature/qos Once the feature branch is merged into master, I plan to start converting existing resources to objects. It may take time and will definitely span to M. Depending on progress in this regard, we'll see whether we will be able to consider live data migration. At the moment, I don't see it happening in M, at least not at the start of it. Are there use-cases written down when talking about Neutron upgrades? One thing that is currently in review are partial upgrades. They are tested for nova (including nova-network) but not for neutron, so it's considered a nova-network/neutron parity issue. You should find most of relevant patches in: https://review.openstack.org/#/q/owner:%22Russell+Bryant%22+status:open, n,z Yes, there's a ton of work to make rolling upgrades as robust as what Nova has done. There's significant limitations to what Neutron can do without breaking it, but hopefully the grenade job would help us catch things that would break it sooner. At the moment those jobs have been blocked pending some re-work of how the partial upgrade jobs work. As of the last release (Kilo), rolling upgrades from Juno with Neutron worked when verified manually. I'm hoping we'll have the same for Liberty, but I'm not sure if anyone has tried it out recently. All of the things discussed here sound like good things to work on. I actually thought a group was going to work on versioned objects for Kilo, but that never materialized. I'll also plug a project I'm working on (OVN, part of the Open vSwitch project), which I also think simplifies this a good bit for Neutron, because you won't have to run Neutron agents on compute nodes anymore. -- Russell Bryant __ 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] [grenade] future direction on partial upgrade support
On 06/24/2015 01:31 PM, Joe Gordon wrote: On Tue, Jun 16, 2015 at 9:58 AM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: Back when Nova first wanted to test partial upgrade, we did a bunch of slightly odd conditionals inside of grenade and devstack to make it so that if you were very careful, you could just not stop some of the old services on a single node, upgrade everything else, and as long as the old services didn't stop, they'd be running cached code in memory, and it would look a bit like a 2 node worker not upgraded model. It worked, but it was weird. There has been some interest by the Nova team to expand what's not being touched, as well as the Neutron team to add partial upgrade testing support. Both are great initiatives, but I think going about it the old way is going to add a lot of complexity in weird places, and not be as good of a test as we really want. Nodepool now supports allocating multiple nodes. We have a multinode job in Nova regularly testing live migration using this. If we slice this problem differently, I think we get a better architecture, a much easier way to add new configs, and a much more realistic end test. Conceptually, use devstack-gate multinode support to set up 2 nodes, an all in one, and a worker. Let grenade upgrade the all in one, leave the worker alone. I think the only complexity here is the fact that grenade.sh implicitly drives stack.sh. Which means one of: 1) devstack-gate could build the worker first, then run grenade.sh 2) we make it so grenade.sh can execute in parts more easily, so it can hand something else running stack.sh for it.' 3) we make grenade understand the subnode for partial upgrade, so it will run the stack phase on the subnode itself (given credentials). This kind of approach means deciding which services you don't want to upgrade doesn't require devstack changes, it's just a change of the services on the worker. We need a volunteer for taking this on, but I think all the follow on partial upgrade support will be much much easier to do after we have this kind of mechanism in place. I think this is a great approach for the future of partial upgrade support in grenade. I would like to point out step 0 here, is to get tempest passing consistently in multinode. Currently the neutron job is failing consistently, and nova-network fails roughly 10% of the time due to https://bugs.launchpad.net/nova/+bug/1462305 and https://bugs.launchpad.net/nova/+bug/1445569 If multi-node isn't reliable more generally yet, do you think the simpler implementation of partial-upgrade testing could proceed? I've already done all of the patches to do it for Neutron. That way we could quickly get something in place to help block regressions and work on the longer-term multinode refactoring without as much time pressure. For reference, the Neutron related partial-upgrade test related patches are: devstack patches: https://review.openstack.org/189408 https://review.openstack.org/189707 https://review.openstack.org/189710 grenade patches: https://review.openstack.org/189417 https://review.openstack.org/189712 devstack-gate patches: https://review.openstack.org/189424 https://review.openstack.org/189715 project-config patches: https://review.openstack.org/189426 https://review.openstack.org/189727 -- Russell Bryant __ 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] [grenade] future direction on partial upgrade support
On 06/24/2015 01:49 PM, Dan Smith wrote: If multi-node isn't reliable more generally yet, do you think the simpler implementation of partial-upgrade testing could proceed? I've already done all of the patches to do it for Neutron. That way we could quickly get something in place to help block regressions and work on the longer-term multinode refactoring without as much time pressure. I was going to ask the same about the (arguably MUUCH tinier) patch to include nova-net in the nova-compute partial upgrade bin. I know the right answer is working on the multinode job, but fixing that and then extending grenade to work that way is a significant amount of work. The fact that we're not testing nova-net with nova-compute properly right now and claiming we're safe is just lying to ourselves. Yeah, that's certainly a tiny change. There are several Neutron patches, but they're all pretty simple IMO. I picked up this task to help with the Neutron and nova-network parity work. It tests the backend that isn't even my primary focus/interest, but I still wanted to help the parity work along. If it ends up requiring this significant extra work, I'll honestly most likely just drop it completely and hope someone else feels like taking it on. -- Russell Bryant __ 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