<div dir="ltr">Hi folks,<div><br></div><div>At this point we have a few major action items, mostly patches on review.</div><div>Please note that the gate is in pretty bad shape, so don't expect anything to be approved/merged until this is sorted out.</div>
<div><br></div><div>1) SSL extension</div><div><a href="https://review.openstack.org/#/c/63510/">https://review.openstack.org/#/c/63510/</a><br></div><div>The code here is in a good shape IMO, but we are yet undecided on the general approach.</div>
<div>In my opinion while we are lacking good and stable open source solution (which is Haproxy 1.5 released) that can be made a vendor extension with a prospect of moving into the core lbaas API.</div><div><br></div><div>
2) Loadbalancer instance</div><div><a href="https://review.openstack.org/#/c/60207/">https://review.openstack.org/#/c/60207/</a><br></div><div>New API made fully backward-compatible.</div><div>As new drivers appear (like <a href="https://review.openstack.org/#/c/67405/">https://review.openstack.org/#/c/67405/</a> ) the code shows the need of container entity to bind entities like router, device, agents.</div>
<div><br></div><div>3) Multiple providers with the same driver</div><div><a href="https://review.openstack.org/#/c/64139/">https://review.openstack.org/#/c/64139/</a></div><div>The code is good to merge, we need for the gate to be stable.</div>
<div><br></div><div>4) L7 rules</div><div><a href="https://review.openstack.org/#/c/61721/">https://review.openstack.org/#/c/61721/</a></div><div>My concern here is  how Vip and Pool are associated. I think it could be made more generic.</div>
<div>I've left corresponding comments.</div><div><br></div><div>5) We have lbaas scenario test which is still waiting to be merged:</div><div><a href="https://review.openstack.org/#/c/58697/">https://review.openstack.org/#/c/58697/</a><br>
</div><div><br></div><div>We'll have a regular irc meeting tomorrow at 14-00 UTC on #openstack-meeting.</div><div>I'd like to discuss primarily 1 item which is 'uneven API experience',</div><div>which could be divided into two distinct parts:</div>
<div> - Presenting different API for different drivers (e.g. justification for vendor extension framework)</div><div> - Generic API experience</div><div>On the (2) I'd like to discuss the concern that I've raised in <a href="https://review.openstack.org/#/c/68190/">https://review.openstack.org/#/c/68190/</a></div>
<div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div>