[openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

Samuel Bercovici SamuelB at Radware.com
Sun Nov 23 07:06:54 UTC 2014

Hi Stephen,

1.       The issue is that if we do 1:1 and allow status/state to proliferate throughout all objects we will then get an issue to fix it later, hence even if we do not do sharing, I would still like to have all objects besides LB be treated as logical.

2.       The 3rd use case bellow will not be reasonable without pool sharing between different policies. Specifying different pools which are the same for each policy make it non-started to me.


From: Stephen Balukoff [mailto:sbalukoff at bluebox.net]
Sent: Friday, November 21, 2014 10:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

I think the idea was to implement 1:1 initially to reduce the amount of code and operational complexity we'd have to deal with in initial revisions of LBaaS v2. Many to many can be simulated in this scenario, though it does shift the burden of maintenance to the end user. It does greatly simplify the initial code for v2, in any case, though.

Did we ever agree to allowing listeners to be shared among load balancers?  I think that still might be a N:1 relationship even in our latest models.

There's also the difficulty introduced by supporting different flavors:  Since flavors are essentially an association between a load balancer object and a driver (with parameters), once flavors are introduced, any sub-objects of a given load balancer objects must necessarily be purely logical until they are associated with a load balancer.  I know there was talk of forcing these objects to be sub-objects of a load balancer which can't be accessed independently of the load balancer (which would have much the same effect as what you discuss: State / status only make sense once logical objects have an instantiation somewhere.) However, the currently proposed API treats most objects as root objects, which breaks this paradigm.

How we handle status and updates once there's an instantiation of these logical objects is where we start getting into real complexity.

It seems to me there's a lot of complexity introduced when we allow a lot of many to many relationships without a whole lot of benefit in real-world deployment scenarios. In most cases, objects are not going to be shared, and in those cases with sufficiently complicated deployments in which shared objects could be used, the user is likely to be sophisticated enough and skilled enough to manage updating what are essentially "copies" of objects, and would likely have an opinion about how individual failures should be handled which wouldn't necessarily coincide with what we developers of the system would assume. That is to say, allowing too many many to many relationships feels like a solution to a problem that doesn't really exist, and introduces a lot of unnecessary complexity.

In any case, though, I feel like we should walk before we run: Implementing 1:1 initially is a good idea to get us rolling. Whether we then implement 1:N or M:N after that is another question entirely. But in any case, it seems like a bad idea to try to start with M:N.


On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici <SamuelB at radware.com<mailto:SamuelB at radware.com>> wrote:

Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I would like to remind everyone why we choose to follow a model where pools and listeners are shared (many to many relationships).

Use Cases:
1. The same application is being exposed via different LB objects.
For example: users coming from the internal "private" organization network, have an LB1(private_VIP) --> Listener1(TLS) -->Pool1 and user coming from the "internet", have LB2(public_vip)-->Listener1(TLS)-->Pool1.
This may also happen to support ipv4 and ipv6: LB_v4(ipv4_VIP) --> Listener1(TLS) -->Pool1 and LB_v6(ipv6_VIP) --> Listener1(TLS) -->Pool1
The operator would like to be able to manage the pool membership in cases of updates and error in a single place.

2. The same group of servers is being used via different listeners optionally also connected to different LB objects.
For example: users coming from the internal "private" organization network, have an LB1(private_VIP) --> Listener1(HTTP) -->Pool1 and user coming from the "internet", have LB2(public_vip)-->Listener2(TLS)-->Pool1.
The LBs may use different flavors as LB2 needs TLS termination and may prefer a different "stronger" flavor.
The operator would like to be able to manage the pool membership in cases of updates and error in a single place.

3. The same group of servers is being used in several different L7_Policies connected to a listener. Such listener may be reused as in use case 1.
For example: LB1(VIP1)-->Listener_L7(TLS)

I think that the "key" issue handling correctly the "provisioning" state and the operation state in a many to many model.
This is an issue as we have attached status fields to each and every object in the model.
A side effect of the above is that to understand the "provisioning/operation" status one needs to check many different objects.

To remedy this, I would like to turn all objects besides the LB to be logical objects. This means that the only place to manage the status/state will be on the LB object.
Such status should be hierarchical so that logical object attached to an LB, would have their status consumed out of the LB object itself (in case of an error).
We also need to discuss how modifications of a logical object will be "rendered" to the concrete LB objects.
You may want to revisit https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r the "Logical Model + Provisioning Status + Operation Status + Statistics" for a somewhat more detailed explanation albeit it uses the LBaaS v1 model as a reference.


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

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/20141123/27480565/attachment.html>

More information about the OpenStack-dev mailing list