Removing associations between resources
Hi again, Reading the specs I cannot quite figure out how to remove an association between one resource and another. As far as I understand PUT can be used to add a new or change an existing association, i.e. using Link headers. But how to remove an association? Reading the Wiki [1] I found some new text which indicates that DELETE somehow can be used to remove associations as well as resources. The described semantics seemed to be rather complicated. You have probably thought a lot about this already but from my point of view any operation which irreversibly deletes/destroys a resource should have as simple semantics as possible. Using DELETE to remove associations seem dangerous to me. What are your thoughts on this matter? regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModels...
Hey Ralf! Thanks for bringing this up :-) I'd whole-heartedly agree with you that having clear and simple semantics are a must especially with potentially dangerous operation like DELETE. Semantics related to removal/deletion of Link, in my view should be divided into two separate but complimentary areas: 1) Unlinking - to unlink one resource from another the use of PUT should be used to update the appropriate resource 2) Destroying a link - to destroy a link resource it must be unlinked from dependent resources using PUT and then finally destroyed using DELETE. If a user attempts to destroy before unlinking then the server should raise an exception. That way there are no dangling references to non-existent resources. What do you and others think? Andy -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Sunday, August 08, 2010 3:20 PM To: occi-wg@ogf.org Subject: [occi-wg] Removing associations between resources Hi again, Reading the specs I cannot quite figure out how to remove an association between one resource and another. As far as I understand PUT can be used to add a new or change an existing association, i.e. using Link headers. But how to remove an association? Reading the Wiki [1] I found some new text which indicates that DELETE somehow can be used to remove associations as well as resources. The described semantics seemed to be rather complicated. You have probably thought a lot about this already but from my point of view any operation which irreversibly deletes/destroys a resource should have as simple semantics as possible. Using DELETE to remove associations seem dangerous to me. What are your thoughts on this matter? regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModels... _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hi Andy! (1) Generally I think the rule for deletion is a domain-specific question, too. That is it may depend on whether a child (dependent) resource's life cycle is bound to the parent or not. If it is bound then the child should live and die with the parent that means cascade delete. However if the child is not tied to the parent then a scenario like the unlink-destroy outlined below should happen. So it might be valuable to analyse the question case-by-case for the specific infrastructure resources (or whatever entitiy OCCI supports). (1.a.) Is storage life cycle bound to the compute life cycle? Can a storage entity live outside of a compute? - To my understanding data disks should live indenpendently - at least in my limited experience I've met this end user request ie. to preserve data produced by virtual machines after the vm terminates. - Similar may apply to root disks (containing the operating system) but for another reason - when configuring a system is a tough task then it is valuable to preserve such configurations. (1.b.) Is network (ie. NIC) life cycle bound to the compute life cycle? Can a network (NIC) entity live outside of a compute? I would say yes it can, but don't see much 'business' value in it. Not since NIC configuration in itself is not a big deal or is it?:) (2) Rule for deletion is also technical, especially a usability question as Ralf and Andy pointed at. Though I'm not a usability expert, some thoughts:) I think the options (cascade delete and unlink first-delete next) outlined earlier are quite common techniques, do not break usability. But again I could be completely wrong:) BTW: Of course deleting resources while references exist to them (ie. breaking referential integrity) is not a (usable) option... - Simplicity - I think both the 'unlink-destroy' scenario and the 'cascade delete' operation is simple. - Effectiveness - I think this is the point where cascade delete may give some value, ie. by supporting batch operations. - Robustness - Cascade deletes are dangerous meanwhile there are common techniques to guard against unwanted deletes (like confirmation dialog, logical deletes, trash). Gyula ________________________________________ Feladó: occi-wg-bounces@ogf.org [occi-wg-bounces@ogf.org] ; meghatalmazó: Edmonds, AndrewX [andrewx.edmonds@intel.com] Küldve: 2010. augusztus 10. 10:21 Címzett: Ralf Nyren; occi-wg@ogf.org Tárgy: Re: [occi-wg] Removing associations between resources Hey Ralf! Thanks for bringing this up :-) I'd whole-heartedly agree with you that having clear and simple semantics are a must especially with potentially dangerous operation like DELETE. Semantics related to removal/deletion of Link, in my view should be divided into two separate but complimentary areas: 1) Unlinking - to unlink one resource from another the use of PUT should be used to update the appropriate resource 2) Destroying a link - to destroy a link resource it must be unlinked from dependent resources using PUT and then finally destroyed using DELETE. If a user attempts to destroy before unlinking then the server should raise an exception. That way there are no dangling references to non-existent resources. What do you and others think? Andy -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Sunday, August 08, 2010 3:20 PM To: occi-wg@ogf.org Subject: [occi-wg] Removing associations between resources Hi again, Reading the specs I cannot quite figure out how to remove an association between one resource and another. As far as I understand PUT can be used to add a new or change an existing association, i.e. using Link headers. But how to remove an association? Reading the Wiki [1] I found some new text which indicates that DELETE somehow can be used to remove associations as well as resources. The described semantics seemed to be rather complicated. You have probably thought a lot about this already but from my point of view any operation which irreversibly deletes/destroys a resource should have as simple semantics as possible. Using DELETE to remove associations seem dangerous to me. What are your thoughts on this matter? regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModels... _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Good threads....Regarding the cascading concept as described below....it seems a bit dangerous, albeit useful. It potentiality deletes more than just the resource in question and therefore that process would need to consider all other links and all the related linked resources (potentially an entire tree of resources). Also, we need to be careful about allowing circular links (which might be possible now). Also, it is likely that a resource would be linked to more than one parent (linked clones, backups, etc). There is even the possibility of circular links (which we might want to prevent in the spec). The burnden of integrity would be on the server. Csom Gyula wrote:
Hi Andy!
(1) Generally I think the rule for deletion is a domain-specific question, too. That is it may depend on whether a child (dependent) resource's life cycle is bound to the parent or not. If it is bound then the child should live and die with the parent that means cascade delete. However if the child is not tied to the parent then a scenario like the unlink-destroy outlined below should happen. So it might be valuable to analyse the question case-by-case for the specific infrastructure resources (or whatever entitiy OCCI supports).
(1.a.) Is storage life cycle bound to the compute life cycle? Can a storage entity live outside of a compute? - To my understanding data disks should live indenpendently - at least in my limited experience I've met this end user request ie. to preserve data produced by virtual machines after the vm terminates. - Similar may apply to root disks (containing the operating system) but for another reason - when configuring a system is a tough task then it is valuable to preserve such configurations.
(1.b.) Is network (ie. NIC) life cycle bound to the compute life cycle? Can a network (NIC) entity live outside of a compute? I would say yes it can, but don't see much 'business' value in it. Not since NIC configuration in itself is not a big deal or is it?:)
(2) Rule for deletion is also technical, especially a usability question as Ralf and Andy pointed at. Though I'm not a usability expert, some thoughts:)
I think the options (cascade delete and unlink first-delete next) outlined earlier are quite common techniques, do not break usability. But again I could be completely wrong:)
BTW: Of course deleting resources while references exist to them (ie. breaking referential integrity) is not a (usable) option...
- Simplicity - I think both the 'unlink-destroy' scenario and the 'cascade delete' operation is simple. - Effectiveness - I think this is the point where cascade delete may give some value, ie. by supporting batch operations. - Robustness - Cascade deletes are dangerous meanwhile there are common techniques to guard against unwanted deletes (like confirmation dialog, logical deletes, trash).
Gyula ________________________________________ Feladó: occi-wg-bounces@ogf.org [occi-wg-bounces@ogf.org] ; meghatalmazó: Edmonds, AndrewX [andrewx.edmonds@intel.com] Küldve: 2010. augusztus 10. 10:21 Címzett: Ralf Nyren; occi-wg@ogf.org Tárgy: Re: [occi-wg] Removing associations between resources
Hey Ralf!
Thanks for bringing this up :-) I'd whole-heartedly agree with you that having clear and simple semantics are a must especially with potentially dangerous operation like DELETE.
Semantics related to removal/deletion of Link, in my view should be divided into two separate but complimentary areas: 1) Unlinking - to unlink one resource from another the use of PUT should be used to update the appropriate resource 2) Destroying a link - to destroy a link resource it must be unlinked from dependent resources using PUT and then finally destroyed using DELETE. If a user attempts to destroy before unlinking then the server should raise an exception. That way there are no dangling references to non-existent resources.
What do you and others think?
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Sunday, August 08, 2010 3:20 PM To: occi-wg@ogf.org Subject: [occi-wg] Removing associations between resources
Hi again,
Reading the specs I cannot quite figure out how to remove an association between one resource and another. As far as I understand PUT can be used to add a new or change an existing association, i.e. using Link headers. But how to remove an association?
Reading the Wiki [1] I found some new text which indicates that DELETE somehow can be used to remove associations as well as resources. The described semantics seemed to be rather complicated.
You have probably thought a lot about this already but from my point of view any operation which irreversibly deletes/destroys a resource should have as simple semantics as possible. Using DELETE to remove associations seem dangerous to me.
What are your thoughts on this matter?
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModels...
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) (703) 714-0442 (land)
On Tue, 10 Aug 2010 11:50:26 +0200, Csom Gyula <csom@interface.hu> wrote:
(1) Generally I think the rule for deletion is a domain-specific question, too. That is it may depend on whether a child (dependent) resource's life cycle is bound to the parent or not.
I agree, if for instance the creation of a compute resource by use of the IMF's templates in reality also creates let us say two associated storage resources and one network resource it would be useful if they could be destroyed at the same time the compute resource is destroyed. The semantics of creating e.g. a compute resource in different IMFs of course varies a great deal. However I still would want the OCCI operations to have standardized semantics, independent of the underlying IMFs view of things. Let us say we have two different IMFs each exposing an external API using OCCI. With both IMFs creating a compute also creates an attached storage resource. However, when deleting the compute the first IMF also deletes the storage resource (and whatever the user had saved there) while the other only destroys the compute resource but leaves the disk intact. If we were to build a OCCI client which we could be used with both of these IMFs a DELETE operation could give the user an unpleasant surprise.
(1.a.) Is storage life cycle bound to the compute life cycle? Can a storage entity live outside of a compute? - To my understanding data disks should live indenpendently - at least in my limited experience I've met this end user request ie. to preserve data produced by virtual machines after the vm terminates. - Similar may apply to root disks (containing the operating system) but for another reason - when configuring a system is a tough task then it is valuable to preserve such configurations.
I agree.
(1.b.) Is network (ie. NIC) life cycle bound to the compute life cycle? Can a network (NIC) entity live outside of a compute? I would say yes it can, but don't see much 'business' value in it. Not since NIC configuration in itself is not a big deal or is it?:)
If you let network resources include static IP addresses it can be quite useful to have them still exist after the compute resource is gone.
I think the options (cascade delete and unlink first-delete next) outlined earlier are quite common techniques, do not break usability. But again I could be completely wrong:)
Yes I agree, I think both techniques should be supported.
BTW: Of course deleting resources while references exist to them (ie. breaking referential integrity) is not a (usable) option...
Indeed not. One approach (as I wrote to Andrew) might be to remove all associations bound to the particular resource when it is destroyed. That way you never break referential integrity while at the same time never removes more than the specified resource. I still think your point about cascade delete should be supported somehow. Maybe an "allow cascade" attribute could be an alternative. regards, Ralf
On Tue, 10 Aug 2010 10:21:38 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote: Hi Andrew, thanks for your response!
Semantics related to removal/deletion of Link, in my view should be divided into two separate but complimentary areas: 1) Unlinking - to unlink one resource from another the use of PUT should be used to update the appropriate resource
I agree, the use of PUT to remove an association between two resources is how I would want it. The question is though, how to express the removal operation using the Link header?
2) Destroying a link - to destroy a link resource it must be unlinked from dependent resources using PUT and then finally destroyed using DELETE. If a user attempts to destroy before unlinking then the server should raise an exception. That way there are no dangling references to non-existent resources.
By a "link resource" you mean an association applied to a Resource, right? That is, an association/link can never exist on its own? The way I view things the unlinking operation would not be necessary. Let us say we have a compute resource '/compute/vm01' and a storage resource '/storage/san01'. We then decide to associate these two resources by a link. This can be accomplished by two different PUT request: We could make a link from the compute resource to the storage resource, e.g. "add a disk": PUT /compute/vm01 HTTP/1.1 Link: </storage/san01>; class='link'; rel=... Or we could make a link from the storage resource to the compute resource, e.g. "make the disk available to the virtual machine". PUT /storage/san01 HTTP/1.1 Link: </compute/vm01>; class='link'; rel=... Now, since there is only one association here, removing either compute or storage resource would also destroy the association. An association between two resource can only exist as long as both resources exist. If you view things this way you can never have dangling references. What do think of this approach? I might just have misunderstood something though... regards, Ralf
Personally, I think this is a really bad idea, since we are breaking the traditional semantics of HTTP and REST. If there is a need for a lifecycle of a link, then the link should be a resource, and not some header construct. Otherwise, it should never be altered by the client, but instead, fully managed by the server. That is, if a resource gets deleted, the server should be responsible for finding and updating all dangling links and, on the next GET or HEAD for any affected resource, return the correct data. Really, guys -- we are imposing additional CRUD semantics on the headers here. Shouldn't do that, though. -Al. Am 10.08.2010 um 15:09 schrieb Ralf Nyren:
On Tue, 10 Aug 2010 10:21:38 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Hi Andrew, thanks for your response!
Semantics related to removal/deletion of Link, in my view should be divided into two separate but complimentary areas: 1) Unlinking - to unlink one resource from another the use of PUT should be used to update the appropriate resource
I agree, the use of PUT to remove an association between two resources is how I would want it.
The question is though, how to express the removal operation using the Link header?
2) Destroying a link - to destroy a link resource it must be unlinked from dependent resources using PUT and then finally destroyed using DELETE. If a user attempts to destroy before unlinking then the server should raise an exception. That way there are no dangling references to non-existent resources.
By a "link resource" you mean an association applied to a Resource, right? That is, an association/link can never exist on its own?
The way I view things the unlinking operation would not be necessary. Let us say we have a compute resource '/compute/vm01' and a storage resource '/storage/san01'. We then decide to associate these two resources by a link. This can be accomplished by two different PUT request:
We could make a link from the compute resource to the storage resource, e.g. "add a disk": PUT /compute/vm01 HTTP/1.1 Link: </storage/san01>; class='link'; rel=...
Or we could make a link from the storage resource to the compute resource, e.g. "make the disk available to the virtual machine". PUT /storage/san01 HTTP/1.1 Link: </compute/vm01>; class='link'; rel=...
Now, since there is only one association here, removing either compute or storage resource would also destroy the association. An association between two resource can only exist as long as both resources exist.
If you view things this way you can never have dangling references.
What do think of this approach? I might just have misunderstood something though...
regards, Ralf _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
My .2c Storage and Network can both live happily independently, so too compute. In the scenario where there is, for example, a Compute and Storage resource linked by a "Link", is should only be that link that gets destroyed and not the related resources of Compute and Storage. Even if a Link is deleted and removing the relationship between the 2 resources, these resources are still referenceable via the "id" attribute of resource. I'd agree with Michael and Alexander here. I would not embed any "cascade" semantics into the model. It's not an ORM-style model. If cascade-style functionality is needed this can be provided by clients and if there is enough interest in such a feature we can add it in later or position it as an extension. Ralph, to unlink using PUT I'd see as the following. (when PUT'ting you have to PUT the full representation of the resource). 1. Lets get a representation of the resource whose link we want to remove (I'm only including the necessary parts of the request/responses for the example) Req: GET /compute/vm01 HTTP/1.1 Res: HTTP/1.1 200 OK Link: </storage/san01>; class='link'; rel=... occi.compute.cores = 2 2. Lets update the resource without the link, thereby removing the link Req: PUT /compute/vm01 HTTP/1.1 occi.compute.cores = 2 3. The OCCI implementation will now update the representation of that resource and carry out the provisioning system related activities, if necessary, of unlinking the resources. That deletion should remove the Compute instance to Storage instance link and any link that that Storage instance has to that Compute instance. Andy -----Original Message----- From: Alexander Papaspyrou [mailto:alexander.papaspyrou@tu-dortmund.de] Sent: Tuesday, August 10, 2010 3:11 PM To: Ralf Nyren Cc: Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] Removing associations between resources Personally, I think this is a really bad idea, since we are breaking the traditional semantics of HTTP and REST. If there is a need for a lifecycle of a link, then the link should be a resource, and not some header construct. Otherwise, it should never be altered by the client, but instead, fully managed by the server. That is, if a resource gets deleted, the server should be responsible for finding and updating all dangling links and, on the next GET or HEAD for any affected resource, return the correct data. Really, guys -- we are imposing additional CRUD semantics on the headers here. Shouldn't do that, though. -Al. Am 10.08.2010 um 15:09 schrieb Ralf Nyren:
On Tue, 10 Aug 2010 10:21:38 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Hi Andrew, thanks for your response!
Semantics related to removal/deletion of Link, in my view should be divided into two separate but complimentary areas: 1) Unlinking - to unlink one resource from another the use of PUT should be used to update the appropriate resource
I agree, the use of PUT to remove an association between two resources is how I would want it.
The question is though, how to express the removal operation using the Link header?
2) Destroying a link - to destroy a link resource it must be unlinked from dependent resources using PUT and then finally destroyed using DELETE. If a user attempts to destroy before unlinking then the server should raise an exception. That way there are no dangling references to non-existent resources.
By a "link resource" you mean an association applied to a Resource, right? That is, an association/link can never exist on its own?
The way I view things the unlinking operation would not be necessary. Let us say we have a compute resource '/compute/vm01' and a storage resource '/storage/san01'. We then decide to associate these two resources by a link. This can be accomplished by two different PUT request:
We could make a link from the compute resource to the storage resource, e.g. "add a disk": PUT /compute/vm01 HTTP/1.1 Link: </storage/san01>; class='link'; rel=...
Or we could make a link from the storage resource to the compute resource, e.g. "make the disk available to the virtual machine". PUT /storage/san01 HTTP/1.1 Link: </compute/vm01>; class='link'; rel=...
Now, since there is only one association here, removing either compute or storage resource would also destroy the association. An association between two resource can only exist as long as both resources exist.
If you view things this way you can never have dangling references.
What do think of this approach? I might just have misunderstood something though...
regards, Ralf _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Wed, 11 Aug 2010 11:33:58 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Ralph, to unlink using PUT I'd see as the following. (when PUT'ting you have to PUT the full representation of the resource).
Yes, that is definitely a solution. However you will only have to PUT the full representation of the resource as far as Links are concerned, if I understand things correctly. So in order to increase the memory of a compute resource the sequence would be: 1. GET /compute/xxx 2. Remember all Links with class='link' 3. Issue PUT /compute/xxx with occi.compute.memory = X and include all the links from step 2. In other words all Links must always by present in a PUT while only those attributes one wishes to change has to be present. Correct?
3. The OCCI implementation will now update the representation of that resource and carry out the provisioning system related activities, if necessary, of unlinking the resources. That deletion should remove the Compute instance to Storage instance link and any link that that Storage instance has to that Compute instance.
Yep, as long as the deleting of a resource removes all Links but no other resources I am happy. regards, Ralf
Hey Ralph, Inline... -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Wednesday, August 11, 2010 11:02 AM To: Edmonds, AndrewX; Alexander Papaspyrou Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Removing associations between resources <snip/> In other words all Links must always by present in a PUT while only those attributes one wishes to change has to be present. Correct? AE: Yes <snip/> ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Ralf, comments inline... Am 11.08.2010 um 12:01 schrieb Ralf Nyren:
On Wed, 11 Aug 2010 11:33:58 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Ralph, to unlink using PUT I'd see as the following. (when PUT'ting you have to PUT the full representation of the resource).
Yes, that is definitely a solution. However you will only have to PUT the full representation of the resource as far as Links are concerned, if I understand things correctly.
So in order to increase the memory of a compute resource the sequence would be: 1. GET /compute/xxx 2. Remember all Links with class='link' 3. Issue PUT /compute/xxx with occi.compute.memory = X and include all the links from step 2.
In other words all Links must always by present in a PUT while only those attributes one wishes to change has to be present. Correct?
Sounds reasonable. OTOH, this indicates that a Link is something with its own CRUD semantics. Shouldn't this be then a resource (not Resource) as well?
3. The OCCI implementation will now update the representation of that resource and carry out the provisioning system related activities, if necessary, of unlinking the resources. That deletion should remove the Compute instance to Storage instance link and any link that that Storage instance has to that Compute instance.
Yep, as long as the deleting of a resource removes all Links but no other resources I am happy.
Let me rephrase to understand. If I delete a Resource, and other Resources have Links to it, the OCCI implementation will take care of updating (i.e. removing) stale Links automatically. That is, for a Resource A which is DELETEd and a Resource B with a Link to Resource A, a subsequent GET on B will render B without the Link to A? Best, Alexander -- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
In other words all Links must always by present in a PUT while only those attributes one wishes to change has to be present. Correct?
Sounds reasonable. OTOH, this indicates that a Link is something with its own CRUD semantics. Shouldn't this be then a resource (not Resource) as well?
I see what you mean, a Link is indeed something we create, update and delete. However, I do not know if turning a Link into a resource (not Resource) would make the specification simpler or more complex than it is with the current semantics.
Let me rephrase to understand. If I delete a Resource, and other Resources have Links to it, the OCCI implementation will take care of updating (i.e. removing) stale Links automatically. That is, for a Resource A which is DELETEd and a Resource B with a Link to Resource A, a subsequent GET on B will render B without the Link to A?
Exactly, that is how I would want it. Nice description. regards, Ralf
I tend to be in agreement with Alex on this one. We are assigning a life cycle to a link element intended to represent an association between resources. Its the association, an implicate resource property, represented by the link (as the implementation) that is constructed and deleted. The OCCI challenge surrounding this discussion is founded in how storage and network resources exist in the OCCI model when not attached to a Compute resource (orphans). Once we clearly define how and where they exist, resource life cycle practices can be developed around it. Then we could consider using verbs including using CRUD update (via a configuration definition) and the OCCI verb Move. cheers, gary Alexander Papaspyrou wrote:
Personally, I think this is a really bad idea, since we are breaking the traditional semantics of HTTP and REST.
If there is a need for a lifecycle of a link, then the link should be a resource, and not some header construct. Otherwise, it should never be altered by the client, but instead, fully managed by the server. That is, if a resource gets deleted, the server should be responsible for finding and updating all dangling links and, on the next GET or HEAD for any affected resource, return the correct data.
Really, guys -- we are imposing additional CRUD semantics on the headers here. Shouldn't do that, though.
-Al.
Am 10.08.2010 um 15:09 schrieb Ralf Nyren:
On Tue, 10 Aug 2010 10:21:38 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Hi Andrew, thanks for your response!
Semantics related to removal/deletion of Link, in my view should be divided into two separate but complimentary areas: 1) Unlinking - to unlink one resource from another the use of PUT should be used to update the appropriate resource
I agree, the use of PUT to remove an association between two resources is how I would want it.
The question is though, how to express the removal operation using the Link header?
2) Destroying a link - to destroy a link resource it must be unlinked from dependent resources using PUT and then finally destroyed using DELETE. If a user attempts to destroy before unlinking then the server should raise an exception. That way there are no dangling references to non-existent resources.
By a "link resource" you mean an association applied to a Resource, right? That is, an association/link can never exist on its own?
The way I view things the unlinking operation would not be necessary. Let us say we have a compute resource '/compute/vm01' and a storage resource '/storage/san01'. We then decide to associate these two resources by a link. This can be accomplished by two different PUT request:
We could make a link from the compute resource to the storage resource, e.g. "add a disk": PUT /compute/vm01 HTTP/1.1 Link: </storage/san01>; class='link'; rel=...
Or we could make a link from the storage resource to the compute resource, e.g. "make the disk available to the virtual machine". PUT /storage/san01 HTTP/1.1 Link: </compute/vm01>; class='link'; rel=...
Now, since there is only one association here, removing either compute or storage resource would also destroy the association. An association between two resource can only exist as long as both resources exist.
If you view things this way you can never have dangling references.
What do think of this approach? I might just have misunderstood something though...
regards, Ralf _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (6)
-
Alexander Papaspyrou -
Csom Gyula -
Edmonds, AndrewX -
Gary Mazz -
Michael Behrens -
Ralf Nyren