[occi-wg] Comments, Suggested Changes for Walkthrough

Wed Sep 30 11:19:58 CDT 2009

Hello,

We just manage running instances representations. We distinguish them
using the ID tag in the XML document, and also, as you say, using the
URL.

Please come back to us if this doesn't make sense to you.

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 4:30 PM, Alexis Richardson
<alexis.richardson at gmail.com> wrote:
> On Wed, Sep 30, 2009 at 2:56 PM, Tino Vazquez <tinova at fdi.ucm.es> wrote:
>> 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
>
> Great!  Thanks.
>
> How do you distinguish between the representation and the running
> instance?  Eg, if you start 2 VMs with one representation then are
> they distinguished?  And, if they are, then are they distinguished
> within the representation, eg <ID>123AF</ID>, or by the URL of the
> representation, eg http://www.opennebula.org/compute/123AF
>
> alexis
>
>
>
>
>
>
>> 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
>>>
>>
>