Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Vikram Choudhary]

Thanks for resuming this up Armando!

On Fri, Apr 8, 2016 at 8:45 AM, Armando M.  wrote:

>
>
> On 29 March 2016 at 20:43, Vikram Choudhary  wrote:
>
>> Hi Armando,
>>
>> We want to add the support for a new ML2 driver. Can you please guide
>> what is the step moving forward?
>>
>> Thanks
>> Vikram
>>
>
> Vikram,
>
> Apologies for the late reply, the Mitaka release tasks took precedence and
> I did not have the time to fully resume this effort though it's my
> intention to come back to it in the next few days. To start with, I resumed
> [1,2] to reflect the team decision made in [3]. Now that Newton has
> started, and other repos of the same nature are available in openstack.org,
> it makes sense to give power back to the individual teams to be fully in
> charge of release and backport duties. Some of these projects were already
> released as indicated in [4], and I'll work with the openstack release team
> to clarify next steps for those that have not.
>
> Thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/303026/
> [2] https://review.openstack.org/#/c/303039/
> [3] https://review.openstack.org/#/c/276461/
> [4]
> https://github.com/openstack/releases/tree/master/deliverables/_independent
>
>
>
>>
>>
>> On Fri, Mar 4, 2016 at 12:39 AM, Armando M.  wrote:
>>
>>> Hi folks,
>>>
>>> Status update on this matter:
>>>
>>> Russell, Kyle and I had a number of patches out [1], to try and converge
>>> on how to better organize Neutron-related efforts. As a result, a number of
>>> patches merged and a number of patches are still pending. Because of Mitaka
>>> feature freeze, other initiatives too priority.
>>>
>>> That said, some people rightly wonder what's the latest outcome of the
>>> discussion. Bottom line: we are still figuring this out. For now the
>>> marching order is unchanged: as far as Mitaka is concerned, things stay as
>>> they were, and new submissions for inclusion are still frozen. I aim (with
>>> or without the help of the new PTL) to get to a final resolution by or
>>> shortly after the Mitaka release [2].
>>>
>>> Please be patient and stay focussed on delivering a great Mitaka
>>> experience!
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1]
>>> https://review.openstack.org/#/q/branch:master+topic:stadium-implosion
>>> [2] http://releases.openstack.org/mitaka/schedule.html
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 29 March 2016 at 20:43, Vikram Choudhary  wrote:

> Hi Armando,
>
> We want to add the support for a new ML2 driver. Can you please guide what
> is the step moving forward?
>
> Thanks
> Vikram
>

Vikram,

Apologies for the late reply, the Mitaka release tasks took precedence and
I did not have the time to fully resume this effort though it's my
intention to come back to it in the next few days. To start with, I resumed
[1,2] to reflect the team decision made in [3]. Now that Newton has
started, and other repos of the same nature are available in openstack.org,
it makes sense to give power back to the individual teams to be fully in
charge of release and backport duties. Some of these projects were already
released as indicated in [4], and I'll work with the openstack release team
to clarify next steps for those that have not.

Thanks,
Armando

[1] https://review.openstack.org/#/c/303026/
[2] https://review.openstack.org/#/c/303039/
[3] https://review.openstack.org/#/c/276461/
[4]
https://github.com/openstack/releases/tree/master/deliverables/_independent



>
>
> On Fri, Mar 4, 2016 at 12:39 AM, Armando M.  wrote:
>
>> Hi folks,
>>
>> Status update on this matter:
>>
>> Russell, Kyle and I had a number of patches out [1], to try and converge
>> on how to better organize Neutron-related efforts. As a result, a number of
>> patches merged and a number of patches are still pending. Because of Mitaka
>> feature freeze, other initiatives too priority.
>>
>> That said, some people rightly wonder what's the latest outcome of the
>> discussion. Bottom line: we are still figuring this out. For now the
>> marching order is unchanged: as far as Mitaka is concerned, things stay as
>> they were, and new submissions for inclusion are still frozen. I aim (with
>> or without the help of the new PTL) to get to a final resolution by or
>> shortly after the Mitaka release [2].
>>
>> Please be patient and stay focussed on delivering a great Mitaka
>> experience!
>>
>> Cheers,
>> Armando
>>
>> [1]
>> https://review.openstack.org/#/q/branch:master+topic:stadium-implosion
>> [2] http://releases.openstack.org/mitaka/schedule.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Vikram Choudhary]

Hi Armando,

We want to add the support for a new ML2 driver. Can you please guide what
is the step moving forward?

Thanks
Vikram


On Fri, Mar 4, 2016 at 12:39 AM, Armando M.  wrote:

> Hi folks,
>
> Status update on this matter:
>
> Russell, Kyle and I had a number of patches out [1], to try and converge
> on how to better organize Neutron-related efforts. As a result, a number of
> patches merged and a number of patches are still pending. Because of Mitaka
> feature freeze, other initiatives too priority.
>
> That said, some people rightly wonder what's the latest outcome of the
> discussion. Bottom line: we are still figuring this out. For now the
> marching order is unchanged: as far as Mitaka is concerned, things stay as
> they were, and new submissions for inclusion are still frozen. I aim (with
> or without the help of the new PTL) to get to a final resolution by or
> shortly after the Mitaka release [2].
>
> Please be patient and stay focussed on delivering a great Mitaka
> experience!
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/q/branch:master+topic:stadium-implosion
> [2] http://releases.openstack.org/mitaka/schedule.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

Hi folks,

Status update on this matter:

Russell, Kyle and I had a number of patches out [1], to try and converge on
how to better organize Neutron-related efforts. As a result, a number of
patches merged and a number of patches are still pending. Because of Mitaka
feature freeze, other initiatives too priority.

That said, some people rightly wonder what's the latest outcome of the
discussion. Bottom line: we are still figuring this out. For now the
marching order is unchanged: as far as Mitaka is concerned, things stay as
they were, and new submissions for inclusion are still frozen. I aim (with
or without the help of the new PTL) to get to a final resolution by or
shortly after the Mitaka release [2].

Please be patient and stay focussed on delivering a great Mitaka experience!

Cheers,
Armando

[1] https://review.openstack.org/#/q/branch:master+topic:stadium-implosion
[2] http://releases.openstack.org/mitaka/schedule.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Gary Kotton]

At times I feel like it is the 80’s and we are witnessing the Heysel stadium 
disaster. My understanding from the whole thread and the patches in review for 
the stadium criteria is that accidents happen and the community is trying to 
prevent that. Honestly I am really on the fence here, but leaning to us keeping 
the status quo, this has been a very positive step and maybe we should pursue 
it for a while longer.
We have a very talented PTL and he need the help of the cores and the 
‘decomposed’ plugins to all work together to address the issues. The community 
and stadium are evolving as we mature. Sometimes for the better and sometimes 
for the worse.
Putting aside the bike shedding one of the pain points at hand is the fact that 
the core neutron code is being neglected and not enough people are involved 
there. So maybe if we as a community would focus a little more on the core 
parts then we would not be having these discussions.
Thanks
Gary



From: "Armando M." <arma...@gmail.com<mailto:arma...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, February 5, 2016 at 11:37 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Ayal Baron <ayal.ba...@huawei.com<mailto:ayal.ba...@huawei.com>>, Eran 
Gampel <eran.gam...@huawei.com<mailto:eran.gam...@huawei.com>>
Subject: Re: [openstack-dev] [Neutron] Evolving the stadium concept



On 5 February 2016 at 05:41, Gal Sagie 
<gal.sa...@gmail.com<mailto:gal.sa...@gmail.com>> wrote:
Armando,

I think that contributing and innovating in Dragonflow to implement Neutron in 
an open way and serve as an  alternative and as an example
for distributed networking patterns IS driving Neutron forward, i am very sad 
that you fail to see this and try to pick to
my review/patches count.

Beside the big over head i devote to Dragonflow, due to the fact that it really 
runs as an open source project, i also help and contribute
as much as i can to OVN and of course my efforts in Kuryr, which to me solves a 
critical and important thing for Neutron and for OpenStack
in mixed containers environments.
(And the rest of the time that i try to devote to Neutron and other 
sub-projects, currently still under Neutron big-stadium)

Of course that all of this in addition to my efforts and success to convince 
and assist in bringing more people
and more companies to contribute in an open way with the community in many 
areas in Neutron (some you are familiar with like the border gateway and 
l2gateway others that you are not..),
both internally and externally, writing blogs/arranging meetups to promote and 
extend some
of the above projects visibility and Neutron as such.

Believe me that i truly am passionate about Neutron, OpenStack and open source 
and try my best to help and
contribute when ever i can and many times not due to my "Job requirement", i 
apologise that this is
not enough for you, there is only a limited amount of hours in a day :)

However, i truly believe that Dragonflow, and ANY other true open source 
implementation of Neutron helps move
Neutron forward and i hope to continue do so either as Neutron big-stadium, as 
a big-tent project or as something else.

I don't recall pointing at any stats. I appreciate your sales pitch, but that 
doesn't change the fact that when looking at features like port forwarding and 
tags (stuff that you indeed proposed and that can be beneficial for the project 
as a whole), you didn't seem to give them enough priority, meaning that Neutron 
core is not a priority for you...but don't get me wrong...everyone has his/her 
own priorities.

My point being contributing to Dragonflow/OVN/etc alone is great because it 
drives adoption and provide choice, but it is not enough to provide benefit and 
value to the rest of projects and initiatives that exist within the Neutron 
ecosystem, and use Neutron as a backbone to deliver network services.

There's a wealth of more or less glamorous activities that the core team is 
responsible for and are the true blood of this project. If the heart doesn't 
pump out this blood to the limbs, the limbs might as well die.


As i have talked with Russell and explained, to me the Big Stadium was/is a way 
to keep Networking related projects "near"
the group of people that has the best context to review / help and comment, its 
obviously not working and thats fine, lets
try something different...


On Thu, Feb 4, 2016 at 8:18 PM, Armando M. 
<arma...@gmail.com<mailto:arma...@gmail.com>> wrote:


On 4 February 2016 at 04:05, Gal Sagie 
<gal.sa...@gmail.com<mailto:gal.sa...@gmail.com>> wrote:
Hi Assaf,

I think that if we define a certain criteria we need to make sure that it 
applies to everyone equally.
and it is well understood.

I must admit I am still 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Russell Bryant]

On 02/05/2016 10:36 AM, Neil Jerram wrote:
> As some others have said, I see the current discussion as being about
> the chain of accountability, from a stadium project, through Neutron, up
> to the OpenStack TC and board.  IIUC, Armando and other cores feel that
> there is a gap there - because they can't reasonably understand and
> vouch for all the stadium projects to the same standard they can for
> core Neutron.  Plus it seems (from the current
> https://review.openstack.org/#/c/275888/9 text) that there is a desire
> for strong core team overlap between openstack/neutron and all Neutron
> stadium projects.
> 
> As the lead of networking-calico, I think it's a reasonable call to say
> that networking-calico (and similar projects) should therefore be
> OpenStack big tent projects, rather than Neutron stadium, and hence the
> reviews I've just left.

Thanks, Neil.  You've summarized this well.  A more clear and accurate
chain of accountability is indeed what we're trying to get to here.

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Neil Jerram]

On 04/02/16 22:39, Assaf Muller wrote:
> On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins  wrote:
>> On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote:
>>
>>> Currently I don't understand why
>>> being a part of the stadium is good or bad for a networking project,
>>> or why does it matter.
>>
>> I think the issue is of public perception.

I agree.  Being 'out' can matter, in some sense, if you are competing -
whether for money, mindshare or whatever - with another project or
approach that is 'in'.  Because it can appear to casual observers that
your project is less 'official', 'blessed', likely to be long term
supported, etc. etc.

But all of that can be mitigated if the criteria are clearly specified
and understand, and uniformly applied.

> That's what I was trying to point out. But it must be something other
> than perception, otherwise we could remove the inclusion list
> altogether. A project would not be in or out.

I'm afraid I don't understand here.

>
>> As others have stated, the
>> issue is the "in" vs. "out" problem. We had a similar situation
>> with 3rd party CI, where we had a list of drivers that were "nice" and
>> had CI running vs drivers that were "naughty" and didn't. Prior to the
>> vendor decomposition effort, We had a multitude of drivers that were
>> in-tree, with the public perception that drivers that were in Neutron's
>> tree were "sanctioned" by the Neutron project.
>>
>> That may not have been the intention, but that's what I think happened.

Precisely.

