Open Stack

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.

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