Open Stack

To me, and i could got it wrong, the stadium means two main things: (At
this point in time)

1) Remove/ease the burden of OpenStack governance and extra job for
projects/drivers that implement Neutron and are "relatively small"
    This saves the projects that just want to implement Neutron to be
managed with the same infrastructure but not deal
    with a lot of extra stuff (That same extra stuff you are complaining
about and i totally understand where you coming from..)

2) Be able to set a standard of "quality" (and this needs to be better
defined) for all the drivers that implement Neutron, and
    also set a standard for development process (specs, bugs, priorities,
CI, testing)

With this definition, it first means to me, as Russell suggested, that
Kuryr should be an independent project.
Regarding Dragonflow and Octavia i am not sure yet but lean to the same
conclusion as Russell.

In order to solve some of the problems you mention, I suggest the following:

1) Define a set of responsibilities/guidelines for the sub-projects
lieutenants in order to comply with the "quality" standard
    If they fail to do it with no good explanation for X cycles, the
project should be removed from the stadium.

2) As suggested, delegate and increase the team size that is responsible to
verify and help these projects with the extra work.
    I am sure there are people willing to volunteer and help with these
tasks, and test periods could be applied for trust issues.
    I believe we all want to see Neutron and OpenStack succeed.

I dont see how just moving this work to the TC or any other centralized
group in OpenStack is going to help, i think we
want to strive to group common work to parents projects, especially in this
case (in my opinion anyway).

I think this can be very handy when we will want our processes (at least in
the Neutron world) to be similar and
complimenting.

Just the way i see things right now..

Gal.




On Tue, Dec 1, 2015 at 9:10 AM, Armando M. <armamig at gmail.com> wrote:

