Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs
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
[openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs
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}.
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?
Thanks,
Shaunak
References:
[1] https://wiki.openstack.org/wiki/Poppy
[2] https://bugs.launchpad.net/poppy/+bug/1392573
[3]
https://github.com/mikekelly/hal_specification/blob/master/hal_specification.md
___
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
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
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
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
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
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
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
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
