[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