<div dir="ltr">Hi neutron & lbaas folks,<div><br></div><div>Let's meet tomorrow, Thursday, 06 at 14-00 on #openstack-meeting to continue discussing the object model.</div><div><br></div><div>We had discussed with Samuel Bercovici proposals at hand and currently there are two main proposals that we are evaluating.</div>
<div>Both of them allow to add two major features that initially made us to do that whole object model redesign: </div><div>1) neutron port (ip address reuse) by multiple vips pointing to the same pool.</div><div>Use case: http and https protocols for the same pool</div>
<div>2) multiple pools per vip via L7 rules.</div><div><br></div><div>Approach #1 (which I'm advocating) is #3 here: <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion</a></div>
<div><br></div><div>Approach #2 (Sam's proposal): <a href="https://docs.google.com/a/mirantis.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r">https://docs.google.com/a/mirantis.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r</a></div>
<div><br></div><div>In short, the difference between two is in how neutron port reuse is achieved:</div><div>- Proposal #1 uses VIP object to keep neutron port (ip address) and Listener objects </div><div>to represent different tcp ports and protocols.</div>
<div>- 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.</div><div>Both proposals suggest making VIP a root object (e.g. the object to which different bindings are applied)</div>
<div><br></div><div>Those two proposals have the following advantages and disadvantages:</div><div>Proposal #1: </div><div> - logical instance has 1 root object (VIP) which gives API clarity and implementation advantage. </div>
<div>The following operations will have clear semantics: changing SLA for the logical balancer, plugging into the different network, changing operational status, etc. </div><div>E.g. many kinds of update operations applied to the root object (VIP) affect whole child configuration.</div>
<div> - Introducing another resource (listener) is a disadvantage (although backward compatibility could be preserved)</div><div><br></div><div>Proposal #2:</div><div> - Keeping existing set of resources, which might be an advantage for some consumers.</div>
<div> - As a disadvantage I see several root object that are implicitly bound to the same logical configuration. </div><div>That creates small subtle inconsistencies in API that are better to be avoided (IMO):</div><div> when when updating certain VIP parameters like IP address or subnet that leads to a changed parameters of another VIP that shares neutron port. </div>
<div>That is a direct consequence of having several 'root objects' within one logical configuration (non-hierarchical)</div><div><br></div><div>Technically both proposals are fine to me.</div><div>Practically I prefer #1 over #2 because IMO it leads to a clearer API.</div>
<div><br></div><div>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.</div><div><br></div><div>Thanks,</div>
<div>Eugene.</div><div><br></div><div><br></div></div>