<div dir="ltr">+1 to this, eh!<div><br></div><div>Though it sounds more like you're talking about spinning the Octavia user API out of Octavia to become it's own thing (ie. "Openstack LBaaS"), and then ensuring a standardized driver interface that vendors (including Octavia) will interface with. It's sort of a half-dozen of one, six of the other kind of deal.</div><div><br></div><div>To the pros, I would add:  Spin out from Neutron ensures that LBaaS uses "clean" interfaces to the networking layer, and separation of concerns here means that Neutron and LBaaS can evolve independently. (And testing and failure modes, etc. all become easier with separation of concerns.)</div><div><br></div><div>One other thing to consider (not sure if pro or con): I know at Atlanta there was a lot of talk around using the Neutron flavor framework to allow for multiple vendors in a single installation as well as differentiated product offerings for Operators. If / when LBaaS is spun out of Neutron, LBaaS will still probably have need for something like Neutron flavors, even if it isn't an equivalent implementation. (Noting of course, that no implementation of Neutron flavors actually presently exists. XD )</div><div><br></div><div>Stephen</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 24, 2014 at 2:47 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With the recent talk about advanced services spinning out of Neutron,<br>
and the fact most of the LBaaS community has wanted LBaaS to spin out of<br>
Neutron, I wanted to bring up a possibility and gauge interest and<br>
opinion on this possibility.<br>
<br>
Octavia is going to (and has) an API.  The current thinking is that an<br>
Octavia driver will be created in Neutron LBaaS that will make a<br>
requests to the Octavia API.  When LBaaS spins out of Neutron, it will<br>
need a standalone API.  Octavia's API seems to be a good solution to<br>
this.  It will support vendor drivers much like the current Neutron<br>
LBaaS does.  It has a similar API as Neutron LBaaS v2, but its not an<br>
exact duplicate.  Octavia will be growing more mature in stackforge at a<br>
higher velocity than an Openstack project, so I expect by the time Kilo<br>
comes around it's API will be very mature.<br>
<br>
Octavia's API doesn't have to be called Octavia either.  It can be<br>
separated out and it can be called Openstack LBaaS, and the rest of<br>
Octavia (the actual brains of it) will just be another driver to<br>
Openstack LBaaS, which would retain the Octavia name.<br>
<br>
This is my PROS and CONS list to using Octavia's API as the spun out<br>
LBaaS:<br>
<br>
PROS<br>
1. Time will need to be spent on a spun out LBaaS's API anyway.  Octavia<br>
will already have this done.<br>
2. Most of the same people working on Octavia have worked on Neutron<br>
LBaaS v2.<br>
3. It's out of Neutron faster, which is good for Neutron and LBaaS.<br>
<br>
CONS<br>
1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be yet<br>
another version of an LBaaS API.<br>
2. The Octavia API will also have a separate Operator API which will<br>
most likely only work with Octavia, not any vendors.<br>
<br>
The CONS are easily solvable, and IMHO the PROS greatly outweigh the<br>
CONS.<br>
<br>
This is just my opinion though and I'd like to hear back from as many as<br>
possible.  Add on to the PROS and CONS if wanted.<br>
<br>
If it is direction we can agree on going then we can add as a talking<br>
point in the advanced services spin out meeting:<br>
<br>
<a href="http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VEq66HWx3UY" target="_blank">http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VEq66HWx3UY</a><br>
<br>
Thanks,<br>
Brandon<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div>