openstack team mailing list archive

[Andrew Clay Shafer <acs@xxxxxxxxxxxxxxxx>]

Disagreements and misunderstanding concerning etiquette and upgrading
Cassandra aside, this thread has three major themes: 1) the relative ease
or burden of upgrade paths 2) compatibility between versions and 3) what
OpenStack values when making decisions.

I believe the first two hinge on the third and the overriding theme is how
do the inevitable burdens of the choices made impact individuals and
organizations.

OpenStack choices impact at least these different personas across different
organizations: core, operators and consumers.

Those groups can obviously be segmented further. Work in core has been done
by individuals with a wide range of motives and interests. Operators are in
stages of deploying and supporting services of various shapes and sizes.
Consumers represent everyone trying to integrate or use OpenStack in one or
all of it's incarnations. Some people fit into more than one of these
groups.

The last two groups are clearly under represented in OpenStack decision
making across the board.

This impacts every decision from what code gets written to how releases are
scheduled and gated. I personally believe this imbalance seriously
jeopardizes the stated OpenStack mission.

In this particular case, I chose option 1 under the following assumptions
(which may be wrong):

   - the api for the end user would not change
   - the code for the service is essentially the same, it is just being
   renamed
   - option 2 doesn't lower risk or burden for anyone, it just postpones
   them, while increasing complexity, confusion and future burdens for core
   development and probably operators as well

Under these assumptions, the impact on users would be negligible if any,
and for the operators of existing deployments  the burden is copying a
database, changing some configurations and starting some services.

Data and consequently storage should arguably be the most important thing
in the hierarchy of priorities. Any risk of losing user data should be
given the highest consideration. My assumption was that this could be
applied to running deployments without risk of data loss.

On the question of compatibility, my assumption is this a non-issue for the
moment.
On the question of an upgrade path and the relative ease of deployment, my
assumption is this is no worse than any of the other upgrades.
On the question of how we make decisions as a community and how they are
perceived in the ecosystem at large, I believe this thread reveals more
questions than answers.

These assumptions could be totally wrong. If they are correct, I still
advocate option 1. If they are wrong, or the preponderance of support is
for option 2, I would support that and hope we collectively attempt to
mitigate the complexity and confusion by over communicating with the
community and each other.

In specific, I think getting more information from operators and users is
generally good. Ultimately, if OpenStack cannot be operated and utilized,
the mission will fail. I'd hope that doesn't have to be done in a
reactionary way and we can collectively get better at considering the
cascading impacts of the choices we make both for operators, users and also
across projects.

I don't agree with George Reese on every point and he clearly knows nothing
about Cassandra, but I don't have a problem with his message or his
language choices. In this case, he is in a position to provide valuable
insights into the current state of the OpenStack ecosystem, both relative
to itself and most other cloud platforms. He's only mad because he cares. I
prefer that to silent apathy.

For the future, OpenStack has to come to terms with what it wants to be
when it grows up.

API compatibility should not be taken lightly. It doesn't mean things can't
change, for me it means being mindful about how things are versioned and
communicated. This is all about attitude and discipline.

Ease of deployment and operations has been left as an exercise for the
reader. Configuration management and packaging is something people
understand to various degrees. Reliability and availability have been left
up to deployment specific architectural choices. API end points can be
scaled like any http service. Scaling up and scaling out relational
databases is something people know how to do. There are technically more
sophisticated ways to handle many of these issues by giving them more
consideration in the projects and making openstack services more aware of
themselves and each other. These changes would be a considerable
undertaking and should not be taken lightly. So far, we haven't
collectively had the patience or stomach to move in this direction, and in
some places where progress has been made, it hasn't been pushed back
upstream for a variety of reasons, real or imagined. I personally hope
OpenStack will one day be able to deploy itself on bare metal and sensibly
adding or removing capacity is relatively trivial compared to today.

As for community, I am personally disappointed by how past decisions were
made about lots of things. We can do better. The issues and emotions raised
in this thread should not be dismissed. Doing that is to put the potential
of OpenStack in peril.

Regards,
Andrew Clay Shafer