[occi-wg] Issue 13

Gary Mazz garymazzaferro at gmail.com
Sat Oct 10 00:34:51 CDT 2009

Hi Michael,

Can you put item 13 in a deferred  (if that's possible) ?  I would like 
to revisit this issue in the next draft.


Michael Behrens wrote:
> I'm fine with closing issue 13 then.  I think the material is covered 
> in 2.2 Getting Started and in table 4.
> It may be good to replace /compute/123 in other parts of the 
> specification with /node123 to avoid confusion.
> Thanks.
> Gary Mazz wrote:
>> 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

More information about the occi-wg mailing list