[occi-wg] Issue 13

[Michael Behrens]

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


-- 
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell)
(703) 714-0442 (land)