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

Fox, Kevin M Kevin.Fox at pnnl.gov
Mon Jan 25 21:37:22 UTC 2016


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



More information about the OpenStack-dev mailing list