On Fri, Aug 14, 2009 at 10:49 AM, Lars Larsson <larsson@cs.umu.se> wrote:
- Page 2 states that it is trivial to translate between wire formats. It then gives an example in the "text" format. Could the translation to e.g. XML (Atom) be shown as well? This would clear up how one would go about posting e.g. a Create request using something else than the HTTP Form encoding, as show on Page 3.
There are two types of interactions: - retrieving representations (e.g. OVF or our own descriptor format), which use the usual GET/PUT/POST/DELETE semantics - doing stuff (e.g. start, stop, restart) which often requires more than just an empty POST (e.g. for stop/restart is that soft, hard, acpi off, cable pull, etc.) - html forms are best for these types of interactions as we don't need to define a new DSL & all clients have support built in OOTB. - Page 3 states that there are both global and local IDs, and
that resources should also have a UUID attribute. Is the local ID the same as the UUID, and the global one simply the URL (which includes the UUID)? Clarifications may be in order here, perhaps with an example.
Everything, by virtue of having a URL, has a globally unique identifier. However these are not immutable - perhaps the same resource will appear on a node as well as a gateway, or it will move between nodes throughout its lifecycle. Initially we spoke about embedding a uuid into the URL but for legacy purposes this was deemed a bad idea (e.g. most systems already have unique IDs). Simple fix for tracking resources is to allocate them a random (v4) UUID which is immutable... this is the same as what VMware do (and why they ask you if you want to keep the same UUID - eg if the machine was moved - or generate a new one - eg if the machine was copied).
- Page 3 also states that the resource may be moved by an implementation to some other implementation. If so, it is according to the text permissible to not know the new URL for the resource. How will the user find out about this new URL, if she is given a HTTP 410 Gone message by the site she submitted the resource to?
The semantics of moving resources was discussed on this week's call. However we define the API it will be possible for: - one cloud to enumerate and render the resources of another (eg pull) - one cloud to create resources on another (eg push) The use case we haven't yet catered for (but are looking at HTTP COPY and MOVE as defined by WebDAV) is where you have a remote client (eg an iPhone app) that wants to send instructions to migrate without handling the 1's and 0's itself.
- On Page 4, given the presence of "Requests", it is not clear to me what should be considered an "Update" or a "Request". Is there a semantic difference between the two, and if so, what is it?
It makes sense for us to separate out any descriptor format so as to resolve such confusion. Requests are things like state changes (think of them as jobs or tasks if you like) - things that may happen immediately, later, on some schedule, etc.
- Page 6, at the "DELETE" operation, there is a note that everything "under" a resource is deleted. What does this mean, specifically?
Currently each resource has collections of e.g. interfaces/devices, requests, etc. - if you delete the resource then those things that are associated with it no longer make sense.
- On Page 6, Collections are mentioned, and that they will be rendered as Atom feeds. Are collections (as Atom feeds) to be accepted as input to some/all operations? Could examples of this be presented in that case?
That was originally the idea but there was some stiff opposition to Atom and XML in general so it was relegated to collections so as to avoid creating another DSL. Making everything reconcile without the benefit of the atom specification is what is taking most of the time at the moment (e.g. writing the HTTP Category header draft).
Please note that collections as input, and the related collections as output will require some special handling, since the Atom specification does not consider the Entries in a Feed to be ordered. Thus, the mapping from the output Entries to the input Entries must be made clear in the output.
Each entry has at least one unique identifier (the URL) so order is not important, except in terms of dependencies. Again, without the benefit of Atom feeds you then have to look to stateless HTTP for transactions which is a huge PITA (albeit one with potential, if convoluted, solutions).
- Page 6 has an overfull hbox (in LaTeX terms, in English "text too long to fit on the paper") in the example, which makes reading the example impossible. Please fix!
Apologies - we'll certainly fix the formatting as the document matures. There are HTML and DocBook versions if the PDF version is inconvenient. - On Pages 8 -- 10, it is unclear how most of the attributes
will be mapped to Atom (starting with Section 4.4.4 "Status" and onward). What should be elements, and what should be attributes? The information needs to be represented somehow, and mappings to Atom Entry elements is not defined. Thus, they must be defined by the OCCI.
Yes, and GData provide a good example for how to do this. The problem is making it reconcile with the other formats without trying to map Atom to JSON, text and whatever other renderings people want to use (eg protocol buffers).
- Monitoring is supposed to be supplied as an OCCI extension, but there is a set of attributes for reporting status on Page 8. How does the client get such status reports, and is monitoring intended to work in the same way?
This is definitely a work in progress... the idea was to specify a mechanism in core and expose it inline and/or via LINKs where relevant.
- Page 10 mentions the State machine, without presenting it. Perhaps it would be clearer to the reader if the state machine is included, given that the document describes how to alter the state of a (compute) resource?
This was discussed before but state machines tend to be quite religious and if the proposed state machine doesn't match your existing implementation you're in trouble. We obviously need to define some states but the rest will live in a registry.
On that note, what are the state machines for the other types of resources?
The state machine protocol will hopefully be sufficiently generic that it can be used with storage and network resources as well, plus any future work we do (e.g. PaaS, SaaS). I hope that at least partially answers most of your questions. I'm working on the spec actively at the moment (while on holidays in the south of france no less) so I hope some of these gaps will be closed soon enough. Sam
On Fri, 14 Aug 2009, Thijs Metsch wrote:
Hi @all,
The current version of the OCCI specification can be found here:
http://forge.ogf.org/sf/go/doc15731?nav=1
Please have a look with a special look on the attributes defined in the document? Are any missing? Are there to much? What about the naming?
We will be working on the document in the next days to push it further to get it done for OGF27. So more details and information to come. For now comments and ideas about the attributes are more then welcome!
All the best,
-Thijs
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg