Open Stack

The discussion about whether flavors should exist as-is or be decomposed is useful and should continue. It is, however, somewhat orthogonal to the discussion I was hoping to have on this thread :)

So coming back to the original question (now generalized away from flavors): how should resource representations refer to other resources?

a) Using an "{resource}_id" property whose value is a naked ID (e.g. 12345, "1ef1cf90-6f53-11e4-9803-0800200c9a66”), or
b) Using a "{resource}_ref" property whose value is the URI for the referenced resource, (e.g. {base}/{resource}/12345), or
c) Using a "links" property whose value is an array of links, one of which has an object like { "rel": "{resource}", "href": "{base}/{resource}/12345" }, or
d) Similar to c) but using HAL instead, or
e) A combination of a) and c), or
f) A combination of a) and d), or
g) Something else?

So far I've heard two opinions on the above:

- Using a) primarily, but possibly e) for convenience
- Not using c), d), e) or f) since "links" or "_links" in JSON+HAL aren't intended for this purpose

Are there any other opinions on this issue of referencing? If not, I'm thinking of going with a).

Thank you,

Shaunak

On Nov 17, 2014, at 3:33 PM, Amit Gandhi <amit.gandhi at rackspace.com> wrote:

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