Will do.<br><br><font size="2" face="Tahoma, Arial, Sans-Serif"><hr size="2" width="100%" align="center"><strong>From</strong>: Gary Mazz &lt;garymazzaferro@gmail.com&gt;<br><strong>Sent</strong>: Saturday, October 10, 2009 1:35 AM<br><strong>To</strong>: Michael Behrens &lt;michael.behrens@r2ad.com&gt;<br><strong>Subject</strong>: Re: [occi-wg] Issue 13</font><br><br>Hi Michael,<br><br>Can you put item 13 in a deferred  (if that's possible) ?  I would like <br>to revisit this issue in the next draft.<br><br>-g<br><br>Michael Behrens wrote:<br>&gt; I'm fine with closing issue 13 then.  I think the material is covered <br>&gt; in 2.2 Getting Started and in table 4.<br>&gt; It may be good to replace /compute/123 in other parts of the <br>&gt; specification with /node123 to avoid confusion.<br>&gt; Thanks.<br>&gt;<br>&gt; Gary Mazz wrote:<br>&gt;&gt; Sam,<br>&gt;&gt;<br>&gt;&gt; Are you saying you are changing the concepts of buckets ? for an <br>&gt;&gt; ambiguous URL path ?  where the management of the path is out of <br>&gt;&gt; scope and control of occi api ? . So in the case of this <br>&gt;&gt; configuration from the same provider:<br>&gt;&gt; http://node01/web01: OCCI-STUFF<br>&gt;&gt; http://node03/web02 <http: node01="" web01="">: OCCI-STUFF<br>&gt;&gt; http://node04/web03 <http: node01="" web01="">: OCCI-STUFF<br>&gt;&gt; http://node02/web04 <http: node01="" web01="">: OCCI-STUFF<br>&gt;&gt;<br>&gt;&gt; We do not have a way of aggregating those "nodes" in  the occi <br>&gt;&gt; interface. The reason for the buckets following the domain name and <br>&gt;&gt; socket number was to eliminate the requirement for  this type of <br>&gt;&gt; additional management complexity, at least for the first draft of the <br>&gt;&gt; occi spec. I was an advocate of a more flexible scheme from the <br>&gt;&gt; beginning, I'm not sure if its wise to change this without a <br>&gt;&gt; management api.<br>&gt;&gt;<br>&gt;&gt; -gary<br>&gt;&gt;<br>&gt;&gt; Sam Johnston wrote:<br>&gt;&gt;&gt; Ok so to further explain this requirement, early versions of the <br>&gt;&gt;&gt; spec talked about dumping similar resources into buckets or <br>&gt;&gt;&gt; "collections" - e.g. /compute, /storage, /network. The problem is <br>&gt;&gt;&gt; that the web today doesn't tell you that images need to live in <br>&gt;&gt;&gt; /images (even if they often do). Once you add the type of resource <br>&gt;&gt;&gt; to its metadata you no longer need to encode it into the URL (which <br>&gt;&gt;&gt; is fugly btw, and not particularly RESTful) and the result is that <br>&gt;&gt;&gt; users have much more freedom as to how they lay out their resources.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Unfortunately many APIs restrict you to certain (generally legacy) <br>&gt;&gt;&gt; terminology like "virtual data centers" and "virtual racks" which is <br>&gt;&gt;&gt; something I very much wanted to avoid - even if only to be able to <br>&gt;&gt;&gt; cater for the various perspectives on this issue rather than <br>&gt;&gt;&gt; (unsuccessfully) trying to force our view down everyone's throats.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; That is to say that said URLs are informative rather than normative, <br>&gt;&gt;&gt; and perhaps even belong in the walkthrough. I was thinking more <br>&gt;&gt;&gt; along the lines of:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; http://cloud.example.com/us-east/webapp/web02<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; For a burnt-in hypervisor this might be simply:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; http://node01/web01<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Sam<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On Fri, Oct 9, 2009 at 5:33 AM, Michael Behrens <br>&gt;&gt;&gt; <michael.behrens@r2ad.com><mailto:michael.behrens@r2ad.com>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;     For paragraph 2.2 Basics, under the URL Namespace paragraph, is <br>&gt;&gt;&gt; this the sort of<br>&gt;&gt;&gt;     table desired/accurate?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;     The following table is a list of recommended URLs and their <br>&gt;&gt;&gt; purpose:<br>&gt;&gt;&gt; http://example.com/<myresource compute=""><br>&gt;&gt;&gt; <http: example.com="" %3cmyresource="" compute="">        Define and <br>&gt;&gt;&gt; configure machines<br>&gt;&gt;&gt; http://example.com/myresource/network        Network configuration<br>&gt;&gt;&gt; http://example.com/myresource/storage        Storage services (SANs, <br>&gt;&gt;&gt; etc)<br>&gt;&gt;&gt; http://example.com/myresource/application    Application control<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;     --     Michael Behrens<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;     _______________________________________________<br>&gt;&gt;&gt;     occi-wg mailing list<br>&gt;&gt;&gt; occi-wg@ogf.org <mailto:occi-wg@ogf.org><br>&gt;&gt;&gt; http://www.ogf.org/mailman/listinfo/occi-wg<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; ------------------------------------------------------------------------ <br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; occi-wg mailing list<br>&gt;&gt;&gt; occi-wg@ogf.org<br>&gt;&gt;&gt; http://www.ogf.org/mailman/listinfo/occi-wg<br>&gt;&gt;<br>&gt;&gt;<br>&gt;<br>&gt;<br><br><br></mailto:occi-wg@ogf.org></http:></myresource></mailto:michael.behrens@r2ad.com></michael.behrens@r2ad.com></http:></http:></http:>