On Thu, Jun 25, 2009 at 4:44 PM, <shlomo.swidler@gmail.com> wrote:
On Thu, Jun 25, 2009 at 3:45 PM, <shlomo.swidler@gmail.com> wrote:
4. How will I be able to discover VM images that are appropriate for my "compute"s? For example, Amazon has public AMIs that I can launch on my instances, and I can filter the ElasticFox view to only show me 64-bit AMIs or otherwise filter them by AMI name. Is this use case covered by OVF, or is it more appropriate at the OCCI level?
This one I have a better answer for, in that there should be no "start" verb for a template (e.g. AMI), rather only a "clone" verb which returns a Location: to a new compute resource (pre-linked to any storage and network resources as necessary). We could also bundle templates into a
On Thu, Jun 25, 2009 at 5:34 PM, Sam Johnston<samj@samj.net> wrote: pre-defined
category, such that machines that are just not startable (e.g. due to permissions, faults, etc.) don't appear as templates.
Sounds strange to me.
Sheep aSheep = new Sheep(); Object dolly = aSheep.clone();
I would expect "dolly" to be of type Sheep, the same type as the object that was cloned.
The original object was a compute resource and the result of "cloning" it is a compute resource too - I don't see a problem here (though I agree with your argument).
Perhaps the verb "instantiate" is more appropriate to describe the act of "using a template". But it's harder to spell.
Perhaps, and you're right it is harder to spell. Whatever we choose we just need to make sure we define it properly. For performance reasons it might be useful to be able to "start" a template anyway (one call instead of two)... in which case a pre-defined "template" category makes sense. Sam
On Thu, Jun 25, 2009 at 5:54 PM, Sam Johnston<samj@samj.net> wrote:
On Thu, Jun 25, 2009 at 4:44 PM, <shlomo.swidler@gmail.com> wrote:
On Thu, Jun 25, 2009 at 5:34 PM, Sam Johnston<samj@samj.net> wrote:
On Thu, Jun 25, 2009 at 3:45 PM, <shlomo.swidler@gmail.com> wrote:
4. How will I be able to discover VM images that are appropriate for my "compute"s? For example, Amazon has public AMIs that I can launch on my instances, and I can filter the ElasticFox view to only show me 64-bit AMIs or otherwise filter them by AMI name. Is this use case covered by OVF, or is it more appropriate at the OCCI level?
This one I have a better answer for, in that there should be no "start" verb for a template (e.g. AMI), rather only a "clone" verb which returns a Location: to a new compute resource (pre-linked to any storage and network resources as necessary). We could also bundle templates into a pre-defined category, such that machines that are just not startable (e.g. due to permissions, faults, etc.) don't appear as templates.
Sounds strange to me.
Sheep aSheep = new Sheep(); Object dolly = aSheep.clone();
I would expect "dolly" to be of type Sheep, the same type as the object that was cloned.
The original object was a compute resource and the result of "cloning" it is a compute resource too - I don't see a problem here (though I agree with your argument).
Perhaps the verb "instantiate" is more appropriate to describe the act of "using a template". But it's harder to spell.
Perhaps, and you're right it is harder to spell. Whatever we choose we just need to make sure we define it properly.
For performance reasons it might be useful to be able to "start" a template anyway (one call instead of two)... in which case a pre-defined "template" category makes sense.
Sam
I had assumed that the original template (AMI) was of type "template" and not of type "compute resource". I think it muddies the definitions to call "templates from which compute resources can be built" by the name "compute resource". So the idea would be a template, with only three possible verbs: - clone (create my own copy of this template, owned by me, and not necessarily visible to the public) - instantiate or start (create a compute resource based on this template, like launching an EC2 instance) - delete (remove a template, assuming I own it and/or have permission to delete it) [BTW, the same verbs are what I envisioned for the noun meaning disk "snapshot"s.]
On Thu, Jun 25, 2009 at 5:06 PM, <shlomo.swidler@gmail.com> wrote:
I had assumed that the original template (AMI) was of type "template" and not of type "compute resource".
I think it muddies the definitions to call "templates from which compute resources can be built" by the name "compute resource". So the idea would be a template, with only three possible verbs: - clone (create my own copy of this template, owned by me, and not necessarily visible to the public) - instantiate or start (create a compute resource based on this template, like launching an EC2 instance) - delete (remove a template, assuming I own it and/or have permission to delete it)
[BTW, the same verbs are what I envisioned for the noun meaning disk "snapshot"s.]
A template is just a special type of compute resource and there's nothing to say we're not going to end up with template network and storage resources as well - I really don't think a new noun is justified and would prefer to keep things as simple as possible... 3 nouns is about right. Sam
A template is just a special type of compute resource and there's nothing to say we're not going to end up with template network and storage resources as well - I really don't think a new noun is justified and would prefer to keep things as simple as possible... 3 nouns is about right.
Sam
I'm still warping^H^H^H^H^H wrapping my head around RESTful thinking as opposed to OO, so please bear with me. If both "AMI"s (template-computes) and "instances" (actual-computes) are "compute" resources, then how would the client distinguish between the two? One reason to distinguish between them is to separately classify them into different areas of the UI (for example the "Images" vs. Instances" tabs of ElasticFox) based on the verbs that can be done to them. On second thought, I may have answered my own question: we can distinguish template-computes from actual-computes by looking at the verb links that are provided on them. Actual-computes will have verbs such as "start","stop", "pause", "resume", "delete" (depending on their current state); while template-computes will only have "start" and "delete", and their state will never change (not sure, but it seems to me that a template's state will not change - you can only create a new resource from a template or delete the template altogether). Then again, if an infrastructure provider does not allow actual-computes to be "paused" or "resumed" but does allow "start" and "stop", then we cannot distinguish between actual-computes that are stopped (having verbs "start" and "delete") and between template-computes (having verbs "start" and "delete"). So then the question remains: how do we reliably distinguish between template-computes and actual-computes? Or template-XXs and actual-XXs ?
On Thu, Jun 25, 2009 at 8:29 PM, <shlomo.swidler@gmail.com> wrote:
A template is just a special type of compute resource and there's nothing to say we're not going to end up with template network and storage resources as well - I really don't think a new noun is justified and would prefer to keep things as simple as possible... 3 nouns is about right.
Sam
I'm still warping^H^H^H^H^H wrapping my head around RESTful thinking as opposed to OO, so please bear with me.
That's ok... in fact RESTful interfaces are usually fairly OO - what I call ROA is just taking it to the extreme. Most people are still thinking like functional programming (e.g. RPC-style), as reflected in APIs like Amazon EC2.
If both "AMI"s (template-computes) and "instances" (actual-computes) are "compute" resources, then how would the client distinguish between the two? One reason to distinguish between them is to separately classify them into different areas of the UI (for example the "Images" vs. Instances" tabs of ElasticFox) based on the verbs that can be done to them.
The simplest solution for this is to add templates to a "template" category. In fact we could specify a number of well known categories like "validated", "[in]secure", etc.
On second thought, I may have answered my own question: we can distinguish template-computes from actual-computes by looking at the verb links that are provided on them. Actual-computes will have verbs such as "start","stop", "pause", "resume", "delete" (depending on their current state); while template-computes will only have "start" and "delete", and their state will never change (not sure, but it seems to me that a template's state will not change - you can only create a new resource from a template or delete the template altogether).
Exactly, only there may be conditions where machines in transition or in abnormal/error states appear as templates when they should not. I'm not yet sure whether we need to explicitly state that a machine is a template (or just rely on the presence or absence of verbs like "clone" and "start" respectively)... but I am sure that they are the same noun.
Then again, if an infrastructure provider does not allow actual-computes to be "paused" or "resumed" but does allow "start" and "stop", then we cannot distinguish between actual-computes that are stopped (having verbs "start" and "delete") and between template-computes (having verbs "start" and "delete").
Right. It's also possible that user permissions will confuse things - perhaps a failover operator can start but not stop machines for example.
So then the question remains: how do we reliably distinguish between template-computes and actual-computes? Or template-XXs and actual-XXs ?
I'm thinking categories - we already have a category system that will handle this well and can even have a dedicated vocabulary/schema for our well-defined categories. Sam
Geez I wish people would stop the RESTful is OO vs. RPC is functional. Nothing could be further from thhe truth. RESTful, RPC, SOAP, XML RPC are all remote calls. It has nothing at all to do with functional vs. imperative programming. That comes from something else, the definition of the language. RESTful is functional, it just deals with objects (or it can). The same can be said of RPC, after all Corba is object based use of "RPC". Chance Sam Johnston wrote:
On Thu, Jun 25, 2009 at 8:29 PM, <shlomo.swidler@gmail.com <mailto:shlomo.swidler@gmail.com>> wrote:
> A template is just a special type of compute resource and there's nothing to > say we're not going to end up with template network and storage resources as > well - I really don't think a new noun is justified and would prefer to keep > things as simple as possible... 3 nouns is about right. > > Sam
I'm still warping^H^H^H^H^H wrapping my head around RESTful thinking as opposed to OO, so please bear with me.
That's ok... in fact RESTful interfaces are usually fairly OO - what I call ROA is just taking it to the extreme. Most people are still thinking like functional programming (e.g. RPC-style), as reflected in APIs like Amazon EC2.
If both "AMI"s (template-computes) and "instances" (actual-computes) are "compute" resources, then how would the client distinguish between the two? One reason to distinguish between them is to separately classify them into different areas of the UI (for example the "Images" vs. Instances" tabs of ElasticFox) based on the verbs that can be done to them.
The simplest solution for this is to add templates to a "template" category. In fact we could specify a number of well known categories like "validated", "[in]secure", etc.
On second thought, I may have answered my own question: we can distinguish template-computes from actual-computes by looking at the verb links that are provided on them. Actual-computes will have verbs such as "start","stop", "pause", "resume", "delete" (depending on their current state); while template-computes will only have "start" and "delete", and their state will never change (not sure, but it seems to me that a template's state will not change - you can only create a new resource from a template or delete the template altogether).
Exactly, only there may be conditions where machines in transition or in abnormal/error states appear as templates when they should not. I'm not yet sure whether we need to explicitly state that a machine is a template (or just rely on the presence or absence of verbs like "clone" and "start" respectively)... but I am sure that they are the same noun.
Then again, if an infrastructure provider does not allow actual-computes to be "paused" or "resumed" but does allow "start" and "stop", then we cannot distinguish between actual-computes that are stopped (having verbs "start" and "delete") and between template-computes (having verbs "start" and "delete").
Right. It's also possible that user permissions will confuse things - perhaps a failover operator can start but not stop machines for example.
So then the question remains: how do we reliably distinguish between template-computes and actual-computes? Or template-XXs and actual-XXs ?
I'm thinking categories - we already have a category system that will handle this well and can even have a dedicated vocabulary/schema for our well-defined categories.
Sam
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Sat, Jun 27, 2009 at 12:22 PM, <eprparadocs@gmail.com> wrote:
Geez I wish people would stop the RESTful is OO vs. RPC is functional. Nothing could be further from thhe truth. RESTful, RPC, SOAP, XML RPC are all remote calls. It has nothing at all to do with functional vs. imperative programming. That comes from something else, the definition of the language.
RESTful is functional, it just deals with objects (or it can). The same can be said of RPC, after all Corba is object based use of "RPC".
Actually I think it does make sense to differentiate. Traditionally APIs have been a never-ending sprawl of "doSomething(withSomething)" calls, with new ones being added whenever there's a new itch that needs scratching (e.g. EC2). In a pure REST API (what I call "ROA") everything's a [representation of a] resource... an object or a document if you like... and most of your operations look like GET-modify-PUT. Unfortunately many/most even RESTful APIs tend to cut corners and in doing so lose much of the advantage of being RESTful in the first place. For example, if we use an RPC-style call for state changes then we have to punch through to the hypervisor for each and every call (which severely hurts scalability). If we handle these instead as (cancelable) requests then the API clients and the nodes themselves can be completely decoupled, effectively using the API implementation as a[n infinitely scalable] document repository. Anyway we definitely don't have time for more bikeshed painting so if you want to talk about the theory of REST then rest-discuss<http://tech.groups.yahoo.com/group/rest-discuss/>is probably the place to do it. Sam
Well I wasn't the one to bring up the dribble about RESTful being closer to God because it was OO and RPC, like SOAP, isn't. That is just crap. They are all the same thing. So stop trying to sell it. Chance Sam Johnston wrote:
On Sat, Jun 27, 2009 at 12:22 PM, <eprparadocs@gmail.com <mailto:eprparadocs@gmail.com>> wrote:
Geez I wish people would stop the RESTful is OO vs. RPC is functional. Nothing could be further from thhe truth. RESTful, RPC, SOAP, XML RPC are all remote calls. It has nothing at all to do with functional vs. imperative programming. That comes from something else, the definition of the language.
RESTful is functional, it just deals with objects (or it can). The same can be said of RPC, after all Corba is object based use of "RPC".
Actually I think it does make sense to differentiate. Traditionally APIs have been a never-ending sprawl of "doSomething(withSomething)" calls, with new ones being added whenever there's a new itch that needs scratching (e.g. EC2).
In a pure REST API (what I call "ROA") everything's a [representation of a] resource... an object or a document if you like... and most of your operations look like GET-modify-PUT. Unfortunately many/most even RESTful APIs tend to cut corners and in doing so lose much of the advantage of being RESTful in the first place.
For example, if we use an RPC-style call for state changes then we have to punch through to the hypervisor for each and every call (which severely hurts scalability). If we handle these instead as (cancelable) requests then the API clients and the nodes themselves can be completely decoupled, effectively using the API implementation as a[n infinitely scalable] document repository.
Anyway we definitely don't have time for more bikeshed painting so if you want to talk about the theory of REST then rest-discuss <http://tech.groups.yahoo.com/group/rest-discuss/> is probably the place to do it.
Sam
On Sat, Jun 27, 2009 at 1:27 PM, <eprparadocs@gmail.com> wrote:
Well I wasn't the one to bring up the dribble about RESTful being closer to God because it was OO and RPC, like SOAP, isn't. That is just crap. They are all the same thing. So stop trying to sell it.
Thanks again for your insighful contributions. Now if you want to have a sensible discussion about the advantages of one approach to API development over another then this is the place to do it. If not then perhaps I wasn't clear enough before: take it elsewhere. Cheers, Sam
Sam Johnston wrote:
On Sat, Jun 27, 2009 at 12:22 PM, <eprparadocs@gmail.com <mailto:eprparadocs@gmail.com>> wrote:
Geez I wish people would stop the RESTful is OO vs. RPC is functional. Nothing could be further from thhe truth. RESTful, RPC, SOAP, XML RPC are all remote calls. It has nothing at all to do with functional vs. imperative programming. That comes from something else, the definition of the language.
RESTful is functional, it just deals with objects (or it can). The same can be said of RPC, after all Corba is object based use of "RPC".
Actually I think it does make sense to differentiate. Traditionally APIs have been a never-ending sprawl of "doSomething(withSomething)" calls, with new ones being added whenever there's a new itch that needs scratching (e.g. EC2).
In a pure REST API (what I call "ROA") everything's a [representation of a] resource... an object or a document if you like... and most of your operations look like GET-modify-PUT. Unfortunately many/most even RESTful APIs tend to cut corners and in doing so lose much of the advantage of being RESTful in the first place.
For example, if we use an RPC-style call for state changes then we have to punch through to the hypervisor for each and every call (which severely hurts scalability). If we handle these instead as (cancelable) requests then the API clients and the nodes themselves can be completely decoupled, effectively using the API implementation as a[n infinitely scalable] document repository.
Anyway we definitely don't have time for more bikeshed painting so if you want to talk about the theory of REST then rest-discuss <http://tech.groups.yahoo.com/group/rest-discuss/> is probably the place to do it.
Sam
On Sat, Jun 27, 2009 at 1:12 PM, Sam Johnston<samj@samj.net> wrote:
I'm thinking categories - we already have a category system that will handle this well and can even have a dedicated vocabulary/schema for our well-defined categories.
Can you please point me to where categories are defined in the API, and how they are manipulated? I recall some posts about a query format along the lines of http://example.com/-/cat1/cat2 but I don't see that in the wiki anywhere. Categories are mostly useless for interoperability without a dedicated vocabulary/schema - I will want to ask every provider for a list of my "compute template" (or whatever the official label is) resources, and I can't do that if the label is not standardized by the spec. And, does the API support adding my own tag to a resource I own, like tagging a specific compute resource "dbserver"? .. Shlomo
On Sat, Jun 27, 2009 at 10:37 PM, <shlomo.swidler@gmail.com> wrote:
On Sat, Jun 27, 2009 at 1:12 PM, Sam Johnston<samj@samj.net> wrote:
I'm thinking categories - we already have a category system that will handle this well and can even have a dedicated vocabulary/schema for our well-defined categories.
Can you please point me to where categories are defined in the API, and how they are manipulated? I recall some posts about a query format along the lines of http://example.com/-/cat1/cat2 but I don't see that in the wiki anywhere.
The categories were derived from Atom so in dropping it for individual resources we're going to have to reinvent it (think HTTP headers). Categories are mostly useless for interoperability without a dedicated
vocabulary/schema - I will want to ask every provider for a list of my "compute template" (or whatever the official label is) resources, and I can't do that if the label is not standardized by the spec.
The "templates" category is optional (in that you can reverse engineer it from the verbs available) but it's definitely a nice to have, and there are other categories that would be worth standardising too. It's a non-trivial area though (think official templates vs shared templates vs private templates) so we'll have to consider whether it's worth doing - my main concern right now is getting something functional out the door ASAP (the draft is already well overdue).
And, does the API support adding my own tag to a resource I own, like tagging a specific compute resource "dbserver"?
Yes, and you can have your own schemes too - e.g. db vs web as distinct from lax vs nyc. Sam
On Sun, Jun 28, 2009 at 3:48 AM, Sam Johnston<samj@samj.net> wrote:
The categories were derived from Atom so in dropping it for individual resources we're going to have to reinvent it (think HTTP headers).
I know the following is a bad idea, but: It is still possible to support the use cases in the wiki even if we do not provide categories for single-resource responses in the HTTP headers. The Management Dashboard use case will still be able to get the categories from the API call that returns the collection of all resources - because this collection will be in atom format, it will have the categories. Subsequently, if the dashboard queries the API for more details about each resource one-by-one, the categories will not be present in those responses, but the categories can be taken from the first "get all my resources" call. It's possible, but, as you say, fugly. I would prefer to have the categories implemented in the HTTP headers for single-resource responses.
Categories are mostly useless for interoperability without a dedicated vocabulary/schema - I will want to ask every provider for a list of my "compute template" (or whatever the official label is) resources, and I can't do that if the label is not standardized by the spec.
The "templates" category is optional (in that you can reverse engineer it from the verbs available) but it's definitely a nice to have, and there are other categories that would be worth standardising too.
I thought we demonstrated in another thread that the verbs cannot be relied on to infer the category of the resource because there are some cases where the verbs will be limited by the permissions available to the authenticated user, which could cause mis-categorization if we rely on verbs alone. I think we will need to use categories.
It's a non-trivial area though (think official templates vs shared templates vs private templates) so we'll have to consider whether it's worth doing - my main concern right now is getting something functional out the door ASAP (the draft is already well overdue).
Why don't the same questions of official vs. shared vs. private apply to any category label? In other words, you seem to be saying that templates are different from "just plain" categories - and if so, why? I don't follow why it's non-trivial. The label can be applied either by the provider or by the user. The API will report the category label if it has been applied by anyone. .. Shlomo
participants (3)
-
eprparadocs＠gmail.com -
Sam Johnston -
shlomo.swidler＠gmail.com