[openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners

Stephen Balukoff sbalukoff at bluebox.net
Tue Jun 10 22:58:44 UTC 2014


Hi Jorge,

On Fri, Jun 6, 2014 at 12:48 PM, Jorge Miramontes <
jorge.miramontes at rackspace.com> wrote:

>
> 1) We are assuming that load balancers can only operate on one update at a
> time correct? I.E. We are not allowing multiple updates to occur
> concurrently? Whatever the case on this I advocate that we do NOT allow
> concurrent modification as complexity of the system increases dramatically
> and the gain is very small since load balancers are usually configured
> upon create and then rarely updated over their lifetime.
>

I agree. The only exception to this rule I would say is that operations
which delete objects should be allowed to override any queued up
reconfiguration. (If a resource gets into a strange state where it isn't
otherwise alterable, it's handy to be able to delete it without operator
intervention.)


2) It appears that sharing objects is causing complexity to creep in the
> deeper the conversations are getting. For example, managing object
> statuses seems like a nightmare! That said, does the fundamental rationale
> for sharing objects outweigh the simplicity of not sharing objects?
>

I wouldn't say it's a nightmare, but it certainly isn't trivial, and some
solutions to this problem may reveal more about the back-end than we really
want to reveal to a user. This particular complication only comes into play
when "status" becomes a meaningful attribute of the object. (For example,
"status" is meaningless on logical constructs like L7Policies or TLS
Certificates.) Do you see complications other than status and stats
collection becoming an issue here?

Having said this, it would be possible to define most things with a
'status' from the load balancer down in the object tree as being
non-share-able, I suppose. It does simplify what needs to be done
algorithmically by quite a bit, but does complicate the user experience
when it comes to setting up and maintaining load balancer related
configuration.

I will say: I'm a little reluctant to change horses at this stage in the
race, though. I feel like we have discussed this pretty thoroughly in the
past and am not sure it's appropriate to re-hash those discussions now.
What you're talking about are essentially core object-model level changes.
 (Obviously, others should feel free to disagree with me about whether it
makes sense to revisit this discussion yet again.)


> I understand that we've been diligently working on the API revision but I
> wanted to take a step back and look at the goal we are trying to solve and
> weigh the perceived need for complexity (i.e "flexibility" in the API) vs
> a simpler solution.
>
>
Stephen


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140610/f251c950/attachment.html>


More information about the OpenStack-dev mailing list