[occi-wg] OCCI specification document

Lars Larsson larsson at cs.umu.se
Mon Aug 17 02:24:04 CDT 2009 

Dear Sam,

thank you for your replies (especially since you're posting 
while on vacation!). I hope that some of the clarifications can 
be written in the spec itself as well.

The topic of moving resources interests me greatly. Where can I 
find information on what was discussed during that telco? I 
can't find a link in the Concall page[1] at the Wiki (and, by 
the way, it appears that the last few concalls are missing 
notes).

Best regards,

-- Lars

[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/TeleconferenceCalls

On Fri, 14 Aug 2009, Sam Johnston wrote:

> 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
>>
>

More information about the occi-wg mailing list