A while ago I had a little rant about Ceilometer and dangers of overreaching. A similar discussion has popped up in the OpenStack-Operators list, during which it became clear that some operators had taken the bits they wanted from Ceilometer and gotten rid of the rest. Others had simply stopped using it.
A little while ago the deprecation of the EC2 API from Nova cropped up on OpenStack Operators and covered a variety of topics, notably the overheads experienced when developing an OpenStack project stifling the creativity and motivation of developers.
Yesterday, I read the new project requirements for OpenStack, where one of the criteria is:
Where it makes sense, the project cooperates with existing projects rather than gratuitously competing or reinventing the wheel.
This sounds great, except when you consider a partially successful case like Ceilometer.
When it rolled around to today, and I thought “what the hell am I going to write now?” these thoughts glommed together.
What would happen if OpenStack minimised it’s scope? What if it delivered a framework to fulfil its mission, but stopped short of providing the entire solution?
the focus of core development would change to providing all the basic hygiene items users require: smooth upgrades, stable branches mean stable software and that sort of thing.
Almost all feature-based innovation moves outside of the core (into Stackforge? elsewhere? Does it actually matter?)
Software vendors are free to pursue their own agendas, and it becomes obvious whether they are contributing to OpenStack or building their own features. Vendors use this information to market themselves as they please.
- Developers have frictionless mechanisms to contribute as they see fit.
- Requirements for changes in the core are delivered no more slowly than they are today.
- Core components that get their architecture “right” create much less maintenance work freeing resources that can be applied to creating new user value. Similarly consistent architectures across components can deliver efficiency gains that can be expended on creating user value.
- The number and size of official OpenStack project teams will probably shrink. Possibly by a great deal.
Now, I’m not an expert on the architecture of any of the components, so I can’t really comment on whether this is feasible for all projects, or perhaps has already happened in many of them. My point is more about whether this approach should be an explicit goal for OpenStack. My view is that it must.
OpenStack is already showing signs of stress from the difficulty of providing an integrated release between a large number of projects. The response from the TC has the same intent as what I have described above: improve focus on the core, lessen the friction for developers. However the methods for achieve this are markedly different:
- The barrier to entry for a project is lower
- The concept of an integrated release is removed over time
- Metadata is created to describe each project so that OpenStack users can determine the qualities of a given project.
It seems that the reason for this approach is to ensure that the community engagement: to allow a larger number of developers to work on projects that are sanctioned as part of OpenStack. This is laudable, but I’m not sure that the cost of maintaining an ever growing list of projects, even without an integrated release, is manageable. The quality of projects must still be assessed regularly in order for users to make accurate decisions, and this assessment must be made over a larger and larger set of projects.
The other benefit is that it allows easy reporting to the board for trademark related concerns, which is entirely secondary to anything the users might experience, and so probably quite irrelevant to increasing the quality of OpenStack.
It also does nothing to address the issue of troubled projects. Where a project has tried and only partially succeeded delivering on it’s mission we are faced with a problem. It seems we must convince the TC delegates that a competing project is worthwhile.
Reducing the scope of what an OpenStack sanctioned project to a high quality framework for innovation strongly controls the size of the QA task thus increasing the confidence of the users on the attributes of a particular version of the code. Whilst fewer developers would be working under an OpenStack sanctioned umbrella, the overall developer population should be working with a better OpenStack and those not in an OpenStack project can build whatever they want, however they want.
Yes, the number of ATCs will shrink, with a corresponding impact on the size of the electorate for the TC. I don’t think this is a problem. The core devs have a tightly focussed remit on a relatively small code base and can concentrate on that without the overhead of getting caught up in a vendor’s product delivery cycle.
This isn’t a proposal for the democratisation of the core of OpenStack. Quite the opposite: it’s a proposal to focus the control of the OpenStack Foundation to the very core of the ecosystem and to allow, or actually foster, innovation and the creation of value to occur unimpeded. Make of it what you will.
Written by Roland Chan
