nova server details always return hard coded flavor id '1'

[ajiang38740]

Saw issue #87 and #27 regarding flavor discussion.

I am not sure how this problem fits into those 2 problems. The issue I ran into
is nova boot with --flavor-id will create a CCI VS with some flavor. But when you show
the server details, it is always return flavor 1, which is hardcoded.

What I have done is to save the flavor id in the userData json structure that is
passed to the create_instance() and retrieve back when show the server details.

At least this way, it can show the used flavor properly.

I am not sure whether using userData is a desired approach from SL CCI point of view.

Please let me know whether I should submit such patch.

Alan

[ajiang38740]

With storing the flavor id in the userData of VS. I can show the flavor properly:

+-----------------------------+-------------------------------------------------------------+
| Property | Value |
+-----------------------------+-------------------------------------------------------------+
| OS-EXT-AZ:availability_zone | 138124 |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | - |
| OS-EXT-STS:vm_state | ACTIVE |
| accessIPv4 | |
| accessIPv6 | |
| created | 2014-04-30T23:37:49-06:00 |
| flavor | 2 vCPU, 2GB ram, 100GB, local (3) |
| hostId | 4579566 |
| id | 4579566 |
| image | 100G CentOS 6 64-bit (c27eb0ad-bddd-44c7-a37a-e3ddbbfed277) |
| image_name | |
| key_name | ajiang-rsa.pub |
| name | ajiang-sl-san-01 |
| private network | 10.84.178.181 |
| public network | 75.126.148.184 |
| security_groups | default |
| status | ACTIVE |
| tenant_id | 278190 |
| updated | 2014-04-30T23:39:49-06:00 |
| user_id | 187096 |
+-----------------------------+-------------------------------------------------------------+

[sudorandom]

@ajiang38740 This looks like an acceptable solution to me. Of course, this won't handle virtual servers created before this change or virtual servers not created by Jumpgate but that can be handled a bit later.

+1, this is a nice short term approach

[ajiang38740]

You got a good point. For the virtual servers created before this change or not by jumpgate, as long as it fits the hardcoded flavor list, I can update the VS instance's metadata to put in the flavor id if nova show is called(for the first time).

There is one problem with this above approach:
The cpu/memory/disk permutation is 10x10x2 right now with the way CCI instance can be ordered. And the flavor that has been hardcoded is only 15. Even though I have a way to retrieve and show
the flavor, but the current flavor list is incomplete. This is probably back to the "how should flavor be handled by jumpgate" discussion.

Here is another thought about how to handle flavor id for jumpgate.

For openstack, flavor id is a string: (nova.db.sqlalchemy.models.InstanceTypes)

flavorid = Column(String(255))

What we can do is to define the flavor id in this form

CCCCMMMMDDDD
which is 4 bytes for number of cores, 4 bytes of amount of memory
and 4 bytes of disk size with left padded by zeros. Since core and memory and disk are limited choices, this can always give a fixed pattern for any given flavor combination. This way, we don't have to keep a hardcoded list in the code with sequential ID for the flavorid. We can always generate
the flavor id on the fly. This way we can even cover the case that the CCI instance has been
resized. Since the choices for resizing cpu and memory is in the same cpu/memory choice list.

If you like this idea, i can put this together and submit for review.

[ajiang38740]

Actually, there is a private core vs non private and need to deal with local vs san disks. Here is the refined version of this flavorid

P-C-M-A-D , P private core or not. C is number of cores, M is GB of memory, A attachment('l' for local, 's' for san) and D is the GB of first disks.

For a flavor that has 4 private cores 64 GB memory and 100GB san attached disk, the flavor will be
like this:
p-4-64-s-100

Another example:

n-2-16-l-25

This will be a non-private 2 core 16GB memory with 25G local disk flavor.

[ajiang38740]

The '-' dash is just easy for python split().

[ajiang38740]

So when nova flavor-list is called, the flavor code will generate the full list of permutation based on
the above formula and this flavor string can be used for CCI instance creation. And with this dynamic
flavor id generation, there is no need to save the flavor anymore in the metadata.

Of course this approach is based on the assumption CCI instance cpu/memory/disk is always a limited list of predefined choices.

[sudorandom]

You should re-read the discussion that was had between Boden and I in issue #27. We were led down this path and I believe the preferred conclusion was to have a base-64 encoded parsable string which represents each option (CPU, memory, disk size/type, etc). The only hitch with that plan is that some OpenStack projects (like trove) treat flavor ids as integers. I believe that to be a bug in those projects, since the type returned for flavor ids are strings.

[ajiang38740]

Thanks for point that out. I think my idea is the same as what you have planned in #27. And Trove
is broken from flavor perspective:
https://github.com/openstack/trove/blob/d745a60c351473ac2bd565e25041d65a350f61e3/trove/flavor/views.py

def data(self):

    flavor = {
        'id': int(self.flavor.id),
        'links': self._build_links(),
        'name': self.flavor.name,
        'ram': self.flavor.ram,
    }

That self.flavor is a dict got from nova client by looking up the nova flavor id.

Any non-predefined openstack flavor may break this Trove flavor function. Unfortunately that
is what we have to resolve here for Trove.

I think there is a way out of this by still use the original idea. I will expand on my idea to bitmap based flavor encoding since we have limited options for cpus memory and disks.

0xCCMMDDDD This is a 32-bits flavor id which still fits into the 32bit integer. So it won't break
the Trove flavor.id code. And it is still generated dynamically.
C -- core (with most significant bit reserved for the flag to indicate private='1' or standard='0')
M -- memory in GB
D -- disk size in GB (with most significant bit reserved for the flag to indicate whether it is local='0' or san='1')
Take the above example:

For a flavor that has 4 private cores 64 GB memory and 100GB san attached disk

The binary format will be 0x84 40 8064 and the flavor id in decimal will be 2218819684

[ajiang38740]

In order to do nova flavor-list, just need to predefine the list of possible choices of cpus , memory and disks and generate permutation on the fly.

[sudorandom]

@ajiang38740 It's become clear to me that (API-exposed) flavor ids are strings and should be able to be treated as such and that other projects who use nova that can't work with them as strings treat them as bugs. I'd prefer that the flavors not be serialized into an integer due to the limited amount of space for future augmentations of flavors that nova can/is doing.