[occi-wg] Issue 13

[Gary Mazz]

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.

-g

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
>>
>>
>
>