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

Assaf Muller amuller at redhat.com
Thu Feb 4 22:36:00 UTC 2016


On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins <sean at coreitpro.com> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list