[occi-wg] Issue 13
Michael Behrens
michael.behrens at r2ad.com
Sat Oct 10 20:44:49 CDT 2009
Will do.
----------------------------------------
From: Gary Mazz <garymazzaferro at gmail.com>
Sent: Saturday, October 10, 2009 1:35 AM
To: Michael Behrens <michael.behrens at r2ad.com>
Subject: Re: [occi-wg] Issue 13
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 : OCCI-STUFF
>> http://node04/web03 : OCCI-STUFF
>> http://node02/web04 : 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
>>> > 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/
>>> 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
>>> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091010/aa34eecf/attachment.html
More information about the occi-wg
mailing list