[occi-wg] Another proposal on Linking

[Ralf Nyren]

> --8<-- snip --8<--
> Let me take my favorite example again. We have:
> - A Compute resource - in this case it is a Virtual Machine
> - A Storage resource - in this case it is a shared disk for use with a  
> cluster filesystem (e.g. GFS2)
> Now we need to attach the disk to the virtual machine and in order to do  
> so we must specify what disk controller interface/address the disk  
> should appear on in the virtual machine. Let's say we want it to appear  
> as an IDE drive on bus 1, unit 0 (hdc for Linux people).
> --8<-- snap --8<--
>
> resource::compute -> link -> resource::disk -> link ->   
> resource::clusterfs
>
> where disk is the "logical disk" that is plugged into the compute vm,  
> and clusterfs is your shared disk/cluster filesystem. The former then  
> would capture the interface/address stuff, and basically is a disk  
> representation specifically for your compute VM.

Yep. But what about the life cycle issues? What should happen when either  
resource::disk or one of the links is deleted?

Could a resource::disk exist on its own now, i.e. without reference to  
both compute and storage?

How to handle the case where the IMF does not allow resource:disk to exist  
on its own (as stated in my example)?

You could also have the scenario where two resource::compute link to the  
same resource::disk. This sort of defies the purpose of the resource::disk  
in the first place.

Not to mention that you would have to issue 3 POST request for each  
storage you want to hook up to the compute.

> From my point of view, especially for the VM use case, you have VMs and  
> some kind of virtual storage, which is attached to it. This virtual  
> storage may or may not be shared and, if necessary, can again rely upon  
> other (physical or virtual) storage. There will be a layer of "virtual  
> storage" anyway, since even if you attach physical storage directly to a  
> VM, the representation of it within the VM is still a virtual disk.

Indeed but the virtual drive in this case should be unique to the VM.  
Little point in having a bunch of virtual drives with different  
pre-defined attachment points (SCSI/IDE/whatever) lying around.

With Fat Links you can still add whatever additional virtual layer you  
need by creating new resources. The important part is that you do not have  
to model things as a resource when the life cycle properties do not match  
those of a full-blown resource.

I do appreciate your description and explanation of the Thin Link approach  
though. My goal is to have as many of the pros and cons of the different  
approaches spelled out so we perhaps could reach a decision tomorrow ;)

regards, Ralf