> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev