In a recent TC Report I said we need more 'written works...that layout a vision of how things could or should be that community members can react and refer to' and 'Many of the things that get written will start off wrong but the only way they have a chance of becoming right is if they are written in the first place. Providing ideas allows people to say "that's right" or "that's wrong" or "that's right, except...'.

The point of writing stuff like this is so there can be a reaction and a process of refinement where we can reach some ideas that we all can live with. When I write, I hope that when you read this you don't think of ways to shoot me down and tell me I'm wrong, but instead think of ways to make the ideas more right.

This is a collection of opinions about the state of OpenStack that I wrote down this morning while I had no connection to the internet. There are some ideas (many wrong) that I hope can provide some grist for discussions surrounding building a tech vision and working through some of the pains we're experiencing while evolving as a community.

This only way in which this post is actionable is as a way to have further discussion. It's not really an accurate description of the current reality, nor a prescription for how to get to a new one from here. There are an enormous number of people and activities with whom I have no experience. These ideas take no account of those. I'm not leaving something out because I don't care about it, but because I'm ignorant. Want me to know something? Tell me about it.

These are vast glittering generalities with sweeping gestures. To me, these provide the foundations upon which to think about stuff and understand it. It's how I see the world: vast pattern-based analogies. For others it is annoying because there's no concrete advice. We probably need both, and each feeds the other, so I hope this is useful in what amounts to an aspirational fashion: It would be nice if we could get closer to $something even if only by a little bit.

With all that out of the way, let's begin.

The current work on the technical vision is mostly oriented around describing what OpenStack is and what OpenStack can become. A lot of that is trying to discern what different groups have thought it to be. A thing which provides the building blocks for enabling a market. Or the blocks for building a datacentre. Or not solely blocks, but a full service cloud.

Each of these is a reasonable thing but none of it is a description for how to build or how to make decisions in the face of ambiguity. We need answers to questions related to the boundaries between things and how they are composed. Descriptions of not only vertical layers but also horizontal groupings. Common wisdom to live by.

And in all these areas the questions are not limited to technical. OpenStack is a complex system of people, companies, and technology, all making competing and conflicting demands.

Because of the way OpenStack chose to model itself, the system (technical and social) is simultaneously centralized and siloed, leading to the now well-known problems of fragility and unreliable views and understanding (of social and technical state).

Random Ideas on Maintainership

As the number of people available to provide large amounts of time to keeping OpenStack healthy shrinks, the need to focus on maintenance grows. Those people who are most present must focus their energy on enabling other people. They should be maintainers, foremost, and focus on:

• bugs before features
• code maintainability before features
• refactoring to enhance code scrutability before features
• code reviews before features
• enabling other people to write features

If no one shows up to write features, that presumably means the features aren't all that important.

This kind of focus requires that corporate contributors appreciate and acknowledge the importance of providing maintainers. This feels like a hard sell, but we can make its importance more obvious by not squeezing these maintenance tasks in between other "more important" stuff or after hours. Do the maintenance tasks first, go home at the end of the day, and let the other things lag. Don't be a hero. Otherwise, everyone else is forced to be one too and the true cost of doing business is obscured.

Anyone who self-identifies as a "maintainer" should consider themselves a maintainer of OpenStack, not of an individual project (e.g., nova, cinder, etc). If we can break down our own mental barriers between projects we can break down some of the classism in OpenStack society and pay more effective attention to managing the technical boundaries between projects.

Random Ideas on State and State Management

• In an OpenSource and multi-purpose system like OpenStack, the purpose of an HTTP API is to both enable and enforce boundaries and to not share state. They are for exposing state and manipulating state which can be used for both planned and unplanned uses. If you don't want unplanned uses, don't use an HTTP API.
• You want unplanned uses. That's the engine of innovation.
• If the real world can provide information with sufficient reliability there's little point modelling and mirroring that world in the artifact world of a database.
• What are the reasons for why each sub-project uses its own database? Managing migrations? Scaling and distribution opportunities? What else? Is it worth it?

Random Ideas on Architecture and Design

Discussing OpenStack architecture can easily become a dark depressing hole as we get trapped in a state of "how can we get there from here?". We can work on that. We have to. It may be necessary to break some of our own rules to achieve it.

These range all over the place. Some of them are obvious or repeats of things we've heard many times.

• Single responsibility principle is a good one.
• Separate specific actions (launch a VM with these resources) from orchestration (give me a vm of flavor X, affined to group Z, using block storage A, with network B, running application C).
• Make the actions as granular and composable as possible, in both use and code.
• Put UI/UX at the level of orchestration. Thus the "public" HTTP APIs too.
• At each layer produce enough information about activity so the layer above can consume it usefully and make some decisions. This is akin to backpressure.
• Anything can be a layer to something else. One person's top is another person's bottom.
• Don't push lots of info to things. Instead push typed events with identifiers that allow the recipient to choose what and how much information they retrieve. For example: What would it take and what would it achieve if we were to stop doing RPC with fat objects and instead pass identifiers which allow agents to retrieve (only) the necessary information?
• If there is a already a type of tool that provides useful and mature functionality, don't reinvent tools in that class and don't use something weird. Use standard and boring stuff that can work and be forgotten. The classic misstep in OpenStack was using the eventlet-based web server. If you are making a fairly simply CRUD-style web service, then make a WSGI application that can be hosted by any WSGI server and don't delve into the complexity of using eventlet.

Random Ideas on Project Inclusion

• It should not be the job of OpenStack to audit, bill, monitor or archive. Instead OpenStack should be auditable, billable, monitorable, and archivable. That is, it should be observable and eventing.
• Similarly, if it is (is it?) to be OpenStack's job to install itself, then there should be one good way to do that which OpenStack (the community) owns, a way that enables realistic and quick trials and experimentation. If we're not going to do that, then OpenStack should enable itself to be installed in various ways, but tools to do it are not OpenStack itself. Instead they are very good friends of OpenStack.

Random Ideas on Code Style

• Using globals to avoid a bit of boilerplate is often not a good trade. I'm looking at you oslo.config.
• If you're writing code that requires mocks to test it, you have just discovered an opportunity for refactoring. If you're writing a new module or class, write your tests first, because then you'll be inclined to avoid mocks and as a result will be writing more maintainable, scrutable, and reusable code.
• We continue to use Python because it has many advantages with regards to maintainability and readability. Don't let Python down by building classes, methods and files that are 100s or even 1000s of lines long. Try to be idiomatic in your use of Python. import this and other clichés.

Random Ideas on Random Ideas

• Don't use IRC to share information on the fly or build decisions and expect them to stick. Doing so leaves out vast swathes of the community. Either because they are asleep or because they can't use IRC. The only reliable messaging platforms we have are email lists and gerrit reviews.
• If you're a long term member of the community, one of your main jobs is making more members of the community. One way to do this is by sharing random ideas in a way that people can see them. If you're spending too much time hanging out in your echo chamber with your chums, you're building confirmation and survivorship bias.
• For reasons I can't quite discern, there are karmic social forces at work in OpenStack that work against spouting random ideas and engaging people in conversation that questions the current state of things. This is a great way to never change anything. I hope we've finally learned we need to change.

All of the above statements could very well be wrong (some assuredly are), but they are related to topics that keep coming up. Some kind of resolution needs to happen, somehow. We've managed reasonably well so far, and we can continue to manage, even in the face of the changes we are witnessing. But wouldn't it be nice to do more than manage?