delete private flavor will cause access problem with existed instance

Bug #1366168 reported by Wei T on 2014-09-05
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Feodor Tersin

Bug Description

How to reproduce

1. create a private flavor "private-flavor"
2. add a tenant access to "private-flavor"
3. use Member role user to create instance "XXX" with "private-flavor"
4. nova flavor-delete "private-flavor" with admin role
5. nova show XXX with Member role suer, will be end with error message say do not have access to the flavor


the delete a flavor will also delete the access in instance_type_projects table


One quick solution is mark flavor as public while do soft delete

Wei T (nuaafe) wrote :

Also related to

Please comment the better solution if any

Changed in nova:
assignee: nobody → Wei T (nuaafe)
Wei T (nuaafe) wrote :

Another solution is while delete a flavor, do not soft delete the record in the instance_type_projects table. is that acceptable ?

Fix proposed to branch: master

Changed in nova:
status: New → In Progress
Sean Dague (sdague) wrote :

I think we need to do what we did with other InstanceType info and copy it into the Instance metadata so it lives with the instance. This also means it remains accurate if flavors get updated for some reason.

Changed in nova:
importance: Undecided → Medium
Wei T (nuaafe) wrote :

Hi Sean, I think I got some mis-understanding of your comments last time, sorry about that.
I'm working on copying instance type info into instance metadata in order to solve the issue. Thanks.

Wei T.

Change abandoned by Sean Dague (<email address hidden>) on branch: master
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

Removing "In Progress" status and assignee as change is abandoned.

Changed in nova:
status: In Progress → Confirmed
assignee: Wei T (nuaafe) → nobody
Feodor Tersin (ftersin) wrote :

The same result is occured with a deleted public flavor or when a private flavor become inaccessible for the instance project.
For all cases Nova reports the flavor id and doesn't crash. The failure occures in novaclient side.
Nova reports the id always, even when the flavor exists and is accessible.

Similar cases could occure with an instance image. But novaclient properly handles these, though Nova returns only image id as well.

So i propose to fix this in novaclient and do nothing for Nova.

Fix proposed to branch: master

Changed in python-novaclient:
assignee: nobody → Feodor Tersin (ftersin)
status: New → In Progress
melanie witt (melwitt) on 2015-04-06
Changed in python-novaclient:
importance: Undecided → Medium

Submitter: Jenkins
Branch: master

commit a63aa515f579c2ccce6c75eca4a3b2e0be6f331a
Author: Feodor Tersin <email address hidden>
Date: Mon Apr 6 15:31:16 2015 +0300

    Fix displaying of an unavailable flavor of a showing instance

    Since then an instance was booted with a flavor, the flavor could be
    deleted or become unavailable (private flavors). As a result novaclient
    fails to show the instance with member role user.

    This patch set adds handling of unavailable flavors to showing of
    instances as it is done for unavailable images.

    Closes-Bug: #1366168

    Change-Id: I810dcac814b7523313112bb9151754659b85df51

Changed in python-novaclient:
status: In Progress → Fix Committed
Matt Riedemann (mriedem) on 2015-05-12
Changed in python-novaclient:
milestone: none → 2.25.0
Matt Riedemann (mriedem) on 2015-05-12
Changed in python-novaclient:
status: Fix Committed → Fix Released

Another use case:

1. In Horizon, create a non-public flavor as an admin user
2. Launch an instance against that flavor
3. Edit the flavor

Now, when attempting to view the instance as a non-admin user, Nova will throw errors.

