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 [[email protected]] Sent: Monday, January 25, 2016 1:03 PM To: [email protected] 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 > <[email protected]> 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 > <[email protected]> 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 > <[email protected]> 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 > <[email protected]> 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" > <[email protected]> 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:[email protected]] > > >>>> 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:[email protected]] > > >>>> Sent: Saturday, January 16, 2016 6:56 AM > > >>>> To: [email protected] > > >>>> 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: > > >>>> > [email protected]?subject:unsubscribe > > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >>>> > > >>> > > >>>>> > > __________________________________________________________________________ > > >>>> OpenStack Development Mailing List (not for usage > questions) > > >>>> Unsubscribe: > > >>>> > [email protected]?subject:unsubscribe > > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >>>> > > >>> > > >>>>> > > __________________________________________________________________________ > > >>>> OpenStack Development Mailing List (not for usage > questions) > > >>>> Unsubscribe: > > >>>> > [email protected]?subject:unsubscribe > > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >>> > > __________________________________________________________________________ > > >>> OpenStack Development Mailing List (not for usage > questions) > > >>> Unsubscribe: > [email protected]?subject:unsubscribe > > >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >> > > >> > > >> > > >> > > >> -- > > >> Stephen Balukoff > > >> Principal Technologist > > >> Blue Box, An IBM Company > > >> www.blueboxcloud.com > > >> [email protected] > > >> 206-607-0660 x807 > > >> > > >> > > __________________________________________________________________________ > > >> OpenStack Development Mailing List (not for usage > questions) > > >> Unsubscribe: > [email protected]?subject:unsubscribe > > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >> > > > > > > > > __________________________________________________________________________ > > > OpenStack Development Mailing List (not for usage > questions) > > > Unsubscribe: > [email protected]?subject:unsubscribe > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Stephen Balukoff > Principal Technologist > Blue Box, An IBM Company > www.blueboxcloud.com > [email protected] > 206-607-0660 x807 > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
