[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