Open Stack

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" <jaypipes at 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 <dougw at 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.logan at 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.logan at 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 at lists.openstack.org
> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> OpenStack-dev mailing list
> >>>>>> OpenStack-dev at lists.openstack.org
> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenStack-dev mailing list
> >>>>> OpenStack-dev at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev