Open Stack

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.

Stephen


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

> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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/20141121/c7efe9e8/attachment.html>