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 +0000, 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
