German-- I agree. This sounds very much like an edge case that we don't need to worry about supporting until someone comes up with a specific use case to illustrate the problem.
Stephen On Mon, May 5, 2014 at 5:03 PM, Eichberger, German <german.eichber...@hp.com > wrote: > Hi Stephen, > > > > I think this is too strange an edge case to be covered by the LBaaS. In > any case I am wondering if there is a valid use case if we can add it to > the user stories. > > > > German > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Monday, May 05, 2014 4:05 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs > Distinction > > > > Hi Sam, > > > > So, If I understand you correctly, you don't think that specifying routing > rules (eg. static routing configuration) should be beyond the scope of > LBaaS? > > > > I agree that it might be possible to reach a given member over different > routes. The example that comes to mind for me is a member with a public IP > on the internet somewhere that's either accessible from the VIP address via > the VIP's subnet's default gateway, or via a VPN service available on the > same layer 2 network. But if we're going to support choosing routes to a > given member, shouldn't this information be located with the member? > > > > I don't know why putting this information as properties of the VIP in the > object model would make scheduling and placing the configuration any > easier-- specifically, if you've got enough information / completed > objects to deploy a load balancing service, wouldn't the service's pools > and pool member information also be implicitly available as part of the > overall configuration for the service? > > > > Thanks, > > Stephen > > > > On Sun, May 4, 2014 at 12:36 AM, Samuel Bercovici <samu...@radware.com> > wrote: > > Hi, > > > > I prefer a different approach (AKA, I oppose J) > > I think that this information should be properties of the VIP and not the > pool. > > So VIP should have: > > 1. VIP subnet (this is where the IP will be allocated) > > 2. List of members subnets (it could be optional. This means that > members have L2 proximity on the VIP subnet) > > 3. List of static routes (to be able to specify how to reach > members which are not on L2 proximity) – if not presented, this could be > calculated by the “driver” backend but sometimes where you can use multiple > different paths a user intervention might be required. > > > > I prefer this approach for the following: > > 1. Concentrating the L3 information in a single place (VIP) – this > also makes scheduling and placement of the configuration easier. > > 2. When using multiple pools (L7 content switching) that have > members on the same subnet, no need to repeat the subnet information > > > > Regards, > > -Sam. > > > > > > > > *From:* Adam Harwell [mailto:adam.harw...@rackspace.com] > *Sent:* Saturday, May 03, 2014 10:17 AM > > > *To:* OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs > Distinction > > > > Sounds about right to me. I guess I agree with your agreement. :) > > Does anyone actually *oppose* this arrangement? > > > > --Adam > > > > *From: *Stephen Balukoff <sbaluk...@bluebox.net> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *Date: *Friday, May 2, 2014 7:53 PM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs > Distinction > > > > Hi guys, > > > > Yep, so what I'm hearing is that we should be able to assume that either > all members in a single pool are adjacent (ie. layer-2 connected), or are > routable from that subnet. > > > > Adam-- I could see it going either way with regard to how to communicate > with members: If the particular device that the provider uses lives > outside tenant private networks, the driver for said devices would need to > make sure that VIFs (or some logical equivalent) are added such that the > devices can talk to the members. This is also the case for virtual load > balancers (or other devices) which are assigned to the tenant but live on > an "external" network. (In this topology, VIP subnet and pool subnet could > differ, and the driver needs to make sure that the load balancer has a > virtual interface/neutron port + IP address on the pool subnet.) > > > > There's also the option that if the "device" being used for load balancing > exists as a virtual appliance that can be deployed on an internal network, > one can make it publicly accessible by adding a "neutron floating IP" (ie. > static NAT rule) that forwards any traffic destined for a public "external" > IP to the load balancer's internal IP address. (In this topology, VIP > subnet and pool subnet would be the same thing.) The nifty thing about this > topology is that load balancers that don't have this static NAT rule added > are implicitly "private" to the tenant internal subnet. > > > > Having seen what our customers do with their topologies, my gut reaction > is to say that the 99.9% use case is that all the members of a pool will be > in the same subnet, or routable from the pool subnet. And I agree that if > someone has a really strange topology in use that doesn't work with this > assumption, it's not the job of LBaaS to try and solve this for them. > > > > Anyway, I'm hearing general agreement that subnet_id should be an > attribute of the pool. > > > > On Fri, May 2, 2014 at 5:24 AM, Eugene Nikanorov <enikano...@mirantis.com> > wrote: > > Agree with Sam here, > > Moreover, i think it makes sense to leave subnet an attribute of the pool. > > Which would mean that members reside in that subnet or are available > (routable) from this subnet, and LB should have a port on this subnet. > > > > Thanks, > > Eugene. > > > > On Fri, May 2, 2014 at 3:51 PM, Samuel Bercovici <samu...@radware.com> > wrote: > > I think that associating a VIP subnet and list of member subnets is a good > choice. > > This is declaratively saying to where is the configuration expecting layer > 2 proximity. > > The minimal would be the VIP subnet which in essence means the VIP and > members are expected on the same subnet. > > > > Any member outside the specified subnets is supposedly accessible via > routing. > > > > It might be an option to state the static route to use to access such > member(s). > > On many cases the needed static routes could also be computed > automatically. > > Regards, > > -Sam. > > > On 2 במאי 2014, at 03:50, "Stephen Balukoff" <sbaluk...@bluebox.net> > wrote: > > Hi Trevor, > > > > I was the one who wrote that use case based on discussion that came out of > the question I wrote the list last week about SSL re-encryption: Someone > had stated that sometimes pool members are local, and sometimes they are > hosts across the internet, accessible either through the usual default > route, or via a VPN tunnel. > > > > The point of this use case is to make the distinction that if we associate > a neutron_subnet with the pool (rather than with the member), then some > members of the pool that don't exist in that neutron_subnet might not be > accessible from that neutron_subnet. However, if the behavior of the > system is such that attempting to reach a host through the subnet's > "default route" still works (whether that leads to communication over a VPN > or the usual internet routes), then this might not be a problem. > > > > The other option is to associate the neutron_subnet with a pool member. > But in this case there might be problems too. Namely: > > - The device or software that does the load balancing may need to have > an interface on each of the member subnets, and presumably an IP address > from which to originate requests. > - How does one resolve cases where subnets have overlapping IP ranges? > > In the end, it may be simpler not to associate neutron_subnet with a > pool at all. Maybe it only makes sense to do this for a VIP, and then the > assumption would be that any member addresses one adds to pools must be > accessible from the VIP subnet. (Which is easy, if the VIP exists on the > same neutron_subnet. But this might require special routing within Neutron > itself if it doesn't.) > > > > This topology question (ie. what is feasible, what do people actually want > to do, and what is supported by the model) is one of the more difficult > ones to answer, especially given that users of OpenStack that I've come in > contact with barely understand the Neutron networking model, if at all. > > > > In our case, we don't actually have any users in the scenario of having > members spread across different subnets that might not be be routable, so > the use case is somewhat contrived, but I thought it was worth mentioning > based on what people were saying in the SSL re-encryption discussion last > week. > > > > On Thu, May 1, 2014 at 1:52 PM, Trevor Vardeman < > trevor.varde...@rackspace.com> wrote: > > Hello, > > After going back through the use-cases to double check some of my > understanding, I realized I didn't quite understand the ones I had > already answered. I'll use a specific use-case as an example of my > misunderstanding here, and hopefully the clarification can be easily > adapted to the rest of the use-cases that are similar. > > Use Case 13: A project-user has an HTTPS application in which some of > the back-end servers serving this application are in the same subnet, > and others are across the internet, accessible via VPN. He wants this > HTTPS application to be available to web clients via a single IP > address. > > In this use-case, is the Load Balancer going to act as a node in the > VPN? What I mean here, is the Load Balancer supposed to establish a > connection to this VPN for the client, and simulate itself as a computer > on the VPN? If this is not the case, wouldn't the VPN have a subnet ID, > and simply be added to a pool during its creation? If the latter is > accurate, would this not just be a basic HTTPS Load Balancer creation? > After looking through the VPNaaS API, you would provide a subnet ID to > the create VPN service request, and it establishes a VPN on said subnet. > Couldn't this be provided to the Load Balancer pool as its subnet? > > Forgive me for requiring so much distinction here, but what may be clear > to the creator of this use-case, it has left me confused. This same > type of clarity would be very helpful across many of the other > VPN-related use-cases. Thanks again! > > -Trevor > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev