Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova
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
Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova
+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 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. 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
Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova
> 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
Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova
On 4/6/2016 8:06 AM, Qiming Teng wrote: Thanks for the explanation, Sean. I wasn't subscribing to the operators mailinglist so wasn't aware of the notice. With that, I'm still surprised that there was no response to that email. Anyway, if people believe the benefits overweighs the impacts caused, just do it. The only thing I can think of is about tagging a email with some eye-catching tags, e.g. [!!!] [Disruptive!] [Important!] ... It is so easy to have such big change go unnoticed. Regards, Qiming On Wed, Apr 06, 2016 at 06:47:12AM -0400, Sean Dague wrote: On 04/06/2016 04:19 AM, Sylvain Bauza wrote: Le 06/04/2016 06:44, Qiming Teng a écrit : Not an expert of Nova but I am really shocked by such a change. Because I'm not a Nova expert, I don't have a say on the *huge* efforts in maintaining some builtin/default flavors. As a user I don't care where the data have been stored, but I do care that they are gone. They are gone because they **WILL** be supported by devstack. They are gone with the workflow +1'ed **BEFORE** the devstack patch gets merged (many thanks to the depends-on tag). They are gone in hope that all deployment tools will know this when they fail, or fortunately they read this email, or they were reviewing nova patches. It would be a little nicer to initiate a discussion on the mailinglist before such a change is introduced. It was communicated accordingly to operators with no strong arguments : http://lists.openstack.org/pipermail/openstack-operators/2016-March/010045.html Not only with no strong arguments, but with a general - "yes please, that simplifies our life". You can also see that https://review.openstack.org/#/c/300127/ is having three items : - a DocImpact tag creating a Launchpad bug for documentation about that - a reno file meaning that our release notes will provide also some comments about that - a Depends-On tag (like you said) on a devstack change meaning that people using devstack won't see a modified behavior. Not sure what you need more. The default flavors were originally hardcoded in Nova (in the initial commit) - https://github.com/openstack/nova/commit/bf6e6e718cdc7488e2da87b21e258ccc065fe499#diff-5ca8c06795ef481818ea1710fce91800R64 and moved into the db 5 years ago to be a copy of the EC2 flavors at the time - https://github.com/openstack/nova/commit/563a77fd4aa80da9bddac5cf7f8f27ed2dedb39d. Those flavors were meant to be examples, not the final story. All the public clouds delete these and do their own thing, as do I expect many of the products. Any assumption that software or users have that these will exist is a bad assumption. It is a big change, which is why it's being communicated on Mailing Lists in addition to in the release notes so that people have time to make any of their tooling not assume these flavors by name will be there, or to inject them yourself if you are sure you need them (as was done in the devstack case). -Sean -- Sean Dague http://dague.net __ 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 There were several replies in the operators list thread and as Sean said they were generally favorable about this because they delete the default flavors anyway. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova
Thanks for the explanation, Sean. I wasn't subscribing to the operators mailinglist so wasn't aware of the notice. With that, I'm still surprised that there was no response to that email. Anyway, if people believe the benefits overweighs the impacts caused, just do it. The only thing I can think of is about tagging a email with some eye-catching tags, e.g. [!!!] [Disruptive!] [Important!] ... It is so easy to have such big change go unnoticed. Regards, Qiming On Wed, Apr 06, 2016 at 06:47:12AM -0400, Sean Dague wrote: > On 04/06/2016 04:19 AM, Sylvain Bauza wrote: > > > > > > Le 06/04/2016 06:44, Qiming Teng a écrit : > >> Not an expert of Nova but I am really shocked by such a change. Because > >> I'm not a Nova expert, I don't have a say on the *huge* efforts in > >> maintaining some builtin/default flavors. As a user I don't care where > >> the data have been stored, but I do care that they are gone. They are > >> gone because they **WILL** be supported by devstack. They are gone with > >> the workflow +1'ed **BEFORE** the devstack patch gets merged (many > >> thanks to the depends-on tag). They are gone in hope that all deployment > >> tools will know this when they fail, or fortunately they read this email, > >> or they were reviewing nova patches. > >> > >> It would be a little nicer to initiate a discussion on the mailinglist > >> before such a change is introduced. > > > > > > It was communicated accordingly to operators with no strong arguments : > > http://lists.openstack.org/pipermail/openstack-operators/2016-March/010045.html > > Not only with no strong arguments, but with a general - "yes please, > that simplifies our life". > > > You can also see that https://review.openstack.org/#/c/300127/ is having > > three items : > > - a DocImpact tag creating a Launchpad bug for documentation about that > > - a reno file meaning that our release notes will provide also some > > comments about that > > - a Depends-On tag (like you said) on a devstack change meaning that > > people using devstack won't see a modified behavior. > > > > Not sure what you need more. > > The default flavors were originally hardcoded in Nova (in the initial > commit) - > https://github.com/openstack/nova/commit/bf6e6e718cdc7488e2da87b21e258ccc065fe499#diff-5ca8c06795ef481818ea1710fce91800R64 > and moved into the db 5 years ago to be a copy of the EC2 flavors at > the time - > https://github.com/openstack/nova/commit/563a77fd4aa80da9bddac5cf7f8f27ed2dedb39d. > Those flavors were meant to be examples, not the final story. > > All the public clouds delete these and do their own thing, as do I > expect many of the products. Any assumption that software or users have > that these will exist is a bad assumption. > > It is a big change, which is why it's being communicated on Mailing > Lists in addition to in the release notes so that people have time to > make any of their tooling not assume these flavors by name will be > there, or to inject them yourself if you are sure you need them (as was > done in the devstack case). > > -Sean > > -- > Sean Dague > http://dague.net __ 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
