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.lo...@rackspace.com] > Sent: Monday, January 25, 2016 1:03 PM > To: openstack-dev@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.lo...@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 > > <johnso...@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 > > <sbaluk...@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 > > <vivekj...@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" > > <samu...@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:samu...@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.lo...@rackspace.com] > > > >>>> Sent: Saturday, January 16, 2016 6:56 AM > > > >>>> To: openstack-dev@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-requ...@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-requ...@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-requ...@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-requ...@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 > > > >> sbaluk...@blueboxcloud.com > > > >> 206-607-0660 x807 > > > >> > > > >> > > > > __________________________________________________________________________ > > > >> OpenStack Development Mailing List (not for usage > > questions) > > > >> Unsubscribe: > > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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 > > sbaluk...@blueboxcloud.com > > 206-607-0660 x807 > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev