<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Ok. cool. thanks. :)<br>
<br>
Kevin<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF31790"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Kevin Benton [kevin@benton.pub]<br>
<b>Sent:</b> Wednesday, November 09, 2016 1:43 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">The people working on the migration are ensuring API compatibility and are even leaving in a shim on the Neutron side for some time so you don't even have to change endpoints initially. It should be a seamless change.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M <span dir="ltr">
<<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">Just please don't make this a lbv3 thing that completely breaks compatibility of existing lb's yet again. If its just an "point url endpoint from thing like x to thing like y" in
 one place, thats ok. I still have v1 lb's in existence though I have to deal with and a backwards incompatible v3 would just cause me to abandon lbaas all together I think as it would show the lbaas stuff is just not maintainable.<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family:Times New Roman; color:#000000; font-size:16px">
<hr>
<div id="m_7254127914907924311divRpF44932" style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Armando M. [<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>]<br>
<b>Sent:</b> Wednesday, November 09, 2016 8:05 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap<br>
</font><br>
</div>
<div>
<div class="h5">
<div></div>
<div>
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 9 November 2016 at 05:50, Gary Kotton <span dir="ltr">
<<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
Hi,<br>
What about neutron-lbaas project? Is this project still alive and kicking to the merge is done or are we going to continue to maintain it? I feel like we are between a rock and a hard place here. LBaaS is in production and it is not clear the migration process.
 Will Octavia have the same DB models as LBaaS or will there be a migration?<br>
Sorry for the pessimism but I feel that things are very unclear and that we cannot even indicate to our community/consumers what to use/expect.<br>
Thanks<br>
<span class="m_7254127914907924311gmail-HOEnZb"><font color="#888888">Gary<br>
</font></span></blockquote>
<div><br>
</div>
<div><a href="http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html" target="_blank">http://specs.openstack.org/<wbr>openstack/neutron-specs/specs/<wbr>newton/kill-neutron-lbaas.html</a></div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<span class="m_7254127914907924311gmail-HOEnZb"><font color="#888888"></font></span>
<div class="m_7254127914907924311gmail-HOEnZb">
<div class="m_7254127914907924311gmail-h5"><br>
On 11/8/16, 1:36 AM, "Michael Johnson" <<a href="mailto:johnsomor@gmail.com" target="_blank">johnsomor@gmail.com</a>> wrote:<br>
<br>
    Ocata LBaaS retrospective and next steps recap<br>
    ------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
    This session lightly touched on the work in the newton cycle, but<br>
    primarily focused on planning for the Ocata release and the LBaaS spin<br>
    out of neutron and merge into the octavia project [1].  Notes were<br>
    captured on the etherpad [1].<br>
<br>
    The focus of work for Ocata in neutron-lbaas and octavia will be on<br>
    the spin out/merge and not new features.<br>
<br>
    Work has started on merging neutron-lbaas into the octavia project<br>
    with API sorting/pagination, quota support, keystone integration,<br>
    neutron-lbaas driver shim, and documentation updates.  Work is still<br>
    needed for policy support, the API shim to handle capability gaps<br>
    (example: stats are by listener in octavia, but by load balancer in<br>
    neturon-lbaas), neutron api proxy, a database migration script from<br>
    the neutron database to the octavia database for existing non-octavia<br>
    load balancers, and adding the "bug for bug" neutron-lbaas v2 API to<br>
    the octavia API server.<br>
<br>
    The room agreed that since we will have a shim/proxy in neutron for<br>
    some time, updating the OpenStack client can be deferred to a future<br>
    cycle.<br>
<br>
    There is a lot of concern about Ocata being a short cycle and the<br>
    amount of work to be done.  There is hope that additional resources<br>
    will help out with this task to allow us to complete the spin<br>
    out/merge for Ocata.<br>
<br>
    We discussed the current state of the active/active topology patches<br>
    and agreed that it is unlikely this will merge in Ocata.  There are a<br>
    lot of open comments and work to do on the patches.  It appears that<br>
    these patches may have been created against an old release and require<br>
    significant updating.<br>
<br>
    Finally there was a question about when octavia would implement<br>
    metadata tags.  When we dug into the need for the tags we found that<br>
    what was really wanted is a full implementation of the flavors<br>
    framework [3] [4].  Some vendors expressed interest in finishing the<br>
    flavors framework for Octavia.<br>
<br>
    Thank you to everyone that participated in our design session and etherpad.<br>
<br>
    Michael<br>
<br>
    [1] <a href="https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html" rel="noreferrer" target="_blank">
https://specs.openstack.org/op<wbr>enstack/neutron-specs/specs/ne<wbr>wton/kill-neutron-lbaas.html</a><br>
    [2] <a href="https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session" rel="noreferrer" target="_blank">
https://etherpad.openstack.org<wbr>/p/ocata-neutron-octavia-lbaas<wbr>-session</a><br>
    [3] <a href="https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates.html" rel="noreferrer" target="_blank">
https://specs.openstack.org/op<wbr>enstack/neutron-specs/specs/mi<wbr>taka/neutron-flavor-framework-<wbr>templates.html</a><br>
    [4] <a href="https://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html" rel="noreferrer" target="_blank">
https://specs.openstack.org/op<wbr>enstack/neutron-specs/specs/li<wbr>berty/neutron-flavor-framework<wbr>.html</a><br>
<br>
    ______________________________<wbr>______________________________<wbr>______________<br>
    OpenStack Development Mailing List (not for usage questions)<br>
    Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">
http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>