Hi Samuel, We've actually been avoiding having a deeper discussion about status in Neutron LBaaS since this can get pretty hairy as the back-end implementations get more complicated. I suspect managing that is probably one of the bigger reasons we have disagreements around object sharing. Perhaps it's time we discussed representing state "correctly" (whatever that means), instead of a round-a-bout discussion about object sharing (which, I think, is really just avoiding this issue)?
Do you have a proposal about how status should be represented (possibly including a description of the state machine) if we collapse everything down to be logical objects except the loadbalancer object? (From what you're proposing, I suspect it might be too general to, for example, represent the UP/DOWN status of members of a given pool.) Also, from an haproxy perspective, sharing pools within a single listener actually isn't a problem. That is to say, having the same L7Policy pointing at the same pool is OK, so I personally don't have a problem allowing sharing of objects within the scope of parent objects. What do the rest of y'all think? Stephen On Sat, Nov 22, 2014 at 11:06 PM, Samuel Bercovici <samu...@radware.com> wrote: > 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. > > > > -Sam. > > > > > > > > *From:* Stephen Balukoff [mailto:sbaluk...@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. > > > > Stephen > > > > > > On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici <samu...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev