On 11/17/2014 02:47 PM, Shaunak Kashyap wrote:

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, 

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 

a) Using a “flavor_id” (or similar) property whose value is the flavor ID (e.g. 
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.


OpenStack-dev mailing list

Reply via email to