Instances cannot be booted using name of a non-public, but accessible, flavor

[Daniel Berrange]

Setup credentials to allow access to Nova as an administrator account

[root@localhost ] # . keystonerc_admin
[root@localhost ~(keystone_admin)]#

Now create a new flavor but mark it as non-public

[root@localhost ~(keystone_admin)] # nova flavor-create --is-public False astrochicken 21 2048 20 1
+----+--------------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+--------------+-----------+------+-----------+------+-------+-------------+-----------+
| 21 | astrochicken | 2048 | 20 | 0 | | 1 | 1.0 | False |
+----+--------------+-----------+------+-----------+------+-------+-------------+-----------+

Then try a boot an instance using this flavour, specified by name

[root@localhost ~(keystone_admin)] # nova boot --flavor astrochicken vmm
ERROR: No flavor with a name or ID of 'astrochicken' exists.

This is clearly bogus as we just created the flavor successfully. Booting the instance succeeds with specifying the flavor ID instead of its name. So whatever resolves flavor names is failing for the non-public flavor, even when the user has permission to see the non-public flavor.

It is also noted that the flavour does not appear in the listing by default

[root@localhost ~(keystone_admin)]# nova flavor-list
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True |
| 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True |
| 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True |
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True |
| 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+

[root@localhost ~(keystone_admin)]# nova flavor-list --all
+----+--------------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+--------------+-----------+------+-----------+------+-------+-------------+-----------+
| 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True |
| 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True |
| 21 | astrochicken | 2048 | 20 | 0 | | 1 | 1.0 | False |
| 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True |
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True |
| 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True |
+----+--------------+-----------+------+-----------+------+-------+-------------+-----------+

[Daniel Berrange (berrange)]

The problem turns out to be on the client side.

In novaclient/v1_1/flavors.py the FlavorManager.list method defaults to is_public=True, which means that it will only ever resolve flavours which are marked public, even if the user has permission to access non-public flavours.

If we change this to is_public=None, then the server side will do the right thing - privileged users will be shown all images they can access and unprivileged users will still be restricted to just public images.

[melanie witt (melwitt)]

https://review.openstack.org/#/c/98409/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/98409
Committed: https://git.openstack.org/cgit/openstack/python-novaclient/commit/?id=d17253b29a5b7b422538c6496239cf713be627a3
Submitter: Jenkins
Branch: master

commit d17253b29a5b7b422538c6496239cf713be627a3
Author: Daniel P. Berrange <email address hidden>
Date: Fri Jun 6 14:23:17 2014 +0100

    Look for all accessible flavors by default, not just public ones

    The Nova server will restrict unprivileged user accounts to just
    public images, while allowing administrator accounts access to
    all. The Nova client shouldn't force the flavor name lookup to
    be restricted to just public images, since that breaks the ability
    to the flavor name when booting an instance

    Fixes bug #1327212

    Change-Id: I949aec52660242249b8cba51d77bfdc1acaf31d2