Edit flavor unstable

[Malini Bhandaru]

Edit flavor is implemented as deleting the original flavor and creating a new flavor with the respective fields.
The first time one "edits" a flavor this works, the fields get set and the database id assigned is +1 the largest flavor-id in the system. The second time one tries to edit the same flavor, oddly this does not quite work the same way.
Consequently, the display on the flavor list page seems all correct, but when one clicks on a flavor to edit it, the field values do not quite match those displayed in the flavor list page.
It feels like the largest_id computation is unstable.

if flavors:
            largest_id = max(flavors, key=lambda f: f.id).id
            flavor_id = int(largest_id) + 1

All this stems from the way flavor-id is handled on create and edit, related to #952657

[Malini Bhandaru (malini-k-bhandaru)]

To reproduce .. try editting "m1.tiny" root-disk to "10", view the flavor list, its flavor-id becomes 6, root-disk value becomes 10, all fine. Now edit it again, change name to m1.tiny.1 and then view flavor list and this is when you see inconsistencies.

[Malini Bhandaru (malini-k-bhandaru)]

The only way this can happen is some flavor data is being cached .. but the outer flavor list calls api.nova.flavor_list and the inner call to api.flavor_list somehow retrieves some cached copy of flavor list, and thus its determination of the largest flavor_id is stale.

[Tom Fifield (fifieldt)]

Following comment #1, I can confirm that in the latest devstack:
* after the first edit, the flavor ID increases to 6
* after the second edit, the flavor ID stays at 6 and does not increase

[Vinay Bannai (vbannai)]

Gabriel,
Would this issue be tied to the message I posted earlier today for this bug?
https://bugs.launchpad.net/bugs/1045382

The problem seems to be in this line of code :
   largest_id = max(flavors, key=lambda f: f.id).id

This should be changed to
   largest_id = max(flavors, key=lambda f: int(f.id)).id

I tried the fix on my build (last updated it a month ago) and it works. I have not tested the edit operations, but the symptoms appear to be similar.

[Vinay Bannai (vbannai)]

I dug around a bit and know why this is happening.
In the database, when a flavor gets deleted, the row is marked as deleted by a column setting "deleted=1".
When editing a flavor type, if there happens to exist a flavor with the same id (eventhough it is marked as deleted), that is returned as part of the get_initial_data() call. When I deleted the rows marked with column setting of "deleted=1", I did not see the problem.

This brings up a larger issue, why is the api.nova.flavor_get() returning a flavor which has been marked as deleted?

[Tihomir Trifonov (ttrifonov)]

A *deleted* flavor means a flavor which cannot be used for launching new instances. But instances launched with a deleted flavor need the flavor as a reference. That's the reason the flavor records don't get deleted from database, but just 'deactivated'. The problem here is that Nova should assign next available ID to a flavor, and not the Dashboard ... Also there is a problem with editing a flavor - all currently running instances will be displayed in the 'Instances' page with the updated flavor details, while in fact they have different parameters... It is a questionable if edit of flavor should be allowed at all, if there are instances launched with that flavor, or maybe all flavor details should be appended to instance and read from there, instead from flavor, which might be modified since...

[Vinay Bannai (vbannai)]

I am not aware of a reason as why an instance would need the details of the flavor once it is launched. But if there are reasons, I agree with your suggestion that is is best to attach the details of the flavor to the instance or get rid of the "edit" option.
As far maintaining a deleted record, I agree there might be reasons to keep it around a little longer, but I have seen discussions where the value of maintaining deleted record is being hotly debated.
However, the caller has no indication of knowing the status of the flavor (whether it is deleted or not).
I have a work-around that fixes this bug that I want to discuss with you and Gabriel at the design summit.

I agree that in the end we need Nova to do the right thing for assigning the flavor id and returning non-deleted flavors. My proposal is to get around in the interim.

[Gabriel Hurley (gabriel-hurley)]

The flavor data is retained after marking a flavor as deleted because deleting a flavor does not delete the instances launched with that flavor and for a whole range of reasons it's important to know what flavor/properties an instance was launched with.

Storing the flavor data with the instance isn't really going to happen in Nova.

We retrieve the flavor data for the instance because the Nova API only returns the ID of the flavor, not any of its associated data, and it's nice to know these things as a user when you look at your instances list or details.

The first step is to get a patch into Nova that makes the flavor create API not require the we give it an ID; Nova needs to generate a unique internal ID for the new flavor on its own.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/14581

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/14787

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/14787
Committed: http://github.com/openstack/horizon/commit/ef4e9314eb880238642e3122ae699f553b98db0e
Submitter: Jenkins
Branch: master

commit ef4e9314eb880238642e3122ae699f553b98db0e
Author: Gabriel Hurley <email address hidden>
Date: Wed Oct 24 14:03:17 2012 -0700

    Use UUIDs for flavor create/edit.

    Now that Nova accepts strings as flavor IDs we can just use UUIDs
    on our end and get rid of the horrors of trying to guess the next
    integer ID. This fixes all the instability in flavor editing.

    Fixes bug 1057799.

    Change-Id: I55eb1d7408655fd27e81cc1196f15ceb3659a7b4

[Thiago Martins (martinx)]

Please, backport it to Folsom on Ubuntu Cloud Archives!
I am unable to edit / add new flavors.

Tks,
Thiago

[Malini Bhandaru (malini-k-bhandaru)]

Needs uuid for flavor-id, has that been backported to Folsom?
Also, should we backport this fix, we need to modify not just the two files mentioned here, but
All the changes that we made for another flavor related bug, and associated unit tests.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Thiago Martins
Sent: Tuesday, January 29, 2013 4:49 PM
To: Bhandaru, Malini K
Subject: [Bug 1057799] Re: Edit flavor unstable

Please, backport it to Folsom on Ubuntu Cloud Archives!
I am unable to edit / add new flavors.

Tks,
Thiago

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1057799

Title:
  Edit flavor unstable

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Edit flavor is implemented as deleting the original flavor and creating a new flavor with the respective fields.
  The first time one "edits" a flavor this works, the fields get set and the database id assigned is +1 the largest flavor-id in the system. The second time one tries to edit the same flavor, oddly this does not quite work the same way.
  Consequently, the display on the flavor list page seems all correct, but when one clicks on a flavor to edit it, the field values do not quite match those displayed in the flavor list page.
  It feels like the largest_id computation is unstable.

  if flavors:
              largest_id = max(flavors, key=lambda f: f.id).id
              flavor_id = int(largest_id) + 1

  All this stems from the way flavor-id is handled on create and edit,
  related to #952657

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1057799/+subscriptions