[occi-wg] Removing associations between resources

[Ralf Nyren]

On Tue, 10 Aug 2010 11:50:26 +0200, Csom Gyula <csom at 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