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