On 06/04/16 19:28, "Fox, Kevin M" <kevin....@pnnl.gov> wrote:
>+1 >________________________________________ >From: Neil Jerram [neil.jer...@metaswitch.com] >Sent: Wednesday, April 06, 2016 10:15 AM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from >nova > >I hesitate to write this, even now, but I do think that OpenStack has a >problem with casual incompatibilities, such as this appears to be. But, >frankly, I've been slapped down for expressing my opinion in the past >(on the pointless 'tenant' to 'project' change), so I just quietly >despaired when I saw that ops thread, rather than saying anything. > >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. > >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'. Given that hassle and >bad feeling, is the benefit that developers get from the incompatibility >still worth it? I have rarely seen the operator community so in agreement as on this change impact. Over the past 4 years, there have been lots of changes which were debated with major impacts on end users (EC2, nova-network, …). However, I do not believe that this is one of those: This change - does not break existing clouds - has a simple 5 line shell script to cover the new cloud install and can be applied before opening the cloud to the end users - raises a fundamental compatibility question to be solved by the community What I’d like to replace it is a generic query along the lines of give me a flavor with X GB RAM, Y cores, Z system disk and the metadata flags so I get a GCPU and ideally huge pages There is a major difference from option dropped or major functionality deprecated as I can hide it from my end users with a few flavor definitions which make sense for my cloud. Incompatible changes for existing production deployments, e.g. CLIs, should be handled very carefully. Cleaning up some past choices for new clouds with appropriate documentation and workarounds to keep the old behaviour seems reasonable. > >I would guess there are many others like me, who generally don't say >anything because they've already observed that the prevailing sentiment >is not sufficiently on the side of compatibility. We have a production cloud with 2,200 users who feel the pain of incompatible change (and pass that on to the support teams :-) I feel there is a strong distinction between incompatible change (i.e. you cannot hide this from your end users) vs change with a workaround (where you can do some work for some projects to emulate the prior environment, but new projects can be working with the future only, not accidentally selecting the legacy options). I do feel that people should be able raise their concerns, each environment is different and there is no single scenario. Thus, a debate, such as this one, is valuable to find the balance between the need to move forward versus the risks. Tim > > Neil > > >__________________________________________________________________________ >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 > >__________________________________________________________________________ >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 __________________________________________________________________________ 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