As some others have said, I see the current discussion as being about
the chain of accountability, from a stadium project, through Neutron, up
to the OpenStack TC and board.  IIUC, Armando and other cores feel that
there is a gap there - because they can't reasonably understand and
vouch for all the stadium projects to the same standard they can for
core Neutron.  Plus it seems (from the current
https://review.openstack.org/#/c/275888/9 text) that there is a desire
for strong core team overlap between openstack/neutron and all Neutron
stadium projects.

As the lead of networking-calico, I think it's a reasonable call to say
that networking-calico (and similar projects) should therefore be
OpenStack big tent projects, rather than Neutron stadium, and hence the
reviews I've just left.

Regards,
Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 5 February 2016 at 05:41, Gal Sagie  wrote:

> Armando,
>
> I think that contributing and innovating in Dragonflow to implement
> Neutron in an open way and serve as an  alternative and as an example
> for distributed networking patterns IS driving Neutron forward, i am very
> sad that you fail to see this and try to pick to
> my review/patches count.
>

> Beside the big over head i devote to Dragonflow, due to the fact that it
> really runs as an open source project, i also help and contribute
> as much as i can to OVN and of course my efforts in Kuryr, which to me
> solves a critical and important thing for Neutron and for OpenStack
> in mixed containers environments.
> (And the rest of the time that i try to devote to Neutron and other
> sub-projects, currently still under Neutron big-stadium)
>
> Of course that all of this in addition to my efforts and success to
> convince and assist in bringing more people
> and more companies to contribute in an open way with the community in many
> areas in Neutron (some you are familiar with like the border gateway and
> l2gateway others that you are not..),
> both internally and externally, writing blogs/arranging meetups to promote
> and extend some
> of the above projects visibility and Neutron as such.
>
> Believe me that i truly am passionate about Neutron, OpenStack and open
> source and try my best to help and
> contribute when ever i can and many times not due to my "Job requirement",
> i apologise that this is
> not enough for you, there is only a limited amount of hours in a day :)
>
> However, i truly believe that Dragonflow, and ANY other true open source
> implementation of Neutron helps move
> Neutron forward and i hope to continue do so either as Neutron
> big-stadium, as a big-tent project or as something else.
>

I don't recall pointing at any stats. I appreciate your sales pitch, but
that doesn't change the fact that when looking at features like port
forwarding and tags (stuff that you indeed proposed and that can be
beneficial for the project as a whole), you didn't seem to give them enough
priority, meaning that Neutron core is not a priority for you...but don't
get me wrong...everyone has his/her own priorities.

My point being contributing to Dragonflow/OVN/etc alone is great because it
drives adoption and provide choice, but it is not enough to provide benefit
and value to the rest of projects and initiatives that exist within the
Neutron ecosystem, and use Neutron as a backbone to deliver network
services.

There's a wealth of more or less glamorous activities that the core team is
responsible for and are the true blood of this project. If the heart
doesn't pump out this blood to the limbs, the limbs might as well die.


>
> As i have talked with Russell and explained, to me the Big Stadium was/is
> a way to keep Networking related projects "near"
> the group of people that has the best context to review / help and
> comment, its obviously not working and thats fine, lets
> try something different...
>
>
> On Thu, Feb 4, 2016 at 8:18 PM, Armando M.  wrote:
>
>>
>>
>> On 4 February 2016 at 04:05, Gal Sagie  wrote:
>>
>>> Hi Assaf,
>>>
>>> I think that if we define a certain criteria we need to make sure that
>>> it applies to everyone equally.
>>> and it is well understood.
>>>
>>
>> I must admit I am still waking up and going through the entire logs etc.
>> However I cannot help but point out that one criteria that Russell and
>> other TC people are behind (me included) is the significant 'team overlap'
>> (and I would add it to be for a prolonged amount of time). This doesn't
>> mean just drop the accidental bug fix or enhancement to enable the
>> subproject to work with Neutron or address the odd regression that sneaks
>> in from time to time, but it means driving Neutron forward so that it is
>> beneficial for the project as a whole.
>>
>> If you look at yourself, can you candidly say that you are making an
>> impact to the core of Neutron? You seem you have dropped off the radar in
>> the Mitaka timeframe, and haven't made a lasting impact in the Liberty
>> timeframe. I applaud your Kuryr initiative and your specs proposals, but
>> both are not enough to warrant Dragonflow for inclusion.
>>
>> If the team overlap changes, then great, we'll reassess.
>>
>> That said, I'll continue my discussion on the patch...
>>
>>
>>> I have contributed and still am to both OVN and Dragonflow and hope to
>>> continue do so in the future,
>>> i want to see both of these solutions become a great production grade
>>> open source alternatives.
>>>
>>> I have less experience in open source and in this community from most of
>>> you, but from what i saw users
>>> do take these things into consideration, its hard for a new user and
>>> even not so new to understand the possibilities correctly
>>> specially if we cant even define them ourselves
>>>
>>> Instead of spending time on technology and 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Gal Sagie]

Armando,

I think that contributing and innovating in Dragonflow to implement Neutron
in an open way and serve as an  alternative and as an example
for distributed networking patterns IS driving Neutron forward, i am very
sad that you fail to see this and try to pick to
my review/patches count.

Beside the big over head i devote to Dragonflow, due to the fact that it
really runs as an open source project, i also help and contribute
as much as i can to OVN and of course my efforts in Kuryr, which to me
solves a critical and important thing for Neutron and for OpenStack
in mixed containers environments.
(And the rest of the time that i try to devote to Neutron and other
sub-projects, currently still under Neutron big-stadium)

Of course that all of this in addition to my efforts and success to
convince and assist in bringing more people
and more companies to contribute in an open way with the community in many
areas in Neutron (some you are familiar with like the border gateway and
l2gateway others that you are not..),
both internally and externally, writing blogs/arranging meetups to promote
and extend some
of the above projects visibility and Neutron as such.

Believe me that i truly am passionate about Neutron, OpenStack and open
source and try my best to help and
contribute when ever i can and many times not due to my "Job requirement",
i apologise that this is
not enough for you, there is only a limited amount of hours in a day :)

However, i truly believe that Dragonflow, and ANY other true open source
implementation of Neutron helps move
Neutron forward and i hope to continue do so either as Neutron big-stadium,
as a big-tent project or as something else.

As i have talked with Russell and explained, to me the Big Stadium was/is a
way to keep Networking related projects "near"
the group of people that has the best context to review / help and comment,
its obviously not working and thats fine, lets
try something different...


On Thu, Feb 4, 2016 at 8:18 PM, Armando M.  wrote:

>
>
> On 4 February 2016 at 04:05, Gal Sagie  wrote:
>
>> Hi Assaf,
>>
>> I think that if we define a certain criteria we need to make sure that it
>> applies to everyone equally.
>> and it is well understood.
>>
>
> I must admit I am still waking up and going through the entire logs etc.
> However I cannot help but point out that one criteria that Russell and
> other TC people are behind (me included) is the significant 'team overlap'
> (and I would add it to be for a prolonged amount of time). This doesn't
> mean just drop the accidental bug fix or enhancement to enable the
> subproject to work with Neutron or address the odd regression that sneaks
> in from time to time, but it means driving Neutron forward so that it is
> beneficial for the project as a whole.
>
> If you look at yourself, can you candidly say that you are making an
> impact to the core of Neutron? You seem you have dropped off the radar in
> the Mitaka timeframe, and haven't made a lasting impact in the Liberty
> timeframe. I applaud your Kuryr initiative and your specs proposals, but
> both are not enough to warrant Dragonflow for inclusion.
>
> If the team overlap changes, then great, we'll reassess.
>
> That said, I'll continue my discussion on the patch...
>
>
>> I have contributed and still am to both OVN and Dragonflow and hope to
>> continue do so in the future,
>> i want to see both of these solutions become a great production grade
>> open source alternatives.
>>
>> I have less experience in open source and in this community from most of
>> you, but from what i saw users
>> do take these things into consideration, its hard for a new user and even
>> not so new to understand the possibilities correctly
>> specially if we cant even define them ourselves
>>
>> Instead of spending time on technology and on solving the problems for
>> our users we are concentrating
>> on this conversation, we haven't even talked about production maturity,
>> feature richness and stability as you say
>> and by doing this move, we are signaling something else for our users
>> without actually discussing about all the
>> former ourselves.
>>
>> I will be ok with what ever the Neutron team decide on this, as they can
>> define the criteria as they please.
>> Just shared my opinion on this process and my disappointment from it as
>> someone who values open source
>> a lot.
>>
>> Gal.
>>
>>
>> On Thu, Feb 4, 2016 at 11:31 AM, Assaf Muller  wrote:
>>
>>> On Thu, Feb 4, 2016 at 10:20 AM, Assaf Muller 
>>> wrote:
>>> > On Thu, Feb 4, 2016 at 8:33 AM, Gal Sagie  wrote:
>>> >> As i have commented on the patch i will also send this to the mailing
>>> list:
>>> >>
>>> >> I really dont see why Dragonflow is not part of this list, given the
>>> >> criteria you listed.
>>> >>
>>> >> Dragonflow is fully developed under Neutron/OpenStack, no other
>>> >> repositories. It is fully Open 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Gal Sagie]

Hi Assaf,

I think that if we define a certain criteria we need to make sure that it
applies to everyone equally.
and it is well understood.
I have contributed and still am to both OVN and Dragonflow and hope to
continue do so in the future,
i want to see both of these solutions become a great production grade open
source alternatives.

I have less experience in open source and in this community from most of
you, but from what i saw users
do take these things into consideration, its hard for a new user and even
not so new to understand the possibilities correctly
specially if we cant even define them ourselves

Instead of spending time on technology and on solving the problems for our
users we are concentrating
on this conversation, we haven't even talked about production maturity,
feature richness and stability as you say
and by doing this move, we are signaling something else for our users
without actually discussing about all the
former ourselves.

I will be ok with what ever the Neutron team decide on this, as they can
define the criteria as they please.
Just shared my opinion on this process and my disappointment from it as
someone who values open source
a lot.

Gal.


On Thu, Feb 4, 2016 at 11:31 AM, Assaf Muller  wrote:

> On Thu, Feb 4, 2016 at 10:20 AM, Assaf Muller  wrote:
> > On Thu, Feb 4, 2016 at 8:33 AM, Gal Sagie  wrote:
> >> As i have commented on the patch i will also send this to the mailing
> list:
> >>
> >> I really dont see why Dragonflow is not part of this list, given the
> >> criteria you listed.
> >>
> >> Dragonflow is fully developed under Neutron/OpenStack, no other
> >> repositories. It is fully Open source and already have a community of
> people
> >> contributing and interest from various different companies and OpenStack
> >> deployers. (I can prepare the list of active contributions and of
> interested
> >> parties) It also puts OpenStack Neutron APIs and use cases as first
> class
> >> citizens and working on being an integral part of OpenStack.
> >>
> >> I agree that OVN needs to be part of the list, but you brought up this
> >> criteria in regards to ODL, so: OVN like ODL is not only Neutron and
> >> OpenStack and is even running/being implemented on a whole different
> >> governance model and requirements to it.
> >>
> >> I think you also forgot to mention some other projects as well that are
> >> fully open source with a vibrant and diverse community, i will let them
> >> comment here by themselves.
> >>
> >> Frankly this approach disappoints me, I have honestly worked hard to
> make
> >> Dragonflow fully visible and add and support open discussion and follow
> the
> >> correct guidelines to work in a project. I think that Dragonflow
> community
> >> has already few members from various companies and this is only going to
> >> grow in the near future. (in addition to deployers that are considering
> it
> >> as a solution)  we also welcome anyone that wants to join and be part
> of the
> >> process to step in, we are very welcoming
> >>
> >> I also think that the correct way to do this is to actually add as
> reviewers
> >> all lieutenants of the projects you are now removing from Neutron big
> >> stadium and letting them comment.
> >>
> >> Gal.
> >
> > I understand you see 'Dragonflow being part of the Neutron stadium'
> > and 'Dragonflow having high visibility' as tied together. I'm curious,
> > from a practical perspective, how does being a part of the stadium
> > give Dragonflow visibility? If it were not a part of the stadium and
> > you had your own PTL etc, what specifically would change so that
> > Dragonflow would be less visible. Currently I don't understand why
> > being a part of the stadium is good or bad for a networking project,
> > or why does it matter. Looking at Russell's patch, it's concerned with
> > placing projects (e.g. ODL, OVN, Dragonflow) either in or out of the
> > stadium and the criteria for doing so, I'm just asking how do you
> > (Gal) perceive the practical effect of that decision.
>
> Allow me to expand:
> It seems to me like there is no significance to who is 'in or out'.
> However, people, including potential customers, look at the list of
> the Neutron stadium and deduce that project X is better than Y because
> X is in but Y is out, and *that* in itself is the value of being in or
> out, even though it has no meaning. Maybe we should explain what
> exactly does it mean being in or out. It's just a governance decision,
> it doesn't reflect in any way of the quality or appeal of a project
> (For example some of the open source Neutron drivers out of the
> stadium are much more mature, stable and feature full than other
> drivers in the stadium).
>
> >
> >>
> >>
> >> On Wed, Feb 3, 2016 at 11:48 PM, Russell Bryant 
> wrote:
> >>>
> >>> On 11/30/2015 07:56 PM, Armando M. wrote:
> >>> > I would like to suggest that we evolve the structure of the Neutron
> 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Assaf Muller]

On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins  wrote:
> On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote:
>> I understand you see 'Dragonflow being part of the Neutron stadium'
>> and 'Dragonflow having high visibility' as tied together. I'm curious,
>> from a practical perspective, how does being a part of the stadium
>> give Dragonflow visibility? If it were not a part of the stadium and
>> you had your own PTL etc, what specifically would change so that
>> Dragonflow would be less visible.
>
>> Currently I don't understand why
>> being a part of the stadium is good or bad for a networking project,
>> or why does it matter.
>
>
> I think the issue is of public perception.

That's what I was trying to point out. But it must be something other
than perception, otherwise we could remove the inclusion list
altogether. A project would not be in or out.

> As others have stated, the
> issue is the "in" vs. "out" problem. We had a similar situation
> with 3rd party CI, where we had a list of drivers that were "nice" and
> had CI running vs drivers that were "naughty" and didn't. Prior to the
> vendor decomposition effort, We had a multitude of drivers that were
> in-tree, with the public perception that drivers that were in Neutron's
> tree were "sanctioned" by the Neutron project.
>
> That may not have been the intention, but that's what I think happened.
>
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Russell Bryant]

On 02/04/2016 05:36 PM, Assaf Muller wrote:
> On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins  wrote:
>> On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote:
>>> I understand you see 'Dragonflow being part of the Neutron stadium'
>>> and 'Dragonflow having high visibility' as tied together. I'm curious,
>>> from a practical perspective, how does being a part of the stadium
>>> give Dragonflow visibility? If it were not a part of the stadium and
>>> you had your own PTL etc, what specifically would change so that
>>> Dragonflow would be less visible.
>>
>>> Currently I don't understand why
>>> being a part of the stadium is good or bad for a networking project,
>>> or why does it matter.
>>
>>
>> I think the issue is of public perception.
> 
> That's what I was trying to point out. But it must be something other
> than perception, otherwise we could remove the inclusion list
> altogether. A project would not be in or out.

There has to be a list somewhere.  That's how OpenStack governance
works.  We have project teams that work together to produce a set of
deliverables, where each deliverable is made up of one or more git
repositories.

The ongoing issue is trying to find the right structure that matches how
our teams are working and what they're willing to own.  The current
approach hasn't worked, so it's time for another iteration.

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Kyle Mestery]

On Thu, Feb 4, 2016 at 1:33 AM, Gal Sagie  wrote:
> As i have commented on the patch i will also send this to the mailing list:
>
> I really dont see why Dragonflow is not part of this list, given the
> criteria you listed.
>
> Dragonflow is fully developed under Neutron/OpenStack, no other
> repositories. It is fully Open source and already have a community of people
> contributing and interest from various different companies and OpenStack
> deployers. (I can prepare the list of active contributions and of interested
> parties) It also puts OpenStack Neutron APIs and use cases as first class
> citizens and working on being an integral part of OpenStack.
>
> I agree that OVN needs to be part of the list, but you brought up this
> criteria in regards to ODL, so: OVN like ODL is not only Neutron and
> OpenStack and is even running/being implemented on a whole different
> governance model and requirements to it.
>
> I think you also forgot to mention some other projects as well that are
> fully open source with a vibrant and diverse community, i will let them
> comment here by themselves.
>
> Frankly this approach disappoints me, I have honestly worked hard to make
> Dragonflow fully visible and add and support open discussion and follow the
> correct guidelines to work in a project. I think that Dragonflow community
> has already few members from various companies and this is only going to
> grow in the near future. (in addition to deployers that are considering it
> as a solution)  we also welcome anyone that wants to join and be part of the
> process to step in, we are very welcoming
>
> I also think that the correct way to do this is to actually add as reviewers
> all lieutenants of the projects you are now removing from Neutron big
> stadium and letting them comment.
>
Hi Gal:

I don't think it's a completely fair characterize this as anything
other than an attempt to accurately reflect what the Neutron team can
stand behind. Most of these other open source projects (like
Dragonflow, networking-odl, even networking-ovn) can quite easily
apply for Big Tent admission, and would make the grade pretty easily.
This was not done to hurt anyones feelings or anything, and I know
Russell spent a lot of time on this. We knew this conversation would
be difficult, so I applaud him for sticking his neck out here and
moving things forward.

Thanks!
Kyle

> Gal.
>
>
> On Wed, Feb 3, 2016 at 11:48 PM, Russell Bryant  wrote:
>>
>> 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).
>>
>> After thinking over the discussion in this thread for a while, I have
>> started the following proposal to implement the stadium renovation that
>> Armando originally proposed in this thread.
>>
>> https://review.openstack.org/#/c/275888
>>
>> --
>> Russell Bryant
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Assaf Muller]

On Thu, Feb 4, 2016 at 8:33 AM, Gal Sagie  wrote:
> As i have commented on the patch i will also send this to the mailing list:
>
> I really dont see why Dragonflow is not part of this list, given the
> criteria you listed.
>
> Dragonflow is fully developed under Neutron/OpenStack, no other
> repositories. It is fully Open source and already have a community of people
> contributing and interest from various different companies and OpenStack
> deployers. (I can prepare the list of active contributions and of interested
> parties) It also puts OpenStack Neutron APIs and use cases as first class
> citizens and working on being an integral part of OpenStack.
>
> I agree that OVN needs to be part of the list, but you brought up this
> criteria in regards to ODL, so: OVN like ODL is not only Neutron and
> OpenStack and is even running/being implemented on a whole different
> governance model and requirements to it.
>
> I think you also forgot to mention some other projects as well that are
> fully open source with a vibrant and diverse community, i will let them
> comment here by themselves.
>
> Frankly this approach disappoints me, I have honestly worked hard to make
> Dragonflow fully visible and add and support open discussion and follow the
> correct guidelines to work in a project. I think that Dragonflow community
> has already few members from various companies and this is only going to
> grow in the near future. (in addition to deployers that are considering it
> as a solution)  we also welcome anyone that wants to join and be part of the
> process to step in, we are very welcoming
>
> I also think that the correct way to do this is to actually add as reviewers
> all lieutenants of the projects you are now removing from Neutron big
> stadium and letting them comment.
>
> Gal.

I understand you see 'Dragonflow being part of the Neutron stadium'
and 'Dragonflow having high visibility' as tied together. I'm curious,
from a practical perspective, how does being a part of the stadium
give Dragonflow visibility? If it were not a part of the stadium and
you had your own PTL etc, what specifically would change so that
Dragonflow would be less visible. Currently I don't understand why
being a part of the stadium is good or bad for a networking project,
or why does it matter. Looking at Russell's patch, it's concerned with
placing projects (e.g. ODL, OVN, Dragonflow) either in or out of the
stadium and the criteria for doing so, I'm just asking how do you
(Gal) perceive the practical effect of that decision.

>
>
> On Wed, Feb 3, 2016 at 11:48 PM, Russell Bryant  wrote:
>>
>> 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).
>>
>> After thinking over the discussion in this thread for a while, I have
>> started the following proposal to implement the stadium renovation that
>> Armando originally proposed in this thread.
>>
>> https://review.openstack.org/#/c/275888
>>
>> --
>> Russell Bryant
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Assaf Muller]

On Thu, Feb 4, 2016 at 10:20 AM, Assaf Muller  wrote:
> On Thu, Feb 4, 2016 at 8:33 AM, Gal Sagie  wrote:
>> As i have commented on the patch i will also send this to the mailing list:
>>
>> I really dont see why Dragonflow is not part of this list, given the
>> criteria you listed.
>>
>> Dragonflow is fully developed under Neutron/OpenStack, no other
>> repositories. It is fully Open source and already have a community of people
>> contributing and interest from various different companies and OpenStack
>> deployers. (I can prepare the list of active contributions and of interested
>> parties) It also puts OpenStack Neutron APIs and use cases as first class
>> citizens and working on being an integral part of OpenStack.
>>
>> I agree that OVN needs to be part of the list, but you brought up this
>> criteria in regards to ODL, so: OVN like ODL is not only Neutron and
>> OpenStack and is even running/being implemented on a whole different
>> governance model and requirements to it.
>>
>> I think you also forgot to mention some other projects as well that are
>> fully open source with a vibrant and diverse community, i will let them
>> comment here by themselves.
>>
>> Frankly this approach disappoints me, I have honestly worked hard to make
>> Dragonflow fully visible and add and support open discussion and follow the
>> correct guidelines to work in a project. I think that Dragonflow community
>> has already few members from various companies and this is only going to
>> grow in the near future. (in addition to deployers that are considering it
>> as a solution)  we also welcome anyone that wants to join and be part of the
>> process to step in, we are very welcoming
>>
>> I also think that the correct way to do this is to actually add as reviewers
>> all lieutenants of the projects you are now removing from Neutron big
>> stadium and letting them comment.
>>
>> Gal.
>
> I understand you see 'Dragonflow being part of the Neutron stadium'
> and 'Dragonflow having high visibility' as tied together. I'm curious,
> from a practical perspective, how does being a part of the stadium
> give Dragonflow visibility? If it were not a part of the stadium and
> you had your own PTL etc, what specifically would change so that
> Dragonflow would be less visible. Currently I don't understand why
> being a part of the stadium is good or bad for a networking project,
> or why does it matter. Looking at Russell's patch, it's concerned with
> placing projects (e.g. ODL, OVN, Dragonflow) either in or out of the
> stadium and the criteria for doing so, I'm just asking how do you
> (Gal) perceive the practical effect of that decision.

Allow me to expand:
It seems to me like there is no significance to who is 'in or out'.
However, people, including potential customers, look at the list of
the Neutron stadium and deduce that project X is better than Y because
X is in but Y is out, and *that* in itself is the value of being in or
out, even though it has no meaning. Maybe we should explain what
exactly does it mean being in or out. It's just a governance decision,
it doesn't reflect in any way of the quality or appeal of a project
(For example some of the open source Neutron drivers out of the
stadium are much more mature, stable and feature full than other
drivers in the stadium).

>
>>
>>
>> On Wed, Feb 3, 2016 at 11:48 PM, Russell Bryant  wrote:
>>>
>>> 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).
>>>
>>> After thinking over the discussion in this thread for a while, I have
>>> started the following proposal to implement the stadium renovation that
>>> Armando originally proposed in this thread.
>>>
>>> https://review.openstack.org/#/c/275888
>>>
>>> --
>>> Russell Bryant
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Sean M. Collins]

On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote:
> I understand you see 'Dragonflow being part of the Neutron stadium'
> and 'Dragonflow having high visibility' as tied together. I'm curious,
> from a practical perspective, how does being a part of the stadium
> give Dragonflow visibility? If it were not a part of the stadium and
> you had your own PTL etc, what specifically would change so that
> Dragonflow would be less visible. 

> Currently I don't understand why
> being a part of the stadium is good or bad for a networking project,
> or why does it matter. 


I think the issue is of public perception. As others have stated, the
issue is the "in" vs. "out" problem. We had a similar situation
with 3rd party CI, where we had a list of drivers that were "nice" and
had CI running vs drivers that were "naughty" and didn't. Prior to the
vendor decomposition effort, We had a multitude of drivers that were
in-tree, with the public perception that drivers that were in Neutron's
tree were "sanctioned" by the Neutron project. 

That may not have been the intention, but that's what I think happened.

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 4 February 2016 at 04:05, Gal Sagie  wrote:

> Hi Assaf,
>
> I think that if we define a certain criteria we need to make sure that it
> applies to everyone equally.
> and it is well understood.
>

I must admit I am still waking up and going through the entire logs etc.
However I cannot help but point out that one criteria that Russell and
other TC people are behind (me included) is the significant 'team overlap'
(and I would add it to be for a prolonged amount of time). This doesn't
mean just drop the accidental bug fix or enhancement to enable the
subproject to work with Neutron or address the odd regression that sneaks
in from time to time, but it means driving Neutron forward so that it is
beneficial for the project as a whole.

If you look at yourself, can you candidly say that you are making an impact
to the core of Neutron? You seem you have dropped off the radar in the
Mitaka timeframe, and haven't made a lasting impact in the Liberty
timeframe. I applaud your Kuryr initiative and your specs proposals, but
both are not enough to warrant Dragonflow for inclusion.

If the team overlap changes, then great, we'll reassess.

That said, I'll continue my discussion on the patch...


