<div dir="ltr">Agree with Sam here,<div>Moreover, i think it makes sense to leave subnet an attribute of the pool. </div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 3:51 PM, Samuel Bercovici <span dir="ltr"><<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>I think that associating a VIP subnet and list of member subnets is a good choice. </div>
<div>This is declaratively saying to where is the configuration expecting layer 2 proximity. </div>
<div>The minimal would be the VIP subnet which in essence means the VIP and members are expected on the same subnet. </div>
<div><br>
</div>
<div>Any member outside the specified subnets is supposedly accessible via routing. </div>
<div><br>
</div>
<div>It might be an option to state the static route to use to access such member(s). </div>
<div>On many cases the needed static routes could also be computed automatically. <br>
<br>
Regards,
<div> -Sam.</div>
</div><div><div class="h5">
<div><br>
On 2 במאי 2014, at 03:50, "Stephen Balukoff" <<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Hi Trevor,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>The other option is to associate the neutron_subnet with a pool member. But in this case there might be problems too. Namely:</div>
<div>
<ul>
<li>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.<br>
</li><li>How does one resolve cases where subnets have overlapping IP ranges?</li></ul>
<div>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.)</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, May 1, 2014 at 1:52 PM, Trevor Vardeman <span dir="ltr">
<<a href="mailto:trevor.vardeman@rackspace.com" target="_blank">trevor.vardeman@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
After going back through the use-cases to double check some of my<br>
understanding, I realized I didn't quite understand the ones I had<br>
already answered. I'll use a specific use-case as an example of my<br>
misunderstanding here, and hopefully the clarification can be easily<br>
adapted to the rest of the use-cases that are similar.<br>
<br>
Use Case 13: A project-user has an HTTPS application in which some of<br>
the back-end servers serving this application are in the same subnet,<br>
and others are across the internet, accessible via VPN. He wants this<br>
HTTPS application to be available to web clients via a single IP<br>
address.<br>
<br>
In this use-case, is the Load Balancer going to act as a node in the<br>
VPN? What I mean here, is the Load Balancer supposed to establish a<br>
connection to this VPN for the client, and simulate itself as a computer<br>
on the VPN? If this is not the case, wouldn't the VPN have a subnet ID,<br>
and simply be added to a pool during its creation? If the latter is<br>
accurate, would this not just be a basic HTTPS Load Balancer creation?<br>
After looking through the VPNaaS API, you would provide a subnet ID to<br>
the create VPN service request, and it establishes a VPN on said subnet.<br>
Couldn't this be provided to the Load Balancer pool as its subnet?<br>
<br>
Forgive me for requiring so much distinction here, but what may be clear<br>
to the creator of this use-case, it has left me confused. This same<br>
type of clarity would be very helpful across many of the other<br>
VPN-related use-cases. Thanks again!<br>
<br>
-Trevor<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<span></span>Stephen Balukoff <br>
Blue Box Group, LLC <br>
(800)613-4305 x807 </div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>OpenStack-dev mailing list</span><br>
<span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br>
</div>
</blockquote>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>