Open Stack

> I haven't researched this particular case in detail, so I could be 
> misunderstanding its implications.  But in general my impression, 
> from the conversations that occur when these topics are raised, is 
> that many prominent OpenStack developers do not care enough about 
> release-to-release compatibility.  The rule for incompatible changes 
> should be "Just Don't", and I believe that if everyone internalized 
> that, they could easily find alternative approaches without breaking 
> compatibility.

I don't think this is an incompatible change. If you have those flavors,
they're not deleted. They're just not added to new deployments.

> When an incompatible change like this is made, imagine the 1000s of 
> operators and users around the world, with complex automation around 
> OpenStack, who see their deployment or testing failing, spend a 
> couple of hours debugging, and eventually discover 'oh, they removed 
> m1.small' or 'oh, they changed the glance command line'.

So they didn't read the release notes then? Agree that changing a
command line interface is pretty uncool, but these flavors are literally
data that is injected into your database for you. It's the only data
that fits that description. If we hadn't added these to the database for
you initially, you'd never have assumed that some arbitrary grouping of
resources would be named "m1.small" in a new deployment if you didn't
define it to be so.

> Given that hassle and bad feeling, is the benefit that developers
> get from the incompatibility still worth it?

I honestly can't understand why this is an incompatibility, so yes, I
still think it's imperative that we do this.

Out of curiosity, how is this any different from us changing defaults in
config options from release to release, or adding new features that
require you to do things before an upgrade and/or when doing a new
deployment?

--Dan