[occi-wg] Another proposal on Linking

[Alexander Papaspyrou]

Am 17.08.2010 um 16:01 schrieb 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?

Well, that pretty much depends on the semantics of the resource::disk usage which, by definition, is domain-specific.

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

The server would probably have to take care of removing the resource::disk.

> 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.

No, actually I disagree regarding this point. On the contrary, resources can be (but not necessary are) shared by definition of the model, and so can resource::disk. Only Links are private (non-shared). Whether this makes sense from a domain-specific view is of course another story, but as said, I was focusing on keeping the model clean, and not rendering things towards being convenient for your use case ;-)

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

Actually, I haven't ever seen this use case coming up. Until now, people wanted compute resources, storage resources (e.g. CDMI), and a link between them. You are right that, if you have a complex IaaS model and map this to thin links, you end up with lots of resources. On the other hand, you could always define an OCCI action, which collates together the complete linking process (i.e. provide a single operation for setting up a more or less complex relationship of OCCI resources).

>> 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.

Agreed.

> 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.

Yes, but again: resources and links get somewhat blended, and the core model FUBARs. Maybe we should work out the differences of Resource and Link wrt. core, and adjust the model there so to cater your needs *and* keep it clean... Any suggestions?

> 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 ;)

Sure. That's the entire point of the list, isn't it? Plus, I like good discussion :-)

Best,
Alexander

-- 
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alexander Papaspyrou.vcf
Type: text/directory
Size: 498 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100817/4bf1856e/attachment.bin 
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4678 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100817/4bf1856e/attachment-0001.bin