[occi-wg] OCCI specification document
Andre Merzky
andre at merzky.net
Fri Aug 14 04:41:51 CDT 2009
Quoting [Sam Johnston] (Aug 14 2009):
>
> Everything, by virtue of having a URL, has a globally unique
> identifier.
file://localhost/etc/passwd is a URL, but not globally
unique (DNS is not globally unique). Same for
file://10.0.0.1/etc/passwd
I guess this does not matter to us, but anyway...
Andre.
> 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:
> >
> > [2]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)
> > [3]http://blogs.sun.com/intheclouds
> > [4]http://www.twitter.com/befreax
> > Software Engineer Cloud, Grid and Virtualization
> > Sun Microsystems GmbH
> > Dr.-Leo-Ritter-Str. 7 mailto:[5]thijs.metsch at sun.com
> > D-93049 Regensburg [6]http://www.sun.com
> >
> > _______________________________________________
> > occi-wg mailing list
> > [7]occi-wg at ogf.org
> > [8]http://www.ogf.org/mailman/listinfo/occi-wg
> >
> _______________________________________________
> occi-wg mailing list
> [9]occi-wg at ogf.org
> [10]http://www.ogf.org/mailman/listinfo/occi-wg
>
> References
>
> 1. mailto:larsson at cs.umu.se
> 2. http://forge.ogf.org/sf/go/doc15731?nav=1
> 3. http://blogs.sun.com/intheclouds
> 4. http://www.twitter.com/befreax
> 5. mailto:thijs.metsch at sun.com
> 6. http://www.sun.com/
> 7. mailto:occi-wg at ogf.org
> 8. http://www.ogf.org/mailman/listinfo/occi-wg
> 9. mailto:occi-wg at ogf.org
> 10. 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
--
Nothing is ever easy.
More information about the occi-wg
mailing list