Tracking this down with a debugger:

    > /opt/stack/nova/nova/db/sqlalchemy/
    -> return query
    (Pdb) stmt = query.statement
    (Pdb) x = stmt.compile(compile_kwargs={'literal_binds': True})
    (Pdb) print str(x)
    SELECT instance_types.created_at, instance_types.updated_at, instance_types.deleted_at, instance_types.deleted,,, instance_types.memory_mb, instance_types.vcpus, instance_types.root_gb, instance_types.ephemeral_gb, instance_types.flavorid, instance_types.swap, instance_types.rxtx_factor, instance_types.vcpu_weight, instance_types.disabled, instance_types.is_public, instance_type_extra_specs_1.created_at, instance_type_extra_specs_1.updated_at, instance_type_extra_specs_1.deleted_at, instance_type_extra_specs_1.deleted,, instance_type_extra_specs_1.key, instance_type_extra_specs_1.value, instance_type_extra_specs_1.instance_type_id
    FROM instance_types LEFT OUTER JOIN instance_type_extra_specs AS instance_type_extra_specs_1 ON instance_type_extra_specs_1.instance_type_id = AND instance_type_extra_specs_1.deleted = 0
    WHERE instance_types.is_public = 1 OR (EXISTS (SELECT 1
    FROM instance_type_projects
    WHERE instance_type_projects.instance_type_id = AND instance_type_projects.deleted = 0 AND instance_type_projects.project_id = '19cdefa3773642db8624a52d9b5d982e'))

...wait, what are those "deleted = 0" constraints? The query explicitly sets read_deleted=True !

Fix proposed to branch: master

Changed in nova:
assignee: nobody → Nicolas Simonds (nicolas.simonds)
status: Confirmed → In Progress
Matt Riedemann (mriedem) wrote :

Why does the non-admin user need to be able to show the instance created from the admin tenant? And what about the flavor was edited in step 3 in comment 12? Was the flavor made public?


3a. Adjust any flavor parameter you like, aside from the flavor access, e.g., add a VCPU, change the root_gb, pretty much anything.

This behavior is not limited to the admin tenant, this is "admin" vs. "member" behavior.

tags: added: liberty-rc-potential
Matt Riedemann (mriedem) on 2015-09-23
tags: removed: liberty-rc-potential
David Pintor (ophintor) wrote :

Also, if you do the following:

- Create flavor F with admin
- Add tenant T to flavor F
- Create instance against flavor F with member user
- Remove tenant T from flavor F with admin
- Re-add tenant T to flavor F with admin

Instance still shows flavor "not available".

If the user looking at the instance is admin then he can see the flavor.

And finally, if the flavor is deleted by the admin the behaviour is the same:

- member user can't see flavor F linked to instance (flavor not available)
- admin user can see flavor F (even though it doesnt exist any more) attached to instance.

Steps to Reproduce:

    1. Stand up devstack
    2. With the web UI, login as "admin" user, switch to the "demo" project
    3. Go to Admin » Flavors, and Create a test flavor. Give it any properties you like, and set its Flavor Access to the "demo" project only.
    4. Go to Project » Instances, and spawn an instance against the test flavor
    5. Go back to Admin » Flavors, and edit the flavor, e.g., adjust the ephemeral disk size, but DO NOT alter the Flavor Access
    6. Get instance details on the test instance, note the contents of the "Specs" section
    7. Sign out of the web UI and sign in as the "demo" user, switching to the "demo" project
    8. Get instance details on the test instance, note the contents of the "Specs" section

Expected Behavior:

The "Specs" section should be populated with the flavor info from when the instance was spawned on both Steps 6 and 8.

Actual Behavior:

On Step 8, the "Specs" section claims that the flavor is not available. It absolutely should be, since the "demo" user is a member of a project that has access to the flavor.

Changed in nova:
assignee: Nicolas Simonds (nicolas.simonds) → Chris St. Pierre (stpierre)
Changed in nova:
assignee: Chris St. Pierre (stpierre) → Nicolas Simonds (nicolas.simonds)

Change abandoned by Matt Riedemann (<email address hidden>) on branch: stable/mitaka
Reason: This shouldn't be in mitaka if it's not in master yet.

Change abandoned by Michael Still (<email address hidden>) on branch: master
Reason: This code hasn't been updated in a long time, and is in merge conflict. I am going to abandon this review, but feel free to restore it if you're still working on this.

Danil Akhmetov (dinobot) on 2016-08-01
Changed in nova:
assignee: Nicolas Simonds (nicolas.simonds) → Danil Akhmetov (dinobot)
Danil Akhmetov (dinobot) on 2016-08-01
Changed in nova:
assignee: Danil Akhmetov (dinobot) → nobody

no assignee -> not in progress

Changed in nova:
status: In Progress → Confirmed


Is anybody still working on the issue?? As I am willing to work on this.

Thanks and Regards,

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers