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 <johnso...@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 <sbaluk...@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 <vivekj...@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" <samu...@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:samu...@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.lo...@rackspace.com] >>>> Sent: Saturday, January 16, 2016 6:56 AM >>>> To: openstack-dev@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-requ...@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-requ...@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-requ...@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-requ...@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 >> sbaluk...@blueboxcloud.com >> 206-607-0660 x807 >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev