<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Got it. So we will be discussing this in the 2PM meeting today. Correct?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Regards,</div><div class="gmail_default" style="font-size:small">Mandeep</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 27, 2014 at 10:02 AM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami <<a href="mailto:dhami@noironetworks.com">dhami@noironetworks.com</a>> wrote:<br>
> Hi Kyle:<br>
><br>
> Are you scheduling an on-demand meeting, or are you proposing that the<br>
> agenda for next neutron meeting include this as an on-demand item?<br>
><br>
</span>Per my email to the list recently [1], the weekly rotating Neutron<br>
meeting is now an on-demand agenda, rather than a rollup of sub-team<br>
status. I'm saying this particular topic (advanced services spinout)<br>
will be discussed in Paris, and it's worth adding it to the weekly<br>
Neutron meeting [2] agenda in the on-demand section. This is a pretty<br>
large topic with many interested parties, thus the attention in the<br>
broader neutron meeting.<br>
<br>
Thanks,<br>
Kyle<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html</a><br>
[2] <a href="https://wiki.openstack.org/wiki/Network/Meetings" target="_blank">https://wiki.openstack.org/wiki/Network/Meetings</a><br>
<div class="HOEnZb"><div class="h5"><br>
> Regards,<br>
> Mandeep<br>
><br>
><br>
> On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery <<a href="mailto:mestery@mestery.com">mestery@mestery.com</a>> wrote:<br>
>><br>
>> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam<br>
>> <<a href="mailto:sumitnaiksatam@gmail.com">sumitnaiksatam@gmail.com</a>> wrote:<br>
>> > Several people have been requesting that we resume the Advanced<br>
>> > Services' meetings [1] to discuss some of the topics being mentioned<br>
>> > in this thread. Perhaps it might help people to have a focussed<br>
>> > discussion on the topic of "advanced services' spin-out" prior to the<br>
>> > design summit session [2] in Paris. So I propose that we resume our<br>
>> > weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on<br>
>> > #openstack-meeting-3.<br>
>> ><br>
>> Given how important this is to Neutron in general, I would prefer NOT<br>
>> to see this discussed in the Advanced Services meeting, but rather in<br>
>> the regular Neutron meeting. These are the types of things which need<br>
>> broader oversight and involvement. Lets please discuss this in the<br>
>> regular Neutron meeting, which is an on-demand meeting format, rather<br>
>> than in a sub-team meeting.<br>
>><br>
>> > Thanks,<br>
>> > ~Sumit.<br>
>> ><br>
>> > [1] <a href="https://wiki.openstack.org/wiki/Meetings/AdvancedServices" target="_blank">https://wiki.openstack.org/wiki/Meetings/AdvancedServices</a><br>
>> > [2]<br>
>> > <a href="http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y" target="_blank">http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y</a><br>
>> ><br>
>> > On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)<br>
>> > <<a href="mailto:skandasw@cisco.com">skandasw@cisco.com</a>> wrote:<br>
>> >> Hi Doug:<br>
>> >><br>
>> >> On 10/26/14, 6:01 PM, "Doug Wiegley" <<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>> wrote:<br>
>> >><br>
>> >>>Hi Brandon,<br>
>> >>><br>
>> >>>> 4. I brought this up now so that we can decide whether we want to<br>
>> >>>> discuss it at the advanced services spin out session.  I don't see<br>
>> >>>> the<br>
>> >>>> harm in opinions being discussed before the summit, during the<br>
>> >>>> summit,<br>
>> >>>> and more thoroughly after the summit.<br>
>> >>><br>
>> >>>I agree with this sentiment.  I¹d just like to pull-up to the decision<br>
>> >>>level, and if we can get some consensus on how we move forward, we can<br>
>> >>>bring a concrete plan to the summit instead of 40 minutes of Kumbaya.<br>
>> >>> We<br>
>> >>>love each other.  Check.  Things are going to change sometime.  Check.<br>
>> >>> We<br>
>> >>>might spin-out someday.  Check.  Now, let¹s jump to the interesting<br>
>> >>> part.<br>
>> >>><br>
>> >>>> 3. The main reason a spin out makes sense from Neutron is that the<br>
>> >>>> scope<br>
>> >>>> for Neutron is too large for the attention advances services needs<br>
>> >>>> from<br>
>> >>>> the Neutron Core.  If all of advanced services spins out, I see that<br>
>> >>><br>
>> >>>There is merit here, but consider the sorts of things that an advanced<br>
>> >>>services framework should be doing:<br>
>> >>><br>
>> >>>- plugging into neutron ports, with all manner of topologies<br>
>> >>>- service VM handling<br>
>> >>>- plugging into nova-network<br>
>> >>>- service chaining<br>
>> >>>- applying things like security groups to services<br>
>> >>><br>
>> >>>Š this is all stuff that Octavia is talking about implementing itself<br>
>> >>> in a<br>
>> >>>basically defensive manner, instead of leveraging other work.  And<br>
>> >>> there<br>
>> >>>are specific reasons for that.  But, maybe we can at least take steps<br>
>> >>> to<br>
>> >>>not be incompatible about it.  Or maybe there is a hierarchy of Neutron<br>
>> >>> -><br>
>> >>>Services -> LB, where we¹re still spun out, but not doing it in a way<br>
>> >>> that<br>
>> >>>we have to re-implement the world all the time.  It¹s at least worth a<br>
>> >>>conversation or three.<br>
>> >><br>
>> >> In total agreement and I have heard these sentiments in multiple<br>
>> >> conversations across multiple players.<br>
>> >> It would be really fruitful to have a constructive conversation on this<br>
>> >> across the services, and there are<br>
>> >> enough similar issues to make this worthwhile.<br>
>> >><br>
>> >> Thanks<br>
>> >><br>
>> >> Sridar<br>
>> >><br>
>> >>><br>
>> >>>Thanks,<br>
>> >>>Doug<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>>On 10/26/14, 6:35 PM, "Brandon Logan" <<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>><br>
>> >>> wrote:<br>
>> >>><br>
>> >>>>Good questions Doug.  My answers are as follows:<br>
>> >>>><br>
>> >>>>1. Yes<br>
>> >>>>2. Some time after Kilo (same as I don't know when)<br>
>> >>>>3. The main reason a spin out makes sense from Neutron is that the<br>
>> >>>> scope<br>
>> >>>>for Neutron is too large for the attention advances services needs<br>
>> >>>> from<br>
>> >>>>the Neutron Core.  If all of advanced services spins out, I see that<br>
>> >>>>repeating itself within an advanced services project.  More and more<br>
>> >>>>"advanced services" will get added in and the scope will become too<br>
>> >>>>large.  There would definitely be benefits to it though, but I think<br>
>> >>>> we<br>
>> >>>>would end up being right where we are today.<br>
>> >>>>4. I brought this up now so that we can decide whether we want to<br>
>> >>>>discuss it at the advanced services spin out session.  I don't see the<br>
>> >>>>harm in opinions being discussed before the summit, during the summit,<br>
>> >>>>and more thoroughly after the summit.<br>
>> >>>><br>
>> >>>>Yes the brunt of the time will not be spent on the API, but since it<br>
>> >>>>seemed like an opportunity to kill two birds with one stone, I figured<br>
>> >>>>it warranted a discussion.<br>
>> >>>><br>
>> >>>>Thanks,<br>
>> >>>>Brandon<br>
>> >>>><br>
>> >>>>On Sun, 2014-10-26 at 23:15 +0000, Doug Wiegley wrote:<br>
>> >>>>> Hi all,<br>
>> >>>>><br>
>> >>>>> Before we get into the details of which API goes where, I¹d like to<br>
>> >>>>> see<br>
>> >>>>>us<br>
>> >>>>> answer the questions of:<br>
>> >>>>><br>
>> >>>>> 1. Are we spinning out?<br>
>> >>>>> 2. When?<br>
>> >>>>> 3. With or without the rest of advanced services?<br>
>> >>>>> 4. Do we want to wait until we (the royal ³we² of ³the Neutron<br>
>> >>>>> team²)<br>
>> >>>>>have<br>
>> >>>>> had the Paris summit discussions on vendor split-out and adv.<br>
>> >>>>> services<br>
>> >>>>> spinout before we answer those questions?  (Yes, that question is<br>
>> >>>>>leading.)<br>
>> >>>>><br>
>> >>>>> To me, the ³where does the API live² is an implementation detail,<br>
>> >>>>> and<br>
>> >>>>>not<br>
>> >>>>> where the time will need to be spent.<br>
>> >>>>><br>
>> >>>>> For the record, my answers are:<br>
>> >>>>><br>
>> >>>>> 1. Yes.<br>
>> >>>>> 2. I don¹t know.<br>
>> >>>>> 3. I don¹t know; this needs some serious discussion.<br>
>> >>>>> 4. Yes.<br>
>> >>>>><br>
>> >>>>> Thanks,<br>
>> >>>>> doug<br>
>> >>>>><br>
>> >>>>> On 10/24/14, 3:47 PM, "Brandon Logan" <<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>><br>
>> >>>>>wrote:<br>
>> >>>>><br>
>> >>>>> >With the recent talk about advanced services spinning out of<br>
>> >>>>> > Neutron,<br>
>> >>>>> >and the fact most of the LBaaS community has wanted LBaaS to spin<br>
>> >>>>> > out<br>
>> >>>>>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<br>
>> >>>>> > 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<br>
>> >>>>> > will<br>
>> >>>>> >need a standalone API.  Octavia's API seems to be a good solution<br>
>> >>>>> > 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<br>
>> >>>>> > an<br>
>> >>>>> >exact duplicate.  Octavia will be growing more mature in stackforge<br>
>> >>>>> > at<br>
>> >>>>>a<br>
>> >>>>> >higher velocity than an Openstack project, so I expect by the time<br>
>> >>>>>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<br>
>> >>>>> > out<br>
>> >>>>> >LBaaS:<br>
>> >>>>> ><br>
>> >>>>> >PROS<br>
>> >>>>> >1. Time will need to be spent on a spun out LBaaS's API anyway.<br>
>> >>>>>Octavia<br>
>> >>>>> >will already have this done.<br>
>> >>>>> >2. Most of the same people working on Octavia have worked on<br>
>> >>>>> > 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<br>
>> >>>>>yet<br>
>> >>>>> >another version of an LBaaS API.<br>
>> >>>>> >2. The Octavia API will also have a separate Operator API which<br>
>> >>>>> > will<br>
>> >>>>> >most likely only work with Octavia, not any vendors.<br>
>> >>>>> ><br>
>> >>>>> >The CONS are easily solvable, and IMHO the PROS greatly outweigh<br>
>> >>>>> > the<br>
>> >>>>> >CONS.<br>
>> >>>>> ><br>
>> >>>>> >This is just my opinion though and I'd like to hear back from as<br>
>> >>>>> > many<br>
>> >>>>>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<br>
>> >>>>> > talking<br>
>> >>>>> >point in the advanced services spin out meeting:<br>
>> >>>>> ><br>
>> >>>>><br>
>><br>
>> >>>>>> >>>>>><a href="http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a" target="_blank">http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a</a><br>
>> >>>>>>6<br>
>> >>>>>>#.<br>
>> >>>>> >VEq66HWx3UY<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>
>> >>>>><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>
>> >>>><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>
>> >>><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>
>> >><br>
>> >><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>
>> ><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>
>><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>
><br>
><br>
><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>
><br>
<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>
</div></div></blockquote></div><br></div>