Open Stack

On 11/17/2014 02:47 PM, Shaunak Kashyap wrote:
> Hi,
>
> I’ve been working with the Poppy project[1] while they are designing their APIs. Poppy has a concept of a flavor. A single flavor resource has the URI, {base}/flavors/{flavor_id}.

Please, can we as a community kill the term "flavor" in a fire?

It has a different spelling in non-American English, it doesn't convey 
appropriate semantic details about the resource itself (i.e. non-English 
speakers think "what is tasty about this particular resource?"), and 
doesn't seem to have any benefit over using a term like "resource type", 
or "CDN service type" or "CDN template" or "CDN spec" that actually 
*does* convey some meaning.

If we're going to use a term that has no meaning with relation to the 
thing being described, I'd rather get creative and call it a 
"thingamabob" or a "whatsit" or a "dingoateyourbaby".

> Poppy APIs refer to a flavor in their request and/or response representations. Some representations do this by using the flavor ID (e.g. 12345) while others use the flavor resource URI (e.g. {base}/flavors/12345).

And some APIs use both -- see, e.g. image_ref and image_id used all over 
the place in nova/image/glance.py, much to my chagrin.

> In this context, I created a bug[2] to settle on one way of referring to a flavor across all API representations in Poppy. So the question to the API working group is this:
>
> How should flavors be referred to in Poppy API representations? Some options to consider:
>
> a) Using a “flavor_id” (or similar) property whose value is the flavor ID (e.g. 12345),
> b) Using a “flavor_ref” (or similar) property whose value is the flavor resource URI (e.g. {base}/flavors/12345),
> c) Using a “links” property whose value is an array of links, one of which has an object like { “rel”: “flavor”, “href”: “{base}/flavors/12345” },

No, this isn't really what links (or _links in JSON+HAL) is intended 
for, IMO.

> d) Similar to c) but using HAL[3] instead,
> e) A combination of a) and c),
> f) A combination of a) and d),
> g) Something else?

I personally do not think that a "flavor" should be stored in the base 
resource. The "flavor" should instead be decomposed into its composite 
pieces (the specification for the CDN creation) and those pieces stored 
in the database.

That way, you don't inherit the terrible problem that Nova has where 
you're never really able to delete a flavor because some instance 
somewhere may still be referring to it. If, in Nova, we decomposed the 
flavor into all of its requisite pieces -- requested resource amounts, 
requested "extra specs" capabilities, requested NUMA topology, etc -- we 
wouldn't have this problem at all.

So, therefore my advice would be to not do any of the above and don't 
have anything other than a "CDN type" or "CDN template" object that is 
just deconstructed into the requested capabilities and resources of the 
to-be-created CDN object and send along those things instead of 
referring to some "flavor" thing.

Best,
-jay