Open Stack

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