Hi Jay, Just so you have some information on the API before the meeting here is the spec for it:
https://review.openstack.org/#/c/122338/ I'm sure there is a lot of details that might be missing but it should give you a decent idea. Sorry for the markup/markdown being dumb if you try to build with spinx. Probably easier to just read the raw .rst file. Thanks, Brandon On Mon, 2014-10-27 at 14:05 -0400, Jay Pipes wrote: > Yup, can do! :) > > -jay > > On 10/27/2014 01:55 PM, Doug Wiegley wrote: > > 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 > > > > _______________________________________________ > 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