<div><br></div>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.<br>



<div class="gmail_quote"><br></div><div class="gmail_quote">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.</div>


<div class="gmail_quote"><br></div><div class="gmail_quote">OpenStack choices impact at least these different personas across different organizations: core, operators and consumers.</div><div class="gmail_quote"><br></div>


<div class="gmail_quote">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. </div>


<div class="gmail_quote"><br></div><div class="gmail_quote">The last two groups are clearly under represented in OpenStack decision making across the board.</div><div class="gmail_quote"><br></div><div class="gmail_quote">


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.</div><div class="gmail_quote"><br></div>


<div class="gmail_quote">In this particular case, I chose option 1 under the following assumptions (which may be wrong):</div><div class="gmail_quote"><ul><li>the api for the end user would not change</li><li>the code for the service is essentially the same, it is just being renamed</li>

<li>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  </li>
</ul><div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div><div><div>On the question of compatibility, my assumption is this a non-issue for the moment.</div><div>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.</div>

<div>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.</div></div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>For the future, OpenStack has to come to terms with what it wants to be when it grows up.</div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>
<div><br></div><div>Regards,</div><div>Andrew Clay Shafer</div><div><br></div>
</div>