Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
This is all good stuff. Thanks. Does/Should the neutron docs have an openvswitch debugging page? This belongs there for easy access. Such a page might go a long way to alleviate fears over the openvswitch backend. Thanks, Kevin From: Attila Fazekas Sent: Tuesday, April 28, 2015 1:22:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] You can tcpdump the ovs ports as usual. Please keep in mind ovs does not have `single contention` port. OVS does MAC learning by default and you may not see `learned` uni-cast traffic on a random trunk port. You MAY see BUM traffic, but many of them also can be canceled by neutron-ml2-ovs, AFAIK it is not enabled by default. OVS behaves like a real switch, real switches also does not have 5 Tbit/sec ports for monitoring :( If you need to tcpudump on a port which is not visible in the userspace (internal patch links) by default you should do port mirroring. [1] Usually you do not need to dump the traffic, What you should do as basic trouble shooting is checking the tags on the ports, (`ovsdb-client dump` show everything, excluding the oflow rules) Hopefully the root cause is fixed, but you should check is the port not trunk when it needs to be tagged. Neutron also dedicates the vlan-4095 on br-int as dead vlan, If you have a port in this, it can mean a miss configuration or a message lost in the void or something Exceptional happened. If you really need to redirect exceptional `out of band` traffic to a special port or to an external service (controller) it would be more complex thing then just doing the mirroring. [1] http://www.yet.org/2014/09/openvswitch-troubleshooting/ PS.: OVS does not generates ICMP packets in many cases when a real `L3` switch would do, thats why the MTU size differences causes issues and requires extra care at configuration, when ovs used with tunneling. (OVS also can be used with vlans) Probably this caused the most headache for many user. PS2.: Somewhere I read the ovs had the PMTUD support, but it was removed because it was not conforming to the standard. It just does silent packet drop :( - Original Message - From: Jeremy Stanley fu...@yuggoth.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, April 21, 2015 5:00:24 PM Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 2015-04-21 03:19:04 -0400 (-0400), Attila Fazekas wrote: [...] IMHO the OVS is less complex than netfilter (iptables, *tables), if someone able to deal with reading the netfilter rules he should be able to deal with OVS as well. In a simple DevStack setup, you really have that many iptables/ebtables rules? OVS has debugging tools for internal operations, I guess you are looking for something else. I do not have any `good debugging` tool for net-filter either. [...] Complexity of connecting tcpdump to the bridge was the primary concern here (convenient means of debugging network problems when you're using OVS, less tools for debugging OVS itself though it can come down to that at times as well). Also ebtables can easily be configured to log every frame it blocks, forwards or rewrites (presumably so can the OVS flow handler? but how?). -- Jeremy Stanley __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
You can tcpdump the ovs ports as usual. Please keep in mind ovs does not have `single contention` port. OVS does MAC learning by default and you may not see `learned` uni-cast traffic on a random trunk port. You MAY see BUM traffic, but many of them also can be canceled by neutron-ml2-ovs, AFAIK it is not enabled by default. OVS behaves like a real switch, real switches also does not have 5 Tbit/sec ports for monitoring :( If you need to tcpudump on a port which is not visible in the userspace (internal patch links) by default you should do port mirroring. [1] Usually you do not need to dump the traffic, What you should do as basic trouble shooting is checking the tags on the ports, (`ovsdb-client dump` show everything, excluding the oflow rules) Hopefully the root cause is fixed, but you should check is the port not trunk when it needs to be tagged. Neutron also dedicates the vlan-4095 on br-int as dead vlan, If you have a port in this, it can mean a miss configuration or a message lost in the void or something Exceptional happened. If you really need to redirect exceptional `out of band` traffic to a special port or to an external service (controller) it would be more complex thing then just doing the mirroring. [1] http://www.yet.org/2014/09/openvswitch-troubleshooting/ PS.: OVS does not generates ICMP packets in many cases when a real `L3` switch would do, thats why the MTU size differences causes issues and requires extra care at configuration, when ovs used with tunneling. (OVS also can be used with vlans) Probably this caused the most headache for many user. PS2.: Somewhere I read the ovs had the PMTUD support, but it was removed because it was not conforming to the standard. It just does silent packet drop :( - Original Message - From: Jeremy Stanley fu...@yuggoth.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, April 21, 2015 5:00:24 PM Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 2015-04-21 03:19:04 -0400 (-0400), Attila Fazekas wrote: [...] IMHO the OVS is less complex than netfilter (iptables, *tables), if someone able to deal with reading the netfilter rules he should be able to deal with OVS as well. In a simple DevStack setup, you really have that many iptables/ebtables rules? OVS has debugging tools for internal operations, I guess you are looking for something else. I do not have any `good debugging` tool for net-filter either. [...] Complexity of connecting tcpdump to the bridge was the primary concern here (convenient means of debugging network problems when you're using OVS, less tools for debugging OVS itself though it can come down to that at times as well). Also ebtables can easily be configured to log every frame it blocks, forwards or rewrites (presumably so can the OVS flow handler? but how?). -- Jeremy Stanley __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
- Original Message - From: Jeremy Stanley fu...@yuggoth.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Friday, April 17, 2015 9:35:07 PM Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 2015-04-17 11:49:23 -0700 (-0700), Kevin Benton wrote: I definitely understand that. But what is the major complaint from operators? I understood that quote to imply it was around Neutron's model of self-service networking. My takeaway from Tom's message was that there was a concern about complexity in all forms (not just of the API but also due to the lack of maturity, documentation and debuggability of the underlying technology), and that the self-service networking model was simply one example of that. Perhaps I was reading between the lines too much because of prior threads on both the operators and developers mailing lists. Anyway, I'm sure Tom will clarify what he meant if necessary. IMHO the OVS is less complex than netfilter (iptables, *tables), if someone able to deal with reading the netfilter rules he should be able to deal with OVS as well. OVS has debugging tools for internal operations, I guess you are looking for something else. I do not have any `good debugging` tool for net-filter either. The way how openstack/neutron/devstack by default uses OVS is simpler, than most small (non openstack related) OVS example trying to explain. I kind of agree with the lack of documentation part. A documentation which explains howto use OVS in same way as neutron does would be helpfull for new comers. If the main reason the remaining Nova-net operators don't want to use Neutron is due to the fact that they don't want to deal with the Neutron API, swapping some implementation defaults isn't really going to get us anywhere on that front. This is where I think the subthread has definitely wandered off topic too. Swapping implementation defaults in DevStack because it's quicker and easier to get running on the typical all-in-one/single-node setup and faster to debug problems with (particularly when you're trying to work on non-network-related bits and just need to observe the network communication between your services) doesn't seem like it should have a lot to do with the recommended default configuration for a large production deployment. One size definitely does not fit all. It's an important distinction because it determines what actionable items we can take (e.g. what Salvatore mentioned in his email about defaults). Does that make sense? It makes sense in the context of the Neutron/Nova network parity topic, but not so much in the context of the DevStack default settings topic. DevStack needs a simple default that just works, and doesn't need the kitchen sink. You can turn on more complex options as you need to test them out. In some ways this has parallels to the complexity concerns the operator community has over Neutron and OVS, but I think they're still relatively distinct topics. -- Jeremy Stanley __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 2015-04-21 03:19:04 -0400 (-0400), Attila Fazekas wrote: [...] IMHO the OVS is less complex than netfilter (iptables, *tables), if someone able to deal with reading the netfilter rules he should be able to deal with OVS as well. In a simple DevStack setup, you really have that many iptables/ebtables rules? OVS has debugging tools for internal operations, I guess you are looking for something else. I do not have any `good debugging` tool for net-filter either. [...] Complexity of connecting tcpdump to the bridge was the primary concern here (convenient means of debugging network problems when you're using OVS, less tools for debugging OVS itself though it can come down to that at times as well). Also ebtables can easily be configured to log every frame it blocks, forwards or rewrites (presumably so can the OVS flow handler? but how?). -- Jeremy Stanley __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Yes. Totally agree. I hate it that I have to spend a giant amount of effort on one of my clouds to get a working network to my VMs when on the other cloud I get a VM that can talk to the network. Guess which one I think should be the default behavior? Whichever one you choose to deploy with Neutron! Neutron supports a bunch of topologies based on vlans, flat networks, overlays, tenant routers, shared networks, etc. There is no 'default' in this regard. From what I've gathered from these emails, the use case you want is no floating IPs and no tenant routers (what I understood you to be referring to as 'SDN'). If that's the case, just create a few networks with the provider attributes you are interested in and you're done. So what I keep trying to say is that there should be an easy and sane way for me to get a non-natted VM connected to a network that can route packets and I should not need to know anything about the advanced network options available to me, because as a person who just wants a vm that can talk to a network, I'm the default case. neutron net-create MYNET --shared --provider:network_type vlan --provider:physical_network PHYSNET --provider:segmentation_id VLAN_ID Or replace the network type with 'flat' if you don't want any VLAN tagging. This is also possible via the 'networks' tab in the Horizon UI. Please let me know if I've misunderstood what you want. The fact that you aren't interested in floating IPs makes your use case easy. The only one we are having difficulty supporting is the nova network style use case where floating IPs are used with regular networks and no tenant routers. But we're not going to get there by ignoring the needs of the people who want to boot vms that can talk to the network by default. If we're only focusing on the people who want to do fancy network things, and not serving the needs of the people who want to do simple network things - then all we're doing is trading one set of limitations for a second set of limitations, and we're switching which set of people we're excluding from the party. We're not talking about ignoring the needs of these users though. The use of Linux bridge vs. OVS would not be tenant-facing. The API would still support all of the things we have been discussing so far (including floating IPs). The vswitch is just an implementation detail not exposed at the API level. What would be impacted is the ability for the cloud administrator to troubleshoot connectivity or use tooling they are comfortable with if they have a back-ground with Linux bridge vs. OVS. This point has been made clear. On Sat, Apr 18, 2015 at 9:42 AM, Monty Taylor mord...@inaugust.com wrote: On 04/18/2015 10:44 AM, Fox, Kevin M wrote: Replying inline. -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: Friday, April 17, 2015 7:53 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. I'm sorry, but with all due respect - I believe that sounds very much like sticking fingers in ears and not paying attention to the very real needs of users. No, when you have complex software, with multiple classes of users, it is almost impossible to please all your users, in every way. Sime times, you must make hard decisions to make one users experience a little less good for the benefit of the whole community. /me channels Spock here... If it makes the Ops life a little harder, but for every Op that has to learn how to debug openvswitch, 100 users don't have to deal with the difference between nova-network and neutron api's and software built on top of OpensStack that only works with one of them, I think that's worth the tradeoff. Its unfortunate,
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
I understand this is important for people, so let's keep it around - but having software routers essentially means that it's a scaling bottleneck. SDN is not software routing. It's about programmatically controlling network traffic. Please don't conflate the two because it leads to a lot of confusion about the causes of issues like scalability. Neutron happens to have an open source implementation that uses a centralized network node. This is a bummer for the reasons you described, but it's not because of SDN. Doug's reply described how you can skip floating IPs and routers just fine with Neutron today to fit your DHCP direct routed IP model just like you described. Also, the Linux bridge plugin should also work fine for this use case since no routing is done in Neutron. I'm an end user. I do not care about this at all. DVR is only important if you have bought in to software routers. It's a solution to a problem that would go away if things worked like networks. DVR just does the same thing Nova network did with floating IPs and linux bridge. It's a system to directly translate and route floating IP traffic on the compute node. Since you're not interested in floating IPs, this isn't really relevant, but it's pretty unfair to throw Neutron under the bus for carrying over Nova network semantics. On Fri, Apr 17, 2015 at 7:53 PM, Monty Taylor mord...@inaugust.com wrote: On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. I'm sorry, but with all due respect - I believe that sounds very much like sticking fingers in ears and not paying attention to the very real needs of users. Let me tell you some non-features I encounter currently: - Needing Floating IPs to get a public address This is touted as the right way to do it - but it's actually a terrible experience for a user. The clouds I have access to that just give me a direct DHCP address are much more useful. In fact, we should delete floating ips - they are a non-feature that make life harder. Literally no user of a cloud has ever wanted them, although we've learned to deal with them. - SDN I understand this is important for people, so let's keep it around - but having software routers essentially means that it's a scaling bottleneck. In the cloud Infra uses that has SDN, we have to create multiple software routers to handle the scaling issues. On the other hand, direct routing / linuxbridge does NOT have this problem, because the network packets are routed directly. We should not delete SDN like we should delete floating IPs, because there are real users who have real uses cases and SDN helps them. However, it should be an opt-in feature for a user that is an add on. vexxhost is getting this right right now - you automatically get a DHCP'd direct routed IP on each VM you provision, but if you decide you need fancy, you can opt in to create a private network. - DVR I'm an end user. I do not care about this at all. DVR is only important if you have bought in to software routers. It's a solution to a problem that would go away if things worked like networks. :/ So is keeping nova-network around forever. :/ But other then requiring some more training for ops folks, I think Neutron can suit the rest of the use cases these days nova-network provided over neutron. The sooner we can put the nova-network issue to bed, the better off the ecosystem will be. It will take a couple of years for the ecosystem to settle out to deprecating it, since a lot of clouds take years to upgrade and finally put the issue to bed. Lets do that sooner rather then later so a couple of years from now, we're done. :/ I'm about to deploy a cloud, I'm going to run neutron, and I'm not going to run openvswitch because I do not need it. I will run the equiv of flatdhcp. If neutron doesn't have it, I will write it, because it's that important that
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
How will it help to have a flat network where all vms, not just the ones that need that scarce resource are on the same network consuming ips? Thanks, Kevin From: Daniel Comnea Sent: Saturday, April 18, 2015 2:07:03 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] Monty many thanks for a clear summary, fully agree with you. I have a nightmare trying to educate developers (mainly from client side) in my group that they need to get used with private net and not consume all FIP because is not an unlimited resource On Sat, Apr 18, 2015 at 3:53 AM, Monty Taylor mord...@inaugust.commailto:mord...@inaugust.com wrote: On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.govmailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. I'm sorry, but with all due respect - I believe that sounds very much like sticking fingers in ears and not paying attention to the very real needs of users. Let me tell you some non-features I encounter currently: - Needing Floating IPs to get a public address This is touted as the right way to do it - but it's actually a terrible experience for a user. The clouds I have access to that just give me a direct DHCP address are much more useful. In fact, we should delete floating ips - they are a non-feature that make life harder. Literally no user of a cloud has ever wanted them, although we've learned to deal with them. - SDN I understand this is important for people, so let's keep it around - but having software routers essentially means that it's a scaling bottleneck. In the cloud Infra uses that has SDN, we have to create multiple software routers to handle the scaling issues. On the other hand, direct routing / linuxbridge does NOT have this problem, because the network packets are routed directly. We should not delete SDN like we should delete floating IPs, because there are real users who have real uses cases and SDN helps them. However, it should be an opt-in feature for a user that is an add on. vexxhost is getting this right right now - you automatically get a DHCP'd direct routed IP on each VM you provision, but if you decide you need fancy, you can opt in to create a private network. - DVR I'm an end user. I do not care about this at all. DVR is only important if you have bought in to software routers. It's a solution to a problem that would go away if things worked like networks. :/ So is keeping nova-network around forever. :/ But other then requiring some more training for ops folks, I think Neutron can suit the rest of the use cases these days nova-network provided over neutron. The sooner we can put the nova-network issue to bed, the better off the ecosystem will be. It will take a couple of years for the ecosystem to settle out to deprecating it, since a lot of clouds take years to upgrade and finally put the issue to bed. Lets do that sooner rather then later so a couple of years from now, we're done. :/ I'm about to deploy a cloud, I'm going to run neutron, and I'm not going to run openvswitch because I do not need it. I will run the equiv of flatdhcp. If neutron doesn't have it, I will write it, because it's that important that it exist. If you take that ability away from me, you will be removing working feature and replacing them with things that make my user experience worse. Let's not do that. Let's listen to the people who are using this thing as end users. Let's understand their experience and frustration. And let's not chase pie-in-the-sky theory of how it should work in the face of what a ton of people are asking and even begging for. FlatDHCP is perfect for the 80% case. The extra complexity of the additional things if you don't actually need them is irresponsible. [Rockyg] Kevin, the problem is that the extra
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 2015-04-18 14:51:36 + (+), Fox, Kevin M wrote: How will it help to have a flat network where all vms, not just the ones that need that scarce resource are on the same network consuming ips? You seem to make the assumption that IP addresses are always scarce. Perhaps for some environments they are, but there are plenty of situations where they are not. If you're suggesting I should perform network address translation to reach my IPv6 addresses, or to connect an OpenStack environment into an existing internal RFC-1918 network, or in my enterprise that got multiple legacy class B IPv4 assignments from InterNIC, I'm pretty scared. Not every cloud is a public service provider. -- Jeremy Stanley __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Replying inline. -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: Friday, April 17, 2015 7:53 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. I'm sorry, but with all due respect - I believe that sounds very much like sticking fingers in ears and not paying attention to the very real needs of users. No, when you have complex software, with multiple classes of users, it is almost impossible to please all your users, in every way. Sime times, you must make hard decisions to make one users experience a little less good for the benefit of the whole community. /me channels Spock here... If it makes the Ops life a little harder, but for every Op that has to learn how to debug openvswitch, 100 users don't have to deal with the difference between nova-network and neutron api's and software built on top of OpensStack that only works with one of them, I think that's worth the tradeoff. Its unfortunate, but necessary. Ops have to learn new things all the time. Its in the job description. I currently Operate 3 different OpenStack clouds, so I'm not just trying to push work on others and not myself. I paid the learning curve cost. Let me tell you some non-features I encounter currently: - Needing Floating IPs to get a public address This is touted as the right way to do it - but it's actually a terrible experience for a user. The clouds I have access to that just give me a direct DHCP address are much more useful. Another case of short term pain for long term gain. Its nice to be able to not use them, up until you realize you needed it, don't have it, and its too late to deal with it. Ip addresses are stateful creatures. You attach dns entries to them. Some users contact them directly. They are a window into your machine. The cloud is all about scaling. If you can't just move an ip from vm to vm, you force them to become pets. Without them, you're operating much like in the virtualization days before cloud. In fact, we should delete floating ips - they are a non-feature that make life harder. Literally no user of a cloud has ever wanted them, although we've learned to deal with them. Terrible idea. The first time I moved a floating ip from vm 1 to vm2 to do a rolling update that took under a second, it paid off. And my users benefited. Or the times I deleted vm's and launched new vm's in their place, and no data was lost and no one noticed. Cloud is a very different way to do things and if you don't understand it well, can be confused with traditional virtualization. It too, is worth the learning curve to understand how to do things the Cloud Way. You don't know you want it, until you go through the learning curve and understand why they really make sense. To keep state where it belongs, out of the vm. This is the hart of the issue we're discussing. People are wanting to force the cloud software to function not as a cloud, but more like what they are familiar with. But that's a bad idea. You gut the very features that make Cloud awesome. - SDN I understand this is important for people, so let's keep it around - but having software routers essentially means that it's a scaling bottleneck. In the cloud Infra uses that has SDN, we have to create multiple software routers to handle the scaling issues. On the other hand, direct routing / linuxbridge does NOT have this problem, because the network packets are routed directly. Only if you gut the network stack by making it flat and making NaaS optional. But for NaaS, OpenVSwitch backend does support scaled routing. Its called DVR. The linux bridge agent does not. And at the current rate of development, the
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 04/18/2015 10:44 AM, Fox, Kevin M wrote: Replying inline. -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: Friday, April 17, 2015 7:53 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. I'm sorry, but with all due respect - I believe that sounds very much like sticking fingers in ears and not paying attention to the very real needs of users. No, when you have complex software, with multiple classes of users, it is almost impossible to please all your users, in every way. Sime times, you must make hard decisions to make one users experience a little less good for the benefit of the whole community. /me channels Spock here... If it makes the Ops life a little harder, but for every Op that has to learn how to debug openvswitch, 100 users don't have to deal with the difference between nova-network and neutron api's and software built on top of OpensStack that only works with one of them, I think that's worth the tradeoff. Its unfortunate, but necessary. Ops have to learn new things all the time. Its in the job description. Absolutely, I think that it's impossible to please everyone all the time and I certainly don't think we should avoid ovs because it might be hard to learn. What I'm saying is that the assumption that every cloud wants SDN and Floating IPs and that that should be our default and only world is dangerous - because it's a very advanced way of running and totally not necessary for most user's apps. If OVS _is_ used, a default behavior of connect a VM to a network would be no different to an end user than if a provider network were used. However, if a cloud supports the extra functionality of SDN features or of floating ips, those are opt in features - and it's already well covered by the does my cloud have this conceptual feature So what I'm saying is, asserting that we MUST have OVS because the most complex case needs it and we don't want our users to be confused is a fallacy. I currently Operate 3 different OpenStack clouds, so I'm not just trying to push work on others and not myself. I paid the learning curve cost. Let me tell you some non-features I encounter currently: - Needing Floating IPs to get a public address This is touted as the right way to do it - but it's actually a terrible experience for a user. The clouds I have access to that just give me a direct DHCP address are much more useful. Another case of short term pain for long term gain. Its nice to be able to not use them, up until you realize you needed it, don't have it, and its too late to deal with it. Ip addresses are stateful creatures. You attach dns entries to them. Some users contact them directly. They are a window into your machine. The cloud is all about scaling. If you can't just move an ip from vm to vm, you force them to become pets. Without them, you're operating much like in the virtualization days before cloud. In fact, we should delete floating ips - they are a non-feature that make life harder. Literally no user of a cloud has ever wanted them, although we've learned to deal with them. Terrible idea. The first time I moved a floating ip from vm 1 to vm2 to do a rolling update that took under a second, it paid off. And my users benefited. Or the times I deleted vm's and launched new vm's in their place, and no data was lost and no one noticed. Cloud is a very different way to do things and if you don't understand it well, can be confused with traditional virtualization. It too, is worth the learning curve to understand how to do things the Cloud Way. You don't know you want it, until you go through the learning curve and understand why they really make
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Monty many thanks for a clear summary, fully agree with you. I have a nightmare trying to educate developers (mainly from client side) in my group that they need to get used with private net and not consume all FIP because is not an unlimited resource On Sat, Apr 18, 2015 at 3:53 AM, Monty Taylor mord...@inaugust.com wrote: On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. I'm sorry, but with all due respect - I believe that sounds very much like sticking fingers in ears and not paying attention to the very real needs of users. Let me tell you some non-features I encounter currently: - Needing Floating IPs to get a public address This is touted as the right way to do it - but it's actually a terrible experience for a user. The clouds I have access to that just give me a direct DHCP address are much more useful. In fact, we should delete floating ips - they are a non-feature that make life harder. Literally no user of a cloud has ever wanted them, although we've learned to deal with them. - SDN I understand this is important for people, so let's keep it around - but having software routers essentially means that it's a scaling bottleneck. In the cloud Infra uses that has SDN, we have to create multiple software routers to handle the scaling issues. On the other hand, direct routing / linuxbridge does NOT have this problem, because the network packets are routed directly. We should not delete SDN like we should delete floating IPs, because there are real users who have real uses cases and SDN helps them. However, it should be an opt-in feature for a user that is an add on. vexxhost is getting this right right now - you automatically get a DHCP'd direct routed IP on each VM you provision, but if you decide you need fancy, you can opt in to create a private network. - DVR I'm an end user. I do not care about this at all. DVR is only important if you have bought in to software routers. It's a solution to a problem that would go away if things worked like networks. :/ So is keeping nova-network around forever. :/ But other then requiring some more training for ops folks, I think Neutron can suit the rest of the use cases these days nova-network provided over neutron. The sooner we can put the nova-network issue to bed, the better off the ecosystem will be. It will take a couple of years for the ecosystem to settle out to deprecating it, since a lot of clouds take years to upgrade and finally put the issue to bed. Lets do that sooner rather then later so a couple of years from now, we're done. :/ I'm about to deploy a cloud, I'm going to run neutron, and I'm not going to run openvswitch because I do not need it. I will run the equiv of flatdhcp. If neutron doesn't have it, I will write it, because it's that important that it exist. If you take that ability away from me, you will be removing working feature and replacing them with things that make my user experience worse. Let's not do that. Let's listen to the people who are using this thing as end users. Let's understand their experience and frustration. And let's not chase pie-in-the-sky theory of how it should work in the face of what a ton of people are asking and even begging for. FlatDHCP is perfect for the 80% case. The extra complexity of the additional things if you don't actually need them is irresponsible. [Rockyg] Kevin, the problem is that the extra features *aren't* critical to the deployers and/or users of many of openstack deployments. And since they are not critical, the deployers won't *move* to using neutron that requires them to learn all this new stuff that thjey don't need. By not providing a simple path to a flatDHCP implementation, you will get existing users refusing to upgrade rather than take a bunch of extraneous stuff from Neutron because the OpenStack project
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Complex is kind of the wrong thing to describe the deployer complaint. Its learning curve. To debug issues, I have to learn someting new, and I dont want to because I dont believe I need that feature. I get it. I really do. But there are three actors here, not just one. The deployer, the app developer, and the user... the deployer often doesnt but the user/developer does. Im convinced OpenStack is a data center operating system. Linux has many parallels. The Linux sysadmin is the deployer, the userspace app developer is the OpenStack app developer, syscalls are rest api... The main odd difference in the parallel is that in Linux, you have to purposefully compile out major kernel subsystems, and in OpenStack, you must install them separately. But think of it this way. What would you get if a third of the Linux population compiled out the unix pipe subsystem? That's the close parallel. Shell scripting changes drastically from something that looks like Unix, to something that looks like Windows pre Powershell. The whole development model for the app deployers changes. The same is true in OpenStack. You leave out naas, you end up with heat templates that are very different. By not wanting to learn something new, the deployers are forcing the complexity of this fractured operating system target on the users (who should long term greatly outnumber deployers). The ecosystem the app developers create on top is worse off because they have to target the lowest common denominator. In the end any Operating System lives or dies by the ecosystem of apps built on top of it. My opinion is the continued push for not supporting naas is weakining the ecosystem. We should make sure neutron will scale the way deployers need, then depricate nova-network. Making it too easy to gut large subsystems functionality too easily to cator to the deployers not wanting to learn something new will hurt everyone in the long run. Apps dont get written and the deployers have less reason to deploy due to lack of demand. Lets focus on a strong OpenStack ecosystem. Thanks, Kevin From: Kevin Benton Sent: Thursday, April 16, 2015 9:17:03 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] What do you disagree with? I was pointing out that using Linux bridge will not reduce the complexity of the model of self-service networking, which is what the quote was complaining about. I just wanted to point out that one of the 'major disconnects' as I understand it will not get any better by switching drivers. On 2015-04-16 18:34:40 -0700 (-0700), Kevin Benton wrote: [...] This is referring to the complexity of the API model for Neutron. While this is a problem that I hope to address by making things like shared networks more useful, it's not really relevant to this particular discussion because the model complexity does not decrease with the switch to Linux bridge. I disagree. Complexity for the operator includes more than the API. It also includes troubleshooting what just went wrong when your network decided to do a headstand. As a datapoint, compare the ease of connecting tcpdump to a bridge interface vs the ease of connecting tcpdump to an OVS instance. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Currently Murano supports part of it. It provides a per cloud region app store like functionality. But I think each deployer needs to load in the apps they want in the catalog. I'm thinking that ui should somehow plug into an openstack.org provided catalog of apps that OpenStack app developers can submit to via the openstack.org website. This would make it very simple to grow a large catalog of OpenStack hostable apps. But also, Murano mostly just wraps heat templates. Having written quite a few heat templates, and trying to make them generic enough to work in this appstore like model, I can tell you its very very hard currently for things that aren't just a simple single server, and sometimes even that's hard. :/ The three major current stumbling blocks are: * Key management. (This helps https://blueprints.launchpad.net/barbican/+spec/vm-integration) * Lack of some basic conditional support in heat. (can be hacked around very nastily like https://github.com/EMSL-MSC/heat-templates/blob/master/cfn/lib/FloatingIp.yaml. Don't tell me that's not painful...) * NaaS being optional. (Requires implementing your own vpn's if the provider doens'nt give you NaaS... way to costly to do) Thanks, Kevin From: Ihar Hrachyshka [ihrac...@redhat.com] Sent: Friday, April 17, 2015 9:34 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2015 06:23 PM, Fox, Kevin M wrote: Really, what I expect to see long term in a healthy OpenStack ecosystem is some global AppStore like functionality baked in to horizon. A user goes to it, selects my awesome scalable web hosting system, hits launch, and is given a link to login via webbrowser to edit their site. Under the hood, the system just stood up a trove database, an elasticsearch cluster in its own network, a web tier, a load balancer etc. The user didnt have to care how hard that use to be, and just gets charged for the resources consumed. Benifiting the cloud deployer and the end user. The easier it is to use/create/consume cloud resources the better it is for the deployer. If a bit steaper learning curve up front is nessisary, that sucks, but will be worth it. This sort of thing is what we need to get to, and is extremely difficult if OpenStack clouds differ wildly in functionality. Isn't it what Murano project is intended to do? /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVMTYEAAoJEC5aWaUY1u57K2IH/A7hyLVMBmtnybih6TomSuyE MK1ZQIzSp2TmoUX8umwAi5d6OFvXxSZR2dm94TFXNedDsZUT2+PN/bOqJg0cXOdn URis7fWC1nU2scLB3SfW5jKgawCoM3R6rBiHHzKu2UrctujRz/obZpqrI5lUf4F6 +ONUYGkdL6eDe/g2tCQB6gfwNSFA44F+q193AdEh9IV/3725OJAvWKcD+iRpdEJq vVxLAh8KI6yokf2R9g+Vck3BLsltxQbjUuQjkyxYsRwq7L1vMcRqr4oTmQ2vRP+6 9dEQNlwEJpmDDqIRlL6vYIFH7NKM639EBtCoijdx6tM1oZ9bGoSwXhVtADBWw5U= =AD+V -END PGP SIGNATURE- __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On the contrary, if you reread the message to which you were previously replying, it's was about the unnecessary complexity of OVS (and Neutron in general) for deployments which explicitly _don't_ need and can never take advantage of self-service networking. The implication being that Neutron needs a just connect everything to a simple flat network on a bridge I can easily debug mode which hides or eliminates those complexities instead. I understand. What I'm saying is that switching to Linux bridge will not change the networking model to 'just connect everything to a simple flat network'. All of the complaints about self-service networking will still hold. On Fri, Apr 17, 2015 at 8:22 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-04-16 21:17:03 -0700 (-0700), Kevin Benton wrote: What do you disagree with? I was pointing out that using Linux bridge will not reduce the complexity of the model of self-service networking, which is what the quote was complaining about. On the contrary, if you reread the message to which you were previously replying, it's was about the unnecessary complexity of OVS (and Neutron in general) for deployments which explicitly _don't_ need and can never take advantage of self-service networking. The implication being that Neutron needs a just connect everything to a simple flat network on a bridge I can easily debug mode which hides or eliminates those complexities instead. -- Jeremy Stanley __ 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 -- 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
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
I definitely understand that. But what is the major complaint from operators? I understood that quote to imply it was around Neutron's model of self-service networking. If the main reason the remaining Nova-net operators don't want to use Neutron is due to the fact that they don't want to deal with the Neutron API, swapping some implementation defaults isn't really going to get us anywhere on that front. It's an important distinction because it determines what actionable items we can take (e.g. what Salvatore mentioned in his email about defaults). Does that make sense? On Fri, Apr 17, 2015 at 11:33 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-04-17 10:55:19 -0700 (-0700), Kevin Benton wrote: I understand. What I'm saying is that switching to Linux bridge will not change the networking model to 'just connect everything to a simple flat network'. All of the complaints about self-service networking will still hold. And conversely, swapping simple bridge interfaces for something else still means problems are harder to debug, whether or not you're stuck with self-service networking features you're not using. -- Jeremy Stanley __ 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 -- 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
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 2015-04-17 10:55:19 -0700 (-0700), Kevin Benton wrote: I understand. What I'm saying is that switching to Linux bridge will not change the networking model to 'just connect everything to a simple flat network'. All of the complaints about self-service networking will still hold. And conversely, swapping simple bridge interfaces for something else still means problems are harder to debug, whether or not you're stuck with self-service networking features you're not using. -- Jeremy Stanley __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
And since we've circled back I might add that perhaps we want nova-network to deliver that. Simple, reliable networking leveraging well-established off-the-shelf technologies that satisfies the use cases Jeremy is referring to. If regardless of changes in governance pertaining openstack project the consensus is still that nova-network functionalities should be performed by neutron under the same assumptions, then what Kevin is suggesting goes in the right direction, regardless of whether the deployer chooses linux bridge, OVS, or some fancy advanced technology like [1]. However, there's more than that. For instance ask the average user that just wants connectivity whether they think creating a router or pointing a floating ip to a port should be part of their workflow. You can figure out the answer by yourself. I had a chat with Sean Dague a few day back on IRC [2]. The point seems that when neutron is deployed as a replacement for nova-network it should provide defaults that provide a replacement for nova-network flatdhcp networking mode. For instance this would be a shared network, a single router, and a single external network (the floating IP pool). If multi-host is required that single router should be distributed (and perhaps one day neutron will distribute SNAT too). Router distribution with linux bridge might be a problem with the current framework, where we're insisting on supporting nova-network scenario using neutron's control plane constructs which have been conceived for multi-tenancy and self service networking. And then there's the API usability perspective. But if we provide default for neutron resources then the problem is probably solved as users will have little to no interaction with the neutron API. Salvatore [1] https://github.com/salv-orlando/hdn [2] http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-04-15.log from 2015-04-15T13:26:55 On 17 April 2015 at 17:22, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-04-16 21:17:03 -0700 (-0700), Kevin Benton wrote: What do you disagree with? I was pointing out that using Linux bridge will not reduce the complexity of the model of self-service networking, which is what the quote was complaining about. On the contrary, if you reread the message to which you were previously replying, it's was about the unnecessary complexity of OVS (and Neutron in general) for deployments which explicitly _don't_ need and can never take advantage of self-service networking. The implication being that Neutron needs a just connect everything to a simple flat network on a bridge I can easily debug mode which hides or eliminates those complexities instead. -- Jeremy Stanley __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 2015-04-16 21:17:03 -0700 (-0700), Kevin Benton wrote: What do you disagree with? I was pointing out that using Linux bridge will not reduce the complexity of the model of self-service networking, which is what the quote was complaining about. On the contrary, if you reread the message to which you were previously replying, it's was about the unnecessary complexity of OVS (and Neutron in general) for deployments which explicitly _don't_ need and can never take advantage of self-service networking. The implication being that Neutron needs a just connect everything to a simple flat network on a bridge I can easily debug mode which hides or eliminates those complexities instead. -- Jeremy Stanley __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2015 06:23 PM, Fox, Kevin M wrote: Really, what I expect to see long term in a healthy OpenStack ecosystem is some global AppStore like functionality baked in to horizon. A user goes to it, selects my awesome scalable web hosting system, hits launch, and is given a link to login via webbrowser to edit their site. Under the hood, the system just stood up a trove database, an elasticsearch cluster in its own network, a web tier, a load balancer etc. The user didnt have to care how hard that use to be, and just gets charged for the resources consumed. Benifiting the cloud deployer and the end user. The easier it is to use/create/consume cloud resources the better it is for the deployer. If a bit steaper learning curve up front is nessisary, that sucks, but will be worth it. This sort of thing is what we need to get to, and is extremely difficult if OpenStack clouds differ wildly in functionality. Isn't it what Murano project is intended to do? /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVMTYEAAoJEC5aWaUY1u57K2IH/A7hyLVMBmtnybih6TomSuyE MK1ZQIzSp2TmoUX8umwAi5d6OFvXxSZR2dm94TFXNedDsZUT2+PN/bOqJg0cXOdn URis7fWC1nU2scLB3SfW5jKgawCoM3R6rBiHHzKu2UrctujRz/obZpqrI5lUf4F6 +ONUYGkdL6eDe/g2tCQB6gfwNSFA44F+q193AdEh9IV/3725OJAvWKcD+iRpdEJq vVxLAh8KI6yokf2R9g+Vck3BLsltxQbjUuQjkyxYsRwq7L1vMcRqr4oTmQ2vRP+6 9dEQNlwEJpmDDqIRlL6vYIFH7NKM639EBtCoijdx6tM1oZ9bGoSwXhVtADBWw5U= =AD+V -END PGP SIGNATURE- __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 2015-04-17 11:49:23 -0700 (-0700), Kevin Benton wrote: I definitely understand that. But what is the major complaint from operators? I understood that quote to imply it was around Neutron's model of self-service networking. My takeaway from Tom's message was that there was a concern about complexity in all forms (not just of the API but also due to the lack of maturity, documentation and debuggability of the underlying technology), and that the self-service networking model was simply one example of that. Perhaps I was reading between the lines too much because of prior threads on both the operators and developers mailing lists. Anyway, I'm sure Tom will clarify what he meant if necessary. If the main reason the remaining Nova-net operators don't want to use Neutron is due to the fact that they don't want to deal with the Neutron API, swapping some implementation defaults isn't really going to get us anywhere on that front. This is where I think the subthread has definitely wandered off topic too. Swapping implementation defaults in DevStack because it's quicker and easier to get running on the typical all-in-one/single-node setup and faster to debug problems with (particularly when you're trying to work on non-network-related bits and just need to observe the network communication between your services) doesn't seem like it should have a lot to do with the recommended default configuration for a large production deployment. One size definitely does not fit all. It's an important distinction because it determines what actionable items we can take (e.g. what Salvatore mentioned in his email about defaults). Does that make sense? It makes sense in the context of the Neutron/Nova network parity topic, but not so much in the context of the DevStack default settings topic. DevStack needs a simple default that just works, and doesn't need the kitchen sink. You can turn on more complex options as you need to test them out. In some ways this has parallels to the complexity concerns the operator community has over Neutron and OVS, but I think they're still relatively distinct topics. -- Jeremy Stanley __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. :/ So is keeping nova-network around forever. :/ But other then requiring some more training for ops folks, I think Neutron can suit the rest of the use cases these days nova-network provided over neutron. The sooner we can put the nova-network issue to bed, the better off the ecosystem will be. It will take a couple of years for the ecosystem to settle out to deprecating it, since a lot of clouds take years to upgrade and finally put the issue to bed. Lets do that sooner rather then later so a couple of years from now, we're done. :/ Kevin From: Kevin Benton [blak...@gmail.com] Sent: Friday, April 17, 2015 11:49 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] I definitely understand that. But what is the major complaint from operators? I understood that quote to imply it was around Neutron's model of self-service networking. If the main reason the remaining Nova-net operators don't want to use Neutron is due to the fact that they don't want to deal with the Neutron API, swapping some implementation defaults isn't really going to get us anywhere on that front. It's an important distinction because it determines what actionable items we can take (e.g. what Salvatore mentioned in his email about defaults). Does that make sense? On Fri, Apr 17, 2015 at 11:33 AM, Jeremy Stanley fu...@yuggoth.orgmailto:fu...@yuggoth.org wrote: On 2015-04-17 10:55:19 -0700 (-0700), Kevin Benton wrote: I understand. What I'm saying is that switching to Linux bridge will not change the networking model to 'just connect everything to a simple flat network'. All of the complaints about self-service networking will still hold. And conversely, swapping simple bridge interfaces for something else still means problems are harder to debug, whether or not you're stuck with self-service networking features you're not using. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Its because someone recommended devstack be switched to linux bridge so that its easier for folks to learn openstack. but my assertion is, if all production sites will have to run ovs (or some vendor plugin) and not linux bridge, your hurting folks by making them think they are learning something useful when they are spending time learning something that won't apply when they try and go production. Its a waste of their time. Set the default to be whatever the production default is. Thanks, Kevin From: Jeremy Stanley [fu...@yuggoth.org] Sent: Friday, April 17, 2015 12:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 2015-04-17 11:49:23 -0700 (-0700), Kevin Benton wrote: I definitely understand that. But what is the major complaint from operators? I understood that quote to imply it was around Neutron's model of self-service networking. My takeaway from Tom's message was that there was a concern about complexity in all forms (not just of the API but also due to the lack of maturity, documentation and debuggability of the underlying technology), and that the self-service networking model was simply one example of that. Perhaps I was reading between the lines too much because of prior threads on both the operators and developers mailing lists. Anyway, I'm sure Tom will clarify what he meant if necessary. If the main reason the remaining Nova-net operators don't want to use Neutron is due to the fact that they don't want to deal with the Neutron API, swapping some implementation defaults isn't really going to get us anywhere on that front. This is where I think the subthread has definitely wandered off topic too. Swapping implementation defaults in DevStack because it's quicker and easier to get running on the typical all-in-one/single-node setup and faster to debug problems with (particularly when you're trying to work on non-network-related bits and just need to observe the network communication between your services) doesn't seem like it should have a lot to do with the recommended default configuration for a large production deployment. One size definitely does not fit all. It's an important distinction because it determines what actionable items we can take (e.g. what Salvatore mentioned in his email about defaults). Does that make sense? It makes sense in the context of the Neutron/Nova network parity topic, but not so much in the context of the DevStack default settings topic. DevStack needs a simple default that just works, and doesn't need the kitchen sink. You can turn on more complex options as you need to test them out. In some ways this has parallels to the complexity concerns the operator community has over Neutron and OVS, but I think they're still relatively distinct topics. -- Jeremy Stanley __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 17 April 2015 at 21:35, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-04-17 11:49:23 -0700 (-0700), Kevin Benton wrote: I definitely understand that. But what is the major complaint from operators? I understood that quote to imply it was around Neutron's model of self-service networking. My takeaway from Tom's message was that there was a concern about complexity in all forms (not just of the API but also due to the lack of maturity, documentation and debuggability of the underlying technology), and that the self-service networking model was simply one example of that. Perhaps I was reading between the lines too much because of prior threads on both the operators and developers mailing lists. Anyway, I'm sure Tom will clarify what he meant if necessary. If the main reason the remaining Nova-net operators don't want to use Neutron is due to the fact that they don't want to deal with the Neutron API, swapping some implementation defaults isn't really going to get us anywhere on that front. This is where I think the subthread has definitely wandered off topic too. Swapping implementation defaults in DevStack because it's quicker and easier to get running on the typical all-in-one/single-node setup and faster to debug problems with (particularly when you're trying to work on non-network-related bits and just need to observe the network communication between your services) doesn't seem like it should have a lot to do with the recommended default configuration for a large production deployment. One size definitely does not fit all. It's an important distinction because it determines what actionable items we can take (e.g. what Salvatore mentioned in his email about defaults). Does that make sense? It makes sense in the context of the Neutron/Nova network parity topic, but not so much in the context of the DevStack default settings topic. DevStack needs a simple default that just works, and doesn't need the kitchen sink. You can turn on more complex options as you need to test them out. In some ways this has parallels to the complexity concerns the operator community has over Neutron and OVS, but I think they're still relatively distinct topics. I think this is the crux of this thread, which is drifting off in the wrong direction. For devstack defaults, I'd say even with OVS it just works imho, but my opinion is partial and also I've been using OVS for 4 years now. So I don't count. I accept the desire to default to a data plane technology whose stability is proven by decades of use in production systems, and has probably still a wider adoption compared with OVS. The discussion about simple networking with neutron, whether the operator needs or not to provide self-service networking, and whether OVS is good or yet another piece of software junk, is super interesting. However it does not belong to this thread. I believe there are a few fairly valid reasons for which devstack is less likely to fail with default params using linux bridge rather than OVS - then let's default to linux bridge. At the end of the day I believe users interested in OVS will find in a simple way in the documentation - possibly even in the README file, a way for enabling it. We might even ship a local.conf.ovs file with a ready to use alternate, ovs-based configuration. Salvatore -- Jeremy Stanley __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On Fri, Apr 17, 2015 at 2:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: Its because someone recommended devstack be switched to linux bridge so that its easier for folks to learn openstack. but my assertion is, if all production sites will have to run ovs I believe this is a false assertion and the crux of the disagreement in this thread. There are valid use cases where OVS is not required, nor many features of Neutron, however desirable they may be to other use cases. Its a waste of their time. Set the default to be whatever the production default is. This is generally good advice and we do follow it much of the time. This happens to be one area where the value of 'production default' is not set in source code. In these cases DevStack makes an opinionated choice, and that choice is based on a number of factors. Here overall simplicity and similarity to the existing default (nova-net) are strong selectors for LB. Frankly, if LB is so bad, let's prepare the patch to deprecate it first thing in Liberty and remove it in M. dt -- Dean Troyer dtro...@gmail.com __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On Fri, Apr 17, 2015 at 3:17 PM, Salvatore Orlando sorla...@nicira.com wrote: let's default to linux bridge. At the end of the day I believe users interested in OVS will find in a simple way in the documentation - possibly even in the README file, a way for enabling it. We might even ship a local.conf.ovs file with a ready to use alternate, ovs-based configuration. I do intend the selection between LB and OVS to be a single setting in local.conf, which means that we also have to have sane and simple OVS defaults. Including some more complex examples in the devstack/samples/ dir is also encouraged. dt -- Dean Troyer dtro...@gmail.com __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. :/ So is keeping nova-network around forever. :/ But other then requiring some more training for ops folks, I think Neutron can suit the rest of the use cases these days nova-network provided over neutron. The sooner we can put the nova-network issue to bed, the better off the ecosystem will be. It will take a couple of years for the ecosystem to settle out to deprecating it, since a lot of clouds take years to upgrade and finally put the issue to bed. Lets do that sooner rather then later so a couple of years from now, we're done. :/ Kevin [Rockyg] Kevin, the problem is that the extra features *aren't* critical to the deployers and/or users of many of openstack deployments. And since they are not critical, the deployers won't *move* to using neutron that requires them to learn all this new stuff that thjey don't need. By not providing a simple path to a flatDHCP implementation, you will get existing users refusing to upgrade rather than take a bunch of extraneous stuff from Neutron because the OpenStack project deprecated their network. So, likely two things will happen: 1) the deployments that are already you there configured with nova-network and flatDHCP will stop upgrading with the last nova-network release and 2) if there isn't a simple equivalent by then in neutron or some other openstack project, someone will fork to keep the flatDHCP solution moving forward. You can lead a devops to pizza, but you can't make it eat soylent green pizza. And that's how you lose some of the community and perhaps spur either Neutron's or OpenStack's successor open source project(s). KISS is still in effect. It seems Neutron is abstracting away the current network complexities for developers and endusers at the expense of tossing it all on the shoulders of the deployer/admins. Until you abstract some of that complexity out of the deployment path, either through good coding, useful templates, configuration and management tools, etc., you're going to continue to get pushback from the devops and they will continue to claim parity doesn't exist *for them*. Something I learned a while ago - the sysadmins control the system and stick with minor changes and/or single system by system upgrades until they are either tempted with something shiny/fun/cool/sexy/powerful or coerced by management to change. Until you can demonstrate a *benefit* to them to move to the neutron paradigm for their flatDHCP network, you won't get them to move. They'll take a learning ramp-up, for either less work or better control, but they won't take it for more work. --Rocky From: Kevin Benton [blak...@gmail.com] Sent: Friday, April 17, 2015 11:49 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] I definitely understand that. But what is the major complaint from operators? I understood that quote to imply it was around Neutron's model of self-service networking. If the main reason the remaining Nova-net operators don't want to use Neutron is due to the fact that they don't want to deal with the Neutron API, swapping some implementation defaults isn't really going to get us anywhere on that front. It's an important distinction because it determines what actionable items we can take (e.g. what Salvatore mentioned in his email about defaults). Does that make sense? On Fri, Apr 17, 2015 at 11:33 AM, Jeremy Stanley fu...@yuggoth.orgmailto:fu...@yuggoth.org wrote: On 2015-04-17 10:55:19 -0700 (-0700), Kevin Benton wrote: I understand. What I'm saying is that switching to Linux bridge will not change the networking model to 'just connect everything to a simple flat network'. All of the complaints about self-service networking will still hold. And
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
See my other mail in this thread about app ecosystem. Encouraging more users/usage is a good reason to pay the cost. I think I've already given more then my fair $0.02 on the matter though so I'll stop talking about it now. Thanks, Kevin From: Rochelle Grober [rochelle.gro...@huawei.com] Sent: Friday, April 17, 2015 3:48 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] I know the DevStack issue seems to be solved, but I had to respond…..inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. :/ So is keeping nova-network around forever. :/ But other then requiring some more training for ops folks, I think Neutron can suit the rest of the use cases these days nova-network provided over neutron. The sooner we can put the nova-network issue to bed, the better off the ecosystem will be. It will take a couple of years for the ecosystem to settle out to deprecating it, since a lot of clouds take years to upgrade and finally put the issue to bed. Lets do that sooner rather then later so a couple of years from now, we're done. :/ Kevin [Rockyg] Kevin, the problem is that the extra features *aren’t* critical to the deployers and/or users of many of openstack deployments. And since they are not critical, the deployers won’t *move* to using neutron that requires them to learn all this new “stuff” that thjey don’t need. By not providing a simple path to a flatDHCP implementation, you will get existing users refusing to upgrade rather than take a bunch of extraneous stuff from Neutron because the OpenStack project deprecated “their network.” So, likely two things will happen: 1) the deployments that are already you there configured with nova-network and flatDHCP will stop upgrading with the last nova-network release and 2) if there isn’t a simple equivalent by then in neutron or some other openstack project, someone will fork to keep the flatDHCP solution moving forward. You can lead a devops to pizza, but you can’t make it eat soylent green pizza. And that’s how you lose some of the community and perhaps spur either Neutron’s or OpenStack’s successor open source project(s). KISS is still in effect. It seems Neutron is abstracting away the current network complexities for developers and endusers at the expense of tossing it all on the shoulders of the deployer/admins. Until you abstract some of that complexity out of the deployment path, either through good coding, useful templates, configuration and management tools, etc., you’re going to continue to get pushback from the devops and they will continue to claim parity doesn’t exist *for them*. Something I learned a while ago – the sysadmins control the system and stick with minor changes and/or single system by system upgrades until they are either tempted with something shiny/fun/cool/sexy/powerful or coerced by management to change. Until you can demonstrate a *benefit* to them to move to the neutron paradigm for their flatDHCP network, you won’t get them to move. They’ll take a learning ramp-up, for either less work or better control, but they won’t take it for more work. --Rocky From: Kevin Benton [blak...@gmail.com] Sent: Friday, April 17, 2015 11:49 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] I definitely understand that. But what is the major complaint from operators? I understood that quote to imply it was around Neutron's model of self-service networking. If the main reason the remaining Nova-net operators don't want to use Neutron is due to the fact that they don't want to deal with the Neutron API, swapping some implementation defaults isn't really going to get us anywhere on that front.
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
In an app ecosystem, the users tend not to interact directly with the low level plumbing, but the app developers do. So likely, its the app developers, not the end users that care about naas in the long run. So I do agree that most users wont directly care about naas. But they will care about the software that is enabled by naas. A fine distinction, but important. Really, what I expect to see long term in a healthy OpenStack ecosystem is some global AppStore like functionality baked in to horizon. A user goes to it, selects my awesome scalable web hosting system, hits launch, and is given a link to login via webbrowser to edit their site. Under the hood, the system just stood up a trove database, an elasticsearch cluster in its own network, a web tier, a load balancer etc. The user didnt have to care how hard that use to be, and just gets charged for the resources consumed. Benifiting the cloud deployer and the end user. The easier it is to use/create/consume cloud resources the better it is for the deployer. If a bit steaper learning curve up front is nessisary, that sucks, but will be worth it. This sort of thing is what we need to get to, and is extremely difficult if OpenStack clouds differ wildly in functionality. Thanks, Kevin From: Salvatore Orlando Sent: Friday, April 17, 2015 8:45:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] And since we've circled back I might add that perhaps we want nova-network to deliver that. Simple, reliable networking leveraging well-established off-the-shelf technologies that satisfies the use cases Jeremy is referring to. If regardless of changes in governance pertaining openstack project the consensus is still that nova-network functionalities should be performed by neutron under the same assumptions, then what Kevin is suggesting goes in the right direction, regardless of whether the deployer chooses linux bridge, OVS, or some fancy advanced technology like [1]. However, there's more than that. For instance ask the average user that just wants connectivity whether they think creating a router or pointing a floating ip to a port should be part of their workflow. You can figure out the answer by yourself. I had a chat with Sean Dague a few day back on IRC [2]. The point seems that when neutron is deployed as a replacement for nova-network it should provide defaults that provide a replacement for nova-network flatdhcp networking mode. For instance this would be a shared network, a single router, and a single external network (the floating IP pool). If multi-host is required that single router should be distributed (and perhaps one day neutron will distribute SNAT too). Router distribution with linux bridge might be a problem with the current framework, where we're insisting on supporting nova-network scenario using neutron's control plane constructs which have been conceived for multi-tenancy and self service networking. And then there's the API usability perspective. But if we provide default for neutron resources then the problem is probably solved as users will have little to no interaction with the neutron API. Salvatore [1] https://github.com/salv-orlando/hdn [2] http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-04-15.log from 2015-04-15T13:26:55 On 17 April 2015 at 17:22, Jeremy Stanley fu...@yuggoth.orgmailto:fu...@yuggoth.org wrote: On 2015-04-16 21:17:03 -0700 (-0700), Kevin Benton wrote: What do you disagree with? I was pointing out that using Linux bridge will not reduce the complexity of the model of self-service networking, which is what the quote was complaining about. On the contrary, if you reread the message to which you were previously replying, it's was about the unnecessary complexity of OVS (and Neutron in general) for deployments which explicitly _don't_ need and can never take advantage of self-service networking. The implication being that Neutron needs a just connect everything to a simple flat network on a bridge I can easily debug mode which hides or eliminates those complexities instead. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. I'm sorry, but with all due respect - I believe that sounds very much like sticking fingers in ears and not paying attention to the very real needs of users. Let me tell you some non-features I encounter currently: - Needing Floating IPs to get a public address This is touted as the right way to do it - but it's actually a terrible experience for a user. The clouds I have access to that just give me a direct DHCP address are much more useful. In fact, we should delete floating ips - they are a non-feature that make life harder. Literally no user of a cloud has ever wanted them, although we've learned to deal with them. - SDN I understand this is important for people, so let's keep it around - but having software routers essentially means that it's a scaling bottleneck. In the cloud Infra uses that has SDN, we have to create multiple software routers to handle the scaling issues. On the other hand, direct routing / linuxbridge does NOT have this problem, because the network packets are routed directly. We should not delete SDN like we should delete floating IPs, because there are real users who have real uses cases and SDN helps them. However, it should be an opt-in feature for a user that is an add on. vexxhost is getting this right right now - you automatically get a DHCP'd direct routed IP on each VM you provision, but if you decide you need fancy, you can opt in to create a private network. - DVR I'm an end user. I do not care about this at all. DVR is only important if you have bought in to software routers. It's a solution to a problem that would go away if things worked like networks. :/ So is keeping nova-network around forever. :/ But other then requiring some more training for ops folks, I think Neutron can suit the rest of the use cases these days nova-network provided over neutron. The sooner we can put the nova-network issue to bed, the better off the ecosystem will be. It will take a couple of years for the ecosystem to settle out to deprecating it, since a lot of clouds take years to upgrade and finally put the issue to bed. Lets do that sooner rather then later so a couple of years from now, we're done. :/ I'm about to deploy a cloud, I'm going to run neutron, and I'm not going to run openvswitch because I do not need it. I will run the equiv of flatdhcp. If neutron doesn't have it, I will write it, because it's that important that it exist. If you take that ability away from me, you will be removing working feature and replacing them with things that make my user experience worse. Let's not do that. Let's listen to the people who are using this thing as end users. Let's understand their experience and frustration. And let's not chase pie-in-the-sky theory of how it should work in the face of what a ton of people are asking and even begging for. FlatDHCP is perfect for the 80% case. The extra complexity of the additional things if you don't actually need them is irresponsible. [Rockyg] Kevin, the problem is that the extra features *aren't* critical to the deployers and/or users of many of openstack deployments. And since they are not critical, the deployers won't *move* to using neutron that requires them to learn all this new stuff that thjey don't need. By not providing a simple path to a flatDHCP implementation, you will get existing users refusing to upgrade rather than take a bunch of extraneous stuff from Neutron because the OpenStack project deprecated their network. So, likely two things will happen: 1) the deployments that are already you there configured with nova-network and flatDHCP will stop upgrading with the last nova-network release and 2) if there isn't a simple equivalent by then in neutron or some other openstack project, someone will fork to keep the flatDHCP solution moving forward. You can lead a devops to pizza,
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On Apr 17, 2015, at 8:53 PM, Monty Taylor mord...@inaugust.com wrote: On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. I'm sorry, but with all due respect - I believe that sounds very much like sticking fingers in ears and not paying attention to the very real needs of users. Let me tell you some non-features I encounter currently: - Needing Floating IPs to get a public address This is touted as the right way to do it - but it's actually a terrible experience for a user. The clouds I have access to that just give me a direct DHCP address are much more useful. Is there a reason that neutron “provider” networks won’t work for you? That exact use case is covered, with neutron providing dhcp and metadata, and the underlying physical network doing everything else. If that physical network is directly routable, so are your VMs. No need for fips or NAT. In fact, we should delete floating ips - they are a non-feature that make life harder. Literally no user of a cloud has ever wanted them, although we've learned to deal with them. - SDN I understand this is important for people, so let's keep it around - but having software routers essentially means that it's a scaling bottleneck. In the cloud Infra uses that has SDN, we have to create multiple software routers to handle the scaling issues. On the other hand, direct routing / linuxbridge does NOT have this problem, because the network packets are routed directly. We should not delete SDN like we should delete floating IPs, because there are real users who have real uses cases and SDN helps them. However, it should be an opt-in feature for a user that is an add on. vexxhost is getting this right right now - you automatically get a DHCP'd direct routed IP on each VM you provision, but if you decide you need fancy, you can opt in to create a private network. The SDN-lite tenant networks can co-exist with provider networks, so it’s not an either/or. - DVR I'm an end user. I do not care about this at all. DVR is only important if you have bought in to software routers. It's a solution to a problem that would go away if things worked like networks. I don’t think this is even an issue if you’re not using neutron routers. Thanks, doug :/ So is keeping nova-network around forever. :/ But other then requiring some more training for ops folks, I think Neutron can suit the rest of the use cases these days nova-network provided over neutron. The sooner we can put the nova-network issue to bed, the better off the ecosystem will be. It will take a couple of years for the ecosystem to settle out to deprecating it, since a lot of clouds take years to upgrade and finally put the issue to bed. Lets do that sooner rather then later so a couple of years from now, we're done. :/ I'm about to deploy a cloud, I'm going to run neutron, and I'm not going to run openvswitch because I do not need it. I will run the equiv of flatdhcp. If neutron doesn't have it, I will write it, because it's that important that it exist. If you take that ability away from me, you will be removing working feature and replacing them with things that make my user experience worse. Let's not do that. Let's listen to the people who are using this thing as end users. Let's understand their experience and frustration. And let's not chase pie-in-the-sky theory of how it should work in the face of what a ton of people are asking and even begging for. FlatDHCP is perfect for the 80% case. The extra complexity of the additional things if you don't actually need them is irresponsible. [Rockyg] Kevin, the problem is that the extra features *aren't* critical to the deployers and/or users of many of openstack deployments. And since they are not critical, the deployers won't *move* to using neutron that requires them to learn all this new stuff that
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? I'd be much more in favor of it. yes. Though I think its a long way from being there... planet openstack has a nice set of articles on how dvr works right now, and having read through, I think its going to be very difficult to implement that way with linuxbridge. It uses flow tables pretty heavily. LinuxBridge has nothing like that as far as I know. Because of that, I would expect that as DVR matures, the LinuxBridge implementation will wither further on the vine. :/ Just my 2 cents. Ops will probably need to consider the complexity necessary, just like the linux kernel is complex but in the end, the complexity is well worth it. To get a truly scalable NaaS, which I think is critical, you need advanced SDN and I'm not convinced LinuxBridge is advanced enough to work long term... Thanks, Kevin From: Tom Fifield [t...@openstack.org] Sent: Wednesday, April 15, 2015 7:09 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 16/04/15 10:54, Fox, Kevin M wrote: Yes, but if stuff like dvr is the only viable replacement to nova-network in production, then learning the non representitive config of neutron with linuxbridge might be misleading/counter productive since ovs looks very very different. Sure, though on the other hand, doesn't current discussion seem to indicate that OVS with DVR is not a viable replacement for nova-network multi-host HA (eg due to complexity), and this is why folks were working towards linux bridge? In essence: if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? Kevin * * *From:* Tom Fifield *Sent:* Wednesday, April 15, 2015 5:58:43 PM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 14/04/15 23:36, Dean Troyer wrote: On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... So, ummm, there is actually a valid use case for ops on devstack: it's part of the learning process. In my rounds, I've had feedback from more than a few whose first OpenStack experience was to run up a devstack, so they could run ps aufx, brctl, iptables, etc just to see what was going on under the covers before moving on to something more 'proper'. While acknowledging that the primary purpose and audience of devstack is and should remain development and developers, if there is something we can do to improve the experience for those ops first-timers that doesn't have a huge impact on devs, it would be kinda nice. After all, one of the reasons this thread exists is because of problems with that ramp up process, no? I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. +1 But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). Changing DevStack's default doesn't remove anything OVS-related, nor does it by itself remove any OVS jobs. It gives everyone who is happy with nova-net (or more correctly doesn't think about it) a new default that changes their experience the least for when nova-net disappears. dt -- Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com __ 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
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Just to be clear, we are talking about two different cases of complexity. The biggest disconnect in the model seems to be that Neutron assumes you want self service networking. Most of these deploys don't. Or even more importantly, they live in an organization where that is never going to be an option. This is referring to the complexity of the API model for Neutron. While this is a problem that I hope to address by making things like shared networks more useful, it's not really relevant to this particular discussion because the model complexity does not decrease with the switch to Linux bridge. On Thu, Apr 16, 2015 at 5:30 PM, Tom Fifield t...@openstack.org wrote: On 17/04/15 03:09, Assaf Muller wrote: - Original Message - if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? I'd be much more in favor of it. yes. Though I think its a long way from being there... planet openstack has a nice set of articles on how dvr works right now, Thank you :) and having read through, I think its going to be very difficult to implement that way with linuxbridge. It uses flow tables pretty heavily. LinuxBridge has nothing like that as far as I know. To be brutally honest I think that any solution that tries to implement DVR with Linux bridge will be shot down by the Neutron community. We're already struggling to maintain DVR, polish it and have it well tested. Adding more complexity seems outright insane to me and I suspect that others will share the sentiment. Because of that, I would expect that as DVR matures, the LinuxBridge implementation will wither further on the vine. :/ Just my 2 cents. Ops will probably need to consider the complexity necessary, just like the linux kernel is complex but in the end, the complexity is well worth it. That's what Neutron developers are likely to say. ... and so we go around in the circle again, because: The biggest disconnect in the model seems to be that Neutron assumes you want self service networking. Most of these deploys don't. Or even more importantly, they live in an organization where that is never going to be an option. http://lists.openstack.org/pipermail/openstack-dev/2015-March/058801.html So, if ops don't need and/or can't use the features the additional complexity provides, there's no way they'll consider the complexity necessary, and will keep using nova-network :) In addition - we kinda have part of our mission statement that has the words simple to implement, so it's very rarely OK to say just eat up the complexity, kthxbai. To get a truly scalable NaaS, which I think is critical, you need advanced SDN and I'm not convinced LinuxBridge is advanced enough to work long term... Thanks, Kevin From: Tom Fifield [t...@openstack.org] Sent: Wednesday, April 15, 2015 7:09 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 16/04/15 10:54, Fox, Kevin M wrote: Yes, but if stuff like dvr is the only viable replacement to nova-network in production, then learning the non representitive config of neutron with linuxbridge might be misleading/counter productive since ovs looks very very different. Sure, though on the other hand, doesn't current discussion seem to indicate that OVS with DVR is not a viable replacement for nova-network multi-host HA (eg due to complexity), and this is why folks were working towards linux bridge? In essence: if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? Kevin * * *From:* Tom Fifield *Sent:* Wednesday, April 15, 2015 5:58:43 PM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 14/04/15 23:36, Dean Troyer wrote: On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... So, ummm, there is actually a valid use case for ops on devstack: it's part of the learning process. In my rounds, I've had feedback from more than a few whose first OpenStack experience was to run up a devstack, so they could run ps aufx, brctl, iptables, etc just to see what was going on under the covers before moving on to something more 'proper'. While acknowledging that the primary purpose and audience of devstack is and should remain development and developers, if there is something we can do to improve the experience for those ops first-timers that
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 2015-04-16 18:34:40 -0700 (-0700), Kevin Benton wrote: [...] This is referring to the complexity of the API model for Neutron. While this is a problem that I hope to address by making things like shared networks more useful, it's not really relevant to this particular discussion because the model complexity does not decrease with the switch to Linux bridge. I disagree. Complexity for the operator includes more than the API. It also includes troubleshooting what just went wrong when your network decided to do a headstand. As a datapoint, compare the ease of connecting tcpdump to a bridge interface vs the ease of connecting tcpdump to an OVS instance. -- Jeremy Stanley __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 17/04/15 03:09, Assaf Muller wrote: - Original Message - if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? I'd be much more in favor of it. yes. Though I think its a long way from being there... planet openstack has a nice set of articles on how dvr works right now, Thank you :) and having read through, I think its going to be very difficult to implement that way with linuxbridge. It uses flow tables pretty heavily. LinuxBridge has nothing like that as far as I know. To be brutally honest I think that any solution that tries to implement DVR with Linux bridge will be shot down by the Neutron community. We're already struggling to maintain DVR, polish it and have it well tested. Adding more complexity seems outright insane to me and I suspect that others will share the sentiment. Because of that, I would expect that as DVR matures, the LinuxBridge implementation will wither further on the vine. :/ Just my 2 cents. Ops will probably need to consider the complexity necessary, just like the linux kernel is complex but in the end, the complexity is well worth it. That's what Neutron developers are likely to say. ... and so we go around in the circle again, because: The biggest disconnect in the model seems to be that Neutron assumes you want self service networking. Most of these deploys don't. Or even more importantly, they live in an organization where that is never going to be an option. http://lists.openstack.org/pipermail/openstack-dev/2015-March/058801.html So, if ops don't need and/or can't use the features the additional complexity provides, there's no way they'll consider the complexity necessary, and will keep using nova-network :) In addition - we kinda have part of our mission statement that has the words simple to implement, so it's very rarely OK to say just eat up the complexity, kthxbai. To get a truly scalable NaaS, which I think is critical, you need advanced SDN and I'm not convinced LinuxBridge is advanced enough to work long term... Thanks, Kevin From: Tom Fifield [t...@openstack.org] Sent: Wednesday, April 15, 2015 7:09 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 16/04/15 10:54, Fox, Kevin M wrote: Yes, but if stuff like dvr is the only viable replacement to nova-network in production, then learning the non representitive config of neutron with linuxbridge might be misleading/counter productive since ovs looks very very different. Sure, though on the other hand, doesn't current discussion seem to indicate that OVS with DVR is not a viable replacement for nova-network multi-host HA (eg due to complexity), and this is why folks were working towards linux bridge? In essence: if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? Kevin * * *From:* Tom Fifield *Sent:* Wednesday, April 15, 2015 5:58:43 PM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 14/04/15 23:36, Dean Troyer wrote: On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... So, ummm, there is actually a valid use case for ops on devstack: it's part of the learning process. In my rounds, I've had feedback from more than a few whose first OpenStack experience was to run up a devstack, so they could run ps aufx, brctl, iptables, etc just to see what was going on under the covers before moving on to something more 'proper'. While acknowledging that the primary purpose and audience of devstack is and should remain development and developers, if there is something we can do to improve the experience for those ops first-timers that doesn't have a huge impact on devs, it would be kinda nice. After all, one of the reasons this thread exists is because of problems with that ramp up process, no? I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. +1 But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). Changing DevStack's default doesn't remove anything OVS-related, nor does it by itself remove any OVS jobs. It gives everyone who is happy
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
What do you disagree with? I was pointing out that using Linux bridge will not reduce the complexity of the model of self-service networking, which is what the quote was complaining about. I just wanted to point out that one of the 'major disconnects' as I understand it will not get any better by switching drivers. On 2015-04-16 18:34:40 -0700 (-0700), Kevin Benton wrote: [...] This is referring to the complexity of the API model for Neutron. While this is a problem that I hope to address by making things like shared networks more useful, it's not really relevant to this particular discussion because the model complexity does not decrease with the switch to Linux bridge. I disagree. Complexity for the operator includes more than the API. It also includes troubleshooting what just went wrong when your network decided to do a headstand. As a datapoint, compare the ease of connecting tcpdump to a bridge interface vs the ease of connecting tcpdump to an OVS instance. -- Jeremy Stanley __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
- Original Message - if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? I'd be much more in favor of it. yes. Though I think its a long way from being there... planet openstack has a nice set of articles on how dvr works right now, Thank you :) and having read through, I think its going to be very difficult to implement that way with linuxbridge. It uses flow tables pretty heavily. LinuxBridge has nothing like that as far as I know. To be brutally honest I think that any solution that tries to implement DVR with Linux bridge will be shot down by the Neutron community. We're already struggling to maintain DVR, polish it and have it well tested. Adding more complexity seems outright insane to me and I suspect that others will share the sentiment. Because of that, I would expect that as DVR matures, the LinuxBridge implementation will wither further on the vine. :/ Just my 2 cents. Ops will probably need to consider the complexity necessary, just like the linux kernel is complex but in the end, the complexity is well worth it. That's what Neutron developers are likely to say. To get a truly scalable NaaS, which I think is critical, you need advanced SDN and I'm not convinced LinuxBridge is advanced enough to work long term... Thanks, Kevin From: Tom Fifield [t...@openstack.org] Sent: Wednesday, April 15, 2015 7:09 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 16/04/15 10:54, Fox, Kevin M wrote: Yes, but if stuff like dvr is the only viable replacement to nova-network in production, then learning the non representitive config of neutron with linuxbridge might be misleading/counter productive since ovs looks very very different. Sure, though on the other hand, doesn't current discussion seem to indicate that OVS with DVR is not a viable replacement for nova-network multi-host HA (eg due to complexity), and this is why folks were working towards linux bridge? In essence: if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? Kevin * * *From:* Tom Fifield *Sent:* Wednesday, April 15, 2015 5:58:43 PM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 14/04/15 23:36, Dean Troyer wrote: On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... So, ummm, there is actually a valid use case for ops on devstack: it's part of the learning process. In my rounds, I've had feedback from more than a few whose first OpenStack experience was to run up a devstack, so they could run ps aufx, brctl, iptables, etc just to see what was going on under the covers before moving on to something more 'proper'. While acknowledging that the primary purpose and audience of devstack is and should remain development and developers, if there is something we can do to improve the experience for those ops first-timers that doesn't have a huge impact on devs, it would be kinda nice. After all, one of the reasons this thread exists is because of problems with that ramp up process, no? I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. +1 But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). Changing DevStack's default doesn't remove anything OVS-related, nor does it by itself remove any OVS jobs. It gives everyone who is happy with nova-net (or more correctly doesn't think about it) a new default that changes their experience the least for when nova-net disappears. dt -- Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com __ 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
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On Wed, Apr 15, 2015 at 10:09:24PM EDT, Tom Fifield wrote: On 16/04/15 10:54, Fox, Kevin M wrote: Yes, but if stuff like dvr is the only viable replacement to nova-network in production, then learning the non representitive config of neutron with linuxbridge might be misleading/counter productive since ovs looks very very different. Sure, though on the other hand, doesn't current discussion seem to indicate that OVS with DVR is not a viable replacement for nova-network multi-host HA (eg due to complexity), and this is why folks were working towards linux bridge? Before we get sidetracked too far into the OVS vs. Linux Bridge bikeshed, let's reflect on the fact that DVR is *not* enabled by default in DevStack. Nor is nova-network's multi_host enabled by default. So in all cases, someone looking at the innards of Nova-Network or Neutron or looking to create a production-like DevStack will be consulting documentation for configuration details. -- 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
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 14/04/15 23:36, Dean Troyer wrote: On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... So, ummm, there is actually a valid use case for ops on devstack: it's part of the learning process. In my rounds, I've had feedback from more than a few whose first OpenStack experience was to run up a devstack, so they could run ps aufx, brctl, iptables, etc just to see what was going on under the covers before moving on to something more 'proper'. While acknowledging that the primary purpose and audience of devstack is and should remain development and developers, if there is something we can do to improve the experience for those ops first-timers that doesn't have a huge impact on devs, it would be kinda nice. After all, one of the reasons this thread exists is because of problems with that ramp up process, no? I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. +1 But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). Changing DevStack's default doesn't remove anything OVS-related, nor does it by itself remove any OVS jobs. It gives everyone who is happy with nova-net (or more correctly doesn't think about it) a new default that changes their experience the least for when nova-net disappears. dt -- Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On Wed, Apr 15, 2015 at 7:58 PM, Tom Fifield t...@openstack.org wrote: If they do they need more help than we can give... So, ummm, there is actually a valid use case for ops on devstack: it's part of the learning process. Yes, this is very true. The context in my mind included the not-present-above phrase in production. In my rounds, I've had feedback from more than a few whose first OpenStack experience was to run up a devstack, so they could run ps aufx, brctl, iptables, etc just to see what was going on under the covers before moving on to something more 'proper'. I hear this too, and do not want to discourage those use cases. However, there is little real guidance on what parts of DevStack are representative of a production deployment and what parts should not be replicated. DevStack's use of sudo, for example, is one of those places that would be a huge security issue in any real deployment. While acknowledging that the primary purpose and audience of devstack is and should remain development and developers, if there is something we can do to improve the experience for those ops first-timers that doesn't have a huge impact on devs, it would be kinda nice. So I would be interested in hearing ideas on this topic. One of the reasons DevStack is (still) written in shell script is that we always felt it was easier to demonstrate how the pieces fit together that way. dt -- Dean Troyer dtro...@gmail.com __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Yes, but if stuff like dvr is the only viable replacement to nova-network in production, then learning the non representitive config of neutron with linuxbridge might be misleading/counter productive since ovs looks very very different. Kevin From: Tom Fifield Sent: Wednesday, April 15, 2015 5:58:43 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 14/04/15 23:36, Dean Troyer wrote: On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... So, ummm, there is actually a valid use case for ops on devstack: it's part of the learning process. In my rounds, I've had feedback from more than a few whose first OpenStack experience was to run up a devstack, so they could run ps aufx, brctl, iptables, etc just to see what was going on under the covers before moving on to something more 'proper'. While acknowledging that the primary purpose and audience of devstack is and should remain development and developers, if there is something we can do to improve the experience for those ops first-timers that doesn't have a huge impact on devs, it would be kinda nice. After all, one of the reasons this thread exists is because of problems with that ramp up process, no? I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. +1 But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). Changing DevStack's default doesn't remove anything OVS-related, nor does it by itself remove any OVS jobs. It gives everyone who is happy with nova-net (or more correctly doesn't think about it) a new default that changes their experience the least for when nova-net disappears. dt -- Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 16/04/15 10:54, Fox, Kevin M wrote: Yes, but if stuff like dvr is the only viable replacement to nova-network in production, then learning the non representitive config of neutron with linuxbridge might be misleading/counter productive since ovs looks very very different. Sure, though on the other hand, doesn't current discussion seem to indicate that OVS with DVR is not a viable replacement for nova-network multi-host HA (eg due to complexity), and this is why folks were working towards linux bridge? In essence: if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? Kevin * * *From:* Tom Fifield *Sent:* Wednesday, April 15, 2015 5:58:43 PM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 14/04/15 23:36, Dean Troyer wrote: On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... So, ummm, there is actually a valid use case for ops on devstack: it's part of the learning process. In my rounds, I've had feedback from more than a few whose first OpenStack experience was to run up a devstack, so they could run ps aufx, brctl, iptables, etc just to see what was going on under the covers before moving on to something more 'proper'. While acknowledging that the primary purpose and audience of devstack is and should remain development and developers, if there is something we can do to improve the experience for those ops first-timers that doesn't have a huge impact on devs, it would be kinda nice. After all, one of the reasons this thread exists is because of problems with that ramp up process, no? I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. +1 But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). Changing DevStack's default doesn't remove anything OVS-related, nor does it by itself remove any OVS jobs. It gives everyone who is happy with nova-net (or more correctly doesn't think about it) a new default that changes their experience the least for when nova-net disappears. dt -- Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Sure, though on the other hand, doesn't current discussion seem to indicate that OVS with DVR is not a viable replacement for nova-network multi-host HA (eg due to complexity), and this is why folks were working towards linux bridge? Some openstacker doesn’t believe ovs performance is higher than linuxbridge. So they don’t want to use OVS. Surely old OVS has many performance problems. Currently, the problems almost might be solved. But they aren’t sure about it. If that is a point of the discussion, we should show it to them. In any case, we need to know why do they prefer linuxbridge rather than OVS. Hirofumi On 2015/04/16, at 11:09, Tom Fifield t...@openstack.org wrote: On 16/04/15 10:54, Fox, Kevin M wrote: Yes, but if stuff like dvr is the only viable replacement to nova-network in production, then learning the non representitive config of neutron with linuxbridge might be misleading/counter productive since ovs looks very very different. Sure, though on the other hand, doesn't current discussion seem to indicate that OVS with DVR is not a viable replacement for nova-network multi-host HA (eg due to complexity), and this is why folks were working towards linux bridge? In essence: if linux bridge was a viable nova-network multi-host HA replacement, you'd be OK with this change? Kevin * * *From:* Tom Fifield *Sent:* Wednesday, April 15, 2015 5:58:43 PM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 14/04/15 23:36, Dean Troyer wrote: On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... So, ummm, there is actually a valid use case for ops on devstack: it's part of the learning process. In my rounds, I've had feedback from more than a few whose first OpenStack experience was to run up a devstack, so they could run ps aufx, brctl, iptables, etc just to see what was going on under the covers before moving on to something more 'proper'. While acknowledging that the primary purpose and audience of devstack is and should remain development and developers, if there is something we can do to improve the experience for those ops first-timers that doesn't have a huge impact on devs, it would be kinda nice. After all, one of the reasons this thread exists is because of problems with that ramp up process, no? I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. +1 But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). Changing DevStack's default doesn't remove anything OVS-related, nor does it by itself remove any OVS jobs. It gives everyone who is happy with nova-net (or more correctly doesn't think about it) a new default that changes their experience the least for when nova-net disappears. dt -- Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com __ 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 __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On 10/4/2015, at 20:10, Kyle Mestery mest...@mestery.com wrote: On Fri, Apr 10, 2015 at 1:03 PM, Sean M. Collins s...@coreitpro.com mailto:s...@coreitpro.com wrote: We already tried to make Neutron the default with OVS - and the results were not good[1]. Operators who are currently not using Neutron have said that they do not want to learn both Neutron and also Open vSwitch at the same time. This was documented at the operator's summit. We clearly have a stumbling block - Open vSwitch. https://etherpad.openstack.org/p/PHL-ops-nova-feedback https://etherpad.openstack.org/p/PHL-ops-nova-feedback https://etherpad.openstack.org/p/PHL-ops-OVS https://etherpad.openstack.org/p/PHL-ops-OVS Based on discussions we had at the QA sprint, the idea is to start with a very simple Neutron configuration in DevStack, so that we can remove nova-network as the default. The argument is that the people who are still using nova-network are comfortable with Linux Bridge, and that having Linux Bridge as the default Neutron agent will serve as a bridge (no pun intended) into the Neutron world. There will be *clear* documentation that this is a very simplistic model, and it will be made obvious that for more advanced scenarios you will need to configure your local.conf to use the Open vSwitch agent. I've spoken with Sean Dague about testing Linux Bridge and the idea is that we should have test coverage of both OVS and Linux Bridge, and that currently there is a gap with Linux Bridge. I think that it's OK if we override the default at the gate to run OVS, since that has the most test coverage and will cause the least disruption. There will be jobs created, that will test Linux Bridge similar to how Open vSwitch is tested at the gate today. As a DevStack user, I would like to see Neutron as the default. After making Neutron the default, the changes needed for the local.conf file for me to run my mechanism driver of choice is significantly smaller than the changes needed today for my local.conf/localrc to disable Nova-Network, enable Neutron, and run my mechanism driver of choice. If Linux Bridge being the default is the way to make the above happen, so be it. ++, well said Sean. I support what's being done here. [1]: https://review.openstack.org/#/c/153208/ https://review.openstack.org/#/c/153208/ -1 ;) Why would operators install from devstack? that’s not going to be the case. I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). -- Sean M. Collins __ 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 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 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Miguel Angel Ajo __ 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On Tue, Apr 14, 2015 at 9:36 AM, Dean Troyer dtro...@gmail.com wrote: On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. +1 But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). Changing DevStack's default doesn't remove anything OVS-related, nor does it by itself remove any OVS jobs. It gives everyone who is happy with nova-net (or more correctly doesn't think about it) a new default that changes their experience the least for when nova-net disappears. I think you summed it up quite eloquently Dean. And this is why we'll do our best to revive the LB support in Neutron during Liberty. Thanks, Kyle dt -- Dean Troyer dtro...@gmail.com __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Why would operators install from devstack? that’s not going to be the case. If they do they need more help than we can give... I believe we should have both LB OVS well tested, if LB is a good option for some operators willing to migrate from nova, that’s great, let’s make sure LB is perfectly tested upstream. +1 But by doing such change we can’t let OVS code rot and we would be neglecting a big customer base which is now making use of the openvswitch mechanism. (may be I’m miss understanding the scope of the change). Changing DevStack's default doesn't remove anything OVS-related, nor does it by itself remove any OVS jobs. It gives everyone who is happy with nova-net (or more correctly doesn't think about it) a new default that changes their experience the least for when nova-net disappears. dt -- Dean Troyer dtro...@gmail.com __ 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
On Wed, Apr 01, 2015 at 01:37:28AM EDT, Dr. Jens Rosenboom wrote: FWIW, I think I made some progress in getting [1] to work, though if someone could jump in and make a proper patch from my hack, that would be great. [1] https://review.openstack.org/168423 Hi, Just wanted to write a quick status update and publicly thank Dr. Rosenboom. We are making excellent progress, and a majority of tests at the gate are passing for Linuxbridge as the default in DevStack. -- 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
