Hi Jay, Let’s add that as an agenda item at our Weekly IRC meeting. Can you make this timeslot?
https://wiki.openstack.org/wiki/Octavia#Meetings Thanks, Doug On 10/27/14, 11:27 AM, "Jay Pipes" <jaypi...@gmail.com> wrote: >Sorry for top-posting, but where can the API working group see the >proposed Octavia API specification or documentation? I'd love it if the >API WG could be involved in reviewing the public REST API. > >Best, >-jay > >On 10/27/2014 10:01 AM, Kyle Mestery wrote: >> On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley <do...@a10networks.com> >>wrote: >>> Hi Brandon, >>> >>>> 4. I brought this up now so that we can decide whether we want to >>>> discuss it at the advanced services spin out session. I don't see the >>>> harm in opinions being discussed before the summit, during the summit, >>>> and more thoroughly after the summit. >>> >>> I agree with this sentiment. I’d just like to pull-up to the decision >>> level, and if we can get some consensus on how we move forward, we can >>> bring a concrete plan to the summit instead of 40 minutes of Kumbaya. >>>We >>> love each other. Check. Things are going to change sometime. Check. >>> We >>> might spin-out someday. Check. Now, let’s jump to the interesting >>>part. >>> >> I think we all know we want to spin these out, as Doug says we just >> need to have a plan around how we make that happen. I'm in agreement >> with Doug's sentiment above. >> >>>> 3. The main reason a spin out makes sense from Neutron is that the >>>>scope >>>> for Neutron is too large for the attention advances services needs >>>>from >>>> the Neutron Core. If all of advanced services spins out, I see that >>> >>> There is merit here, but consider the sorts of things that an advanced >>> services framework should be doing: >>> >>> - plugging into neutron ports, with all manner of topologies >>> - service VM handling >>> - plugging into nova-network >>> - service chaining >>> - applying things like security groups to services >>> >>> … this is all stuff that Octavia is talking about implementing itself >>>in a >>> basically defensive manner, instead of leveraging other work. And >>>there >>> are specific reasons for that. But, maybe we can at least take steps >>>to >>> not be incompatible about it. Or maybe there is a hierarchy of >>>Neutron -> >>> Services -> LB, where we’re still spun out, but not doing it in a way >>>that >>> we have to re-implement the world all the time. It’s at least worth a >>> conversation or three. >>> >> Doug, can you document this on the etherpad for the "services spinout" >> [1]? I've added some brief text at the top on what the objective for >> this session is, but documenting more along the lines of what you have >> here would be good. >> >> Thanks, >> Kyle >> >> [1] https://etherpad.openstack.org/p/neutron-services >> >>> Thanks, >>> Doug >>> >>> >>> >>> >>> On 10/26/14, 6:35 PM, "Brandon Logan" <brandon.lo...@rackspace.com> >>>wrote: >>> >>>> Good questions Doug. My answers are as follows: >>>> >>>> 1. Yes >>>> 2. Some time after Kilo (same as I don't know when) >>>> 3. The main reason a spin out makes sense from Neutron is that the >>>>scope >>>> for Neutron is too large for the attention advances services needs >>>>from >>>> the Neutron Core. If all of advanced services spins out, I see that >>>> repeating itself within an advanced services project. More and more >>>> "advanced services" will get added in and the scope will become too >>>> large. There would definitely be benefits to it though, but I think >>>>we >>>> would end up being right where we are today. >>>> 4. I brought this up now so that we can decide whether we want to >>>> discuss it at the advanced services spin out session. I don't see the >>>> harm in opinions being discussed before the summit, during the summit, >>>> and more thoroughly after the summit. >>>> >>>> Yes the brunt of the time will not be spent on the API, but since it >>>> seemed like an opportunity to kill two birds with one stone, I figured >>>> it warranted a discussion. >>>> >>>> Thanks, >>>> Brandon >>>> >>>> On Sun, 2014-10-26 at 23:15 +0000, Doug Wiegley wrote: >>>>> Hi all, >>>>> >>>>> Before we get into the details of which API goes where, I’d like to >>>>>see >>>>> us >>>>> answer the questions of: >>>>> >>>>> 1. Are we spinning out? >>>>> 2. When? >>>>> 3. With or without the rest of advanced services? >>>>> 4. Do we want to wait until we (the royal “we” of “the Neutron team”) >>>>> have >>>>> had the Paris summit discussions on vendor split-out and adv. >>>>>services >>>>> spinout before we answer those questions? (Yes, that question is >>>>> leading.) >>>>> >>>>> To me, the “where does the API live” is an implementation detail, and >>>>> not >>>>> where the time will need to be spent. >>>>> >>>>> For the record, my answers are: >>>>> >>>>> 1. Yes. >>>>> 2. I don’t know. >>>>> 3. I don’t know; this needs some serious discussion. >>>>> 4. Yes. >>>>> >>>>> Thanks, >>>>> doug >>>>> >>>>> On 10/24/14, 3:47 PM, "Brandon Logan" <brandon.lo...@rackspace.com> >>>>> wrote: >>>>> >>>>>> With the recent talk about advanced services spinning out of >>>>>>Neutron, >>>>>> and the fact most of the LBaaS community has wanted LBaaS to spin >>>>>>out >>>>> of >>>>>> Neutron, I wanted to bring up a possibility and gauge interest and >>>>>> opinion on this possibility. >>>>>> >>>>>> Octavia is going to (and has) an API. The current thinking is that >>>>>>an >>>>>> Octavia driver will be created in Neutron LBaaS that will make a >>>>>> requests to the Octavia API. When LBaaS spins out of Neutron, it >>>>>>will >>>>>> need a standalone API. Octavia's API seems to be a good solution to >>>>>> this. It will support vendor drivers much like the current Neutron >>>>>> LBaaS does. It has a similar API as Neutron LBaaS v2, but its not >>>>>>an >>>>>> exact duplicate. Octavia will be growing more mature in stackforge >>>>>>at >>>>> a >>>>>> higher velocity than an Openstack project, so I expect by the time >>>>>>Kilo >>>>>> comes around it's API will be very mature. >>>>>> >>>>>> Octavia's API doesn't have to be called Octavia either. It can be >>>>>> separated out and it can be called Openstack LBaaS, and the rest of >>>>>> Octavia (the actual brains of it) will just be another driver to >>>>>> Openstack LBaaS, which would retain the Octavia name. >>>>>> >>>>>> This is my PROS and CONS list to using Octavia's API as the spun out >>>>>> LBaaS: >>>>>> >>>>>> PROS >>>>>> 1. Time will need to be spent on a spun out LBaaS's API anyway. >>>>> Octavia >>>>>> will already have this done. >>>>>> 2. Most of the same people working on Octavia have worked on Neutron >>>>>> LBaaS v2. >>>>>> 3. It's out of Neutron faster, which is good for Neutron and LBaaS. >>>>>> >>>>>> CONS >>>>>> 1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be >>>>>>yet >>>>>> another version of an LBaaS API. >>>>>> 2. The Octavia API will also have a separate Operator API which will >>>>>> most likely only work with Octavia, not any vendors. >>>>>> >>>>>> The CONS are easily solvable, and IMHO the PROS greatly outweigh the >>>>>> CONS. >>>>>> >>>>>> This is just my opinion though and I'd like to hear back from as >>>>>>many >>>>> as >>>>>> possible. Add on to the PROS and CONS if wanted. >>>>>> >>>>>> If it is direction we can agree on going then we can add as a >>>>>>talking >>>>>> point in the advanced services spin out meeting: >>>>>> >>>>> >>>>>> >>>>>>http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f >>>>>>1a6 >>>>>> #. >>>>>> VEq66HWx3UY >>>>>> >>>>>> Thanks, >>>>>> Brandon >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> OpenStack-dev@lists.openstack.org >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev