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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
