Open Stack

On Wed, 12 Apr 2017, joehuang wrote:

> Can all these efforts lead us to one platform vision? We have to
> think over the question.
>
> What's the one platform will be in your own words? What's your
> proposal and your focus to help one platform vision being
> achieved?

These are tough questions. It's great to have a vision of one
platform, but if there are multiple understandings of what that
platform is (even when everyone thinks they are agreeing it's often
the case that they are not), it will be very hard to make progress.
At the same time inertia has enormous power to keep people,
projects, and companies doing the same old thing.

As usual, I think spending more effort to write down ideas, such as
the TC Vision draft and its concept of constellations[1] and the
resolution on cloud applications[2], are an important (but not
fully sufficient) step. The documents provide a focus around which
discussion can happen. While disagreement and enthusiasm are
important indicators, at least as important is the degree to which
people squirm about the assumptions being made. Writing helps to
expose those assumptions and once exposed we can decide what to do
with them.

In order for us to move forward on the one platform idea we need to
take the time and effort first to articulate the multiple approaches
and second to convince people of their merit. This second step will
require consistent engagement with not just project members but with
the companies that are funding most contributors. Those companies
have to be convinced of the merit of change. There's no doubt this
will be challenging, especially in these times when some companies
are willing to declare that OpenStack is "broken".

Making progress will require a TC that is proactive. In the last
election in October there were questions around whether the TC
should be a "a reactive council" or "a proactive committee that
initiates change"[3]. I'm firmly in the latter camp but believe the
action must be driven by a very active feedback loop with the entire
OpenStack community.

In any case, I do have a personal vision. It could very well be far
too pie in the sky and require too much change, but if approached
incrementally could provide benefit. My hope is that lots of people
would have a chance to express their vision and from all of them we
would choose the best bits to form the vision that we pursue. Any
vision will have many dependent tasks that must be satisfied
before the vision can even start. For example common policy
scenarios[4] and application user accounts[5] are global issues we
will need to address.

Essentially the idea is to change or expand the layers at which
humans and external applications interact with OpenStack, in the
style of oaktree[5] or enamel[6], where the outer layer is a single
API service driven by use cases (give me a vm, give me a bare metal
server, give me a pod representing elastic application X,
orchestrate the assemblage of Y). That layer speaks to the service
APIs to achieve its needs. Complex use cases (NFV perhaps?) might
skip the outer layer when they require functionality that the outer
layer does not expose. If the constellation metaphor catches on then
it is also possible that different constellations might have
different outer layers.

Like so many technology solutions, this is "simply" introducing
another layer of indirection. Doing so would enable each layer to
evolve with some independence and, critically, would allow different
implementations of the same service type to leapfrog an
incumbent[7]. To use that hackneyed cliché: skate to where the puck
will be.

If we are going to be thinking of OpenStack as one platform, then we
need to evaluate its various pieces with regard to how they support
that platform and each other as a whole. The needs and goals of the
individual services need to be secondary to the needs and goals of
OpenStack at large. That's a huge change in behavior and attitude,
one that might not be achievable, but worth trying.

I've been around long enough to know that there are many objections
to these kinds of changes, both technical and social. I think,
however, that it is important to at least consider them so we can
discover what improvements are possible. We're starting to recognize
that OpenStack must evolve more quickly. In order to do that we must
figure out ways to work around or loosen the constraints we've built
into our process and ways of engaging new audiences.

None of this is possible, however, unless the OpenStack community in
general and the TC in particular is able to come up with an
effective way to effectively publicize and manage the need for
contributors and other resources. The increased writing described
above will provide some help with that, but another important part
will involve being very clear with all stakeholders about the
sheer volume of work required to create and maintain OpenStack.

[1] https://review.openstack.org/#/c/453262/
[2] https://review.openstack.org/#/c/447031/
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-October/104953.html
[4] https://review.openstack.org/#/c/245629/
[5] https://github.com/openstack/oaktree
[6] https://github.com/jaypipes/enamel
[7] Note that I'm not suggesting here that a new implementation of
a service type implement the same internal API. I'm saying there could
be a new API and implementation that the outer layer would interface
with to satisfy the same use cases using changed technologies.

-- 
Chris Dent                 ¯\_(ツ)_/¯           https://anticdent.org/
freenode: cdent                                         tw: @anticdent