Open Stack

On 30 November 2015 at 23:43, Gal Sagie <gal.sagie at gmail.com> wrote:

> 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..)
>

This is a two way street, everything has a cost, and cost should not be
borne by a single party.


>
> 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)
>

That is somewhat of a sticking point, because right now we have anything
but standard quality. However the biggest problem is: ensuring standard
quality is an effort in itself.


>
> 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.
>

Don't you see that we'd be creating work for ourselves...work that steers
important focus away from what really matters? I don't think that Neutron
needs to become a quality certification body. That's not who we are, and
never will be.


>
> 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.
>

Delegating centralized tasks that are supposed to be distributed in the
first place sounds like nonsense to me.


>
> 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 am not advocating to moving anything to the TC or any other centralized
group. I am saying: you want a project hosted in openstack: fine, you are
in charge. No-one else. Help and assistance is always available, but it's
not a birthright.


>
> 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.
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151201/b2c731f1/attachment.html>