On 6/14/2016 8:57 AM, 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 ?
Being someone that doesn't attend TC meetings and doesn't follow every
thread for every project in OpenStack, I'm having a hard time with
concrete examples and what this means. I have a feeling a lot of this
has to do with Neutron stadium stuff, which I haven't been following
either, except I think it's getting reigned in (at least that's what I
remember from the mitaka midcycle discussion).
From the Nova POV I'm really just reading this as compute drivers. We
have some in tree and some out of tree. Among the ones in tree we have a
wide mix when it comes to feature parity, in part because a lot of the
early Nova API was written with libvirt and xenapi in mind (e.g.
agent-builds for xen), or specific volume drivers interacting with a
specific compute driver (e.g. os-assisted-volume-snapshots with
libvirt). And then we have vmcenter, hyper-v and ironic.
And we have out of tree drivers, like zvm, lxd and powervm. powervm is
actively trying to get in tree. lxd is not, nor is zvm (at least I don't
hear anything from the zvm developers).
But taking zVM for example, I don't have a mainframe sitting around in
my basement, so I can't test changes for that. Or a Power8 system for
testing powervm. But that's why we require third party CI for things
that we don't test in community infra.
So is the question does Nova provide a level playing field as a project
because it has drivers that can be deployed and used and tested without
special hardware, i.e. libvirt? Then yes. Or is it Nova doesn't provide
a level playing field because zVM and powervm aren't in tree?
If this is really just, random project wants to be considered an
'official' OpenStack project but is totally unusable without a
proprietary stack to deploy and run it - which makes it completely
vendor specific, regardless of whether or not they open sourced the
front-end to talk to their proprietary backend, so only developers from
said vendor can work on the project, then yeah, I agree with the
proposed change in wording.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
