Hi!:) 1) Do you mean the following diagram: http://forge.ogf.org/sf/sfmain/do/downloadAttachment/projects.occi-wg/wiki/C... Well, yes and maybe not:) The above diagram specifiies the source - link relation as an UML composition, hence deleting a source triggers deleting the link, as well. However it specifiies the target - link relation as a simple binary association which might not have builtin life cycle semantics... 2) Could you please give some more details? Especially do you mean a client-driven solution? Ie. should the client create both the link and the reverse link in this solution? Or?:) 3) Yep:) 4) So a provider can define specific Link categories... ie. within the scheme "http://example.com/occi/link#" Then the category draft should be updated since it tells that even providers can not extend builtin schemes: "Categories schemes can be extended by providers and users by defining there own (with different mutability) scheme. Those MUST be in a different namespace then those described in the OCCI specification." Or did I miss something?:) Gyula ________________________________________ Feladó: Edmonds, AndrewX [andrewx.edmonds@intel.com] Küldve: 2010. szeptember 1. 18:58 Címzett: Csom Gyula; occi-wg@ogf.org Tárgy: RE: Link specification Hey Gyula, 1) How about "An OCCI server MUST delete associated Links after deleting their associated Resource"? This is implicit in Alexander's UML diagram showing that a Resource is composed of Links. Composition indicates that the owning class manages their lifecycle, unless a Link is explicitly removed. 2) If reverse links are required then this can be implemented as a custom/domain-specific link type that subclasses Link 3) Currently the only categories for infrastructure are Compute, Network, Storage. Currently, for my own purposes, I can use Link to associate each of these entities but I cannot associate additional attributes (e.g. IP, macaddress etc) with Link so I will subclass Link and make a domain specific Link (e.g. StorageLink, NetworkLink). 4) I think for now only providers can introduce new categories for the purpose of Resource/Link extension. It will be a useful and valuable addition whereby users can create their own Categories for the sole purpose of organization, in the same vein/style as tags. Andy -----Original Message----- From: Csom Gyula [mailto:csom@interface.hu] Sent: Wednesday, September 01, 2010 5:32 PM To: Edmonds, AndrewX; occi-wg@ogf.org Subject: RE: Link specification Hi, some notes: [1] action on resource delete The working draft specifies the behaviour of deleting links (ie. "An OCCI server MUST NOT delete the associated Resources upon receiving a client DELETE request for a Link."). It's counter part should be also defined, ie. the behaviour of deletion of associated resources. Should the server automatically delete links, as well (CASCADE DELETE behaviour)? Or should it prevent from deleting a resource, if there's a link pointing to it? Or should it be configurable either per link instance or link type? [2] reverse links It might be useful to provide a so called 'reverse link' service, too. Ie. one should be able to query the links that points to a specific resource. Or formally: reverse_links(r) := {link | link.target = r}. In order to? Well, querying reverse links is a common task. For instance: to see what computes belong to a given network... Why... since someone can list all links then filter out the unwanted ones? Within a large system this could be a slow and resource-intensive operation. Meanwhile the cloud system could work from its internal index to filter the necessarry links which is much more faster. This might be modeled as either a new attribute (ie. adding reverse_links to Resource or kinda) or as a special query service (GET /reverse_links/$resource_id HTTP/1.0 or such). [3] built in link types The working draft enables subtyping links: "An OCCI server MAY enforce additional attributes at creation time if the link has been subtyped using additional categories." Sample from the wiki: Category: link; scheme="http://schemas.ogf.org/occi/core#", disk_drive; scheme="http://example.com/occi/link#" Attribute: occi.link.source="/compute/vm01", occi.link.target="/storage/disk03", com.example.drive.interface="ide" I guess built in link categories should be defined for the Infrastructure model (ie. disk, nic and maybe console):) This topic relates to the following one as well: [4] link extensions? It is not clear whether someone could use her own, specific links. The category spec states: "Categories schemes can be extended by providers and users by defining there own (with different mutability) scheme. Those MUST be in a different namespace then those described in the OCCI specification." Hence someone can introduce new Categories within new schemes. But can she introduce new categories within the builtin OCCI namespaces? In order to use user defined links this is mandatory since domain specific links are specified by categories of Link type: "A set of associated attributes defined by the categories of the Link type." Cheers, Gyula ________________________________________ Feladó: Csom Gyula Küldve: 2010. szeptember 1. 17:35 Címzett: Edmonds, AndrewX; occi-wg@ogf.org Tárgy: RE: Link specification Have just ran through the wiki page, though need more time to understand the details:) one basic question came into my mind. In most use cases 'bilateral' links are enough ________________________________________ Feladó: occi-wg-bounces@ogf.org [occi-wg-bounces@ogf.org] ; meghatalmazó: Edmonds, AndrewX [andrewx.edmonds@intel.com] Küldve: 2010. szeptember 1. 17:01 Címzett: occi-wg@ogf.org Tárgy: [occi-wg] Link specification Just a reminder - from our confcall today, the deadline for any further changes that will impact significantly the link specification [1] is next Wednesday August 8th. Get reading! :-) Andy [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link

On Thu, 02 Sep 2010 10:02:32 +0200, Csom Gyula <csom@interface.hu> wrote:

Take the following example:

The user creates a new compute using some networks and disks, ie. define links to some network and disk. The compute is then deployed and soon becomes up and running. Then later the user deletes some network and disk... well, maybe she forgets about that they are used within some running compute. According to the implicit delete behaviour the computes will "loose" its disks and networks which might mean that it becomes unusable.

I would say this is really up to the server implementation. Any kind of server implementation should disallow users from putting part of the system in an unusable state. However, the specification will not enforce this. Different use cases will require different semantics and a server is allowed to refuse requests when needed.

I think deleting source resources with links is a natural behaviour since links are in fact "owned" by the sources. However this might not be the case with target resources, hence alternatives might be examined as well - like:

So if I have a Compute linked by a IPAddressLink to a Network, removing the IPAddressLink would also remove the Compute? That would be sure to upset the users... ;) No, the current model has it very nicely defined I think. And if you need any other (more sophisticated) lifecycle semantics, just subclass the Resourse/Link and implement whatever is needed. regards, Ralf

On Thu, 02 Sep 2010 11:01:06 +0200, Csom Gyula <csom@interface.hu> wrote:

Ok. This clarifies the situation. That is:

* when deleting target resources the default behaviour is to automatically delete links (pointing to them) as well. However

Correct.

* a specific OCCI implementation might enforce its special policies before deleting target resources.

You can enforce your own policies on Resources and Links which have been subclass (subtyped) from the OCCI model Resource/Link.

Ops, no:) What I tried to mean is the following. Taking your example: if I have a Compute (the source) linked by an IPAddressLink (the link) to a Network (the target) then

* when deleting the Compute (the source) it is natural that the IPAddressLink (the link) is deleted automatically as well, since the network link (which in fact represents a NIC) is "owned" by the compute. However

Indeed.

* when deleting the Network (the target) it might not be natural to delete the IPAddressLink as well, since the link (a NIC) is not "owned" by the network.

I see what you mean but I disagree. If you require your NIC to exist without an associated Network it is not a Link you need. You should instead model your NIC as a Resource. regards, Ralf