Open Stack

Hi,

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)
                                            |
                                            +-->L7_Policy1(rules..)-->Pool1
                                            |
                                            +-->L7_Policy2(rules..)-->Pool2
                                            |
                                            +-->L7_Policy3(rules..)-->Pool1
                                            |
                                            +-->L7_Policy3(rules..)-->Reject


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.

Regards,
	-Sam.