<div dir="ltr">Hi neutron folks and everyone interested in LBaaS,<div><br></div><div><br></div><div>Let's meet as usual on #openstack-meeting at 14-00 UTC.</div><div><br></div><div>The meeting agenda will be mostly around schema change.</div>
<div>Please look over ML discussion and this link:</div><div><a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion</a><br>
</div><div><br></div><div>Currently we are evaluating the approach #3.</div><div>I'd urge everyone to focus on the discussion of the basic object relationships </div><div>(vips/pools/listeners/healthmons/members). </div>
<div>I think the best outcome of the meeting should be:</div><div>1) define attribute sets for pool, vip, listener</div><div>2) agree on compatibility mode in which we will introduce the new model</div><div>3) discuss and agree on API limitation in favor of code simplicity.</div>
<div>The limitation is that we will require user to manually envelope complex configurations that involve</div><div>multiple vips and pools into a single instance. </div><div>That limitation can be omitted later when we figure out how is it better to deal with multiple backends serving the configuration.</div>
<div><br></div><div>I think (3) is pretty important: there is already a line of patches depending on the model change.</div><div>More complex change will put more pressure on both developers, reviewers and all those who depend on the change, so more simple approach at the cost of API "limitation" is something we may consider.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div>