[occi-wg] Issue 13

[Gary Mazz]

Sam,

Are you saying you are changing the concepts of buckets ? for an 
ambiguous URL path ?  where the management of the path is out of scope 
and control of occi api ? . So in the case of this configuration from 
the same provider:
http://node01/web01: OCCI-STUFF
http://node03/web02 <http://node01/web01>: OCCI-STUFF
http://node04/web03 <http://node01/web01>: OCCI-STUFF
http://node02/web04 <http://node01/web01>: OCCI-STUFF

We do not have a way of aggregating those "nodes" in  the occi 
interface. The reason for the buckets following the domain name and 
socket number was to eliminate the requirement for  this type of 
additional management complexity, at least for the first draft of the 
occi spec. I was an advocate of a more flexible scheme from the 
beginning, I'm not sure if its wise to change this without a management 
api.

-gary

Sam Johnston wrote:
> Ok so to further explain this requirement, early versions of the spec 
> talked about dumping similar resources into buckets or "collections" - 
> e.g. /compute, /storage, /network. The problem is that the web today 
> doesn't tell you that images need to live in /images (even if they 
> often do). Once you add the type of resource to its metadata you no 
> longer need to encode it into the URL (which is fugly btw, and not 
> particularly RESTful) and the result is that users have much more 
> freedom as to how they lay out their resources.
>
> Unfortunately many APIs restrict you to certain (generally legacy) 
> terminology like "virtual data centers" and "virtual racks" which is 
> something I very much wanted to avoid - even if only to be able to 
> cater for the various perspectives on this issue rather than 
> (unsuccessfully) trying to force our view down everyone's throats.
>
> That is to say that said URLs are informative rather than normative, 
> and perhaps even belong in the walkthrough. I was thinking more along 
> the lines of:
>
> http://cloud.example.com/us-east/webapp/web02
>
> For a burnt-in hypervisor this might be simply:
>
> http://node01/web01
>
> Sam
>
> On Fri, Oct 9, 2009 at 5:33 AM, Michael Behrens 
> <michael.behrens at r2ad.com <mailto:michael.behrens at r2ad.com>> wrote:
>
>     For paragraph 2.2 Basics, under the URL Namespace paragraph, is this the sort of
>     table desired/accurate?
>
>     The following table is a list of recommended URLs and their purpose:
>     http://example.com/<myresource/compute <http://example.com/%3Cmyresource/compute>		Define and configure machines
>     http://example.com/myresource/network		Network configuration
>     http://example.com/myresource/storage		Storage services (SANs, etc)
>     http://example.com/myresource/application	Application control
>         
>
>     -- 
>     Michael Behrens
>
>         
>
>
>     _______________________________________________
>     occi-wg mailing list
>     occi-wg at ogf.org <mailto:occi-wg at ogf.org>
>     http://www.ogf.org/mailman/listinfo/occi-wg
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>