> I have contributed and still am to both OVN and Dragonflow and hope to
> continue do so in the future,
> i want to see both of these solutions become a great production grade open
> source alternatives.
>
> I have less experience in open source and in this community from most of
> you, but from what i saw users
> do take these things into consideration, its hard for a new user and even
> not so new to understand the possibilities correctly
> specially if we cant even define them ourselves
>
> Instead of spending time on technology and on solving the problems for our
> users we are concentrating
> on this conversation, we haven't even talked about production maturity,
> feature richness and stability as you say
> and by doing this move, we are signaling something else for our users
> without actually discussing about all the
> former ourselves.
>
> I will be ok with what ever the Neutron team decide on this, as they can
> define the criteria as they please.
> Just shared my opinion on this process and my disappointment from it as
> someone who values open source
> a lot.
>
> Gal.
>
>
> On Thu, Feb 4, 2016 at 11:31 AM, Assaf Muller  wrote:
>
>> On Thu, Feb 4, 2016 at 10:20 AM, Assaf Muller  wrote:
>> > On Thu, Feb 4, 2016 at 8:33 AM, Gal Sagie  wrote:
>> >> As i have commented on the patch i will also send this to the mailing
>> list:
>> >>
>> >> I really dont see why Dragonflow is not part of this list, given the
>> >> criteria you listed.
>> >>
>> >> Dragonflow is fully developed under Neutron/OpenStack, no other
>> >> repositories. It is fully Open source and already have a community of
>> people
>> >> contributing and interest from various different companies and
>> OpenStack
>> >> deployers. (I can prepare the list of active contributions and of
>> interested
>> >> parties) It also puts OpenStack Neutron APIs and use cases as first
>> class
>> >> citizens and working on being an integral part of OpenStack.
>> >>
>> >> I agree that OVN needs to be part of the list, but you brought up this
>> >> criteria in regards to ODL, so: OVN like ODL is not only Neutron and
>> >> OpenStack and is even running/being implemented on a whole different
>> >> governance model and requirements to it.
>> >>
>> >> I think you also forgot to mention some other projects as well that are
>> >> fully open source with a vibrant and diverse community, i will let them
>> >> comment here by themselves.
>> >>
>> >> Frankly this approach disappoints me, I have honestly worked hard to
>> make
>> >> Dragonflow fully visible and add and support open discussion and
>> follow the
>> >> correct guidelines to work in a project. I think that Dragonflow
>> community
>> >> has already few members from various companies and this is only going
>> to
>> >> grow in the near future. (in addition to deployers that are
>> considering it
>> >> as a solution)  we also welcome anyone that wants to join and be part
>> of the
>> >> process to step in, we are very welcoming
>> >>
>> >> I also think that the correct way to do this is to actually add as
>> reviewers
>> >> all lieutenants of the projects you are now removing from Neutron big
>> >> stadium and letting them comment.
>> >>
>> >> Gal.
>> >
>> > I understand you see 'Dragonflow being part of the Neutron stadium'
>> > and 'Dragonflow having high visibility' as tied together. I'm curious,
>> > from a practical perspective, how does being a part of the stadium
>> > give Dragonflow visibility? If it were not a part of the stadium and
>> > you had your own PTL etc, what specifically would change so that
>> > Dragonflow would be less visible. Currently I don't understand why
>> > being a part of the stadium is good or bad for a networking 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Russell Bryant]

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

After thinking over the discussion in this thread for a while, I have
started the following proposal to implement the stadium renovation that
Armando originally proposed in this thread.

https://review.openstack.org/#/c/275888

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Gal Sagie]

As i have commented on the patch i will also send this to the mailing list:

I really dont see why Dragonflow is not part of this list, given the
criteria you listed.

Dragonflow is fully developed under Neutron/OpenStack, no other
repositories. It is fully Open source and already have a community of
people contributing and interest from various different companies and
OpenStack deployers. (I can prepare the list of active contributions and of
interested parties) It also puts OpenStack Neutron APIs and use cases as
first class citizens and working on being an integral part of OpenStack.

I agree that OVN needs to be part of the list, but you brought up this
criteria in regards to ODL, so: OVN like ODL is not only Neutron and
OpenStack and is even running/being implemented on a whole different
governance model and requirements to it.

I think you also forgot to mention some other projects as well that are
fully open source with a vibrant and diverse community, i will let them
comment here by themselves.

Frankly this approach disappoints me, I have honestly worked hard to make
Dragonflow fully visible and add and support open discussion and follow the
correct guidelines to work in a project. I think that Dragonflow community
has already few members from various companies and this is only going to
grow in the near future. (in addition to deployers that are considering it
as a solution)  we also welcome anyone that wants to join and be part of
the process to step in, we are very welcoming

I also think that the correct way to do this is to actually add as
reviewers all lieutenants of the projects you are now removing from Neutron
big stadium and letting them comment.

Gal.

On Wed, Feb 3, 2016 at 11:48 PM, Russell Bryant  wrote:

> 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).
>
> After thinking over the discussion in this thread for a while, I have
> started the following proposal to implement the stadium renovation that
> Armando originally proposed in this thread.
>
> https://review.openstack.org/#/c/275888
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Thierry Carrez]

Armando M. wrote:
> For whom of you is interested in the conversation, the topic was brought
> for discussion at the latest TC meeting [1]. Unfortunately I was unable
> to join, however I would like to try and respond to some of the comments
> made to clarify my position on the matter:
> 
>> ttx: the neutron PTL say he can't vouch for anything in the neutron
> "stadium"
> 
> To be honest that's not entirely my position.
> [...]

I think I should have said "for everything" rather than "for anything" :)

>> flaper87: I agree a driver should not be independent
> 
> Why, what's your rationale? If we dig deeper, some drivers are small
> code drops with no or untraceable maintainers. Some are actively
> developed and can be fairly complex. The spectrum is pretty wide. Either
> way, I think that preventing them from being independent in principle
> may hurt the ones that can be pretty elaborated, and the ones that are
> stale may hurt Neutron's reputation because we're the ones who are
> supposed to look after them (after all didn't we vouch for them??)
> [...]

Yes, I agree with you that the line in the sand (between what should be
independent and what should stay in neutron) should not be based on a
technical classification, but on a community definition. The "big tent"
is all about project teams - we judge if that team follows the OpenStack
way, more than we judge what the team technically produces. As far as
neutron goes, the question is not whether what the team produces is a
plugin or a driver: the question is whether all the things are actually
produced by the same team and the same leadership.

If the teams producing those things overlap so significantly the Neutron
leadership can vouch for them being done by "the neutron project team",
they should stay in. If the subteams do not overlap, or follow different
development practices, or have independent leadership, they are not
produced by "the neutron project team" and should have their own
independent project team.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Sean Dague]

On 12/09/2015 01:46 AM, Armando M. wrote:
> 
> 
> On 3 December 2015 at 02:21, Thierry Carrez  > wrote:
> 
> Armando M. wrote:
> > On 2 December 2015 at 01:16, Thierry Carrez  
> > >> wrote:
> >> Armando M. wrote:
> >> >> One solution is, like you mentioned, to make some (or all) of 
> them
> >> >> full-fledged project teams. Be aware that this means the TC 
> would judge
> >> >> those new project teams individually and might reject them if 
> we feel
> >> >> the requirements are not met. We might want to clarify what 
> happens
> >> >> then.
> >> >
> >> > That's a good point. Do we have existing examples of this or 
> would we be
> >> > sailing in uncharted waters?
> >>
> >> It's been pretty common that we rejected/delayed applications for
> >> projects where we felt they needed more alignment. In such cases, 
> the
> >> immediate result for those projects if they are out of the Neutron
> >> "stadium" is that they would fall from the list of official 
> projects.
> >> Again, I'm fine with that outcome, but I want to set expectations
> >> clearly :)
> >
> > Understood. It sounds to me that the outcome would be that those
> > projects (that may end up being rejected) would show nowhere on [1], but
> > would still be hosted and can rely on the support and services of the
> > OpenStack community, right?
> >
> > [1] http://governance.openstack.org/reference/projects/
> 
> Yes they would still be hosted on OpenStack development infrastructure.
> Contributions would no longer count toward ATC status, so people who
> only contribute to those projects would no longer be able to vote in the
> Technical Committee election. They would not have "official" design
> summit space either -- they can still camp in the hallway though :)
> 
> 
> Hi folks,
> 
> For whom of you is interested in the conversation, the topic was brought
> for discussion at the latest TC meeting [1]. Unfortunately I was unable
> to join, however I would like to try and respond to some of the comments
> made to clarify my position on the matter:
> 
>> ttx: the neutron PTL say he can't vouch for anything in the neutron
> "stadium"
> 
> To be honest that's not entirely my position.
> 
> The problem stems from the fact that, if I am asked what the stadium
> means, as a PTL I can't give a straight answer; ttx put it relatively
> well (and I quote him): by adding all those projects under your own
> project team, you bypass the Technical Committee approval that they
> behave like OpenStack projects and are produced by the OpenStack
> community. The Neutron team basically vouches for all of them to be on
> par. As far as the Technical Committee goes, they are all being produced
> by the same team we originally blessed (the Neutron project team).
> 
> The reality is: some of these projects are not produced by the same
> team, they do not behave the same way, and they do not follow the same
> practices and guidelines. For the stadium to make sense, in my humble
> opinion, a definition of these practices should happen and enforcement
> should follow, but who's got the time for policing and enforcing
> eviction, especially on a large scale? So we either reduce the scale
> (which might not be feasible because in OpenStack we're all about
> scaling and adding more and more and more), or we address the problem
> more radically by evolving the relationship from tight aggregation to
> loose association; this way who needs to vouch for the Neutron
> relationship is not the Neutron PTL, but the person sponsoring the
> project that wants to be associated to Neutron. On the other end, the
> vouching may still be pursued, but for a much more focused set of
> initiatives that are led by the same team.
> 
>> russellb: Iattempted to start breaking down the different types of
> repos that are part of the stadium (consumer, api, implementation of
> technology, plugins/drivers).
> 
> The distinction between implementation of technology, plugins/drivers
> and api is not justified IMO because from a neutron standpoint they all
> look like the same: they leverage the pluggable extensions to the
> Neutron core framework. As I attempted to say: we have existing plugins
> and drivers that implement APIs, and we have plugins that implement
> technology, so the extra classification seems overspecification.
> 
>> flaper87: I agree a driver should not be independent
> 
> Why, what's your rationale? If we dig deeper, some drivers are small
> code drops with no or untraceable maintainers. Some are actively
> developed and can be fairly complex. The spectrum is pretty wide. Either
> way, I think that preventing them from being independent 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Doug Hellmann]

Excerpts from Armando M.'s message of 2015-12-08 22:46:16 -0800:
> On 3 December 2015 at 02:21, Thierry Carrez  wrote:
> 
> > Armando M. wrote:
> > > On 2 December 2015 at 01:16, Thierry Carrez  > > > wrote:
> > >> Armando M. wrote:
> > >> >> One solution is, like you mentioned, to make some (or all) of
> > them
> > >> >> full-fledged project teams. Be aware that this means the TC
> > would judge
> > >> >> those new project teams individually and might reject them if we
> > feel
> > >> >> the requirements are not met. We might want to clarify what
> > happens
> > >> >> then.
> > >> >
> > >> > That's a good point. Do we have existing examples of this or
> > would we be
> > >> > sailing in uncharted waters?
> > >>
> > >> It's been pretty common that we rejected/delayed applications for
> > >> projects where we felt they needed more alignment. In such cases,
> > the
> > >> immediate result for those projects if they are out of the Neutron
> > >> "stadium" is that they would fall from the list of official
> > projects.
> > >> Again, I'm fine with that outcome, but I want to set expectations
> > >> clearly :)
> > >
> > > Understood. It sounds to me that the outcome would be that those
> > > projects (that may end up being rejected) would show nowhere on [1], but
> > > would still be hosted and can rely on the support and services of the
> > > OpenStack community, right?
> > >
> > > [1] http://governance.openstack.org/reference/projects/
> >
> > Yes they would still be hosted on OpenStack development infrastructure.
> > Contributions would no longer count toward ATC status, so people who
> > only contribute to those projects would no longer be able to vote in the
> > Technical Committee election. They would not have "official" design
> > summit space either -- they can still camp in the hallway though :)
> >
> 
> Hi folks,
> 
> For whom of you is interested in the conversation, the topic was brought
> for discussion at the latest TC meeting [1]. Unfortunately I was unable to
> join, however I would like to try and respond to some of the comments made
> to clarify my position on the matter:
> 
> > ttx: the neutron PTL say he can't vouch for anything in the neutron
> "stadium"
> 
> To be honest that's not entirely my position.
> 
> The problem stems from the fact that, if I am asked what the stadium means,
> as a PTL I can't give a straight answer; ttx put it relatively well (and I
> quote him): by adding all those projects under your own project team, you
> bypass the Technical Committee approval that they behave like OpenStack
> projects and are produced by the OpenStack community. The Neutron team
> basically vouches for all of them to be on par. As far as the Technical
> Committee goes, they are all being produced by the same team we originally
> blessed (the Neutron project team).
> 
> The reality is: some of these projects are not produced by the same team,
> they do not behave the same way, and they do not follow the same practices
> and guidelines. For the stadium to make sense, in my humble opinion, a

This is the thing that's key, for me. As Anita points out elsewhere in
this thread, we want to structure our project teams so that decision
making and responsibility are placed in the same set of hands. It sounds
like the Stadium concept has made it easy to let those diverge.

