[occi-wg] Link specification

[Csom Gyula]

Hi!:)

1) Do you mean the following diagram:

http://forge.ogf.org/sf/sfmain/do/downloadAttachment/projects.occi-wg/wiki/CoreAndModels?id=atch4938

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 at intel.com]
Küldve: 2010. szeptember 1. 18:58
Címzett: Csom Gyula; occi-wg at 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 at interface.hu]
Sent: Wednesday, September 01, 2010 5:32 PM
To: Edmonds, AndrewX; occi-wg at 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 at 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 at ogf.org [occi-wg-bounces at ogf.org] ;
meghatalmazó: Edmonds, AndrewX [andrewx.edmonds at intel.com]
Küldve: 2010. szeptember 1. 17:01
Címzett: occi-wg at 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