Open Stack

On Fri, 12 Feb 2016, Doug Wiegley wrote:

> It hurts discoverability, and “expectedness”. If I’m new to
> openstack, having it default boot unusable just means the first time I
> use ’nova boot’, I’ll end up with a useless VM. People don’t
> read docs first, it should “just work” as far as that’s sane.
> And OpenStack has a LOT of these little annoyances for the sake of
> strict correctness while optimizing for an unusual or rare case.

Sorry for being a bit late to the game and jumping into the thread
in the middle, but: I wanted to highlight above paragraph. Yes,
there are many of these little annoyances in OpenStack where the
principle of least surprise is completely violated.

In the present day, with the many structures we have in place to manage
versions, backwards compatibility, rolling upgrades, etc it is
increasingly difficult to fix these problems. That rather sucks. If
something is wrong and bad for users _now_ (especially the ones that
don't exist yet) and fixing it costs users only a bit of effort, we may
as well do it.

Microversions, as an example, are designed to make backwards
incompatible changes possible: unless a client requests 'latest' it
is fixed in time. The client users and authors have to make an
explicit choice to move forward. Let's use them and quit
constructing obstacles in the way of making things better.

We can argue that some deployer might move the microversion bar without
notifying users and gosh, we better protect against that. No, we
shouldn't. That's an issue between the deployers and the users.
OpenStack has built in the protections, if people just to use them
poorly, their problem.

> The original stated goal of this simpler neutron api was to get back
> to the simpler nova boot. I’d like to see that happen.

+1

-- 
Chris Dent               (╯°□°)╯︵┻━┻            http://anticdent.org/
freenode: cdent                                         tw: @anticdent