For reference, this is an extension of my initial post to the foundation mailing list discussion initiated by Thierry Carrez. I thought that I could be a little clearer here in what I really think about the subject of Core and interoperability in OpenStack.
Having been part of the defcore committee until the end of January, I must say that the work that is being done there is very important. Defining what type of interoperability we want to measure and offer is key to providing OpenStack users valuable information.
However, as part of this committee, I have failed to make myself heard on a very key point. The notion of core, or interoperability, means 3 different things, because of the nature of what we do and the population they address:
- Which projects are part of core and can call themselves OpenStack?
-> Interesting to developers and distribution builders
- Which distributions are based on core OpenStack and can therefore call themselves OpenStack?
-> Interesting to cloud operators that want to pick an OpenStack distribution
- Which clouds are delivering an OpenStack experience and can call themselves OpenStack?
-> Interesting to cloud users and enterprises wanting to pick the right infrastructure to deploy their applications on
The current bylaws of the foundation fails to make this distinction in defining the term Core, and therefore the DefCore committee has failed to distinguish between those 3 aspects; it seems to me that the committee is producing a bunch of generic rules which try to satisfy 3 very different situations. This is going to, at best, produce some lowest common denominator set. This would end up not satisfying anyone in terms of what core means and adding useless complexity in some cases.
Why should we care about which API is defining what OpenStack is when adding a new project into OpenStack? We should care about the quality of the API, how useful and thorough it is, but is it the right moment in the lifecycle to define it as what should be present on every cloud that claims to be OpenStack? I don’t think so, as this second part should be driven more by a user committee that will try to balance usefulness versus adoption. In a same project, we could have some API which are key to interoperability and others which are secondary. This should not prevent us from calling the project “OpenStack X” if we think it brings value to our brand.
We may also find useful to be able to define that a distribution of OpenStack needs to include various subset of components, depending on what we are trying to achieve. For example, why should we not be able to define what is an OpenStack for storage distribution, independently of one for compute, independently of a set of orchestration components, and so on? Not saying that we should do this, but that we should leave ourselves this option.
So, yes, we need to determine which type of interoperability we want to achieve, but I do think that we need to define what is Core independently for each one of the 3 cases above. The perception of what OpenStack “is” cannot be defined independently of the type of users and what interactions they are going to have with OpenStack. And this may very well have ties onto which body has the power to validate what (their version of) Core is.
I fully understand the urgency of defining what Core is, as it is poorly worded in the foundation bylaws, but I think that we could easily define it with either 3 different contexts (confusing, but should not require a change of the bylaws), or plan a bylaws change as soon as the needed quorum can be reached.
In any case, I really think that the very key element to our user base (speaking as an OpenStack community member), is the ability to know where his workloads will work without modifications from one OpenStack provider to the other (case 3 above). This means that we need to be able to advertise which OpenStack cloud can be seen as fully interoperable, with the end goal of being able to form cloud federations which would ensure transposability of workloads with a single identity. This is when we would really be able to see OpenStack as a real option to AWS, when you want to be able to operate the same workloads around the globe and adding multi-sourcing capabilities.
Latest posts by Nick Barcet (see all)
- Why we need 3 cores in OpenStack - 06/02/2014
- History, objectives and limits of the Ceilometer project - 02/09/2013