Open Stack

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 <johnsomor at 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 <sbalukoff at 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 <VIVEKJAIN at 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" <SamuelB at 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:SamuelB at 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.logan at RACKSPACE.COM]
>>>> Sent: Saturday, January 16, 2016 6:56 AM
>>>> To: openstack-dev at 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-request at 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-request at 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-request at 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-request at 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
>> sbalukoff at blueboxcloud.com
>> 206-607-0660 x807
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev