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