[occi-wg] Another proposal on Linking

[Ralf Nyren]

>>> resource::compute -> link -> resource::disk -> link ->  
>>> resource::clusterfs
>>>
>> 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.

Of course but my point is that it is not possible for the IMF to enforce a  
policy which says "resource:disk cannot exist on its own". That is simply  
not possibly due to the nature of a resource. As such it is not possible  
to express a many-to-many relation with relation attributes, not when the  
entities are required. I think this is a limitation which should not be  
overlooked.

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

Yes, thanks for keeping things clean. But again, what I am trying to say  
is that there is a certain type of use cases which cannot be expressed by  
the model.

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

Well, I am sure there are enough real world use cases to justify the need  
for relation attributes. If you would like an example have a look at  
ElasticHosts [1] and see how they allow their users to assign disks and  
VLANs.

For wide adoption of OCCI I believe well defined extensibility is very  
important.

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

Good point about actions although you would still need 2 GET requests to  
find out which Storage Resource the Compute Links to. The target attribute  
of the first Link will point to resource:disk...

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

Good, but how to accomplish this? In order to create the Links you have to  
create resource:disk first, and if you are allowed to do that you end up  
with precisely those virtual drives lying around. Ok, you might say  
actions here but then you all of a sudden have a resource type which is  
not allowed to be created, weird.

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

Yes, I will update the Link page shortly.

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

Indeed, me too. Just trying to be polite =)

regards, Ralf

[1] http://www.elastichosts.com/cloud-hosting/api