> definition of these practices should happen and enforcement should follow,
> but who's got the time for policing and enforcing eviction, especially on a
> large scale? So we either reduce the scale (which might not be feasible
> because in OpenStack we're all about scaling and adding more and more and
> more), or we address the problem more radically by evolving the
> relationship from tight aggregation to loose association; this way who
> needs to vouch for the Neutron relationship is not the Neutron PTL, but the
> person sponsoring the project that wants to be associated to Neutron. On
> the other end, the vouching may still be pursued, but for a much more
> focused set of initiatives that are led by the same team.
> 
> > russellb: I attempted to start breaking down the different types of repos
> that are part of the stadium (consumer, api, implementation of technology,
> plugins/drivers).
> 
> The distinction between implementation of technology, plugins/drivers and
> api is not justified IMO because from a neutron standpoint they all look
> like the same: they leverage the pluggable extensions to the Neutron core
> framework. As I attempted to say: we have existing plugins and drivers that
> implement APIs, and we have plugins that implement technology, so the extra
> classification seems overspecification.
> 
> > flaper87: I agree a driver should not be independent
> 
> Why, what's your rationale? If we dig deeper, some drivers are small code
> drops with no or untraceable maintainers. Some 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Anita Kuno]

On 12/09/2015 07:06 AM, Sean Dague wrote:
> On 12/09/2015 01:46 AM, Armando M. wrote:
>>
>>
>> On 3 December 2015 at 02:21, Thierry Carrez > > wrote:
>>
>> Armando M. wrote:
>> > On 2 December 2015 at 01:16, Thierry Carrez > 
>> > >> wrote:
>> >> Armando M. wrote:
>> >> >> One solution is, like you mentioned, to make some (or all) of 
>> them
>> >> >> full-fledged project teams. Be aware that this means the TC 
>> would judge
>> >> >> those new project teams individually and might reject them if 
>> we feel
>> >> >> the requirements are not met. We might want to clarify what 
>> happens
>> >> >> then.
>> >> >
>> >> > That's a good point. Do we have existing examples of this or 
>> would we be
>> >> > sailing in uncharted waters?
>> >>
>> >> It's been pretty common that we rejected/delayed applications for
>> >> projects where we felt they needed more alignment. In such cases, 
>> the
>> >> immediate result for those projects if they are out of the Neutron
>> >> "stadium" is that they would fall from the list of official 
>> projects.
>> >> Again, I'm fine with that outcome, but I want to set expectations
>> >> clearly :)
>> >
>> > Understood. It sounds to me that the outcome would be that those
>> > projects (that may end up being rejected) would show nowhere on [1], 
>> but
>> > would still be hosted and can rely on the support and services of the
>> > OpenStack community, right?
>> >
>> > [1] http://governance.openstack.org/reference/projects/
>>
>> Yes they would still be hosted on OpenStack development infrastructure.
>> Contributions would no longer count toward ATC status, so people who
>> only contribute to those projects would no longer be able to vote in the
>> Technical Committee election. They would not have "official" design
>> summit space either -- they can still camp in the hallway though :)
>>
>>
>> Hi folks,
>>
>> For whom of you is interested in the conversation, the topic was brought
>> for discussion at the latest TC meeting [1]. Unfortunately I was unable
>> to join, however I would like to try and respond to some of the comments
>> made to clarify my position on the matter:
>>
>>> ttx: the neutron PTL say he can't vouch for anything in the neutron
>> "stadium"
>>
>> To be honest that's not entirely my position.
>>
>> The problem stems from the fact that, if I am asked what the stadium
>> means, as a PTL I can't give a straight answer; ttx put it relatively
>> well (and I quote him): by adding all those projects under your own
>> project team, you bypass the Technical Committee approval that they
>> behave like OpenStack projects and are produced by the OpenStack
>> community. The Neutron team basically vouches for all of them to be on
>> par. As far as the Technical Committee goes, they are all being produced
>> by the same team we originally blessed (the Neutron project team).
>>
>> The reality is: some of these projects are not produced by the same
>> team, they do not behave the same way, and they do not follow the same
>> practices and guidelines. For the stadium to make sense, in my humble
>> opinion, a definition of these practices should happen and enforcement
>> should follow, but who's got the time for policing and enforcing
>> eviction, especially on a large scale? So we either reduce the scale
>> (which might not be feasible because in OpenStack we're all about
>> scaling and adding more and more and more), or we address the problem
>> more radically by evolving the relationship from tight aggregation to
>> loose association; this way who needs to vouch for the Neutron
>> relationship is not the Neutron PTL, but the person sponsoring the
>> project that wants to be associated to Neutron. On the other end, the
>> vouching may still be pursued, but for a much more focused set of
>> initiatives that are led by the same team.
>>
>>> russellb: Iattempted to start breaking down the different types of
>> repos that are part of the stadium (consumer, api, implementation of
>> technology, plugins/drivers).
>>
>> The distinction between implementation of technology, plugins/drivers
>> and api is not justified IMO because from a neutron standpoint they all
>> look like the same: they leverage the pluggable extensions to the
>> Neutron core framework. As I attempted to say: we have existing plugins
>> and drivers that implement APIs, and we have plugins that implement
>> technology, so the extra classification seems overspecification.
>>
>>> flaper87: I agree a driver should not be independent
>>
>> Why, what's your rationale? If we dig deeper, some drivers are small
>> code drops with no or untraceable maintainers. Some are actively
>> 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Doug Wiegley]

> On Dec 9, 2015, at 7:25 AM, Doug Hellmann  wrote:
> 
> Excerpts from Armando M.'s message of 2015-12-08 22:46:16 -0800:
>> On 3 December 2015 at 02:21, Thierry Carrez  wrote:
>> 
>>> Armando M. wrote:
 On 2 December 2015 at 01:16, Thierry Carrez > wrote:
>Armando M. wrote:
>>> One solution is, like you mentioned, to make some (or all) of
>>> them
>>> full-fledged project teams. Be aware that this means the TC
>>> would judge
>>> those new project teams individually and might reject them if we
>>> feel
>>> the requirements are not met. We might want to clarify what
>>> happens
>>> then.
>> 
>> That's a good point. Do we have existing examples of this or
>>> would we be
>> sailing in uncharted waters?
> 
>It's been pretty common that we rejected/delayed applications for
>projects where we felt they needed more alignment. In such cases,
>>> the
>immediate result for those projects if they are out of the Neutron
>"stadium" is that they would fall from the list of official
>>> projects.
>Again, I'm fine with that outcome, but I want to set expectations
>clearly :)
 
 Understood. It sounds to me that the outcome would be that those
 projects (that may end up being rejected) would show nowhere on [1], but
 would still be hosted and can rely on the support and services of the
 OpenStack community, right?
 
 [1] http://governance.openstack.org/reference/projects/
>>> 
>>> Yes they would still be hosted on OpenStack development infrastructure.
>>> Contributions would no longer count toward ATC status, so people who
>>> only contribute to those projects would no longer be able to vote in the
>>> Technical Committee election. They would not have "official" design
>>> summit space either -- they can still camp in the hallway though :)
>>> 
>> 
>> Hi folks,
>> 
>> For whom of you is interested in the conversation, the topic was brought
>> for discussion at the latest TC meeting [1]. Unfortunately I was unable to
>> join, however I would like to try and respond to some of the comments made
>> to clarify my position on the matter:
>> 
>>> ttx: the neutron PTL say he can't vouch for anything in the neutron
>> "stadium"
>> 
>> To be honest that's not entirely my position.
>> 
>> The problem stems from the fact that, if I am asked what the stadium means,
>> as a PTL I can't give a straight answer; ttx put it relatively well (and I
>> quote him): by adding all those projects under your own project team, you
>> bypass the Technical Committee approval that they behave like OpenStack
>> projects and are produced by the OpenStack community. The Neutron team
>> basically vouches for all of them to be on par. As far as the Technical
>> Committee goes, they are all being produced by the same team we originally
>> blessed (the Neutron project team).
>> 
>> The reality is: some of these projects are not produced by the same team,
>> they do not behave the same way, and they do not follow the same practices
>> and guidelines. For the stadium to make sense, in my humble opinion, a
> 
> This is the thing that's key, for me. As Anita points out elsewhere in
> this thread, we want to structure our project teams so that decision
> making and responsibility are placed in the same set of hands. It sounds
> like the Stadium concept has made it easy to let those diverge.
> 
>> definition of these practices should happen and enforcement should follow,
>> but who's got the time for policing and enforcing eviction, especially on a
>> large scale? So we either reduce the scale (which might not be feasible
>> because in OpenStack we're all about scaling and adding more and more and
>> more), or we address the problem more radically by evolving the
>> relationship from tight aggregation to loose association; this way who
>> needs to vouch for the Neutron relationship is not the Neutron PTL, but the
>> person sponsoring the project that wants to be associated to Neutron. On
>> the other end, the vouching may still be pursued, but for a much more
>> focused set of initiatives that are led by the same team.
>> 
>>> russellb: I attempted to start breaking down the different types of repos
>> that are part of the stadium (consumer, api, implementation of technology,
>> plugins/drivers).
>> 
>> The distinction between implementation of technology, plugins/drivers and
>> api is not justified IMO because from a neutron standpoint they all look
>> like the same: they leverage the pluggable extensions to the Neutron core
>> framework. As I attempted to say: we have existing plugins and drivers that
>> implement APIs, and we have plugins that implement technology, so the extra
>> classification seems overspecification.
>> 
>>> flaper87: I agree a driver should not be independent
>> 
>> Why, what's your rationale? If we dig deeper, 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Sean M. Collins]

On Wed, Dec 09, 2015 at 07:06:40AM EST, Sean Dague wrote:
> Changing the REST API isn't innovation, it's incompatibility for end
> users. If we're ever going to have compatible clouds and a real interop
> effort, the APIs for all our services need to be very firmly controlled.
> Extending the API arbitrarily should be a deprecated concept across
> OpenStack.
> 
> Otherwise, I have no idea what the neutron (or any other project) API is.
> 

+1 - when I was at Comcast we had some sites that were nova-network and
some that were Neutron, and there were plenty of differences that people
had to bake into their tooling. I really don't want to see it now become
a case where some Neutron deployments have vastly different behaviors. I
think we've got a lot of API extensions currently that are "must have"
(Security Group API, L3 API are probably the biggest) and at some point
we're going to need grasp the nettle of trying to make more of the API
extensions that we have floating around part of a core network api.

So, when it comes to the REST API I think the Neutron project needs to
have opinions on things and standardize behaviors, and that
implementations behind the API is where products and projects can
differentiate.

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 9 December 2015 at 09:31, Doug Wiegley 
wrote:

>
> > On Dec 9, 2015, at 7:25 AM, Doug Hellmann  wrote:
> >
> > Excerpts from Armando M.'s message of 2015-12-08 22:46:16 -0800:
> >> On 3 December 2015 at 02:21, Thierry Carrez 
> wrote:
> >>
> >>> Armando M. wrote:
>  On 2 December 2015 at 01:16, Thierry Carrez   > wrote:
> >Armando M. wrote:
> >>> One solution is, like you mentioned, to make some (or all) of
> >>> them
> >>> full-fledged project teams. Be aware that this means the TC
> >>> would judge
> >>> those new project teams individually and might reject them if we
> >>> feel
> >>> the requirements are not met. We might want to clarify what
> >>> happens
> >>> then.
> >>
> >> That's a good point. Do we have existing examples of this or
> >>> would we be
> >> sailing in uncharted waters?
> >
> >It's been pretty common that we rejected/delayed applications for
> >projects where we felt they needed more alignment. In such cases,
> >>> the
> >immediate result for those projects if they are out of the Neutron
> >"stadium" is that they would fall from the list of official
> >>> projects.
> >Again, I'm fine with that outcome, but I want to set expectations
> >clearly :)
> 
>  Understood. It sounds to me that the outcome would be that those
>  projects (that may end up being rejected) would show nowhere on [1],
> but
>  would still be hosted and can rely on the support and services of the
>  OpenStack community, right?
> 
>  [1] http://governance.openstack.org/reference/projects/
> >>>
> >>> Yes they would still be hosted on OpenStack development infrastructure.
> >>> Contributions would no longer count toward ATC status, so people who
> >>> only contribute to those projects would no longer be able to vote in
> the
> >>> Technical Committee election. They would not have "official" design
> >>> summit space either -- they can still camp in the hallway though :)
> >>>
> >>
> >> Hi folks,
> >>
> >> For whom of you is interested in the conversation, the topic was brought
> >> for discussion at the latest TC meeting [1]. Unfortunately I was unable
> to
> >> join, however I would like to try and respond to some of the comments
> made
> >> to clarify my position on the matter:
> >>
> >>> ttx: the neutron PTL say he can't vouch for anything in the neutron
> >> "stadium"
> >>
> >> To be honest that's not entirely my position.
> >>
> >> The problem stems from the fact that, if I am asked what the stadium
> means,
> >> as a PTL I can't give a straight answer; ttx put it relatively well
> (and I
> >> quote him): by adding all those projects under your own project team,
> you
> >> bypass the Technical Committee approval that they behave like OpenStack
> >> projects and are produced by the OpenStack community. The Neutron team
> >> basically vouches for all of them to be on par. As far as the Technical
> >> Committee goes, they are all being produced by the same team we
> originally
> >> blessed (the Neutron project team).
> >>
> >> The reality is: some of these projects are not produced by the same
> team,
> >> they do not behave the same way, and they do not follow the same
> practices
> >> and guidelines. For the stadium to make sense, in my humble opinion, a
> >
> > This is the thing that's key, for me. As Anita points out elsewhere in
> > this thread, we want to structure our project teams so that decision
> > making and responsibility are placed in the same set of hands. It sounds
> > like the Stadium concept has made it easy to let those diverge.
> >
> >> definition of these practices should happen and enforcement should
> follow,
> >> but who's got the time for policing and enforcing eviction, especially
> on a
> >> large scale? So we either reduce the scale (which might not be feasible
> >> because in OpenStack we're all about scaling and adding more and more
> and
> >> more), or we address the problem more radically by evolving the
> >> relationship from tight aggregation to loose association; this way who
> >> needs to vouch for the Neutron relationship is not the Neutron PTL, but
> the
> >> person sponsoring the project that wants to be associated to Neutron. On
> >> the other end, the vouching may still be pursued, but for a much more
> >> focused set of initiatives that are led by the same team.
> >>
> >>> russellb: I attempted to start breaking down the different types of
> repos
> >> that are part of the stadium (consumer, api, implementation of
> technology,
> >> plugins/drivers).
> >>
> >> The distinction between implementation of technology, plugins/drivers
> and
> >> api is not justified IMO because from a neutron standpoint they all look
> >> like the same: they leverage the pluggable extensions to the Neutron
> core
> >> framework. As I 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 9 December 2015 at 04:06, Sean Dague  wrote:

