[occi-wg] Comments, Suggested Changes for Walkthrough

Tino Vazquez tinova at fdi.ucm.es
Wed Sep 30 08:56:14 CDT 2009 

Hi there,

OpenNebula OCCI implementation does not uses management verbs. In
turn, it uses the VM representation to update the state via a PUT HTTP
verb. So

* Start a VM with template T: Is POSTing a COMPUTE representation to
the COMPUTE POOL
* Start 2 VMs with template T: Is POSTing it twice
* Stop one or both of them: Is getting the representation and change
it to reflect the STOP state and PUTting them back to the COMPUTE
resource

Regards,

-Tino

--
Constantino Vázquez, Grid Technology Engineer/Researcher:
http://www.dsa-research.org/tinova
DSA Research Group: http://dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org



On Wed, Sep 30, 2009 at 1:22 PM, Alexis Richardson
<alexis.richardson at gmail.com> wrote:
> Hi all,
>
> If Open Nebula have implemented OCCI then it would be great to see
> details from them on the VM lifecyle management verbs.
>
> * Start a VM with template T
> * Start 2 VMs with template T
> * Stop one or both of them
>
> alexis
>
>
>
>
> On Wed, Sep 30, 2009 at 12:18 PM, Edmonds, AndrewX
> <andrewx.edmonds at intel.com> wrote:
>> Hi all,
>> I've gone through the walk through and have a list of comments and suggested
>> changes. I will be continuing on through the spec with a similar intention
>> of contributing comments and suggested changes.
>>
>> Thijs, if you like I can add these to the tracker unless you want to
>> pre-process them?
>>
>> I do not suggest discussing any of these via the mailing list. That
>> discussion can happen via the issue tracker.
>>
>> Andy
>>
>>
>> * General
>>    * Would be useful to introduce the notion of OCCI extensions in the walk
>> through
>>    * A page break should be inserted to separate the walkthrough and "OCCI
>> Core Specification"
>>    * Revise usage of brackets
>>
>> * Paragraph 4 "resource or type of resource"
>>    * what's the difference here?
>>
>> * Paragraph 4 "and search"
>>    * note that this is an extension and may not be supported in all
>> implementations
>>
>> * Paragraph 5 Bracket usage in the sentence "Certain types of accesses..."
>>    * would read better as: Certain types of accesses, such as a compute
>> resource querying OCCI for introspection and configuration, may be possible
>> anonymously in the case where the query has already been authenticated by
>> interface and/or IP address.
>>
>> * Paragraph 6 "Should you be redirected by the API to a node, storage
>> device, etc. (for example, to retrieve a large binary representation) then
>> you should either be able to transparently authenticate or a signed URL
>> should be provided."
>>    * If the basic authentication is not cached then this transparent
>> authentication will not happen. Is what I say a correct statement?
>>
>> * Paragraph 6 "(at least not yet!)"
>>    * Remove this, not necessary.
>>
>> * Paragraph 6 "and while OCCI standardises a number of them for
>> interoperability"
>>    * We can only recommend other standards for use in OCCI not standardise
>> them - that's the responsibility of the relevant standards body
>>
>> * Paragraph 6 List of representations
>>    * I do not agree that a screenshot or access to console is an appropriate
>> general entity representation like what OVF/OVA are. These items are more
>> suitable as attributes in an entity representation (OVF/OVA/OCCI). Suggest
>> removing or noting that they are lesser forms.
>>
>> * Paragraph 7 "The client indicates which representation(s) it desires by
>> way of the URL"
>>    * An example illustrating this might be useful e.g.
>>    * To request a HTML rendering, if supported, of a compute node issue
>> http://example.com/path/to/compute/resource/123-123-123.html
>>    * The same might be for the content negotiation.
>>
>> * Paragraph 8 "In addition to the protocol itself,"
>>    * Remove the protocol includes interaction semantics, syntax and data
>> schemas.
>>
>> * Paragraph 8 "In addition to the protocol itself, OCCI defines a simple
>> key/value based descriptor format for cloud infrastructure resources:".
>>    * Reword to: "OCCI defines a simple key/value based descriptor format for
>> cloud infrastructure resources. These infrastructure resources as defined by
>> OCCI are:".
>>
>> * Paragraph 8 Formatting
>>    * Embolden compute storage and network - these are core concepts to OCCI.
>>
>> * Paragraph 9 Comment
>>    * If we say that it is trivial to translate and present an example that
>> example should show the trivial translation. In this case we should add the
>> XML and JSON examples.
>>
>> * Paragraph 10 Starting "The primary drawback is that" ending "or HTTP 410
>> Gone otherwise)."
>>    * Is this necessary here -  might be better moved out of the walkthrough
>> to elsewhere or just removed.
>>
>> * Paragraph 10 Comment
>>    * Bracket usage should be reviewed.
>>
>> * Paragraph 12 "UUIDs anyway"
>>    * Remove "anyway".
>>
>> * Paragraph 12 "used instead (e.g. http://amazon.com/compute/ami-ef48af86)."
>>    * Any significance using this URL - better we use something fictional
>>
>> * Paragraph 12 "can be safely allocated by any node"
>>    * What's a "node"? A resource? A resource manager?
>>
>> * Section 2.3 Comment
>>    * A brief introduction should be inserted here.
>>
>> * Paragraph 13 "POST it to"
>>    * What is "it"? Explicate.
>>
>> * Paragraph 13 "as an HTML form"
>>    * More correct to say "POST the attributes and values using the
>> application/x-www-form-urlencoded format"
>>
>> * Paragraph 15 "to GET a template"
>>    * New concept introduced with no explanation. Explain briefly (footnote?)
>> or drop and move discussion elsewhere in doc.
>>
>> * Paragraph 15 "POST or PUT it back"
>>    * There are semantic differences here that should be noted to the reader.
>>
>> * Paragraph 17 P18 Comment
>>    * It would make more sense to inform the user how to get a list of
>> supported renders per provider first and then tell how to request it. As it
>> initially reads it appears that 2 calls are needed.
>>
>> * Paragraph 19 "There are two options:"
>>    * Better phrased as "There are two concepts that are supported"
>>
>> * Paragraph 19 "such as searches"
>>    * Change to "such as the collections returned from the search extension"
>>
>> * Paragraph 19 Pass-by-ref, pass-by-value
>>    * This is more a metaphor -  might be worth explaining what is meant by
>> these explicitly, otherwise the reader is left to interpret.
>>
>> * Paragraph 20 "Update"
>>    * It says to PUT but I can also update via POST and be naughty.
>>
>> * Paragraph 22 Comment
>>    * What about "Resource Child Collections".
>>
>> * Paragraph 22 Comment
>>    * These are in effect extensions to the core and so should be noted as
>> such.
>>
>> * Paragraph 24 "Requests"
>>    * Just a comment - isn't this very RPC-like something that REST aims to
>> avoid?
>>
>> * Paragraph 24 "Requests"
>>    * A number of request types are mentioned but nowhere in the spec are
>> they detailed.
>>
>>
>> Andy Edmonds
>> skype: andy.edmonds
>> tweets: @dizz
>>
>>
>>
>>
>> -------------------------------------------------------------
>> Intel Ireland Limited (Branch)
>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>> Registered Number: E902934
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> 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
>

More information about the occi-wg mailing list