<div dir="ltr">Vivek--<div><br></div><div>"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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 18, 2016 at 11:14 AM, Jain, Vivek <span dir="ltr"><<a href="mailto:VIVEKJAIN@ebay.com" target="_blank">VIVEKJAIN@ebay.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Thanks,<br>
Vivek<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
On 1/17/16, 1:05 AM, "Samuel Bercovici" <SamuelB@Radware.com> wrote:<br>
<br>
>Btw.<br>
><br>
>I am still in favor on associating the subnets to the LB and then not specify them per node at all.<br>
><br>
>-Sam.<br>
><br>
><br>
>-----Original Message-----<br>
>From: Samuel Bercovici [mailto:<a href="mailto:SamuelB@Radware.com">SamuelB@Radware.com</a>]<br>
>Sent: Sunday, January 17, 2016 10:14 AM<br>
>To: OpenStack Development Mailing List (not for usage questions)<br>
>Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?<br>
><br>
>+1<br>
>Subnet should be mandatory<br>
><br>
>The only thing this makes supporting load balancing servers which are not running in the cloud more challenging to support.<br>
>But I do not see this as a huge user story (lb in cloud load balancing IPs outside the cloud)<br>
><br>
>-Sam.<br>
><br>
>-----Original Message-----<br>
>From: Brandon Logan [mailto:<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>]<br>
>Sent: Saturday, January 16, 2016 6:56 AM<br>
>To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>Subject: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?<br>
><br>
>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.<br>
><br>
>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.<br>
><br>
>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.<br>
><br>
>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.<br>
><br>
>Thanks,<br>
>Brandon<br>
><br>
>[1] <a href="https://bugs.launchpad.net/neutron/+bug/1426248" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1426248</a><br>
>[2] <a href="https://review.openstack.org/#/c/267935/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/267935/</a><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span></span><div>Stephen Balukoff</div><div>Principal Technologist</div><div>Blue Box, An IBM Company</div><div><a href="http://www.blueboxcloud.com" target="_blank">www.blueboxcloud.com</a></div><div><a href="mailto:sbalukoff@blueboxcloud.com" target="_blank">sbalukoff@blueboxcloud.com</a></div><div>206-607-0660 x807</div></div></div></div></div></div>
</div>