Re: [Openstack-operators] Potential updates to networking guide deployment scenarios
James, >From a configuration standpoint, option one only requires adding the public network to each compute node and some bridge/interface mapping changes. However, the diagrams and traffic flows become more complex. I could split the latter into two categories depending on whether a VM attaches to a public or private network. Option two requires completely duplicating at least the legacy OVS and legacy Linux bridge scenarios. The L3HA OVS and L3HA Linux bridge scenarios also currently only support private networks, but L3HA only applies to private networks with routers, so L3HA with only public networks makes no sense to document. In this particular case, mostly because L3HA essentially builds on the legacy scenarios, we could use option one for them with the assumption that our audience already understands the legacy concepts. A high-level comparison makes sense... perhaps using a table? However, we need to make it as objective as possible. For example, the guide currently limits the legacy OVS scenario to only support attaching VMs to private networks, but one can easily add support for attaching VMs to public networks to any scenario. Also, DVR+L3HA become possible. Legacy means no HA for private networks and/or routers. We originally decided to use the word "legacy" to push HA architectures for new deployments, but a variety of bugs with DVR and L3HA during the first few release cycles limited adoption. I think we should change it to conventional, classic, or some other phrasing to indicate lack of HA for private networks and/or routers. On Tue, Dec 8, 2015 at 7:33 PM, James Dempsey wrote: > Hi Matt, > > Commentary in-line. > > On 05/12/15 14:03, Matt Kassawara wrote: > > The networking guide [1] contains deployment scenarios [2] that describe > > the operation of several common OpenStack Networking (neutron) > > architectures including functional configuration examples. > > > > Currently, the legacy and L3HA scenarios [3][4][5][6] only support > > attaching VMs to private/internal/project networks (managed by projects) > > with a combination of routers and floating IPs that provide connectivity > to > > external networks such as the Internet. However, L3 support regardless of > > architecture adds complexity and can introduce redundancy/performance > > concerns. > > > > On the other hand, the provider networks scenarios [7][8] only support > > attaching VMs to public/external/provider networks (managed by > > administrators) and exclude components such as private networks, routers, > > and floating IPs. > > > > Turns out... you can do both. In fact, the installation guide for Liberty > > [9] supports attaching VMs to both public and private networks. No > choosing > > between the simplicity of provider networks and the "self-service" nature > > of true cloud networking in your deployment. > > > > So, I propose that we update the legacy and L3HA scenarios in the > > networking guide to support attaching VMs to both public and private > > networks using one of the following options: > > > > 1) Add support for attaching VMs to public networks to the existing > > scenarios. > > 2) Create additional scenarios that support attaching VMs to both public > > and private networks. > > 3) Restructure the existing scenarios by starting out with simple > provider > > networks architectures for both Open vSwitch and Linux bridge and > > optionally adding L3 support to them. The installation guide for Liberty > > uses this approach. > > > > Option 1 somewhat increases complexity of scenarios that our audience may > > already find difficult to comprehend. Option 2 proliferates the scenarios > > and makes it more difficult for our audience to choose the best one for a > > particular deployment. In addition, it can lead to duplication of content > > that becomes difficult to keep consistent. Option 3 requires a more > complex > > documentation structure that our audience may find difficult to follow. > As > > the audience, I would like your input on the usefulness of these > potential > > updates and which option works best... or add another option. > > > > > I'm not crazy about option 1 because I think it could over-complicate > the more simple scenarios. > > With respect to option 2, would you be doubling the number of documented > scenarios? > > It sounds like the provider network and "Legacy"/L3HA scenarios are > orthogonal enough that they could be separate from each other. I don't > think it is too much to ask of operators to read a couple of sections > and compose them, provided the requirements and prerequisites are clear. > > > While not specifically pertaining to the re-structure, I will make a > couple of comments about the deploy/scenario sections, if they are being > updated... > > a. I think these sections are bound to be confusing regardless of how > they are structured or re-structured. Perhaps there should be > high-level comparison of the different scenarios to help operators > decide which
Re: [Openstack-operators] Potential updates to networking guide deployment scenarios
Hi Matt, Commentary in-line. On 05/12/15 14:03, Matt Kassawara wrote: > The networking guide [1] contains deployment scenarios [2] that describe > the operation of several common OpenStack Networking (neutron) > architectures including functional configuration examples. > > Currently, the legacy and L3HA scenarios [3][4][5][6] only support > attaching VMs to private/internal/project networks (managed by projects) > with a combination of routers and floating IPs that provide connectivity to > external networks such as the Internet. However, L3 support regardless of > architecture adds complexity and can introduce redundancy/performance > concerns. > > On the other hand, the provider networks scenarios [7][8] only support > attaching VMs to public/external/provider networks (managed by > administrators) and exclude components such as private networks, routers, > and floating IPs. > > Turns out... you can do both. In fact, the installation guide for Liberty > [9] supports attaching VMs to both public and private networks. No choosing > between the simplicity of provider networks and the "self-service" nature > of true cloud networking in your deployment. > > So, I propose that we update the legacy and L3HA scenarios in the > networking guide to support attaching VMs to both public and private > networks using one of the following options: > > 1) Add support for attaching VMs to public networks to the existing > scenarios. > 2) Create additional scenarios that support attaching VMs to both public > and private networks. > 3) Restructure the existing scenarios by starting out with simple provider > networks architectures for both Open vSwitch and Linux bridge and > optionally adding L3 support to them. The installation guide for Liberty > uses this approach. > > Option 1 somewhat increases complexity of scenarios that our audience may > already find difficult to comprehend. Option 2 proliferates the scenarios > and makes it more difficult for our audience to choose the best one for a > particular deployment. In addition, it can lead to duplication of content > that becomes difficult to keep consistent. Option 3 requires a more complex > documentation structure that our audience may find difficult to follow. As > the audience, I would like your input on the usefulness of these potential > updates and which option works best... or add another option. > I'm not crazy about option 1 because I think it could over-complicate the more simple scenarios. With respect to option 2, would you be doubling the number of documented scenarios? It sounds like the provider network and "Legacy"/L3HA scenarios are orthogonal enough that they could be separate from each other. I don't think it is too much to ask of operators to read a couple of sections and compose them, provided the requirements and prerequisites are clear. While not specifically pertaining to the re-structure, I will make a couple of comments about the deploy/scenario sections, if they are being updated... a. I think these sections are bound to be confusing regardless of how they are structured or re-structured. Perhaps there should be high-level comparison of the different scenarios to help operators decide which scenario best fits their use case. Maybe even a table comparing them? b. Does 'Legacy' just mean 'No HA/DVR Routing?' I think that within the context of OpenStack Networking, it is risky to call anything aside from Nova Network 'Legacy.' It seems like a 'single L3 agent' scenario is a perfectly valid use case... It reduces complexity and cost while still letting users create whatever topology they want. Let me know if I'm reading this wrong. Cheers, James > Thanks, > Matt > > [1] http://docs.openstack.org/networking-guide/ > [2] http://docs.openstack.org/networking-guide/deploy.html > [3] http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html > [4] http://docs.openstack.org/networking-guide/scenario_legacy_lb.html > [5] http://docs.openstack.org/networking-guide/scenario_l3ha_ovs.html > [6] http://docs.openstack.org/networking-guide/scenario_l3ha_lb.html > [7] http://docs.openstack.org/networking-guide/scenario_provider_ovs.html > [8] http://docs.openstack.org/networking-guide/scenario_provider_lb.html > [9] http://docs.openstack.org/liberty/install-guide-ubuntu/ > > > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -- James Dempsey Senior Cloud Engineer Catalyst IT Limited +64 4 803 2264 -- ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Potential updates to networking guide deployment scenarios
I wish it was that easy... the external network currently only attaches to the network node. On Sat, Dec 5, 2015 at 12:15 PM, Kevin Benton wrote: > Could you maybe go with option 1 and have the part allowing tenants to > attach directly to the external network at the bottom as a separate section? > > "If you want to allow tenants to attach directly to these networks as > well, continue reading." > > Then it has one step where you mark the network as 'shared' as well and > it's done. ;) > > On Fri, Dec 4, 2015 at 5:03 PM, Matt Kassawara > wrote: > >> The networking guide [1] contains deployment scenarios [2] that describe >> the operation of several common OpenStack Networking (neutron) >> architectures including functional configuration examples. >> >> Currently, the legacy and L3HA scenarios [3][4][5][6] only support >> attaching VMs to private/internal/project networks (managed by projects) >> with a combination of routers and floating IPs that provide connectivity to >> external networks such as the Internet. However, L3 support regardless of >> architecture adds complexity and can introduce redundancy/performance >> concerns. >> >> On the other hand, the provider networks scenarios [7][8] only support >> attaching VMs to public/external/provider networks (managed by >> administrators) and exclude components such as private networks, routers, >> and floating IPs. >> >> Turns out... you can do both. In fact, the installation guide for Liberty >> [9] supports attaching VMs to both public and private networks. No choosing >> between the simplicity of provider networks and the "self-service" nature >> of true cloud networking in your deployment. >> >> So, I propose that we update the legacy and L3HA scenarios in the >> networking guide to support attaching VMs to both public and private >> networks using one of the following options: >> >> 1) Add support for attaching VMs to public networks to the existing >> scenarios. >> 2) Create additional scenarios that support attaching VMs to both public >> and private networks. >> 3) Restructure the existing scenarios by starting out with simple >> provider networks architectures for both Open vSwitch and Linux bridge and >> optionally adding L3 support to them. The installation guide for Liberty >> uses this approach. >> >> Option 1 somewhat increases complexity of scenarios that our audience may >> already find difficult to comprehend. Option 2 proliferates the scenarios >> and makes it more difficult for our audience to choose the best one for a >> particular deployment. In addition, it can lead to duplication of content >> that becomes difficult to keep consistent. Option 3 requires a more complex >> documentation structure that our audience may find difficult to follow. As >> the audience, I would like your input on the usefulness of these potential >> updates and which option works best... or add another option. >> >> Thanks, >> Matt >> >> [1] http://docs.openstack.org/networking-guide/ >> [2] http://docs.openstack.org/networking-guide/deploy.html >> [3] http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html >> [4] http://docs.openstack.org/networking-guide/scenario_legacy_lb.html >> [5] http://docs.openstack.org/networking-guide/scenario_l3ha_ovs.html >> [6] http://docs.openstack.org/networking-guide/scenario_l3ha_lb.html >> [7] http://docs.openstack.org/networking-guide/scenario_provider_ovs.html >> [8] http://docs.openstack.org/networking-guide/scenario_provider_lb.html >> [9] http://docs.openstack.org/liberty/install-guide-ubuntu/ >> >> ___ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> > > > -- > Kevin Benton > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Potential updates to networking guide deployment scenarios
Could you maybe go with option 1 and have the part allowing tenants to attach directly to the external network at the bottom as a separate section? "If you want to allow tenants to attach directly to these networks as well, continue reading." Then it has one step where you mark the network as 'shared' as well and it's done. ;) On Fri, Dec 4, 2015 at 5:03 PM, Matt Kassawara wrote: > The networking guide [1] contains deployment scenarios [2] that describe > the operation of several common OpenStack Networking (neutron) > architectures including functional configuration examples. > > Currently, the legacy and L3HA scenarios [3][4][5][6] only support > attaching VMs to private/internal/project networks (managed by projects) > with a combination of routers and floating IPs that provide connectivity to > external networks such as the Internet. However, L3 support regardless of > architecture adds complexity and can introduce redundancy/performance > concerns. > > On the other hand, the provider networks scenarios [7][8] only support > attaching VMs to public/external/provider networks (managed by > administrators) and exclude components such as private networks, routers, > and floating IPs. > > Turns out... you can do both. In fact, the installation guide for Liberty > [9] supports attaching VMs to both public and private networks. No choosing > between the simplicity of provider networks and the "self-service" nature > of true cloud networking in your deployment. > > So, I propose that we update the legacy and L3HA scenarios in the > networking guide to support attaching VMs to both public and private > networks using one of the following options: > > 1) Add support for attaching VMs to public networks to the existing > scenarios. > 2) Create additional scenarios that support attaching VMs to both public > and private networks. > 3) Restructure the existing scenarios by starting out with simple provider > networks architectures for both Open vSwitch and Linux bridge and > optionally adding L3 support to them. The installation guide for Liberty > uses this approach. > > Option 1 somewhat increases complexity of scenarios that our audience may > already find difficult to comprehend. Option 2 proliferates the scenarios > and makes it more difficult for our audience to choose the best one for a > particular deployment. In addition, it can lead to duplication of content > that becomes difficult to keep consistent. Option 3 requires a more complex > documentation structure that our audience may find difficult to follow. As > the audience, I would like your input on the usefulness of these potential > updates and which option works best... or add another option. > > Thanks, > Matt > > [1] http://docs.openstack.org/networking-guide/ > [2] http://docs.openstack.org/networking-guide/deploy.html > [3] http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html > [4] http://docs.openstack.org/networking-guide/scenario_legacy_lb.html > [5] http://docs.openstack.org/networking-guide/scenario_l3ha_ovs.html > [6] http://docs.openstack.org/networking-guide/scenario_l3ha_lb.html > [7] http://docs.openstack.org/networking-guide/scenario_provider_ovs.html > [8] http://docs.openstack.org/networking-guide/scenario_provider_lb.html > [9] http://docs.openstack.org/liberty/install-guide-ubuntu/ > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- Kevin Benton ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators