Hi folks, Recently we were discussing LBaaS object model with Mark McClain in order to address several problems that we faced while approaching L7 rules and multiple vips per pool.
To cut long story short: with existing workflow and model it's impossible to use L7 rules, because each pool being created is 'instance' object in itself, it defines another logical configuration and can't be attached to other existing configuration. To address this problem, plus create a base for multiple vips per pool, the 'loadbalancer' object was introduced (see https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance ). However this approach raised a concern of whether we want to let user to care about 'instance' object. My personal opinion is that letting user to work with 'loadbalancer' entity is no big deal (and might be even useful for terminological clarity; Libra and AWS APIs have that) especially if existing simple workflow is preserved, so the 'loadbalancer' entity is only required when working with L7 or multiple vips per pool. The alternative solution proposed by Mark is described here under #3: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion In (3) the root object of the configuration is VIP, where all kinds of bindings are made (such as provider, agent, device, router). To address 'multiple vips' case another entity 'Listener' is introduced, which receives most attributes of former 'VIP' (attribute sets are not finalized on those pictures, so don't pay much attention) If you take closer look at #2 and #3 proposals, you'll see that they are essentially similar, where in #3 the VIP object takes instance/loadbalancer role from #2. Both #2 and #3 proposals make sense to me because they address both problems with L7 and multiple vips (or listeners) My concern about #3 is that it redefines lots of workflow and API aspects and even if we manage to make transition to #3 in backward-compatible way, it will be more complex in terms of code/testing, then #2 (which is on review already and works). The whole thing is important design decision, so please share your thoughts everyone. Thanks, Eugene.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
