openstack team mailing list archive

[Andrew Clay Shafer <acs@xxxxxxxxxxxxxxxx>]

What is OpenStack?

Clearly, OpenStack is many things to many people and organizations.

What does it mean to contribute to OpenStack? What does it mean to deploy
OpenStack? What does it mean to operate OpenStack?

What do we mean when we say compatible? interoperable? community? branded?

Is OpenStack a framework? a project? a product?

Recent discussions make it clear that we have a lot of different ideas
about all of these things.

Our collective and individual responsibilities to each other are also a
point of tension.

There is a marked difference in the perspective of those developing the
projects, those operating the projects as services and the final
consumers/clients of those services.

If OpenStack is going to live up to it's full potential and stated mission,
I believe there needs to be a much stronger collective conscience about how
decisions are made.

I feel we will all benefit by making some things more explicit.

If the expectation is that OpenStack is a framework, which is a word I've
heard people use many times, then does an upgrade path have to exist?

The OpenStack dashboard was essentially rewritten to upgrade to a new
version of Django. Was there any expectation that Django should upgrade
itself for us?

Upgrading an application to use a different versions of Rails, another
framework, often borders on impossible, particularly if the application
happens have some feature with a dependency of a gem that hasn't been kept
in sync with the upstream project.

Is OpenStack more or less complicated than those frameworks? What
responsibility should OpenStack core development have to consider existing
deployments? Frameworks are expected be a foundation to build on. By
definition, changing foundations is not easy. Clearly, OpenStack can be
deployed and operated, but if OpenStack needs to be easier to deploy,
operate and upgrade, and that is a responsibility of OpenStack itself, that
can't be something that get's tacked on at the end. There is no 'ease of
deployment' powder to sprinkle on at the end.

Distributions and tooling can and do obscure the difficultly for the
downstream user, but that also leads to a lot of potential fragmentation.
And is that the right answer? Who can and should answer that?

That OpenStack should be easy to deploy and upgrade is somewhat at odds
with OpenStack supporting every possible combination of hypervisor, storage
and networking option, let alone what the expectation should be with closed
source customizations/integrations.

Which brings up questions of compatibility. API compatibility is
potentially misleading if the semantics and behaviors vary. I've heard
several service provider discuss ideas about how they can be differentiated
in the market, and many of those ideas lead differences in APIs to expose.
Is that wrong? Maybe, maybe not, but it certainly makes a lot of work if
your core business is dependent on maintaining integrations with service
providers. Taken to an extreme these decisions complicate and call into
question any future of federated OpenStack services.

I'm not advocating any choice here.

I just want to point out there are compromises that have to be made. There
are goals and desires for OpenStack that are at odds with each other.

Some of that is a function of the perspective of persona, but a lot is also
from fundamental differences in understanding about where OpenStack is,
where OpenStack needs to be, and how to get there.

If there isn't a core guiding conscience about what we are trying to
accomplish that gets applied across the board, then I worry that the future
of OpenStack ends up with more fragments optimizing for their perspective
and inevitable skirmishes when the perspectives collide.

I see there are many conversations we aren't having, which leads to
surfacing all the unaddressed issues when someone does try to involve the
community in discussions.

OpenStack can't be all things, but we get to decide what it will be.

The question is will we do that explicitly and consciously, or indirectly
and passively.

There is no one person who can address this alone.

I'm hoping this can start a conversation.

Best Regards,
Andrew