openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

So many questions, so hard to reply. Whats the best question to answer here ;)

From: Andrew Clay Shafer <acs@xxxxxxxxxxxxxxxx<mailto:acs@xxxxxxxxxxxxxxxx>>
Date: Fri, 10 Aug 2012 14:41:03 -0700
To: openstack <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: [Openstack] Setting Expectations


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