Open Stack

Kyle, Adam,



Based on this thread Kyle is suggesting the follow moving forward plan:



1) We incubate Neutron LBaaS V2 in the “Neutron” incubator “and freeze
LBaas V1.0”
2) “Eventually” It graduates into a project under the networking program.
3) “At that point” We deprecate Neutron LBaaS v1.



The words in “xx“ are works I added to make sure I/We understand the whole
picture.



And as Adam mentions: Octavia != LBaaS-v2. Octavia is a peer to F5 /
Radware / A10 / etc *appliances* which is a definition I agree with BTW.



What I am trying to now understand is how we will move Octavia into the new
LBaaS project?



If we do it later rather than develop Octavia in tree under the new
incubated LBaaS project when do we plan to bring it in-tree from
Stackforge? Kilo? Later? When LBaaS is a separate project under the
Networking program?



What are the criteria to bring a driver into the LBaaS project and what do
we need to do to replace the existing reference driver? Maybe adding a
software driver to LBaaS source tree is less of a problem than converting a
whole project to an OpenStack project.



Again I am open to both directions I just want to make sure we understand
why we are choosing to do one or the other and that our  decision is based
on data and not emotions.



I am assuming that keeping Octavia in Stackforge will increase the velocity
of the project and allow us more freedom which is goodness. We just need to
have a plan to make it part of the Openstack LBaaS project.



Regards Susanne


On Sat, Aug 30, 2014 at 2:09 PM, Adam Harwell <adam.harwell at rackspace.com>
wrote:

