Ugh... this is kind of crazy. Though many of us have been working with OpenStack for years I guess no one on the project has been exposed to UUIDs for Flavors yet.
As others have stated, changing the ID from an int to a string will break the API and will cause complaints from the users of existing deployments. This would be a kludge, but I think for now we need to return "uuid" in addition to the ID and make that one a string. We should also return None for the ID if it can't be coerced into an integer. This way people can use UUIDs today before we start on V2 of the API.
Ugh... this is kind of crazy. Though many of us have been working with OpenStack for years I guess no one on the project has been exposed to UUIDs for Flavors yet.
As others have stated, changing the ID from an int to a string will break the API and will cause complaints from the users of existing deployments. This would be a kludge, but I think for now we need to return "uuid" in addition to the ID and make that one a string. We should also return None for the ID if it can't be coerced into an integer. This way people can use UUIDs today before we start on V2 of the API.