> On 12/09/2015 01:46 AM, Armando M. wrote:
> >
> >
> > On 3 December 2015 at 02:21, Thierry Carrez  > > wrote:
> >
> > Armando M. wrote:
> > > On 2 December 2015 at 01:16, Thierry Carrez  
> > > >>
> wrote:
> > >> Armando M. wrote:
> > >> >> One solution is, like you mentioned, to make some (or all)
> of them
> > >> >> full-fledged project teams. Be aware that this means the
> TC would judge
> > >> >> those new project teams individually and might reject them
> if we feel
> > >> >> the requirements are not met. We might want to clarify
> what happens
> > >> >> then.
> > >> >
> > >> > That's a good point. Do we have existing examples of this
> or would we be
> > >> > sailing in uncharted waters?
> > >>
> > >> It's been pretty common that we rejected/delayed applications
> for
> > >> projects where we felt they needed more alignment. In such
> cases, the
> > >> immediate result for those projects if they are out of the
> Neutron
> > >> "stadium" is that they would fall from the list of official
> projects.
> > >> Again, I'm fine with that outcome, but I want to set
> expectations
> > >> clearly :)
> > >
> > > Understood. It sounds to me that the outcome would be that those
> > > projects (that may end up being rejected) would show nowhere on
> [1], but
> > > would still be hosted and can rely on the support and services of
> the
> > > OpenStack community, right?
> > >
> > > [1] http://governance.openstack.org/reference/projects/
> >
> > Yes they would still be hosted on OpenStack development
> infrastructure.
> > Contributions would no longer count toward ATC status, so people who
> > only contribute to those projects would no longer be able to vote in
> the
> > Technical Committee election. They would not have "official" design
> > summit space either -- they can still camp in the hallway though :)
> >
> >
> > Hi folks,
> >
> > For whom of you is interested in the conversation, the topic was brought
> > for discussion at the latest TC meeting [1]. Unfortunately I was unable
> > to join, however I would like to try and respond to some of the comments
> > made to clarify my position on the matter:
> >
> >> ttx: the neutron PTL say he can't vouch for anything in the neutron
> > "stadium"
> >
> > To be honest that's not entirely my position.
> >
> > The problem stems from the fact that, if I am asked what the stadium
> > means, as a PTL I can't give a straight answer; ttx put it relatively
> > well (and I quote him): by adding all those projects under your own
> > project team, you bypass the Technical Committee approval that they
> > behave like OpenStack projects and are produced by the OpenStack
> > community. The Neutron team basically vouches for all of them to be on
> > par. As far as the Technical Committee goes, they are all being produced
> > by the same team we originally blessed (the Neutron project team).
> >
> > The reality is: some of these projects are not produced by the same
> > team, they do not behave the same way, and they do not follow the same
> > practices and guidelines. For the stadium to make sense, in my humble
> > opinion, a definition of these practices should happen and enforcement
> > should follow, but who's got the time for policing and enforcing
> > eviction, especially on a large scale? So we either reduce the scale
> > (which might not be feasible because in OpenStack we're all about
> > scaling and adding more and more and more), or we address the problem
> > more radically by evolving the relationship from tight aggregation to
> > loose association; this way who needs to vouch for the Neutron
> > relationship is not the Neutron PTL, but the person sponsoring the
> > project that wants to be associated to Neutron. On the other end, the
> > vouching may still be pursued, but for a much more focused set of
> > initiatives that are led by the same team.
> >
> >> russellb: Iattempted to start breaking down the different types of
> > repos that are part of the stadium (consumer, api, implementation of
> > technology, plugins/drivers).
> >
> > The distinction between implementation of technology, plugins/drivers
> > and api is not justified IMO because from a neutron standpoint they all
> > look like the same: they leverage the pluggable extensions to the
> > Neutron core framework. As I attempted to say: we have existing plugins
> > and drivers that implement APIs, and we have plugins that implement
> > technology, so the extra classification seems overspecification.
> >
> >> flaper87: I agree a driver should not be independent
> >
> > Why, what's your rationale? If we 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 9 December 2015 at 02:02, Thierry Carrez  wrote:

> Armando M. wrote:
> > For whom of you is interested in the conversation, the topic was brought
> > for discussion at the latest TC meeting [1]. Unfortunately I was unable
> > to join, however I would like to try and respond to some of the comments
> > made to clarify my position on the matter:
> >
> >> ttx: the neutron PTL say he can't vouch for anything in the neutron
> > "stadium"
> >
> > To be honest that's not entirely my position.
> > [...]
>
> I think I should have said "for everything" rather than "for anything" :)
>
>
ok, It makes more sense!

>> flaper87: I agree a driver should not be independent
> >
> > Why, what's your rationale? If we dig deeper, some drivers are small
> > code drops with no or untraceable maintainers. Some are actively
> > developed and can be fairly complex. The spectrum is pretty wide. Either
> > way, I think that preventing them from being independent in principle
> > may hurt the ones that can be pretty elaborated, and the ones that are
> > stale may hurt Neutron's reputation because we're the ones who are
> > supposed to look after them (after all didn't we vouch for them??)
> > [...]
>
> Yes, I agree with you that the line in the sand (between what should be
> independent and what should stay in neutron) should not be based on a
> technical classification, but on a community definition. The "big tent"
> is all about project teams - we judge if that team follows the OpenStack
> way, more than we judge what the team technically produces. As far as
> neutron goes, the question is not whether what the team produces is a
> plugin or a driver: the question is whether all the things are actually
> produced by the same team and the same leadership.


> If the teams producing those things overlap so significantly the Neutron
> leadership can vouch for them being done by "the neutron project team",
> they should stay in. If the subteams do not overlap, or follow different
> development practices, or have independent leadership, they are not
> produced by "the neutron project team" and should have their own
> independent project team.
>

I am glad you made this point, because some projects have clearly been a
spin-off sponsored by the same team and leadership, whilst others have not
(call it the new stuff if you will). However, people move on, when
technology tend to be the legacy, so I am not sure the judgement call
should be about teams rather than technology, but that's a different
conversation I suppose.

If that's the criteria, managing the growth (or lack thereof) of the
stadium becomes a problem of a different nature. However, before we do that
we'll have to figure out what to do with the growth that has occurred up
until now without taking this criteria into account to the letter!


>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 9 December 2015 at 06:25, Doug Hellmann  wrote:

> Excerpts from Armando M.'s message of 2015-12-08 22:46:16 -0800:
> > On 3 December 2015 at 02:21, Thierry Carrez 
> wrote:
> >
> > > Armando M. wrote:
> > > > On 2 December 2015 at 01:16, Thierry Carrez  > > > > wrote:
> > > >> Armando M. wrote:
> > > >> >> One solution is, like you mentioned, to make some (or all) of
> > > them
> > > >> >> full-fledged project teams. Be aware that this means the TC
> > > would judge
> > > >> >> those new project teams individually and might reject them
> if we
> > > feel
> > > >> >> the requirements are not met. We might want to clarify what
> > > happens
> > > >> >> then.
> > > >> >
> > > >> > That's a good point. Do we have existing examples of this or
> > > would we be
> > > >> > sailing in uncharted waters?
> > > >>
> > > >> It's been pretty common that we rejected/delayed applications
> for
> > > >> projects where we felt they needed more alignment. In such
> cases,
> > > the
> > > >> immediate result for those projects if they are out of the
> Neutron
> > > >> "stadium" is that they would fall from the list of official
> > > projects.
> > > >> Again, I'm fine with that outcome, but I want to set
> expectations
> > > >> clearly :)
> > > >
> > > > Understood. It sounds to me that the outcome would be that those
> > > > projects (that may end up being rejected) would show nowhere on [1],
> but
> > > > would still be hosted and can rely on the support and services of the
> > > > OpenStack community, right?
> > > >
> > > > [1] http://governance.openstack.org/reference/projects/
> > >
> > > Yes they would still be hosted on OpenStack development infrastructure.
> > > Contributions would no longer count toward ATC status, so people who
> > > only contribute to those projects would no longer be able to vote in
> the
> > > Technical Committee election. They would not have "official" design
> > > summit space either -- they can still camp in the hallway though :)
> > >
> >
> > Hi folks,
> >
> > For whom of you is interested in the conversation, the topic was brought
> > for discussion at the latest TC meeting [1]. Unfortunately I was unable
> to
> > join, however I would like to try and respond to some of the comments
> made
> > to clarify my position on the matter:
> >
> > > ttx: the neutron PTL say he can't vouch for anything in the neutron
> > "stadium"
> >
> > To be honest that's not entirely my position.
> >
> > The problem stems from the fact that, if I am asked what the stadium
> means,
> > as a PTL I can't give a straight answer; ttx put it relatively well (and
> I
> > quote him): by adding all those projects under your own project team, you
> > bypass the Technical Committee approval that they behave like OpenStack
> > projects and are produced by the OpenStack community. The Neutron team
> > basically vouches for all of them to be on par. As far as the Technical
> > Committee goes, they are all being produced by the same team we
> originally
> > blessed (the Neutron project team).
> >
> > The reality is: some of these projects are not produced by the same team,
> > they do not behave the same way, and they do not follow the same
> practices
> > and guidelines. For the stadium to make sense, in my humble opinion, a
>
> This is the thing that's key, for me. As Anita points out elsewhere in
> this thread, we want to structure our project teams so that decision
> making and responsibility are placed in the same set of hands. It sounds
> like the Stadium concept has made it easy to let those diverge.
>

Yes, only during this conversation (and whilst I have been thinking about
this) this has been become suddenly clear.


>
> > definition of these practices should happen and enforcement should
> follow,
> > but who's got the time for policing and enforcing eviction, especially
> on a
> > large scale? So we either reduce the scale (which might not be feasible
> > because in OpenStack we're all about scaling and adding more and more and
> > more), or we address the problem more radically by evolving the
> > relationship from tight aggregation to loose association; this way who
> > needs to vouch for the Neutron relationship is not the Neutron PTL, but
> the
> > person sponsoring the project that wants to be associated to Neutron. On
> > the other end, the vouching may still be pursued, but for a much more
> > focused set of initiatives that are led by the same team.
> >
> > > russellb: I attempted to start breaking down the different types of
> repos
> > that are part of the stadium (consumer, api, implementation of
> technology,
> > plugins/drivers).
> >
> > The distinction between implementation of technology, plugins/drivers and
> > api is not justified IMO because from a neutron standpoint they all look
> > like the same: they leverage the pluggable extensions 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 3 December 2015 at 02:21, Thierry Carrez  wrote:

> Armando M. wrote:
> > On 2 December 2015 at 01:16, Thierry Carrez  > > wrote:
> >> Armando M. wrote:
> >> >> One solution is, like you mentioned, to make some (or all) of
> them
> >> >> full-fledged project teams. Be aware that this means the TC
> would judge
> >> >> those new project teams individually and might reject them if we
> feel
> >> >> the requirements are not met. We might want to clarify what
> happens
> >> >> then.
> >> >
> >> > That's a good point. Do we have existing examples of this or
> would we be
> >> > sailing in uncharted waters?
> >>
> >> It's been pretty common that we rejected/delayed applications for
> >> projects where we felt they needed more alignment. In such cases,
> the
> >> immediate result for those projects if they are out of the Neutron
> >> "stadium" is that they would fall from the list of official
> projects.
> >> Again, I'm fine with that outcome, but I want to set expectations
> >> clearly :)
> >
> > Understood. It sounds to me that the outcome would be that those
> > projects (that may end up being rejected) would show nowhere on [1], but
> > would still be hosted and can rely on the support and services of the
> > OpenStack community, right?
> >
> > [1] http://governance.openstack.org/reference/projects/
>
> Yes they would still be hosted on OpenStack development infrastructure.
> Contributions would no longer count toward ATC status, so people who
> only contribute to those projects would no longer be able to vote in the
> Technical Committee election. They would not have "official" design
> summit space either -- they can still camp in the hallway though :)
>

Hi folks,

For whom of you is interested in the conversation, the topic was brought
for discussion at the latest TC meeting [1]. Unfortunately I was unable to
join, however I would like to try and respond to some of the comments made
to clarify my position on the matter:

> ttx: the neutron PTL say he can't vouch for anything in the neutron
"stadium"

To be honest that's not entirely my position.

The problem stems from the fact that, if I am asked what the stadium means,
as a PTL I can't give a straight answer; ttx put it relatively well (and I
quote him): by adding all those projects under your own project team, you
bypass the Technical Committee approval that they behave like OpenStack
projects and are produced by the OpenStack community. The Neutron team
basically vouches for all of them to be on par. As far as the Technical
Committee goes, they are all being produced by the same team we originally
blessed (the Neutron project team).

The reality is: some of these projects are not produced by the same team,
they do not behave the same way, and they do not follow the same practices
and guidelines. For the stadium to make sense, in my humble opinion, a
definition of these practices should happen and enforcement should follow,
but who's got the time for policing and enforcing eviction, especially on a
large scale? So we either reduce the scale (which might not be feasible
because in OpenStack we're all about scaling and adding more and more and
more), or we address the problem more radically by evolving the
relationship from tight aggregation to loose association; this way who
needs to vouch for the Neutron relationship is not the Neutron PTL, but the
person sponsoring the project that wants to be associated to Neutron. On
the other end, the vouching may still be pursued, but for a much more
focused set of initiatives that are led by the same team.

> russellb: I attempted to start breaking down the different types of repos
that are part of the stadium (consumer, api, implementation of technology,
plugins/drivers).

The distinction between implementation of technology, plugins/drivers and
api is not justified IMO because from a neutron standpoint they all look
like the same: they leverage the pluggable extensions to the Neutron core
framework. As I attempted to say: we have existing plugins and drivers that
implement APIs, and we have plugins that implement technology, so the extra
classification seems overspecification.

> flaper87: I agree a driver should not be independent

Why, what's your rationale? If we dig deeper, some drivers are small code
drops with no or untraceable maintainers. Some are actively developed and
can be fairly complex. The spectrum is pretty wide. Either way, I think
that preventing them from being independent in principle may hurt the ones
that can be pretty elaborated, and the ones that are stale may hurt
Neutron's reputation because we're the ones who are supposed to look after
them (after all didn't we vouch for them??)

> dhellmann: we have previously said that projects run by different teams
talk to each other over rest interfaces as a way of clearly delineating
boundaries

As much as 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Thierry Carrez]

Armando M. wrote:
> On 2 December 2015 at 01:16, Thierry Carrez  > wrote:
>> Armando M. wrote:
>> >> One solution is, like you mentioned, to make some (or all) of them
>> >> full-fledged project teams. Be aware that this means the TC would 
>> judge
>> >> those new project teams individually and might reject them if we feel
>> >> the requirements are not met. We might want to clarify what happens
>> >> then.
>> >
>> > That's a good point. Do we have existing examples of this or would we 
>> be
>> > sailing in uncharted waters?
>> 
>> It's been pretty common that we rejected/delayed applications for
>> projects where we felt they needed more alignment. In such cases, the
>> immediate result for those projects if they are out of the Neutron
>> "stadium" is that they would fall from the list of official projects.
>> Again, I'm fine with that outcome, but I want to set expectations
>> clearly :)
> 
> Understood. It sounds to me that the outcome would be that those
> projects (that may end up being rejected) would show nowhere on [1], but
> would still be hosted and can rely on the support and services of the
> OpenStack community, right?
> 
> [1] http://governance.openstack.org/reference/projects/

Yes they would still be hosted on OpenStack development infrastructure.
Contributions would no longer count toward ATC status, so people who
only contribute to those projects would no longer be able to vote in the
Technical Committee election. They would not have "official" design
summit space either -- they can still camp in the hallway though :)

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Thierry Carrez]

Armando M. wrote:
>> One solution is, like you mentioned, to make some (or all) of them
>> full-fledged project teams. Be aware that this means the TC would judge
>> those new project teams individually and might reject them if we feel
>> the requirements are not met. We might want to clarify what happens
>> then.
> 
> That's a good point. Do we have existing examples of this or would we be
> sailing in uncharted waters?

It's been pretty common that we rejected/delayed applications for
projects where we felt they needed more alignment. In such cases, the
immediate result for those projects if they are out of the Neutron
"stadium" is that they would fall from the list of official projects.
Again, I'm fine with that outcome, but I want to set expectations clearly :)

> That said, I didn't see you comment on the
> possible introduction of neutron-relevant tags, is something that the TC
> would be open to?

Totally. We've been pondering "support/relationship" tags (describing
which project has a horizon UI, or a devstack plugin, or...) for a while
now. Boris had one in mind for Rally (to describe projects that have a
Rally profile). We'd likely need to bikeshed on names and colors, but I
think the idea of describing project relationships using tags is a
well-accepted one.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 2 December 2015 at 01:16, Thierry Carrez  wrote:

> Armando M. wrote:
> >> One solution is, like you mentioned, to make some (or all) of them
> >> full-fledged project teams. Be aware that this means the TC would judge
> >> those new project teams individually and might reject them if we feel
> >> the requirements are not met. We might want to clarify what happens
> >> then.
> >
> > That's a good point. Do we have existing examples of this or would we be
> > sailing in uncharted waters?
>
> It's been pretty common that we rejected/delayed applications for
> projects where we felt they needed more alignment. In such cases, the
> immediate result for those projects if they are out of the Neutron
> "stadium" is that they would fall from the list of official projects.
> Again, I'm fine with that outcome, but I want to set expectations clearly
> :)
>

Understood. It sounds to me that the outcome would be that those projects
(that may end up being rejected) would show nowhere on [1], but would still
be hosted and can rely on the support and services of the OpenStack
community, right?

[1] http://governance.openstack.org/reference/projects/


>
> > That said, I didn't see you comment on the
> > possible introduction of neutron-relevant tags, is something that the TC
> > would be open to?
>
> Totally. We've been pondering "support/relationship" tags (describing
> which project has a horizon UI, or a devstack plugin, or...) for a while
> now. Boris had one in mind for Rally (to describe projects that have a
> Rally profile). We'd likely need to bikeshed on names and colors, but I
> think the idea of describing project relationships using tags is a
> well-accepted one.
>

Makes sense. Thanks for clarifying.

Cheers,
Armando

>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 30 November 2015 at 23:43, Gal Sagie  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.  wrote:
>
>>
>>
>> On 30 November 2015 at 20:11, Russell Bryant  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), 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 1 December 2015 at 03:03, Neil Jerram  wrote:

> On 01/12/15 10:42, Thierry Carrez wrote:
> > Armando M. wrote:
> >> [...]
> >> So my question is: would revisiting/clarifying the concept be due after
> >> some time we have seen it in action? I would like to think so.
> > I also think it's time to revisit this experience now that it's been
> > around for some time. On one hand the Neutron stadium allowed to
> > increase the development bandwidth by tackling bottlenecks in reviews
> > using smaller core review teams. On the other it's been difficult for
> > Neutron leadership to follow up on all those initiatives and the results
> > in terms of QA and alignment with "the OpenStack way" have been... mixed.
>
> Agreed.  networking-calico has now existed as an OpenStack and Neutron
> stadium project since August, but we don't yet have an IRC meeting or
> formal subproject PTL (if such a thing should exist - I'm not sure), so
> there are some design discussions that we're not conducting in public;
> and in those senses we are not yet fully following the OpenStack way.
> (These things are planned!  But not there yet.)


If one of the projects does not follow the four opens, then IMO it should
not deserve to be in neither tent or stadium, but then again, I don't think
we should put ourselves as an extra layer of judgement between projects and
the TC, just because the project is related to Neutron. The TC is in charge
of making that call irrespective of the technology.


>
> If the Neutron stadium didn't exist and we were an OpenStack project
> like (say) magnum or sahara, would processes and oversight have forced
> us to address those points sooner?  If so, it might be said that the
> Neutron stadium is providing a grey area for projects that are dragging
> their feet a bit.  From a lazy vendor point of view, that might be
> convenient, but from an OpenStack community point of view it's not good.


> Regards,
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 1 December 2015 at 02:40, Thierry Carrez  wrote:

> Armando M. wrote:
> > [...]
> > So my question is: would revisiting/clarifying the concept be due after
> > some time we have seen it in action? I would like to think so.
>
> I also think it's time to revisit this experience now that it's been
> around for some time. On one hand the Neutron stadium allowed to
> increase the development bandwidth by tackling bottlenecks in reviews
> using smaller core review teams. On the other it's been difficult for
> Neutron leadership to follow up on all those initiatives and the results
> in terms of QA and alignment with "the OpenStack way" have been... mixed.
>
> And this touches on the governance issue. By adding all those projects
> under your own project team, you bypass the Technical Committee approval
> that they behave like OpenStack projects and are produced by the
> OpenStack community. The Neutron team basically vouches for all of them
> to be on par. As far as the Technical Committee goes, they are all being
> produced by the same team we originally blessed (the Neutron project team).
>
> That is perfectly fine with me, as long as the Neutron team feels
> confident they can oversee every single one of them and vouch for every
> single one of them. If the Neutron PTL feels the core Neutron leadership
> just can't keep up, I think we have a problem we need to address, before
> it taints the Neutron project team itself.
>
> One solution is, like you mentioned, to make some (or all) of them
> full-fledged project teams. Be aware that this means the TC would judge
> those new project teams individually and might reject them if we feel
> the requirements are not met. We might want to clarify what happens then.
>

That's a good point. Do we have existing examples of this or would we be
sailing in uncharted waters? That said, I didn't see you comment on the
possible introduction of neutron-relevant tags, is something that the TC
would be open to?


>
> Thanks for raising this thread!
>

Thank you for chiming in!


>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 1 December 2015 at 02:40, Neil Jerram  wrote:

> On 01/12/15 05:16, Doug Wiegley wrote:
> > Part of the issue is that in a year, we added all the repos above. And
> > all of said repos were all heading over to infra with the same newbie
> > questions/mistakes. Not a bad thing in and of itself, but the sheer
> > volume was causing a lot of infra load. So the infra liasions are
> > meant to buffer that; exactly the opposite of splitting again. Now add
> > that many repos again this year, and the problem doubles. The review
> > overhead for centralizing this is quite small. The mentor overhead to
> > avoid the repeated mistakes hitting infra is quite a bit higher, but
> > that has to land somewhere, and still isn’t huge.
>
> On the other hand, it may also be that we're very unlikely to see so
> many new projects again, as we have in the first 'stadium' (half-)year.
> So if this is a significant aspect of the pain that Armando is
> describing, I suspect it would be overreaction to make a big governance
> change for it - as it's unlikely to happen again.
>

I don't think we're nearly reached the inflection point.


>
> But actually I guess most of the pain is elsewhere, i.e. in the
> cognitive aspect of the Neutron PTL logically needing to understand
> everything in all of the stadium projects.
>
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Neil Jerram]

On 01/12/15 04:13, Russell Bryant wrote:
> On 11/30/2015 07:56 PM, Armando M. wrote:
>> 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?
>
> "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.

I'd be happy to do that for networking-calico.  (Even though I'm not
sure quite how great the implications are, it sounds like the Right Thing.)

Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Neil Jerram]

On 01/12/15 05:16, Doug Wiegley wrote:
> Part of the issue is that in a year, we added all the repos above. And
> all of said repos were all heading over to infra with the same newbie
> questions/mistakes. Not a bad thing in and of itself, but the sheer
> volume was causing a lot of infra load. So the infra liasions are
> meant to buffer that; exactly the opposite of splitting again. Now add
> that many repos again this year, and the problem doubles. The review
> overhead for centralizing this is quite small. The mentor overhead to
> avoid the repeated mistakes hitting infra is quite a bit higher, but
> that has to land somewhere, and still isn’t huge. 

On the other hand, it may also be that we're very unlikely to see so
many new projects again, as we have in the first 'stadium' (half-)year. 
So if this is a significant aspect of the pain that Armando is
describing, I suspect it would be overreaction to make a big governance
change for it - as it's unlikely to happen again.

