Re: [openstack-dev] [Horizon][Nova] Editing flavor causing instance flavor display error
I’m planning on putting up a patch for this today. My proposal is to add a setting that disables it by default, then add a big warning side on the setting documentation and release notes. Anyone who then explicitly enables it will see the warning. Beyond that, we can deprecate it this cycle, but won’t be able to drop it until the R release. Rob __ 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] [Horizon][Nova] Editing flavor causing instance flavor display error
On 08/03/2017 04:21 AM, Sean Dague wrote: On 08/03/2017 06:13 AM, Zhenyu Zheng wrote: I was thinking, the current "edit" in Horizon is delete-and-create, and it is there maybe just because flavor has many fields, user may want to have a new flavor but just modify one of the old flavor, so they don't want to manually copy all other fields. And it is the automatic delete action that causes all the problem. Maybe horizon can provide a copy-and-modify action and leave the deletion of the flavor to the admin. For what it is worth, it is already an admin level permission. I do think that "Copy and Modify" is a better paradigm. Or "New Flavor based on X" which will prefill based on an existing one. The Delete flavor button should come with a giant warning of "This will make a lot of information in your environment confusing, you should never do this". The same could also be said for flavor extra-specs (which can be modified in-place). Once they're configured and the flavor is made public it would be best to leave them untouched otherwise you could end up confusing people if the behaviour of the "same" flavor changes due to extra-specs changes. Chris __ 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] [Horizon][Nova] Editing flavor causing instance flavor display error
On 08/03/2017 06:13 AM, Zhenyu Zheng wrote: > I was thinking, the current "edit" in Horizon is delete-and-create, and > it is there maybe just because > flavor has many fields, user may want to have a new flavor but just > modify one of the old flavor, so > they don't want to manually copy all other fields. And it is the > automatic delete action that causes > all the problem. Maybe horizon can provide a copy-and-modify action and > leave the deletion of > the flavor to the admin. For what it is worth, it is already an admin level permission. I do think that "Copy and Modify" is a better paradigm. Or "New Flavor based on X" which will prefill based on an existing one. The Delete flavor button should come with a giant warning of "This will make a lot of information in your environment confusing, you should never do this". -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
Re: [openstack-dev] [Horizon][Nova] Editing flavor causing instance flavor display error
I was thinking, the current "edit" in Horizon is delete-and-create, and it is there maybe just because flavor has many fields, user may want to have a new flavor but just modify one of the old flavor, so they don't want to manually copy all other fields. And it is the automatic delete action that causes all the problem. Maybe horizon can provide a copy-and-modify action and leave the deletion of the flavor to the admin. On Thu, Aug 3, 2017 at 5:59 PM, Sean Dague wrote: > On 08/02/2017 10:12 PM, Zhenyu Zheng wrote: > > Hi All, > > > > Horizon provided the feature to allow user edit existing flavors, no > > matter it is currently used by any instances or not. While Nova doesn't > > provide this kind of ability, Horizon achieved this by deleting the old > > flavor first and create a new flavor with the requested properties. And > > the flavor ID will be changed to a new UUID. > > > > This causes problem when display instances with latest Nova, Horizon > > display flavor name by request flavor details using the flavor id > > returned by get_instance request, because Nova now moved flavor to > > api_db, and when a flavor got deleted, it will be directly removed from > > the DB, and when displaying, the field will be "Not Available". > > > > Should we stop support editing existing flavors? It is actually > > deleting-and-create. > > Yes, it should not be a feature in Horizon, because it's extremely > misleading what it does. It's actually really breaking their > environment. It's unfortunate that it was implemented there at all. :( > > > Maybe we should at least add WARNING notes about this when editing > > flavors, about how it is actually done and what kind of influence will > > be to the existing instances. > > > > Nova now(> microversion 2.47) can reply embedded flavor details > > including ram, vcpus, original_name etc. > > > > Since we provided this flavor editing feature and we displayed "name" as > > a identifier, after we done some flavor edit, even we fix the above > > mentioned problem and displayed the correct flavor name, the flavor > > details will be different than the actual instance type. > > There was an extremely long an heated discussion in the Nova room in > Atlanta about including that name in server document because of this > Horizon behavior. I came down on the side of showing it, because people > that use the flavor "rename" function are actually basically breaking > their environment (in many ways). Lots of people don't do that, so this > is useful to them so that they can create new instances like the ones > there. > > The only way to change the flavor of an instance is to resize it. > > -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 > __ 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] [Horizon][Nova] Editing flavor causing instance flavor display error
On 08/02/2017 10:12 PM, Zhenyu Zheng wrote: > Hi All, > > Horizon provided the feature to allow user edit existing flavors, no > matter it is currently used by any instances or not. While Nova doesn't > provide this kind of ability, Horizon achieved this by deleting the old > flavor first and create a new flavor with the requested properties. And > the flavor ID will be changed to a new UUID. > > This causes problem when display instances with latest Nova, Horizon > display flavor name by request flavor details using the flavor id > returned by get_instance request, because Nova now moved flavor to > api_db, and when a flavor got deleted, it will be directly removed from > the DB, and when displaying, the field will be "Not Available". > > Should we stop support editing existing flavors? It is actually > deleting-and-create. Yes, it should not be a feature in Horizon, because it's extremely misleading what it does. It's actually really breaking their environment. It's unfortunate that it was implemented there at all. :( > Maybe we should at least add WARNING notes about this when editing > flavors, about how it is actually done and what kind of influence will > be to the existing instances. > > Nova now(> microversion 2.47) can reply embedded flavor details > including ram, vcpus, original_name etc. > > Since we provided this flavor editing feature and we displayed "name" as > a identifier, after we done some flavor edit, even we fix the above > mentioned problem and displayed the correct flavor name, the flavor > details will be different than the actual instance type. There was an extremely long an heated discussion in the Nova room in Atlanta about including that name in server document because of this Horizon behavior. I came down on the side of showing it, because people that use the flavor "rename" function are actually basically breaking their environment (in many ways). Lots of people don't do that, so this is useful to them so that they can create new instances like the ones there. The only way to change the flavor of an instance is to resize it. -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
Re: [openstack-dev] [Horizon][Nova] Editing flavor causing instance flavor display error
On Thu, Aug 3, 2017 at 11:12 AM, Zhenyu Zheng wrote: > Hi All, > > Horizon provided the feature to allow user edit existing flavors, no > matter it is currently used by any instances or not. While Nova doesn't > provide this kind of ability, Horizon achieved this by deleting the old > flavor first and create a new flavor with the requested properties. And the > flavor ID will be changed to a new UUID. > > This causes problem when display instances with latest Nova, Horizon > display flavor name by request flavor details using the flavor id returned > by get_instance request, because Nova now moved flavor to api_db, and when > a flavor got deleted, it will be directly removed from the DB, and when > displaying, the field will be "Not Available". > > Should we stop support editing existing flavors? It is actually > deleting-and-create. > I do not know actual use case if this feature but i feel like same as you to stop supporting this. After microversion 2.47, it would not be "Not Available' but it will still show the flavor info where that flavor does not exit in system anymore. If someone refer the existing instance to use the same flavor info for their new instance the will be confused about no such flavor exist. Other solution might be to allow only non used flavor but that need to iterate all existing instance and check is anyone use that flavor or not which is more difficult after 2.47 where nova return flavor detail instead of flavor id. > Maybe we should at least add WARNING notes about this when editing > flavors, about how it is actually done and what kind of influence will be > to the existing instances. > > Nova now(> microversion 2.47) can reply embedded flavor details including > ram, vcpus, original_name etc. > > Since we provided this flavor editing feature and we displayed "name" as a > identifier, after we done some flavor edit, even we fix the above mentioned > problem and displayed the correct flavor name, the flavor details will be > different than the actual instance type. > This also can lead to same issue of having stale flavor info in instance. > > Thoughts? > > BR, > > Kevin Zheng > -gmann > > > __ > 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-dev] [Horizon][Nova] Editing flavor causing instance flavor display error
Hi All, Horizon provided the feature to allow user edit existing flavors, no matter it is currently used by any instances or not. While Nova doesn't provide this kind of ability, Horizon achieved this by deleting the old flavor first and create a new flavor with the requested properties. And the flavor ID will be changed to a new UUID. This causes problem when display instances with latest Nova, Horizon display flavor name by request flavor details using the flavor id returned by get_instance request, because Nova now moved flavor to api_db, and when a flavor got deleted, it will be directly removed from the DB, and when displaying, the field will be "Not Available". Should we stop support editing existing flavors? It is actually deleting-and-create. Maybe we should at least add WARNING notes about this when editing flavors, about how it is actually done and what kind of influence will be to the existing instances. Nova now(> microversion 2.47) can reply embedded flavor details including ram, vcpus, original_name etc. Since we provided this flavor editing feature and we displayed "name" as a identifier, after we done some flavor edit, even we fix the above mentioned problem and displayed the correct flavor name, the flavor details will be different than the actual instance type. Thoughts? BR, Kevin Zheng __ 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
