Open Stack

On 11/17/2014 04:46 PM, Amit Gandhi wrote:
> 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.

In that case, your API is leaking implementation details.

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

Nothing above is different from Nova's flavors, other than the lack of 
leaking driver implementation details.

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

If you can't decompose the flavor into a set of capabilities that are 
standardized across deployers of the Poppy API, then you have an API 
that cannot be interoperable across deployers.

Best,
-jay

> 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.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>