<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Kyle:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</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 class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 27, 2014 at 6:56 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 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>
</span>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>
<div class="HOEnZb"><div class="h5"><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] <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 the<br>
>>>> harm in opinions being discussed before the summit, during the 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. We<br>
>>>love each other. Check. Things are going to change sometime. Check. We<br>
>>>might spin-out someday. Check. Now, let¹s jump to the interesting part.<br>
>>><br>
>>>> 3. The main reason a spin out makes sense from Neutron is that the scope<br>
>>>> for Neutron is too large for the attention advances services needs 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 in a<br>
>>>basically defensive manner, instead of leveraging other work. And there<br>
>>>are specific reasons for that. But, maybe we can at least take steps to<br>
>>>not be incompatible about it. Or maybe there is a hierarchy of Neutron -><br>
>>>Services -> LB, where we¹re still spun out, but not doing it in a way 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>> 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 scope<br>
>>>>for Neutron is too large for the attention advances services needs 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 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 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 team²)<br>
>>>>>have<br>
>>>>> had the Paris summit discussions on vendor split-out and adv. 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, 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 Neutron,<br>
>>>>> >and the fact most of the LBaaS community has wanted LBaaS to spin 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 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 will<br>
>>>>> >need a standalone API. Octavia's API seems to be a good solution 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 an<br>
>>>>> >exact duplicate. Octavia will be growing more mature in stackforge 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 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 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 will<br>
>>>>> >most likely only work with Octavia, not any vendors.<br>
>>>>> ><br>
>>>>> >The CONS are easily solvable, and IMHO the PROS greatly outweigh the<br>
>>>>> >CONS.<br>
>>>>> ><br>
>>>>> >This is just my opinion though and I'd like to hear back from as 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 talking<br>
>>>>> >point in the advanced services spin out meeting:<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>
</div></div></blockquote></div><br></div>