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

ajiang38740 commented 10 years ago

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 commented 10 years ago

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

sudorandom commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

ajiang38740 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

@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.

softlayer / jumpgate

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