Create Flavor dialog should not have a Flavor ID field

[Devin Carlen]

Currently the Create Flavor dialog in the SysPanel has an editable Flavor ID field. It should not be displayed.

=====UPDATE (gabriel)=====

As per conversation with Vish on IRC: The reason the flavor ID field is exposed is because it's really a misnomer. The "id" field there is not the internal auto-incremented ID for the flavor, but in fact a user-facing reference ID. It is editable so that an admin can "delete" (set delete=1 in the DB) a flavor and replace it with a new flavor of the same id, thereby allowing the admin to effectively "replace" a flavor without disassociating the flavor from existing instances.

As such, the best UX Horizon can offer is to cheat, and make the behavior described above an "edit" interface which does a delete-and-create-with-same-id behind the scenes. The create form can then simply auto-generate an ID and hide the field.

[Tres Henry (tres)]

Flavor ID is a required field which used to initialize to a blank value, however, to improve the UX we are now providing an ID on the client-side by taking the highest flavor ID and adding 1. Not sure why flavor ID isn't handled by nova, however, that's another conversation. Are you sure we want to remove the field given given that this is something we are calculating? The use case would be: a user creates a flavor with ID 100 via the CLI even though there are only 5 other flavors with IDs 1-5. If a user tries to create a new flavor via the UI the flavor will have an ID of 101 (instead of 6) and the user will have no way of changing that (if the field is hidden).

Thoughts?

[Devin Carlen (devcamcar)]

In that case, I'd consider this a bug in nova first and horizon second. I have marked this bug as affecting nova as well. I don't have any idea why Flavor IDs would be handled differently than everything else in nova?

[Tres Henry (tres)]

This doesn't seem like an RC blocker.

[Gabriel Hurley (gabriel-hurley)]

Definitely not a blocker. If we want to do anything with it for the RC, we can make the field either non-editable or hidden.

[Tres Henry (tres)]

For previous stated reasons I would prefer not to hide this field until the underlying assignment is fixed. Let's punt.

[Devin Carlen (devcamcar)]

ID should not be editable. Allowing them to edit this behavior and modify the primary key directly is ugly at best and a security vulnerability at worst.

What happens if you change it to the PK of an existing flavor?

It seems quite impractical to have to even consider these questions. I suggest we hide the field entirely from the new flavor screen.

Normally I wouldn't consider something like this a release blocker, but this behavior is quite inelegant and is too clumsy to call a final version.

[Devin Carlen (devcamcar)]

^^^
TL;DR: Hide the flavor ID field from new flavor creation in essex. When nova solves this issue, we'll fix it properly for folsom.

[Devin Carlen (devcamcar)]

Just found Gabriel's edited notes in the case. Given it's the case that Flavor ID does not represent the actual row id from nova, I'm happy to leave this implementation as is for essex.

[Gabriel Hurley (gabriel-hurley)]

This is related to blueprint https://blueprints.launchpad.net/horizon/+spec/edit-flavor-ui for Horizon and probably can be untargeted from Nova.

[Gabriel Hurley (gabriel-hurley)]

Moving to folsom-2 to match blueprint

[Thierry Carrez (ttx)]

My understanding is that nothing needs to be done on Nova's side anymore... Please set back to New or confirmed if you disagree.

[Gabriel Hurley (gabriel-hurley)]

Bumping to F3 to match the associated blueprint.

[Gabriel Hurley (gabriel-hurley)]

Fix for horizon: https://review.openstack.org/#/c/11254/