[openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
Brandon Logan
brandon.logan at RACKSPACE.COM
Thu Jan 28 04:49:04 UTC 2016
I could see it being interesting, but that would have to be something
vetted by other drivers and appliances because they may not support
that.
On Mon, 2016-01-25 at 21:37 +0000, Fox, Kevin M wrote:
> We are using a neutron v1 lb that has external to the cloud members in a lb used by a particular tenant in production. It is working well. Hoping to do the same thing once we get to Octavia+LBaaSv2.
>
> Being able to tweak the routes of the load balancer would be an interesting feature, though I don't think I'd ever need to. Maybe that should be an extension? I'm guessing a lot of lb plugins won't be able to support it at all.
>
> Thanks,
> Kevin
>
> ________________________________________
> From: Brandon Logan [brandon.logan at RACKSPACE.COM]
> Sent: Monday, January 25, 2016 1:03 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
>
> Any additional thoughts and opinions people want to share on this. I
> don't have a horse in this race as long as we don't make dangerous
> assumptions about what the user wants. So I am fine with making
> subnet_id optional.
>
> Michael, how strong would your opposition for this be?
>
> Thanks,
> Brandon
>
> On Tue, 2016-01-19 at 20:49 -0800, Stephen Balukoff wrote:
> > Michael-- I think you're assuming that adding an external subnet ID
> > means that the load balancing service will route requests to out an
> > interface with a route to said external subnet. However, the model we
> > have is actually too simple to convey this information to the load
> > balancing service. This is because while we know the member's IP and a
> > subnet to which the load balancing service should connect to
> > theoretically talk to said IP, we don't have any kind of actual
> > routing information for the IP address (like, say a default route for
> > the subnet).
> >
> >
> > Consider this not far-fetched example: Suppose a tenant wants to add a
> > back-end member which is reachable only over a VPN, the gateway for
> > which lives on a tenant internal subnet. If we had a more feature-rich
> > model to work with here, the tenant could specify the member IP, the
> > subnet containing the VPN gateway and the gateway's IP address. In
> > theory the load balancing service could add local routing rules to
> > make sure that communication to that member happens on the tenant
> > subnet and gets routed to the VPN gateway.
> >
> >
> > If we want to support this use case, then we'd probably need to add an
> > optional gateway IP parameter to the member object. (And I'd still be
> > in favor of assuming the subnet_id on the member is optional, and that
> > default routing should be used if not specified.)
> >
> >
> > Let me see if I can break down several use cases we could support with
> > this model. Let's assume the member model contains (among other
> > things) the following attributes:
> >
> >
> > ip_address (member IP, required)
> > subnet_id (member or gateway subnet, optional)
> > gateway_ip (VPN or other layer-3 gateway that should be used to access
> > the member_ip. optional)
> >
> >
> > Expected behaviors:
> >
> >
> > Scenario 1:
> > ip_address specified, subnet_id and gateway_ip are None: Load
> > balancing service assumes member IP address is reachable through
> > default routing. Appropriate for members that are not part of the
> > local cloud that are accessible from the internet.
> >
> >
> >
> > Scenario 2:
> > ip_address and subnet_id specified, gateway_ip is None: Load balancing
> > service assumes it needs an interface on subnet_id to talk directly to
> > the member IP address. Appropriate for members that live on tenant
> > networks. member_ip should exist within the subnet specified by
> > subnet_id. This is the only scenario supported under the current model
> > if we make subnet_id a required field and don't add a gateway_ip.
> >
> >
> > Scenario 3:
> > ip_address, subnet_id and gateway_ip are all specified: Load
> > balancing service assumes it needs an interface on subnet_id to talk
> > to the gateway_ip. Load balancing service should add local routing
> > rule (ie. to the host and / or local network namespace context of the
> > load balancing service itself, not necessarily to Neutron or anything)
> > to route any packets destined for member_ip to the gateway_ip.
> > gateway_ip should exist within the subnet specified by subnet_id.
> > Appropriate for members that are on the other side of a VPN links, or
> > reachable via other local routing within a tenant network or local
> > cloud.
> >
> >
> > Scenario 4:
> > ip_address and gateway_ip are specified, subnet_id is None: This is an
> > invalid configuration.
> >
> >
> > So.... what do y'all think of this? Am I smoking crack with how this
> > should work?
> >
> >
> > For what it's worth, I think the "member is on the other side of a
> > VPN" scenario is not one our customers are champing at the bit to
> > have, so I'm fine with not supporting that kind of topology if nobody
> > else wants it. I'm still in favor of making subnet_id optional, as
> > this supports both Scenarios 1 and 2 above.
> >
> >
> > Stephen
> >
> >
> >
> > On Tue, Jan 19, 2016 at 7:09 PM, Brandon Logan
> > <brandon.logan at rackspace.com> wrote:
> > So it really comes down to driver (or driver's appliance)
> > implementation. Here's some scenarios to consider:
> >
> > 1) vip on tenant network, members on tenant network
> > - if a user wants to add an external IP to this configuration,
> > how do we
> > handle that? If the subnet is optional the it just uses the
> > default
> > routing, then it won't ever get external unless the backend
> > implementation sets up routing to external from the load
> > balancer. I
> > think this is a bad idea because the tenant would probably
> > want these
> > networks isolated. But if the backend puts a load balancer on
> > it with
> > external connectivity, its not as isolated as it was. So to
> > me, if
> > subnet is optional the best choice is to do default routing
> > which
> > *SHOULD* fail on default routing. This of course is
> > something a tenant
> > will have to realize. The good thing about a required
> > subnet_id is that
> > the tenant has explicitly stated they wanted external
> > connectivity and
> > the backend is not making assumptions as to whether they want
> > it or
> > don't.
> >
> > 2) vip on public network, members on tenant network
> > - defaults route should be able to route out to external IPs
> > now so if
> > subnet_id is optional it works. If subnet_id is required then
> > the
> > tenant would have to specify the public network again, which
> > is less
> > than ideal and also has other issues brought up in this
> > thread.
> >
> > All other scenario permutations are similar to the above ones
> > so I don't
> > think i need to go through them.
> >
> > Basically, I'm waffling on this and am currently on the
> > optional
> > subnet_id side but as the builders of octavia, I don't think
> > we should
> > allow a load balancer external access unless the tenant has in
> > a way
> > given permission by the configuration they've explicitly set.
> > Though,
> > that too should be defined.
> >
> > Thanks,
> > Brandon
> > On Tue, 2016-01-19 at 12:07 -0700, Doug Wiegley wrote:
> > > But, by requiring an external subnet, you are assuming that
> > the packets always originate from inside a neutron network.
> > That is not necessarily the case with a physical device.
> > >
> > > doug
> > >
> > >
> > > > On Jan 19, 2016, at 11:55 AM, Michael Johnson
> > <johnsomor at gmail.com> wrote:
> > > >
> > > > I feel that the subnet should be mandatory as there are
> > too many
> > > > ambiguity issues due to overlapping subnets and multiple
> > routes.
> > > > In the case of an IP being outside of the tenant networks,
> > the user
> > > > would specify an external network that has the appropriate
> > routes. We
> > > > cannot always assume which tenant network with an external
> > (or VPN)
> > > > route is the appropriate one to use.
> > > >
> > > > Michael
> > > >
> > > > On Mon, Jan 18, 2016 at 2:45 PM, Stephen Balukoff
> > <sbalukoff at bluebox.net> wrote:
> > > >> Vivek--
> > > >>
> > > >> "Member" in this case refers to an IP address that
> > (probably) lives on a
> > > >> tenant back-end network. We can't specify just the IP
> > address when talking
> > > >> to such an IP since tenant subnets may use overlapping IP
> > ranges (ie. in
> > > >> this case, subnet is required). In the case of the
> > namespace driver and
> > > >> Octavia, we use the subnet parameter for all members to
> > determine which
> > > >> back-end networks the load balancing software needs a
> > port on.
> > > >>
> > > >> I think the original use case for making subnet optional
> > was the idea that
> > > >> sometimes a tenant would like to add a "member" IP that
> > is not part of their
> > > >> tenant networks at all-- this is more than likely an IP
> > address that lives
> > > >> outside the local cloud. The assumption, then, would be
> > that this IP address
> > > >> should be reachable through standard routing from
> > wherever the load balancer
> > > >> happens to live on the network. That is to say, the load
> > balancer will try
> > > >> to get to such an IP address via its default gateway,
> > unless it has a more
> > > >> specific route.
> > > >>
> > > >> As far as I'm aware, this use case is still valid and
> > being asked for by
> > > >> tenants. Therefore, I'm in favor of making member subnet
> > optional.
> > > >>
> > > >> Stephen
> > > >>
> > > >> On Mon, Jan 18, 2016 at 11:14 AM, Jain, Vivek
> > <VIVEKJAIN at ebay.com> wrote:
> > > >>>
> > > >>> If member port (IP address) is allocated by neutron,
> > then why do we need
> > > >>> to specify it explicitly? It can be derived by LBaaS
> > driver implicitly.
> > > >>>
> > > >>> Thanks,
> > > >>> Vivek
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 1/17/16, 1:05 AM, "Samuel Bercovici"
> > <SamuelB at Radware.com> wrote:
> > > >>>
> > > >>>> Btw.
> > > >>>>
> > > >>>> I am still in favor on associating the subnets to the
> > LB and then not
> > > >>>> specify them per node at all.
> > > >>>>
> > > >>>> -Sam.
> > > >>>>
> > > >>>>
> > > >>>> -----Original Message-----
> > > >>>> From: Samuel Bercovici [mailto:SamuelB at Radware.com]
> > > >>>> Sent: Sunday, January 17, 2016 10:14 AM
> > > >>>> To: OpenStack Development Mailing List (not for usage
> > questions)
> > > >>>> Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia]
> > Should subnet be
> > > >>>> optional on member create?
> > > >>>>
> > > >>>> +1
> > > >>>> Subnet should be mandatory
> > > >>>>
> > > >>>> The only thing this makes supporting load balancing
> > servers which are not
> > > >>>> running in the cloud more challenging to support.
> > > >>>> But I do not see this as a huge user story (lb in cloud
> > load balancing
> > > >>>> IPs outside the cloud)
> > > >>>>
> > > >>>> -Sam.
> > > >>>>
> > > >>>> -----Original Message-----
> > > >>>> From: Brandon Logan
> > [mailto:brandon.logan at RACKSPACE.COM]
> > > >>>> Sent: Saturday, January 16, 2016 6:56 AM
> > > >>>> To: openstack-dev at lists.openstack.org
> > > >>>> Subject: [openstack-dev] [Neutron][LBaaS][Octavia]
> > Should subnet be
> > > >>>> optional on member create?
> > > >>>>
> > > >>>> I filed a bug [1] a while ago that subnet_id should be
> > an optional
> > > >>>> parameter for member creation. Currently it is
> > required. Review [2] is
> > > >>>> makes it optional.
> > > >>>>
> > > >>>> The original thinking was that if the load balancer is
> > ever connected to
> > > >>>> that same subnet, be it by another member on that
> > subnet or the vip on that
> > > >>>> subnet, then the user does not need to specify the
> > subnet for new member if
> > > >>>> that new member is on one of those subnets.
> > > >>>>
> > > >>>> At the midcycle we discussed it and we had an informal
> > agreement that it
> > > >>>> required too many assumptions on the part of the end
> > user, neutron lbaas,
> > > >>>> and driver.
> > > >>>>
> > > >>>> If anyone wants to voice their opinion on this matter,
> > do so on the bug
> > > >>>> report, review, or in response to this thread.
> > Otherwise, it'll probably be
> > > >>>> abandoned and not done at some point.
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Brandon
> > > >>>>
> > > >>>> [1] https://bugs.launchpad.net/neutron/+bug/1426248
> > > >>>> [2] https://review.openstack.org/#/c/267935/
> > > >>>
> > > >>>>>
> > __________________________________________________________________________
> > > >>>> OpenStack Development Mailing List (not for usage
> > questions)
> > > >>>> Unsubscribe:
> > > >>>>
> > OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > > >>>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Stephen Balukoff
> > > >> Principal Technologist
> > > >> Blue Box, An IBM Company
> > > >> www.blueboxcloud.com
> > > >> sbalukoff at blueboxcloud.com
> > > >> 206-607-0660 x807
> > > >>
> > > >>
> > __________________________________________________________________________
> > > >> OpenStack Development Mailing List (not for usage
> > questions)
> > > >> Unsubscribe:
> > OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> > --
> > Stephen Balukoff
> > Principal Technologist
> > Blue Box, An IBM Company
> > www.blueboxcloud.com
> > sbalukoff at blueboxcloud.com
> > 206-607-0660 x807
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list