>
>
> On 30 November 2015 at 20:11, Russell Bryant <rbryant at redhat.com> wrote:
>
>> Some additional context: there are a few proposals for additional git
>> repositories for Neutron that have been put on hold while we sort this
>> out.
>>
>> Add networking-bagpipe:
>>   https://review.openstack.org/#/c/244736/
>>
>> Add the Astara driver:
>>   https://review.openstack.org/#/c/230699/
>>
>> Add tap-as-a-service:
>>   https://review.openstack.org/#/c/229869/
>>
>> On 11/30/2015 07:56 PM, Armando M. wrote:
>> > I would like to suggest that we evolve the structure of the Neutron
>> > governance, so that most of the deliverables that are now part of the
>> > Neutron stadium become standalone projects that are entirely
>> > self-governed (they have their own core/release teams, etc). In order to
>> > denote the initiatives that are related to Neutron I would like to
>> > present two new tags that projects can choose to label themselves with:
>> >
>> >   * 'is-neutron-subsystem': this means that the project provides
>> >     networking services by implementing an integral part (or parts) of
>> >     an end-to-end neutron system. Examples are: a service plugin, an ML2
>> >     mech driver, a monolithic plugin, an agent etc. It's something an
>> >     admin has to use in order to deploy Neutron in a certain
>> configuration.
>> >   * 'use-neutron-system': this means that the project provides
>> >     networking services by using a pre-deployed end-to-end neutron
>> >     system as is. No modifications whatsoever.
>>
>> I just want to clarify the proposal.  IIUC, you propose splitting most
>> of what is currently separately deliverables of the Neutron team and
>> making them separate projects in terms of OpenStack governance.  When I
>> originally proposed including networking-ovn under Neutron (and more
>> generally, making room for all drivers to be included), making them
>> separate projects was one of the options on the table, but it didn't
>> seem best at the time.  For reference, that thread was here:
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062310.html
>>
>> When I was originally proposing this, I was only thinking about Neutron
>> drivers, the stuff that connects Neutron to some other system to make
>> Neutron do something.  The list has grown to include other things, as
>> well.
>>
>> I'm not sure where you propose the line to be, but for the sake of
>> discussion, let's assume every deliverable in the governance definition
>> for Neutron is under consideration for being split out with the
>> exception of neutron, neutron-specs, and python-neutronclient.  The
>> remaining deliverables are:
>>
>>     dragonflow:
>>     kuryr:
>>     networking-ale-omniswitch:
>>     networking-arista:
>>     networking-bgpvpn:
>>     networking-calico:
>>     networking-cisco:
>>     networking-fortinet:
>>     networking-hpe:
>>     networking-hyperv:
>>     networking-infoblox:
>>     networking-fujitsu:
>>     networking-l2gw:
>>     networking-lenovo:
>>     networking-midonet:
>>     networking-odl:
>>     networking-ofagent:
>>     networking-onos:
>>     networking-ovn:
>>     networking-plumgrid:
>>     networking-powervm:
>>     networking-sfc:
>>     networking-vsphere:
>>     octavia:
>>     python-neutron-pd-driver:
>>     vmware-nsx:
>>
>> I think it's helpful to break these into categories, because the answer
>> may be different for each group.  Here's my attempt at breaking this
>> list into some categories:
>>
>> 1) A consumer of Neutron
>>
>>     kuryr
>>
>> IIUC, kuryr is a consumer of Neutron.  Its interaction with Neutron is
>> via using Neutron's REST APIs.  You could think of kuryr's use of
>> Neutron as architecturally similar to how Nova uses Neutron.
>>
>> I think this project makes a ton of sense to become independent.
>>
>> 2) Implementation of a networking technology
>>
>>     dragonflow
>>
>> The dragonflow repo includes a couple of things.  It includes dragonflow
>> itself, and the Neutron driver to connect to it.  Using Astara as an
>> example to follow, dragonflow itself could be an independent project.
>>
>> Following that, the built-in ML2/ovs or ML2/lb control plane could be
>> separate, too, though that's much more painful and complex in practice.
>>
>>     octavia
>>
>> Octavia also seems to fall into this category, just for LBaaS.  It's not
>> just a driver, it's a LBaaS service VM orchestrator (which is in part
>> what Astara is, too).
>>
>> It seems reasonable to propose these as independent projects.
>>
>> 3) New APIs
>>
>> There are some repos that are implementing new REST APIs for Neutron.
>> They're independent enough to need their own driver layer, but coupled
>> with Neutron enough to still need to run inside of Neutron as they can't
>> do everything they need to do by only interfacing with Neutron REST APIs
>> (today, at least).
>>
>>     networking-l2gw:
>>     networking-sfc:
>>
>> Here things start to get less clear to me.  Unless the only interaction
>> with Neutron is via its REST API, then it seems like it should be part
>> of Neutron.  Put another way, if the API runs as a part of the
>> neutron-server process, it should be considered part of Neutron if it
>> exists at all.
>>
>> 4) Neutron plugins/drivers
>>
>
> Even plugins and drivers can implement their own API's, so I don't see
> distinction between 3 and 4, and even 2. That's why I only see two
> categories: consumers and implementers.
>
>
>> This is the biggest category.  It's all the glue code for connecting
>> Neutron to other pieces of software/hardware that implement some piece
>> of networking.
>>
>>     networking-ale-omniswitch:
>>     networking-arista:
>>     networking-bgpvpn:
>>     networking-calico:
>>     networking-cisco:
>>     networking-fortinet:
>>     networking-hpe:
>>     networking-hyperv:
>>     networking-infoblox:
>>     networking-fujitsu:
>>     networking-lenovo:
>>     networking-midonet:
>>     networking-odl:
>>     networking-ofagent:
>>     networking-onos:
>>     networking-ovn:
>>     networking-plumgrid:
>>     networking-powervm:
>>     networking-vsphere:
>>     python-neutron-pd-driver:
>>     vmware-nsx:'
>>
>> I haven't gone and looked at every one of these in detail, so maybe
>> there's another category here.  In any case, for those that fit this
>> category, it seems most natural to consider these part of Neutron.  They
>> are completely useless without Neutron, and Neutron is useless without
>> code from this category.
>>
>
> Nova is useless without Glance or Swift, or Keystone and yet these are all
> separate projects aren't they? I guess the definition of useful vs useless
> can really vary by how you look at it.
>
>
>>
>>
>> My alternate, modified proposal would be to:
>>
>> a) Clarify the line of what should be included in Neutron and what
>> shouldn't be.  The categorization above is a straw man start.  In that,
>> categories 1 and 2 could be split, but 3 and 4 would stay.
>>
>
> Why do you think inclusion is something to keep at all cost? What is
> actually giving you that you couldn't live without? Isn't being part of
> OpenStack not enough?
>
>
>>
>> b) Break down what's actually causing pain and address it point by point.
>>
>> > As a result, there is quite an effort imposed on the PTL, the various
>> > liaisons (release, infra, docs, testing, etc) and the core team to
>> > help manage the existing relationships and to ensure that the picture
>> > stays coherent over time.
>>
>> For example, you mention "release" here, though IIUC, Kyle is handling
>> releases for all of these sub-projects, right?  If so, Kyle, what do you
>> think?  What's causing pain and how can we improve?
>>
>
> Having to manage release and backports of every subproject in the stadium
> is something that currently is in the hands of a single individual (kudos
> to Kyle). This can be revised, and we can go back to delegating...but then
> this means that everyone can and will behave differently, so I wonder:
> what's the point of 'belonging'? Why having an inner circle within the
> outer circle? I can't seem to justify why it's necessary. If you can
> explain that to me in plain English, I would appreciate it very much.
>
>
>>
>> "infra" - I take it this is about the Neutron infra liaisons having to
>> ack every infra patch for all of these repos.  That does sound annoying.
>>  It'd be nice if the lead for each driver or whatever could act as the
>> infra liaison for jobs that only affect that repo.
>>
>
> If infra changes relates to a neutron stadium project, infra folks expect
> those to behave/look consistently, but reality is...they don't: every
> project has its own needs. No single individual has the ability to oversee
> the consistency of dozens of projects. If we arrange ourselves to being
> loose then the consistency doesn't have to be preserved, but if it must,
> then it becomes a lot of work, because there is no single pattern to be
> followed, and the more patterns arise the more likely it is that pitfalls
> show up.
>
>
>>
>> > Sometimes the decision of being part of
>> > this list is even presented before one can see any code, and that
>> > defeats the whole point of the deliverable association.
>>
>> It makes sense to reject something if there's no code.  That's in line
>> with how the TC has been evaluating new projects.
>>
>> > I have experienced first hand that this has become a burden,
>>
>> How about delegating this to the neutron-drivers team?  You already have
>> a meeting with this group reviewing RFEs.  You could spread the load
>> some more by letting others take a look and make a recommendation.
>>
>
> Delegating a broken process is hardly a good answer, is it? The burden
> doesn't go away just by throwing more resources at the problem, but the
> drivers team is already oversubscribed as it is, and we barely manage to
> review a good enough number of RFEs per week.
>
>
>>
>> > and I fear that
>> > the stadium might be an extra layer of governance/complexity that
>> > could even interfere with the existing responsibilities of the TC and
>> > of OpenStack infra.
>>
>> I'm not sure what this means.  Can you elaborate?
>>
>> For the TC, do you mean that Neutron is making in/out decisions that the
>> TC should make?  That's probably true for certain categories (#1 above,
>> especially, and maybe #2), but not for individual drivers, IMO at least.
>
>
> My point in this particular regard is: I fail to understand why Neutron
> (team, PTL, drivers, Lt's etc) have to make the in/out decision, be an
> arbiter of taste and ruler of the whole. Let the individual projects make
> their own decisions by expressing how they relate to Neutron, and how they
> want to integrate with it, across the entire SDLC. They are the ones in the
> best position to do so.
>
>
>
>
>> At the end of the day, it's mostly a governance technicality.  I'm less
>> concerned about what projects.yaml looks like and more concerned about
>> what it implies about how our projects are operating.  I think projects
>> should take more ownership and responsibility for their associated
>> drivers.  No matter how limited the criteria and coordination is, it's
>> better than none.  Let's tackle the pain points instead of just blowing
>> the whole thing up.
>>
>
> I am not advocating of blowing anything thing up. I am proposing to tackle
> the pain points by evolving the structure in a way that I think it better
> reflects the current status and needs of the individual projects.
>
> The governance technicality may have an impact on how the project operate
> (that's the whole point of this discussion). Projects are made of people
> and technology, but mostly people. Currently there's an imbalance to
> sustain the relationship between Neutron and its subprojects. The more
> effort Neutron has to put into dealing with process and governance, the
> less focussed it can be on working on its core capabilities, and that's a
> concern.
>
> What are your concerns about this proposal that you have as Neutron core
> developer, networking-ovn core developer, and TC member? Surely they can't
> all be the same.
>
> Thanks,
> Armando
>
>
>>
>> --
>> Russell Bryant
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

The G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151201/742524e0/attachment.html>