On 20/04/18 17:26, Doug Hellmann wrote:
[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]
Thanks Doug, I think this is a really helpful question.
We are discussing adding at least one new project this cycle, and
the specific case of Adjutant has brought up questions about the
criteria we use for evaluating new projects when they apply to
become official. Although the current system does include some
well-defined requirements [1], it was also designed to rely on TC
members to use their judgement in some other areas, to account for
changing circumstances over the life of the project and to reflect
the position that governance is not something we can automate away.
Without letting the conversation devolve too much into a discussion
of Adjutant's case, please talk a little about how you would evaluate
a project's application in general. What sorts of things do you
consider when deciding whether a project "aligns with the OpenStack
Mission," for example?
Doug
[1] https://governance.openstack.org/tc/reference/new-projects-requirements.html
The first thing to mention is that I take a fairly expansive view of
what IaaS comprises. (For example, I think a message queue like Zaqar is
a critical component of an IaaS, which often surprises people, but how
can an application use its infrastructure as a server without
notifications about what's going on in the infrastructure? I guess we
could try to optimise for polling in a thousand different places, but
it's much simpler to expose events in one place and optimising polling
of that.) A while back[1] I threw together a non-exhaustive list of the
kinds of goals I think OpenStack should be working towards:
* Infinite scaling - the ability in principle to scale from zero to an
arbitrarily large number of users without rewriting your application
(e.g. if your application can store one file in Swift then there's no
theoretical limit to how many it can store. c.f. Cinder where at some
point you'd have to start juggling multiple volumes.)
* Granularity of allocation - pay only for the resources you actually
use, rather than to allocate a chunk that you may or may not be using
(so Nova->containers->FaaS, Cinder->Swift, Trove->??? [RIP MagnetoDB], &c.)
* Full control of infrastructure - notwithstanding the above, maintain
Nova/Cinder/Neutron/Trove/&c. so that legacy applications, highly
specialised applications, and higher-level services like PaaS can make
fully customised use of the virtual infrastructure.
* Hardware virtualisation - make anything that might typically be done
in hardware available in a multi-tenant software-defined environment:
servers, routers, load balancers, firewalls, video codecs, GPGPUs, FPGAs...
* Built-in reliability - don't require even the smallest apps to have 3
VMs + a cluster manager to enforce any reliability guarantees; provide
those guarantees using multi-tenant services that efficiently share
resources between applications (see also: Infinite scaling, Granularity
of allocation).
* Application control - (securely) give applications control over their
own infrastructure, so that no part of the application needs to reside
outside of the cloud.
* Integration - cloud services that effectively form part of the user's
application can communicate amongst themselves, where appropriate,
without the need for client-side glue (see also: Built-in reliability).
* Interoperability - the same applications can be deployed on a variety
of private and public OpenStack clouds.
I'm definitely not claiming to have captured the full range of
possibilities there (notably it doesn't attempt to cover e.g.
deployment-related projects), but at a minimum any project contributing
to one or more of those points is something I would consider to be
aligned with OpenStack's mission. (That, of course, is only one of
several criteria that are considered.)
I would love to see us have a conversation as a community to figure out
what we all, collectively, think that list should look like and document
it. Ideally new projects shouldn't have to wait until they've applied to
join OpenStack to get a sense of whether we believe they're furthering
our mission or not.
To be clear, although I don't expect it to come up, something like a
PaaS (think CloudFoundry, or OpenShift) would be *not* be in-scope for
OpenStack in my view. (We should definitely to encourage them to
integrate with Keystone anyway though!)
One thing I think the TC needs to be wary of is that at this stage of
maturity there may be a temptation to engage in a sort of 'regulatory
arbitrage': to try to land your pet feature wherever it's easiest to get
it accepted, rather than where it makes the most technical sense.
Indulging that temptation works against interoperability, which is a
critical part of our mission. It should be easy enough for the TC to
spot and reject projects that should just be a feature somewhere else.
But another danger is projects whose implementations provide a very
flexible framework (Adjutant is an example, it has a plug-in model that
can basically make it an API for anything) - they run the risk of
turning into a catch-all bucket for random features. The solution there
is clear communication. From the TC perspective I think that should mean
insisting on an explicitly-defined scope, erring on the side of too
narrow if necessary - a team can always come back to the TC and
negotiate an increased scope, but it's almost impossible to narrow the
scope of an established project.
The Four Opens obviously remain critical, and I think the TC has been
doing a good job of policing new projects on those. It will be necessary
to accept single-vendor projects, because in part the purpose of
bringing projects under TC governance is to reassure potential
contributors that the project is committed to the Four Opens. (An
example from my own experience: Heat was accepted into incubation as a
single-vendor project, and only later blossomed into an extremely
diverse project. So it can work.) The main thing I will be looking out
for in those cases is that the project followed the Four Opens *from the
beginning*. Projects that start from a code dump are much less likely to
attract other contributors in my view. Open Source is not a verb.
cheers,
Zane.
[1] You can read it in-context here:
https://review.openstack.org/#/c/401226/2/reference/openstack-vision.rst@34
__________________________________________________________________________
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
