[occi-wg] Comments, Suggested Changes for Walkthrough
Alexis Richardson
alexis.richardson at gmail.com
Wed Sep 30 11:21:32 CDT 2009
Thanks. One last question:
On Wed, Sep 30, 2009 at 5:19 PM, Tino Vazquez <tinova at fdi.ucm.es> wrote:
> 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.
Must both identifiers be the same and if then should that be mandatory
for all OCCI impls?
> 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
>>>>
>>>
>>
>
More information about the occi-wg
mailing list