Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

2014-11-18 Thread Shaunak Kashyap
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.gan...@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 e...@leafe.com wrote:
 
 On Nov 17, 2014, at 3:46 PM, Amit Gandhi amit.gan...@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

2014-11-17 Thread Kevin L. Mitchell
On Mon, 2014-11-17 at 19:47 +, Shaunak Kashyap wrote:
 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).
 
 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 consider:
 
 a) Using a “flavor_id” (or similar) property whose value is the flavor
 ID (e.g. 12345),
 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” },
 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 can't think of any API in OpenStack that uses a URI for referencing
anything.  We may have *links* in the payloads, but those are provided
for convenience; anytime nova refers to a flavor, it returns the flavor
UUID.

I would, by the way, suggest using UUIDs rather than plain IDs, for
consistency with the rest of the APIs…
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.com
Rackspace


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

2014-11-17 Thread Jay Pipes

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

Hi,

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, 
{base}/flavors/{flavor_id}.


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 
consider:

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


Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

2014-11-17 Thread Ed Leafe
On Nov 17, 2014, at 2:18 PM, Jay Pipes jaypi...@gmail.com wrote:
 
 Please, can we as a community kill the term flavor in a fire?

+1

One of the first (but certainly not the last) battle I lost in the early days 
of Nova.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

2014-11-17 Thread Amit Gandhi
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 jaypi...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

2014-11-17 Thread Jay Pipes

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 jaypi...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

2014-11-17 Thread Ed Leafe
On Nov 17, 2014, at 3:46 PM, Amit Gandhi amit.gan...@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







signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

2014-11-17 Thread Amit Gandhi
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 e...@leafe.com wrote:

On Nov 17, 2014, at 3:46 PM, Amit Gandhi amit.gan...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev