The flavor id is not limited when creating a flavor

[HYSong]

when creating a flavor by 'openstack flavor create --id <id> --vcpus <vcpus> --ram <ram> --disk <disk> <flavor-name>',
the parameter id is not limited. It can lead to ambiguities when id is set to an existed flavor name.

[Choi-Sung-Hoon (knu-cse)]

So all we need to do is to filter the flavor name?

What do you think we need something else?

I'd like to assign this bug to me.

[Choi-Sung-Hoon (knu-cse)]

I think it is already limited.

Is this what you meant?

Please check the attachment.

[HYSong (songhongyuan)]

@Choi-Sung-Hoon (knu-cse)
The flavor name is already limited in your attachment, so you can not create flavor named m1.tiny.
however, if you create flavor by setting the parameter id to an existed flavor name,it can be passed, so the param id is not limited, it will cause to ambiguities.

[Choi-Sung-Hoon (knu-cse)]

@HYSong (songhongyuan)
I don't understand what you mean.

openstack flavor create --id 6 --vcpus 1 --ram 512 --disk 1 m1.tiny

This creates a flavor by setting id to 6 to an existing flavor name "m1.tiny" but it causes error because of the same name.
Could you give me an example with that environment in the attachment please?

[Ghanshyam Mann (ghanshyammann)]

id and name are unique by themself but yes id and name are not limited with each other.

You can create flavor with id same as existing flavor name or vice versa. like below example where id can be other flavor name and name can be other flavor id

+----------------------------+-------+
openstack@openstack-VirtualBox:~/devstack$ nova flavor-list
+---------+-----------+------------+------+-----------+------+-------+-------------+-----------+-------------+
| ID | Name | Memory_MiB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | Description |
+---------+-----------+------------+------+-----------+------+-------+-------------+-----------+-------------+
| 1 | m1.tiny | 512 | 1 | 0 | 0 | 1 | 1.0 | True | - |
| 2 | m1.small | 2048 | 20 | 0 | 0 | 1 | 1.0 | True | - |
| 3 | m1.medium | 4096 | 40 | 0 | 0 | 2 | 1.0 | True | - |
| 4 | m1.large | 8192 | 80 | 0 | 0 | 4 | 1.0 | True | - |
| 42 | m1.nano | 64 | 1 | 0 | 0 | 1 | 1.0 | True | - |
| 5 | m1.xlarge | 16384 | 160 | 0 | 0 | 8 | 1.0 | True | - |
| 6 | new | 512 | 1 | 0 | 0 | 1 | 1.0 | True | - |
| 84 | m1.micro | 128 | 1 | 0 | 0 | 1 | 1.0 | True | - |
| c1 | cirros256 | 256 | 1 | 0 | 0 | 1 | 1.0 | True | - |
| d1 | ds512M | 512 | 5 | 0 | 0 | 1 | 1.0 | True | - |
| d2 | ds1G | 1024 | 10 | 0 | 0 | 1 | 1.0 | True | - |
| d3 | ds2G | 2048 | 10 | 0 | 0 | 2 | 1.0 | True | - |
| d4 | ds4G | 4096 | 20 | 0 | 0 | 4 | 1.0 | True | - |
| m1.nano | new12 | 512 | 1 | 0 | 0 | 1 | 1.0 | True | - |
| new | new1 | 512 | 1 | 0 | 0 | 1 | 1.0 | True | - |
| new1 | new123 | 512 | 1 | 0 | 0 | 1 | 1.0 | True | - |
| new12 | 6 | 512 | 1 | 0 | 0 | 1 | 1.0 | True | - |
+---------+-----------+------------+------+-----------+------+-------+-------------+-----------+-------------+
openstack@openstack-VirtualBox:~/devstack$

[Ghanshyam Mann (ghanshyammann)]

what we can do is to restrict d to uuid or name to string only or just make id, name unique to each other. But these changes will require the API version bump. I am not sure if that is worth for this change.

Let's get more feedback if fixing this is ok or just document it properly in API ref about keeping them unique.

[Ghanshyam Mann (ghanshyammann)]

Added in APi cleanup etherpad - https://etherpad.openstack.org/p/nova-api-cleanup

[Balazs Gibizer (balazs-gibizer)]

Agree with Gmann. While it allows creating confusing situations when flavor1.id == flavor2.name this is not a bug. I think we don't want to add any cross check between fields. We always allowed that names can be anything. E.g. You can name your server after the uuid of another server.

[Stephen Finucane (stephenfinucane)]

Also agree. If we're going to do anything, it should be done on the client side. It should be possible to add a flag stating what field we wish to filter on (name or ID), if needed. Since there's nothing to do here from the server side, I'm going to close this as WONTFIX.