Open Stack

On 14/06/2016 17:14, Anita Kuno wrote:
> On 06/14/2016 10:44 AM, Hayes, Graham wrote:
>> On 14/06/2016 15:00, Thierry Carrez wrote:
>>> Hi everyone,
>>>
>>> I just proposed a new requirement for OpenStack "official" projects,
>>> which I think is worth discussing beyond the governance review:
>>>
>>> https://review.openstack.org/#/c/329448/
>>>
>>>  From an upstream perspective, I see us as being in the business of
>>> providing open collaboration playing fields in order to build projects
>>> to reach the OpenStack Mission. We collectively provide resources
>>> (infra, horizontal teams, events...) in order to enable that open
>>> collaboration.
>>>
>>> An important characteristic of these open collaboration grounds is that
>>> they need to be a level playing field, where no specific organization is
>>> being given an unfair advantage. I expect the teams that we bless as
>>> "official" project teams to operate in that fair manner. Otherwise we
>>> end up blessing what is essentially a trojan horse for a given
>>> organization, open-washing their project in the process. Such a project
>>> can totally exist as an unofficial project (and even be developed on
>>> OpenStack infrastructure) but I don't think it should be given free
>>> space in our Design Summits or benefit from "OpenStack community" branding.
>>>
>>> So if, in a given project team, developers from one specific
>>> organization benefit from access to specific knowledge or hardware
>>> (think 3rd-party testing blackboxes that decide if a patch goes in, or
>>> access to proprietary hardware or software that the open source code
>>> primarily interfaces with), then this project team should probably be
>>> rejected under the "open community" rule. Projects with a lot of drivers
>>> (like Cinder) provide an interesting grey area, but as long as all
>>> drivers are in and there is a fully functional (and popular) open source
>>> implementation, I think no specific organization would be considered as
>>> unfairly benefiting compared to others.
>>>
>>> A few months ago we had the discussion about what "no open core" means
>>> in 2016, in the context of the Poppy team candidacy. With our reading at
>>> the time we ended up rejecting Poppy partly because it was interfacing
>>> with proprietary technologies. However, I think what we originally
>>> wanted to ensure with this rule was that no specific organization would
>>> use the OpenStack open source code as crippled bait to sell their
>>> specific proprietary add-on.
>>>
>>> I think taking the view that OpenStack projects need to be open, level
>>> collaboration playing fields encapsulates that nicely. In the Poppy
>>> case, nobody in the Poppy team has an unfair advantage over others, so
>>> we should not reject them purely on the grounds that this interfaces
>>> with non-open-source solutions (leaving only the infrastructure/testing
>>> requirement to solve). On the other hand, a Neutron plugin targeting a
>>> specific piece of networking hardware would likely give an unfair
>>> advantage to developers of the hardware's manufacturer (having access to
>>> that gear for testing and being able to see and make changes to its
>>> proprietary source code) -- that project should probably live as an
>>> unofficial OpenStack project.
>>>
>>> Comments, thoughts ?
>>>
>>
>>
>>  From our perspective, we (designate) currently have a few drivers from
>> proprietary vendors, and would like to add one in the near future.
>>
>> The current drivers are marked as "release compatible" - aka someone is
>> nominated to test the driver throughout the release cycle, and then
>> during the RC fully validate the driver.
>>
>> The new driver will have 3rd party CI, to test it on every commit.
>>
>> These are (very) small parts of the code base, but part of it none
>> the less. If this is passes, should we push these plugins to separate
>> repos, and not include them as part of the Designate project?
>>
>> As another idea - if we have to move them out of tree - could we have
>> another "type" of project?
>>
>> A lot of projects have "drivers" for vendor hardware / software -
>> could there be a way of marking projects as drivers of a deliverable -
>> as most of these drivers will be very tied to specific versions of
>> OpenStack projects.
>>
>> I fully agree with the sentiment, and overall aim of the requirement,
>> I just want to ensure we have as little negative impact on deployers
>> as possible.
>>
>>   -- Graham
>
> I highly recommend you spend some time interacting with the Neutron,
> Nova, Cinder and Ironic communities to learn how they approach this
> issue. Each community has a slightly different approach to interacting
> with vendors with different pain points in each approach. I think
> learning from these projects regarding this issue would be a great way
> to formulate your best plan for designate. Also time spent with Mike
> Perez on this issue is an investment as far as I'm concerned.
>
> Thank you,
> Anita.
>

Yup, and I have looked at each of these projects before.

I am more concerned about how this particular governance change will
affect the project.

Thanks

Graham

>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>