[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
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
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
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
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
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" 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
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
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 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" 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
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
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 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 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" 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/ma
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
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 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 > 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 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" 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
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
So it really comes down to driver (or driver's appliance) implementation. Here's some scenarios to consider: 1) vip on tenant network, members on tenant network - if a user wants to add an external IP to this configuration, how do we handle that? If the subnet is optional the it just uses the default routing, then it won't ever get external unless the backend implementation sets up routing to external from the load balancer. I think this is a bad idea because the tenant would probably want these networks isolated. But if the backend puts a load balancer on it with external connectivity, its not as isolated as it was. So to me, if subnet is optional the best choice is to do default routing which *SHOULD* fail on default routing. This of course is something a tenant will have to realize. The good thing about a required subnet_id is that the tenant has explicitly stated they wanted external connectivity and the backend is not making assumptions as to whether they want it or don't. 2) vip on public network, members on tenant network - defaults route should be able to route out to external IPs now so if subnet_id is optional it works. If subnet_id is required then the tenant would have to specify the public network again, which is less than ideal and also has other issues brought up in this thread. All other scenario permutations are similar to the above ones so I don't think i need to go through them. Basically, I'm waffling on this and am currently on the optional subnet_id side but as the builders of octavia, I don't think we should allow a load balancer external access unless the tenant has in a way given permission by the configuration they've explicitly set. Though, that too should be defined. Thanks, Brandon On Tue, 2016-01-19 at 12:07 -0700, Doug Wiegley wrote: > 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 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 > > 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 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" wrote: > >>> > >>>> Btw. > >>>> > >>>> I am still in favor on associating the subnets to the LB and then not > >>>> specify them per node at all. > >&g
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
to specify the public network again, which is less > than ideal and also has other issues brought up in this thread. > > All other scenario permutations are similar to the above ones so I don't > think i need to go through them. > > Basically, I'm waffling on this and am currently on the optional > subnet_id side but as the builders of octavia, I don't think we should > allow a load balancer external access unless the tenant has in a way > given permission by the configuration they've explicitly set. Though, > that too should be defined. > > Thanks, > Brandon > On Tue, 2016-01-19 at 12:07 -0700, Doug Wiegley wrote: > > 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 > 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 > 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" 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 th
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
I think you'll like that there will soon be a single create call for the entire graph/tree of a load balancer so you can get those subnets up front. However, the API will still allow creating each entity individually which you don't like. I have a feeling most clients and UIs will use the single create call once its available over creating each individual entity independently. That should help out mostly. Thanks, Brandon On Sun, 2016-01-17 at 09:05 +, Samuel Bercovici 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
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
ing 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 > 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" > 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/ > > &g
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
We are using a neutron v1 lb that has external to the cloud members in a lb used by a particular tenant in production. It is working well. Hoping to do the same thing once we get to Octavia+LBaaSv2. Being able to tweak the routes of the load balancer would be an interesting feature, though I don't think I'd ever need to. Maybe that should be an extension? I'm guessing a lot of lb plugins won't be able to support it at all. Thanks, Kevin From: Brandon Logan [brandon.lo...@rackspace.com] Sent: Monday, January 25, 2016 1:03 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create? Any additional thoughts and opinions people want to share on this. I don't have a horse in this race as long as we don't make dangerous assumptions about what the user wants. So I am fine with making subnet_id optional. Michael, how strong would your opposition for this be? Thanks, Brandon On Tue, 2016-01-19 at 20:49 -0800, Stephen Balukoff wrote: > Michael-- I think you're assuming that adding an external subnet ID > means that the load balancing service will route requests to out an > interface with a route to said external subnet. However, the model we > have is actually too simple to convey this information to the load > balancing service. This is because while we know the member's IP and a > subnet to which the load balancing service should connect to > theoretically talk to said IP, we don't have any kind of actual > routing information for the IP address (like, say a default route for > the subnet). > > > Consider this not far-fetched example: Suppose a tenant wants to add a > back-end member which is reachable only over a VPN, the gateway for > which lives on a tenant internal subnet. If we had a more feature-rich > model to work with here, the tenant could specify the member IP, the > subnet containing the VPN gateway and the gateway's IP address. In > theory the load balancing service could add local routing rules to > make sure that communication to that member happens on the tenant > subnet and gets routed to the VPN gateway. > > > If we want to support this use case, then we'd probably need to add an > optional gateway IP parameter to the member object. (And I'd still be > in favor of assuming the subnet_id on the member is optional, and that > default routing should be used if not specified.) > > > Let me see if I can break down several use cases we could support with > this model. Let's assume the member model contains (among other > things) the following attributes: > > > ip_address (member IP, required) > subnet_id (member or gateway subnet, optional) > gateway_ip (VPN or other layer-3 gateway that should be used to access > the member_ip. optional) > > > Expected behaviors: > > > Scenario 1: > ip_address specified, subnet_id and gateway_ip are None: Load > balancing service assumes member IP address is reachable through > default routing. Appropriate for members that are not part of the > local cloud that are accessible from the internet. > > > > Scenario 2: > ip_address and subnet_id specified, gateway_ip is None: Load balancing > service assumes it needs an interface on subnet_id to talk directly to > the member IP address. Appropriate for members that live on tenant > networks. member_ip should exist within the subnet specified by > subnet_id. This is the only scenario supported under the current model > if we make subnet_id a required field and don't add a gateway_ip. > > > Scenario 3: > ip_address, subnet_id and gateway_ip are all specified: Load > balancing service assumes it needs an interface on subnet_id to talk > to the gateway_ip. Load balancing service should add local routing > rule (ie. to the host and / or local network namespace context of the > load balancing service itself, not necessarily to Neutron or anything) > to route any packets destined for member_ip to the gateway_ip. > gateway_ip should exist within the subnet specified by subnet_id. > Appropriate for members that are on the other side of a VPN links, or > reachable via other local routing within a tenant network or local > cloud. > > > Scenario 4: > ip_address and gateway_ip are specified, subnet_id is None: This is an > invalid configuration. > > > So what do y'all think of this? Am I smoking crack with how this > should work? > > > For what it's worth, I think the "member is on the other side of a > VPN" scenario is not one our customers are champing at the bit to > have, so I'm fine with not supporting that kind of topology if nobody > else wants
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
I could see it being interesting, but that would have to be something vetted by other drivers and appliances because they may not support that. On Mon, 2016-01-25 at 21:37 +, Fox, Kevin M wrote: > We are using a neutron v1 lb that has external to the cloud members in a lb > used by a particular tenant in production. It is working well. Hoping to do > the same thing once we get to Octavia+LBaaSv2. > > Being able to tweak the routes of the load balancer would be an interesting > feature, though I don't think I'd ever need to. Maybe that should be an > extension? I'm guessing a lot of lb plugins won't be able to support it at > all. > > Thanks, > Kevin > > > From: Brandon Logan [brandon.lo...@rackspace.com] > Sent: Monday, January 25, 2016 1:03 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be > optional on member create? > > Any additional thoughts and opinions people want to share on this. I > don't have a horse in this race as long as we don't make dangerous > assumptions about what the user wants. So I am fine with making > subnet_id optional. > > Michael, how strong would your opposition for this be? > > Thanks, > Brandon > > On Tue, 2016-01-19 at 20:49 -0800, Stephen Balukoff wrote: > > Michael-- I think you're assuming that adding an external subnet ID > > means that the load balancing service will route requests to out an > > interface with a route to said external subnet. However, the model we > > have is actually too simple to convey this information to the load > > balancing service. This is because while we know the member's IP and a > > subnet to which the load balancing service should connect to > > theoretically talk to said IP, we don't have any kind of actual > > routing information for the IP address (like, say a default route for > > the subnet). > > > > > > Consider this not far-fetched example: Suppose a tenant wants to add a > > back-end member which is reachable only over a VPN, the gateway for > > which lives on a tenant internal subnet. If we had a more feature-rich > > model to work with here, the tenant could specify the member IP, the > > subnet containing the VPN gateway and the gateway's IP address. In > > theory the load balancing service could add local routing rules to > > make sure that communication to that member happens on the tenant > > subnet and gets routed to the VPN gateway. > > > > > > If we want to support this use case, then we'd probably need to add an > > optional gateway IP parameter to the member object. (And I'd still be > > in favor of assuming the subnet_id on the member is optional, and that > > default routing should be used if not specified.) > > > > > > Let me see if I can break down several use cases we could support with > > this model. Let's assume the member model contains (among other > > things) the following attributes: > > > > > > ip_address (member IP, required) > > subnet_id (member or gateway subnet, optional) > > gateway_ip (VPN or other layer-3 gateway that should be used to access > > the member_ip. optional) > > > > > > Expected behaviors: > > > > > > Scenario 1: > > ip_address specified, subnet_id and gateway_ip are None: Load > > balancing service assumes member IP address is reachable through > > default routing. Appropriate for members that are not part of the > > local cloud that are accessible from the internet. > > > > > > > > Scenario 2: > > ip_address and subnet_id specified, gateway_ip is None: Load balancing > > service assumes it needs an interface on subnet_id to talk directly to > > the member IP address. Appropriate for members that live on tenant > > networks. member_ip should exist within the subnet specified by > > subnet_id. This is the only scenario supported under the current model > > if we make subnet_id a required field and don't add a gateway_ip. > > > > > > Scenario 3: > > ip_address, subnet_id and gateway_ip are all specified: Load > > balancing service assumes it needs an interface on subnet_id to talk > > to the gateway_ip. Load balancing service should add local routing > > rule (ie. to the host and / or local network namespace context of the > > load balancing service itself, not necessarily to Neutron or anything) > > to route any packets destined for member_ip to the gateway_ip. > > gateway_ip should exist within the subnet specified
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?
If we take the approach do "download configuration for all v1 out of OpenStack, delete all v1 configuration and then, after lbaas v1 is removed and lbaas v2 is installed, use the data to recreate the items, this should be compatible to all drivers. No sure if such procedure will be accepted though. -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Thursday, January 28, 2016 6:49 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create? I could see it being interesting, but that would have to be something vetted by other drivers and appliances because they may not support that. On Mon, 2016-01-25 at 21:37 +, Fox, Kevin M wrote: > We are using a neutron v1 lb that has external to the cloud members in a lb > used by a particular tenant in production. It is working well. Hoping to do > the same thing once we get to Octavia+LBaaSv2. > > Being able to tweak the routes of the load balancer would be an interesting > feature, though I don't think I'd ever need to. Maybe that should be an > extension? I'm guessing a lot of lb plugins won't be able to support it at > all. > > Thanks, > Kevin > > > From: Brandon Logan [brandon.lo...@rackspace.com] > Sent: Monday, January 25, 2016 1:03 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be > optional on member create? > > Any additional thoughts and opinions people want to share on this. I > don't have a horse in this race as long as we don't make dangerous > assumptions about what the user wants. So I am fine with making > subnet_id optional. > > Michael, how strong would your opposition for this be? > > Thanks, > Brandon > > On Tue, 2016-01-19 at 20:49 -0800, Stephen Balukoff wrote: > > Michael-- I think you're assuming that adding an external subnet ID > > means that the load balancing service will route requests to out an > > interface with a route to said external subnet. However, the model > > we have is actually too simple to convey this information to the > > load balancing service. This is because while we know the member's > > IP and a subnet to which the load balancing service should connect > > to theoretically talk to said IP, we don't have any kind of actual > > routing information for the IP address (like, say a default route > > for the subnet). > > > > > > Consider this not far-fetched example: Suppose a tenant wants to add > > a back-end member which is reachable only over a VPN, the gateway > > for which lives on a tenant internal subnet. If we had a more > > feature-rich model to work with here, the tenant could specify the > > member IP, the subnet containing the VPN gateway and the gateway's > > IP address. In theory the load balancing service could add local > > routing rules to make sure that communication to that member happens > > on the tenant subnet and gets routed to the VPN gateway. > > > > > > If we want to support this use case, then we'd probably need to add > > an optional gateway IP parameter to the member object. (And I'd > > still be in favor of assuming the subnet_id on the member is > > optional, and that default routing should be used if not specified.) > > > > > > Let me see if I can break down several use cases we could support > > with this model. Let's assume the member model contains (among other > > things) the following attributes: > > > > > > ip_address (member IP, required) > > subnet_id (member or gateway subnet, optional) gateway_ip (VPN or > > other layer-3 gateway that should be used to access the member_ip. > > optional) > > > > > > Expected behaviors: > > > > > > Scenario 1: > > ip_address specified, subnet_id and gateway_ip are None: Load > > balancing service assumes member IP address is reachable through > > default routing. Appropriate for members that are not part of the > > local cloud that are accessible from the internet. > > > > > > > > Scenario 2: > > ip_address and subnet_id specified, gateway_ip is None: Load > > balancing service assumes it needs an interface on subnet_id to talk > > directly to the member IP address. Appropriate for members that live > > on tenant networks. member_ip should exist within the subnet > > specified by subnet_id. This is the only scenario supported under > > the current model if we make subnet_id a requi