[occi-wg] Removing associations between resources

Michael Behrens michael.behrens at r2ad.com
Tue Aug 10 07:31:29 CDT 2010


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 at ogf.org [occi-wg-bounces at ogf.org] ; meghatalmazó: Edmonds, AndrewX [andrewx.edmonds at intel.com]
> Küldve: 2010. augusztus 10. 10:21
> Címzett: Ralf Nyren; occi-wg at 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 at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Ralf Nyren
> Sent: Sunday, August 08, 2010 3:20 PM
> To: occi-wg at 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?wikiPageVersion=21
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
>    


-- 
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell)
(703) 714-0442 (land)





More information about the occi-wg mailing list