[occi-wg] OCCI specification document

Sam Johnston samj at samj.net
Fri Aug 14 04:26:56 CDT 2009 

On Fri, Aug 14, 2009 at 10:49 AM, Lars Larsson <larsson at 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 at sun.com
> > D-93049 Regensburg                  http://www.sun.com
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090814/1a3b1563/attachment.html

More information about the occi-wg mailing list