[occi-wg] Removing associations between resources

[Edmonds, AndrewX]

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 at tu-dortmund.de] 
Sent: Tuesday, August 10, 2010 3:11 PM
To: Ralf Nyren
Cc: Edmonds, AndrewX; occi-wg at 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 at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg

--
Alexander Papaspyrou
alexander.papaspyrou at 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.