Open Stack

Hi neutron & lbaas folks,

Let's meet tomorrow, Thursday, 06 at 14-00 on #openstack-meeting to
continue discussing the object model.

We had discussed with Samuel Bercovici proposals at hand and currently
there are two main proposals that we are evaluating.
Both of them allow to add two major features that initially made us to do
that whole object model redesign:
1) neutron port (ip address reuse) by multiple vips pointing to the same
pool.
Use case: http and https protocols for the same pool
2) multiple pools per vip via L7 rules.

Approach #1 (which I'm advocating) is #3 here:
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion

Approach #2 (Sam's proposal):
https://docs.google.com/a/mirantis.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r

In short, the difference between two is in how neutron port reuse is
achieved:
- Proposal #1 uses VIP object to keep neutron port (ip address) and
Listener objects
to represent different tcp ports and protocols.
- Proposal #2 uses VIP object only, neutron port reuse is achieved by
creating another VIP with vip_id of the VIP who's port is going to be
shared.
Both proposals suggest making VIP a root object (e.g. the object to which
different bindings are applied)

Those two proposals have the following advantages and disadvantages:
Proposal #1:
 - logical instance has 1 root object (VIP) which gives API clarity and
implementation advantage.
The following operations will have clear semantics: changing SLA for the
logical balancer, plugging into the different network, changing operational
status, etc.
E.g. many kinds of update operations applied to the root object (VIP)
affect whole child configuration.
 - Introducing another resource (listener) is a disadvantage (although
backward compatibility could be preserved)

Proposal #2:
 - Keeping existing set of resources, which might be an advantage for some
consumers.
 - As a disadvantage I see several root object that are implicitly bound to
the same logical configuration.
That creates small subtle inconsistencies in API that are better to be
avoided (IMO):
 when when updating certain VIP parameters like IP address or subnet that
leads to a changed parameters of another VIP that shares neutron port.
That is a direct consequence of having several 'root objects' within one
logical configuration (non-hierarchical)

Technically both proposals are fine to me.
Practically I prefer #1 over #2 because IMO it leads to a clearer API.

Please look at those proposals, think about the differences, your
preference and any concern you have about these two. We're going to
dedicate the meeting to that.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/8fae574c/attachment.html>