[openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

Brandon Logan brandon.logan at RACKSPACE.COM
Wed Jan 20 03:09:57 UTC 2016


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



More information about the OpenStack-dev mailing list