But actually I guess most of the pain is elsewhere, i.e. in the
cognitive aspect of the Neutron PTL logically needing to understand
everything in all of the stadium projects.

Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Thierry Carrez]

Armando M. wrote:
> [...]
> So my question is: would revisiting/clarifying the concept be due after
> some time we have seen it in action? I would like to think so.

I also think it's time to revisit this experience now that it's been
around for some time. On one hand the Neutron stadium allowed to
increase the development bandwidth by tackling bottlenecks in reviews
using smaller core review teams. On the other it's been difficult for
Neutron leadership to follow up on all those initiatives and the results
in terms of QA and alignment with "the OpenStack way" have been... mixed.

And this touches on the governance issue. By adding all those projects
under your own project team, you bypass the Technical Committee approval
that they behave like OpenStack projects and are produced by the
OpenStack community. The Neutron team basically vouches for all of them
to be on par. As far as the Technical Committee goes, they are all being
produced by the same team we originally blessed (the Neutron project team).

That is perfectly fine with me, as long as the Neutron team feels
confident they can oversee every single one of them and vouch for every
single one of them. If the Neutron PTL feels the core Neutron leadership
just can't keep up, I think we have a problem we need to address, before
it taints the Neutron project team itself.

One solution is, like you mentioned, to make some (or all) of them
full-fledged project teams. Be aware that this means the TC would judge
those new project teams individually and might reject them if we feel
the requirements are not met. We might want to clarify what happens then.

Thanks for raising this thread!

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Neil Jerram]

On 01/12/15 10:42, Thierry Carrez wrote:
> Armando M. wrote:
>> [...]
>> So my question is: would revisiting/clarifying the concept be due after
>> some time we have seen it in action? I would like to think so.
> I also think it's time to revisit this experience now that it's been
> around for some time. On one hand the Neutron stadium allowed to
> increase the development bandwidth by tackling bottlenecks in reviews
> using smaller core review teams. On the other it's been difficult for
> Neutron leadership to follow up on all those initiatives and the results
> in terms of QA and alignment with "the OpenStack way" have been... mixed.

Agreed.  networking-calico has now existed as an OpenStack and Neutron
stadium project since August, but we don't yet have an IRC meeting or
formal subproject PTL (if such a thing should exist - I'm not sure), so
there are some design discussions that we're not conducting in public;
and in those senses we are not yet fully following the OpenStack way. 
(These things are planned!  But not there yet.)

If the Neutron stadium didn't exist and we were an OpenStack project
like (say) magnum or sahara, would processes and oversight have forced
us to address those points sooner?  If so, it might be said that the
Neutron stadium is providing a grey area for projects that are dragging
their feet a bit.  From a lazy vendor point of view, that might be
convenient, but from an OpenStack community point of view it's not good.

Regards,
Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Doug Wiegley]

> On Nov 30, 2015, at 5:56 PM, Armando M.  wrote:
> 
> Hi folks,
> 
> The stadium concept was introduced more or less formally since April of this 
> year. At the time it was introduced (see [1]), the list of deliverables 
> included neutron, client, specs and *-aas services. As you may be well aware, 
> 6+ months is a long time in the OpenStack world, and lots of things happened 
> since then. The list has grown to [2]. 
> 
> When I think about what 'deliverables' are, I am inclined to think that all 
> of the projects that are part of the list will have to behave and follow the 
> same rules, provided that there is flexibility given by the tags. However, 
> reality has proven us that rules are somewhat difficult to follow and 
> enforce, and some boundaries may be too strict for some initiatives to comply 
> with. This is especially true if we go from a handful of projects that we had 
> when this had started to the nearly the two dozens we have now.
> 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. 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. I have experienced first hand that this has 
> become a burden, 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.
> 
> So my question is: would revisiting/clarifying the concept be due after some 
> time we have seen it in action? I would like to think so. To be fair, I am 
> not sure what the right answer is, but I know for a fact that some iterations 
> are in order, and I like to make a proposal:
> 
> 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:
> 
Interesting proposal, and I’m just thinking out loud here. I’m generally in 
favor of separating the governance as we separate the dependencies, just 
because at some point what we’re doing doesn’t scale. To provide a little 
context, there are two points worth keeping in mind:

- The neutron stadium actually slightly pre-dates the big tent, and works 
around some earlier governance friction. So it may make less sense now in light 
of those changes.

- Many of the neutron subprojects *MUST RELEASE IN LOCKSTEP WITH NEUTRON* to be 
useful. These items are less useful to be considered standalone, as they need 
general oversight, co-gating, and such, to stay sane. As we break the massive 
coupling that exists, this point will get less and less relevant. 

- I think that part of the initial intent was that these small subprojects 
would have their own core teams, but be able to take advantage of the 
infrastructure that exists around neutron as a whole (specs, release team, 
stable team, co-gates, mentors).

For your proposal, are you suggesting:

1. That these projects are fully separate, with their own PTLs and everything, 
and just have tags that imply their neutron dependency?  OR,
2. That they stay stadium projects, but we use tags to differentiate them? Many 
already have different core teams and their own specs process.

Are there particular projects that add more overhead? Does your proposal make 
it easier to get code to our user base? Does it add a bunch of makework to fit 
into a new model (same question, really). Is the PTL overhead too high 
currently? Is the shed pink or blue?  :-)

Thanks,
doug




> 
> '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.
> 
> As a result, there is no oversight by the Neutron core team, the PTL or 
> liasons, but that should not stop people from being involved if they choose 
> to. We would not lose the important piece of information which is the 
> association to Neutron, and at the same time that would relieve some of us 
> from the onus of dealing with initiatives for which we lack enough context 
> and ability of providing effective guidance.
> 
> In the process, the core team 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 30 November 2015 at 20:47, Doug Wiegley 
wrote:

>
> On Nov 30, 2015, at 5:56 PM, Armando M.  wrote:
>
> Hi folks,
>
> The stadium concept was introduced more or less formally since April of
> this year. At the time it was introduced (see [1]), the list of
> deliverables included neutron, client, specs and *-aas services. As you may
> be well aware, 6+ months is a long time in the OpenStack world, and lots of
> things happened since then. The list has grown to [2].
>
> When I think about what 'deliverables' are, I am inclined to think that
> all of the projects that are part of the list will have to behave and
> follow the same rules, provided that there is flexibility given by the
> tags. However, reality has proven us that rules are somewhat difficult to
> follow and enforce, and some boundaries may be too strict for some
> initiatives to comply with. This is especially true if we go from a handful
> of projects that we had when this had started to the nearly the two dozens
> we have now.
>
> 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. 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. I have experienced first hand that
> this has become a burden, 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.
>
> So my question is: would revisiting/clarifying the concept be due after
> some time we have seen it in action? I would like to think so. To be
> fair, I am not sure what the right answer is, but I know for a fact that
> some iterations are in order, and I like to make a proposal:
>
> 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:
>
> Interesting proposal, and I’m just thinking out loud here. I’m generally
> in favor of separating the governance as we separate the dependencies, just
> because at some point what we’re doing doesn’t scale. To provide a little
> context, there are two points worth keeping in mind:
>
> - The neutron stadium actually slightly pre-dates the big tent, and works
> around some earlier governance friction. So it may make less sense now in
> light of those changes.
>

If my memory doesn't fail me, the first time I recall of talks about the
big tent is September 2014, in this email thread:

http://lists.openstack.org/pipermail/openstack-dev/2014-September/046437.html

So, no I don't think we were a novelty :)


>
> - Many of the neutron subprojects *MUST RELEASE IN LOCKSTEP WITH NEUTRON*
> to be useful. These items are less useful to be considered standalone, as
> they need general oversight, co-gating, and such, to stay sane. As we break
> the massive coupling that exists, this point will get less and less
> relevant.
>

I don't think that requires the oversight of a single individual, but
you're right that this point will fade away over time.


>
> - I think that part of the initial intent was that these small subprojects
> would have their own core teams, but be able to take advantage of the
> infrastructure that exists around neutron as a whole (specs, release team,
> stable team, co-gates, mentors).
>
> For your proposal, are you suggesting:
>
> 1. That these projects are fully separate, with their own PTLs and
> everything, and just have tags that imply their neutron dependency?  OR,
>

My point is: the project decides what's best, I don't have to have an
opinion :)

If they want to signal a relationship with Neutron they can do so by
choosing one of the two tags being proposed.


> 2. That they stay stadium projects, but we use tags to differentiate them?
> Many already have different core teams and their own specs process.
>

Must there be a place where we are together that is not OpenStack already?
And what would that together mean exactly? That's the conundrum I am trying
to move away from


>
> Are there particular projects that add more overhead? Does your proposal
> make it easier to get code to our user base? Does it add a bunch of
> makework to fit into a new model (same question, really). Is the PTL
> overhead too high currently? Is the shed pink or blue?  :-)
>

Not sure what you're asking: this isn't just about overhead to a single or
a small group of people. It's about arranging ourselves the best way
possible in order 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Brandon Logan]

On Mon, 2015-11-30 at 23:11 -0500, Russell Bryant 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).

Actually I would put Octavia in #1 as it only interacts with neutron
through its REST API.  There is a neutron-lbaas octavia driver that
simply just calls the Octavia REST API, but it lives in the
neutron-lbaas tree.  Octavia is standalone and consumes all openstack
services through their REST APIs.

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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Doug Wiegley]

> On Nov 30, 2015, at 9:11 PM, Russell Bryant  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).

From the perspective of our users, I tend to consider neutron-lbaas and octavia 
as a unit, technical distinctions aside.

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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Doug Wiegley]

> On Nov 30, 2015, at 10:15 PM, Armando M.  wrote:
> 
> 
> 
> On 30 November 2015 at 20:47, Doug Wiegley  > wrote:
> 
>> On Nov 30, 2015, at 5:56 PM, Armando M. > > wrote:
>> 
>> Hi folks,
>> 
>> The stadium concept was introduced more or less formally since April of this 
>> year. At the time it was introduced (see [1]), the list of deliverables 
>> included neutron, client, specs and *-aas services. As you may be well 
>> aware, 6+ months is a long time in the OpenStack world, and lots of things 
>> happened since then. The list has grown to [2]. 
>> 
>> When I think about what 'deliverables' are, I am inclined to think that all 
>> of the projects that are part of the list will have to behave and follow the 
>> same rules, provided that there is flexibility given by the tags. However, 
>> reality has proven us that rules are somewhat difficult to follow and 
>> enforce, and some boundaries may be too strict for some initiatives to 
>> comply with. This is especially true if we go from a handful of projects 
>> that we had when this had started to the nearly the two dozens we have now.
>> 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. 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. I have experienced first hand that this has 
>> become a burden, 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.
>> 
>> So my question is: would revisiting/clarifying the concept be due after some 
>> time we have seen it in action? I would like to think so. To be fair, I am 
>> not sure what the right answer is, but I know for a fact that some 
>> iterations are in order, and I like to make a proposal:
>> 
>> 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:
>> 
> 
> Interesting proposal, and I’m just thinking out loud here. I’m generally in 
> favor of separating the governance as we separate the dependencies, just 
> because at some point what we’re doing doesn’t scale. To provide a little 
> context, there are two points worth keeping in mind:
> 
> - The neutron stadium actually slightly pre-dates the big tent, and works 
> around some earlier governance friction. So it may make less sense now in 
> light of those changes.
> 
> If my memory doesn't fail me, the first time I recall of talks about the big 
> tent is September 2014, in this email thread:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046437.html 
> 
> 
> So, no I don't think we were a novelty :)
>  
> 
> - Many of the neutron subprojects *MUST RELEASE IN LOCKSTEP WITH NEUTRON* to 
> be useful. These items are less useful to be considered standalone, as they 
> need general oversight, co-gating, and such, to stay sane. As we break the 
> massive coupling that exists, this point will get less and less relevant. 
> 
> I don't think that requires the oversight of a single individual, but you're 
> right that this point will fade away over time.
>  
> 
> - I think that part of the initial intent was that these small subprojects 
> would have their own core teams, but be able to take advantage of the 
> infrastructure that exists around neutron as a whole (specs, release team, 
> stable team, co-gates, mentors).
> 
> For your proposal, are you suggesting:
> 
> 1. That these projects are fully separate, with their own PTLs and 
> everything, and just have tags that imply their neutron dependency?  OR,
> 
> My point is: the project decides what's best, I don't have to have an opinion 
> :)

I don’t think you *have* to have an opinion in either scheme. That sounds 
self-imposed. Delegate it.

> 
> If they want to signal a relationship with Neutron they can do so by choosing 
> one of the two tags being proposed.
>  
> 2. That they stay stadium projects, but we use tags to differentiate them? 
> Many already have different core teams and their own specs process.
> 
> Must there be a place where we are together that is not OpenStack already? 
> And what would that together mean exactly? That's the conundrum I am 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Russell Bryant]

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

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.

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 30 November 2015 at 20:11, Russell Bryant  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 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Gal Sagie]

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

>
>
> On 30 November 2015 at 20:11, Russell Bryant  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:
>>