Open Stack

Got it. So we will be discussing this in the 2PM meeting today. Correct?

Regards,
Mandeep

On Mon, Oct 27, 2014 at 10:02 AM, Kyle Mestery <mestery at mestery.com> wrote:

> On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami <dhami at noironetworks.com>
> wrote:
> > Hi Kyle:
> >
> > Are you scheduling an on-demand meeting, or are you proposing that the
> > agenda for next neutron meeting include this as an on-demand item?
> >
> Per my email to the list recently [1], the weekly rotating Neutron
> meeting is now an on-demand agenda, rather than a rollup of sub-team
> status. I'm saying this particular topic (advanced services spinout)
> will be discussed in Paris, and it's worth adding it to the weekly
> Neutron meeting [2] agenda in the on-demand section. This is a pretty
> large topic with many interested parties, thus the attention in the
> broader neutron meeting.
>
> Thanks,
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html
> [2] https://wiki.openstack.org/wiki/Network/Meetings
>
> > Regards,
> > Mandeep
> >
> >
> > On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery <mestery at mestery.com>
> wrote:
> >>
> >> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
> >> <sumitnaiksatam at gmail.com> wrote:
> >> > Several people have been requesting that we resume the Advanced
> >> > Services' meetings [1] to discuss some of the topics being mentioned
> >> > in this thread. Perhaps it might help people to have a focussed
> >> > discussion on the topic of "advanced services' spin-out" prior to the
> >> > design summit session [2] in Paris. So I propose that we resume our
> >> > weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
> >> > #openstack-meeting-3.
> >> >
> >> Given how important this is to Neutron in general, I would prefer NOT
> >> to see this discussed in the Advanced Services meeting, but rather in
> >> the regular Neutron meeting. These are the types of things which need
> >> broader oversight and involvement. Lets please discuss this in the
> >> regular Neutron meeting, which is an on-demand meeting format, rather
> >> than in a sub-team meeting.
> >>
> >> > Thanks,
> >> > ~Sumit.
> >> >
> >> > [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
> >> > [2]
> >> >
> http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y
> >> >
> >> > On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
> >> > <skandasw at cisco.com> wrote:
> >> >> Hi Doug:
> >> >>
> >> >> On 10/26/14, 6: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.
> >> >>>
> >> >>>> 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.
> >> >>
> >> >> In total agreement and I have heard these sentiments in multiple
> >> >> conversations across multiple players.
> >> >> It would be really fruitful to have a constructive conversation on
> this
> >> >> across the services, and there are
> >> >> enough similar issues to make this worthwhile.
> >> >>
> >> >> Thanks
> >> >>
> >> >> Sridar
> >> >>
> >> >>>
> >> >>>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/8a0b7c1d64883c08286e4446e163f1a
> >> >>>>>>6
> >> >>>>>>#.
> >> >>>>> >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
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141027/45c61dbc/attachment-0001.html>