>   Only really have comments on two of your related points:
>
>  [Susanne] To me Octavia is a driver so it is very hard to me to think of
> it as a standalone project. It needs the new Neutron LBaaS v2 to function
> which is why I think of them together. This of course can change since we
> can add whatever layers we want to Octavia.
>
>  [Adam] I guess I've always shared Stephen's viewpoint — Octavia !=
> LBaaS-v2. Octavia is a peer to F5 / Radware / A10 / etc appliances, not
> to an Openstack API layer like Neutron-LBaaS. It's a little tricky to
> clearly define this difference in conversation, and I have noticed that
> quite a few people are having the same issue differentiating. In a small
> group, having quite a few people not on the same page is a bit scary, so
> maybe we need to really sit down and map this out so everyone is together
> one way or the other.
>
>  [Susanne] Ok now I am confused… But I agree with you that it need to
> focus on our use cases. I remember us discussing Octavia being the refenece
> implementation for OpenStack LBaaS (whatever that is). Has that changed
> while I was on vacation?
>
>  [Adam] I believe that having the Octavia "driver" (not the Octavia
> codebase itself, technically) become the reference implementation for
> Neutron-LBaaS is still the plan in my eyes. The Octavia Driver in
> Neutron-LBaaS is a separate bit of code from the actual Octavia project,
> similar to the way the A10 driver is a separate bit of code from the A10
> appliance. To do that though, we need Octavia to be fairly close to fully
> functional. I believe we can do this because even though the reference
> driver would then require an additional service to run, what it requires is
> still fully-open-source and (by way of our plan) available as part of
> OpenStack core.
>
>   --Adam
>
>  https://keybase.io/rm_you
>
>
>   From: Susanne Balle <sleipnir012 at gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Friday, August 29, 2014 9:19 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
>
> Subject: Re: [openstack-dev] [neutron][lbaas][octavia]
>
>    Stephen
>
>
>
> See inline comments.
>
>
>
> Susanne
>
>
>
> -----------------------------------------
>
>
>
> Susanne--
>
>
>
> I think you are conflating the difference between "OpenStack incubation"
> and "Neutron incubator." These are two very different matters and should be
> treated separately. So, addressing each one individually:
>
>
>
> *"OpenStack Incubation"*
>
> I think this has been the end-goal of Octavia all along and continues to
> be the end-goal. Under this scenario, Octavia is its own stand-alone
> project with its own PTL and core developer team, its own governance, and
> should eventually become part of the integrated OpenStack release. No
> project ever starts out as "OpenStack incubated."
>
>
>
> [Susanne] I totally agree that the end goal is for Neutron LBaaS to become
> its own incubated project. I did miss the nuance that was pointed out by
> Mestery in an earlier email that if a Neutron incubator project wants to
> become a separate project it will have to apply for incubation again or at
> that time. It was my understanding that such a Neutron incubated project
> would be grandfathered in but again we do not have much details on the
> process yet.
>
>
>
> To me Octavia is a driver so it is very hard to me to think of it as a
> standalone project. It needs the new Neutron LBaaS v2 to function which is
> why I think of them together. This of course can change since we can add
> whatever layers we want to Octavia.
>
>
>
> *"Neutron Incubator"*
>
> This has only become a serious discussion in the last few weeks and has
> yet to land, so there are many assumptions about this which don't pan out
> (either because of purposeful design and governance decisions, or because
> of how this project actually ends up being implemented from a practical
> standpoint). But given the inherent limitations about making statements
> with so many unknowns, the following seem fairly clear from what has been
> shared so far:
>
> ·  Neutron incubator is the on-ramp for projects which should eventually
> become a part of Neutron itself.
>
> ·  Projects which enter the Neutron incubator on-ramp should be fairly
> close to maturity in their final form. I think the intent here is for them
> to live in incubator for 1 or 2 cycles before either being merged into
> Neutron core, or being ejected (as abandoned, or as a separate project).
>
> ·  Neutron incubator projects effectively do not have their own PTL and
> core developer team, and do not have their own governance.
>
> [Susanne] Ok I missed the last point. In an earlier discussion Mestery
> implied that an incubated project would have at least one or two of its own
> cores. Maybe that changed between now and then.
>
> In addition we know the following about Neutron LBaaS and Octavia:
>
> ·  It's already (informally?) agreed that the ultimate long-term place
> for a LBaaS solution is probably to be spun out into its own project, which
> might appropriately live under a yet-to-be-defined master "Networking"
> project. (This would make Neutron, LBaaS, VPNaaS, FWaaS, etc. effective
> "peer" projects under the Networking umbrella.)  Since this "Networking"
> umbrella project has even less defined about it than Neutron incubator,
> it's impossible to know whether being a part of Neutron incubator would be
> of any benefit to Octavia (or, conversely, to Neutron incubator) at all as
> an on-ramp to becoming part of "Networking." Presumably, Octavia *might* fit
> well under the "Networking" umbrella-- but, again, with nothing defined
> there it's impossible to draw any reasonable conclusions at this time.
>
> [Susanne] We are in agreement here. This was the reasons we had the ad-hoc
> meeting in Atlanta so get a feel for hw people felt if we made Neutron
> LBaaS its own project and also how we got an operator large scale LBaaS
> that fit most of our service provider requirements. I am just worried
> because you keep on talking of Octavia as a standaloe project. To me it is
> an extension of Neutron LBaaS or of a new LBaaS …. I do not see us (== me)
> use Octavia in a non OpenStack context. And yes it is a driver that I am
> hoping we all expect to become the reference implementation for LBaaS.
>
> ·  When the LBaaS component spins out of Neutron, it will more than
> likely not be Octavia.  Octavia is *intentionally* less friendly to 3rd
> party load balancer vendors both because it's envisioned that Octavia would
> just be another implementation which lives along-side said 3rd party vendor
> products (plugging into a higher level LBaaS layer via a driver), and
> because we don't want to have to compromise certain design features of
> Octavia to meet the lowest common denominator 3rd party vendor product.
> (3rd party vendors are welcome, but we will not make design compromises to
> meet the needs of a proprietary product-- compatibility with available
> open-source products and standards trumps this.)
>
> [Susanne] Ok now I am confused… But I agree with you that it need to focus
> on our use cases. I remember us discussing Octavia being the refenece
> implementation for OpenStack LBaaS (whatever that is). Has that changed
> while I was on vacation?
>
> The end-game for the above point is: In the future I see "Openstack LBaaS"
> (or whatever the project calls itself) being a separate but complimentary
> project to Octavia.
>
> ·  While its true that we would like Octavia to become the reference
> implementation for Neutron LBaaS, we are nowhere near being able to deliver
> on that. Attempting to become a part of Neutron LBaaS right now is likely
> just to create frustration (and very little merged code) for both the
> Octavia and Neutron teams.
>
> [Susanne] Agreed.
>
> So given that the only code in Octavia right now are a few database
> migrations, we are very, very far away from being ready for either
> OpenStack incubation or the Neutron incubator project. I don't think it's
> very useful to be spending time right now worrying about either of these
> outcomes:  We should be working on Octavia!
>
> [Susanne] Agreed. You suggested we discuss this on the ML NOW. I wanted to
> wait until the summit given that we would have more info on Neutron
> incubation, etc. I haven’t seen much written down on the Neutron incubator
> project so most of what we are doing is guessing….
>
> Please also understand:  I realize that probably the reason you're asking
> this right now is because you have a mandate within your organization to
> use only "official" OpenStack branded components, and if Octavia doesn't
> fall within that category, you won't be able to use it.  Of course everyone
> working on this project wants to make that happen too, so we're doing
> everything we can to make sure we don't jeopardize that possibility. And
> there are enough voices in this project that want that to happen, so I
> think if we strayed from the path to get there, there would be sufficient
> clangor over this that it would be hard to miss. But I don't think there's
> anyone at all at this time that can honestly give you a promise that
> Octavia definitely will be incubated and will definitely end up in the
> integrated OpenStack release.
>
>
>
> If you want to increase the chances of that happening, please help push
> the project forward!
>
>
>
> [Susanne] That is what HP is doing. Remember we were here from the
> beginning helping change the direction for LBaaS.
>
>
>
> Thanks,
>
> Stephen
>
>
>
>
> On Thu, Aug 28, 2014 at 9:52 PM, Stephen Balukoff <sbalukoff at bluebox.net>
> wrote:
>
>> Susanne--
>>
>>  I think you are conflating the difference between "OpenStack
>> incubation" and "Neutron incubator." These are two very different matters
>> and should be treated separately. So, addressing each one individually:
>>
>>  *"OpenStack Incubation"*
>> I think this has been the end-goal of Octavia all along and continues to
>> be the end-goal. Under this scenario, Octavia is its own stand-alone
>> project with its own PTL and core developer team, its own governance, and
>> should eventually become part of the integrated OpenStack release. No
>> project ever starts out as "OpenStack incubated."
>>
>>  *"Neutron Incubator"*
>> This has only become a serious discussion in the last few weeks and has
>> yet to land, so there are many assumptions about this which don't pan out
>> (either because of purposeful design and governance decisions, or because
>> of how this project actually ends up being implemented from a practical
>> standpoint). But given the inherent limitations about making statements
>> with so many unknowns, the following seem fairly clear from what has been
>> shared so far:
>>
>>    - Neutron incubator is the on-ramp for projects which should
>>    eventually become a part of Neutron itself.
>>    - Projects which enter the Neutron incubator on-ramp should be fairly
>>    close to maturity in their final form. I think the intent here is for them
>>    to live in incubator for 1 or 2 cycles before either being merged into
>>    Neutron core, or being ejected (as abandoned, or as a separate project).
>>    - Neutron incubator projects effectively do not have their own PTL
>>    and core developer team, and do not have their own governance.
>>
>> In addition we know the following about Neutron LBaaS and Octavia:
>>
>>    - It's already (informally?) agreed that the ultimate long-term place
>>    for a LBaaS solution is probably to be spun out into its own project, which
>>    might appropriately live under a yet-to-be-defined master "Networking"
>>    project. (This would make Neutron, LBaaS, VPNaaS, FWaaS, etc. effective
>>    "peer" projects under the Networking umbrella.)  Since this "Networking"
>>    umbrella project has even less defined about it than Neutron incubator,
>>    it's impossible to know whether being a part of Neutron incubator would be
>>    of any benefit to Octavia (or, conversely, to Neutron incubator) at all as
>>    an on-ramp to becoming part of "Networking." Presumably, Octavia
>>    *might* fit well under the "Networking" umbrella-- but, again, with
>>    nothing defined there it's impossible to draw any reasonable conclusions at
>>    this time.
>>    - When the LBaaS component spins out of Neutron, it will more than
>>    likely not be Octavia.  Octavia is *intentionally* less friendly to
>>    3rd party load balancer vendors both because it's envisioned that Octavia
>>    would just be another implementation which lives along-side said 3rd party
>>    vendor products (plugging into a higher level LBaaS layer via a driver),
>>    and because we don't want to have to compromise certain design features of
>>    Octavia to meet the lowest common denominator 3rd party vendor product.
>>    (3rd party vendors are welcome, but we will not make design compromises to
>>    meet the needs of a proprietary product-- compatibility with available
>>    open-source products and standards trumps this.)
>>    - The end-game for the above point is: In the future I see "Openstack
>>    LBaaS" (or whatever the project calls itself) being a separate but
>>    complimentary project to Octavia.
>>    - While its true that we would like Octavia to become the reference
>>    implementation for Neutron LBaaS, we are nowhere near being able to deliver
>>    on that. Attempting to become a part of Neutron LBaaS right now is likely
>>    just to create frustration (and very little merged code) for both the
>>    Octavia and Neutron teams.
>>
>>
>>
>>  So given that the only code in Octavia right now are a few database
>> migrations, we are very, very far away from being ready for either
>> OpenStack incubation or the Neutron incubator project. I don't think it's
>> very useful to be spending time right now worrying about either of these
>> outcomes:  We should be working on Octavia!
>>
>>  Please also understand:  I realize that probably the reason you're
>> asking this right now is because you have a mandate within your
>> organization to use only "official" OpenStack branded components, and if
>> Octavia doesn't fall within that category, you won't be able to use it.  Of
>> course everyone working on this project wants to make that happen too, so
>> we're doing everything we can to make sure we don't jeopardize that
>> possibility. And there are enough voices in this project that want that to
>> happen, so I think if we strayed from the path to get there, there would be
>> sufficient clangor over this that it would be hard to miss. But I don't
>> think there's anyone at all at this time that can honestly give you a
>> promise that Octavia definitely will be incubated and will definitely end
>> up in the integrated OpenStack release.
>>
>>  If you want to increase the chances of that happening, please help push
>> the project forward!
>>
>>  Thanks,
>> Stephen
>>
>>
>>
>>  On Thu, Aug 28, 2014 at 2:57 PM, Susanne Balle <sleipnir012 at gmail.com>
>> wrote:
>>
>>>    I would like to discuss the pros and cons of putting Octavia into
>>> the Neutron LBaaS incubator project right away. If it is going to be the
>>> reference implementation for LBaaS v 2 then I believe Octavia belong in
>>> Neutron LBaaS v2 incubator.
>>>
>>>  The Pros:
>>>  * Octavia is in Openstack incubation right away along with the lbaas v2
>>> code. We do not have to apply for incubation later on.
>>>  * As incubation project we have our own core and should be able ot
>>> commit our code
>>>  * We are starting out as an OpenStack incubated project
>>>
>>>  The Cons:
>>>  * Not sure of the velocity of the project
>>>  * Incubation not well defined.
>>>
>>>  If Octavia starts as a standalone stackforge project we are assuming
>>> that it would be looked favorable on when time is to move it into incubated
>>> status.
>>>
>>>  Susanne
>>>
>>>
>>>
>>>  _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>>  --
>> Stephen Balukoff
>> Blue Box Group, LLC
>> (800)613-4305 x807
>>
>> _______________________________________________
>> 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/20140901/b4bc8f54/attachment.html>