Open Stack

Agreed it helps with billing.  It also allows the customer to make a
choice based on the features offered in a flavor.  At the end of the day,
the API works the same way regardless of the flavor selected.  The flavor
selection merely gives the customer the experience they are looking for.

I see flavors working this way:
Nova - choosing a flavor that represents the type of compute power you
need.  Many combinations could exist.
Zaqar - choosing a flavor that represents the type of messaging you need
(performance, durability, ha, or any combinations of them)
Poppy - choosing a flavor that represents the type of cdn you need
(performance, regionality, cost, or any combination of them)

…and so on…


Within each ‘feature’ there could be multiple options.

Hence I struggle to see how ‘features’ could be exposed directly by the
api’s if that only limits it to one driver of each feature (i.e. There
could be multiple drivers that meet the performance feature for example).

The flavor concept allows operators to package together some of these
features, and offer it to customers - who can then select that flavor via
the API.

In terms of inter-operable clouds, since the API functionality works the
same regardless of flavor, I don’t think it breaks interoperability.

Since operators can define their flavor names themselves and what drives
those flavors, then there is work on the dev to refer to the new flavor at
the new operator’s cloud.  But inverting that argument - will every cloud
operator always offer the same flavors?  Will some operators prefer to
offer certain flavors only?  How do you define flavors (or their features)
in a generic way that allows for the gray area’s in between, and multiple
permutations of the same benefit?

I am curious to explore the idea of not using flavors and replacing the
concept with something more generic (with concrete examples with some of
the existing API’s).  It sounds great to me, I just can’t (at this time)
think of how it would work.


Thanks.
Amit.







On 11/17/14, 5:38 PM, "Ed Leafe" <ed at leafe.com> wrote:

>On Nov 17, 2014, at 3:46 PM, Amit Gandhi <amit.gandhi at rackspace.com>
>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.
>
>For Nova, flavors emerged more as a billing convenience than anything
>technical regarding creating a VM with certain characteristics.
>
>> 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.
>
>Again, this seems like the sort of packaging you would need to charge
>customers for different levels of service, and not something that you
>would need to make a working CDN API.
>
>
>-- Ed Leafe
>
>
>
>
>