Open Stack

I can see where this makes a lot of sense in API¹s such as Nova¹s where
flavors represent some combination of memory, disk, and cpu performance.

In the case of CDN, the flavor represents a list of CDN providers.

So... you could have a flavor representing a region of the world
(America¹s) consisting of one or more CDN providers with a strong presence
in those regions.
Or a flavor could represent performance or features offered (number of
edge nodes, speed, etc).  And it is up to the operator to define those
flavors and assign one or more appropriate CDN providers to those flavors.

Im not sure decomposing the flavor in this context makes as much sense.


Amit.


On 11/17/14, 3:18 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:

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