Open Stack

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.eichberger at 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:sbalukoff at 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 <SamuelB at 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.harwell at 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 <sbalukoff at bluebox.net>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> *Date: *Friday, May 2, 2014 7:53 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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 <enikanorov at 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 <SamuelB at 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" <sbalukoff at 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.vardeman at 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 at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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 at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140505/6f250b8c/attachment-0001.html>