[occi-wg] Is OCCI the HTTP of Cloud Computing?

Tue May 12 04:36:00 CDT 2009

Morning Gary,

On Tue, May 12, 2009 at 10:24 AM, Gary Mazz <garymazzaferro at gmail.com>wrote:

>
> I like Tim's explanation.
>
> I have some on  some trivial subjects...
>
> 1) Are we also talking about using IRIs or URIs only ?

There was some discussion about this before with Ben Black - Atom IDs are
not meant to be dereferenceable so for simplicity (especially w.r.t.
concurrency and migration/merging of resources safely) there was an earlier
decision to use version 4 (random) UUID
URN<http://en.wikipedia.org/wiki/Uniform_Resource_Name>s
for the IDs. There was then some contention as to whether link relations
should specify the URN of the target resource or a dereferenceable URI... I
prefer the former (bearing in mind that the same resource can appear at
multiple endpoints, dereferenceable URIs are easily created and working
internal document references are useful) while Ben prefers the latter. These
and related topics probably need further discussion re: pros and cons down
the road.

> 2) What is the thoughts on handling foreign markups at endpoints and
> gateways/bridges ?

Foreign markups should/must not be touched (not sure which requirement level
to use here) as this is the basis of much of our extensibility.

> 3) How are the scheme attributes handled for child element when
> presented without the parent element that has the scheme assignment ?

Elaborate - not sure what you mean here.

> 4) Can we publish work spaces ? Will work spaces require authorization?

Workspaces are neither required nor supported by Google's GData
implementation so there is good reason to believe that we won't need them.
If the use case doesn't exist then I'd opt for the simplicity of excluding
them from the spec.

> 5) Will there be top level resources be defined? or will each vendor
> define their own resources schemes?  How do we preserve proprietary
> technology?

We need to define this, at least at a high level, for interoperability. So
far I had made provision for three top level categories (compute, storage
and network) or "types" (what Google call "kinds").

> 6) How are document writers/editors defined and authorized ?

Out of scope - I'm not even sure we need to specify how they are
authenticated (though I have a whitelist on the Resources page already if we
take an interest in this). Authorisation can range from none (simple XML
file on embedded web server) to fine grained/field level, depending on the
implementation. I'm expecting this to be an area where implementors can
differentiate themselves.

> 7) Will there be document caching/synchronization policies and schemes ?

Google have used ETags with good
results<http://globelogger.com/2008/11/gdata-now-compliant-with-atompub.html>,
and this makes a lot of sense given much of the work for clients will be
keeping their view of the world in sync with reality. Being able to crank up
a desktop client and have it display a large number of [cached] resources in
seconds even over a modest link becomes a reality with this approach - and
web based third-party services like RightScale have similar needs.

> 8) How are collection components authorized ? Private/authorized partial
> lists in collection of public lists ?

See above - two different users looking at the same endpoint may or may not
see different things depending on which resources they are authorised to
see. Public cloud offerings may have many millions of resources at a single
endpoint but your average user will only see a small handful, while an
enterprise setup may have all authenticated users seeing the same thing. I
don't see much point in trying to burn any of this into the standard.

> 9) What are the policies for conformance levels? Will occi define our own ?

Possibly, though I would prefer to keep the core simple and require everyone
to implement it fully and faithfully.

> 10) What will the policy be for non-IANA content ?
>

I'm guessing by this you mean Internet media
types<http://en.wikipedia.org/wiki/Internet_media_type>that are not
defined by IANA, in which case we have the usual x-, vnd. and
prs. namespaces available.

> Sorry for the long list..
>

No problem - the more detailed the discussion the better the result.

Sam

> Tim Bray wrote:
> > On May 11, 2009, at 1:54 PM, Sam Johnston wrote:
> >
> >
> >> The ideal core protocol would contain no references to
> >> infrastructure, rather allow manipulation of resources (CRUD,
> >> linking, actuators) irrespective of what the resource was. It would
> >> thus be reusable for any resource (as Google have done for 16
> >> different services and who knows how many different resource types
> >> already with GData).
> >>
> >
> > Odd though it may seem, until I saw this I didn't grok what Sam was
> > proposing.  Maybe I still don't, but let me take a guess:
> >
> > You're focusing not so much Atom the RFC4287 data format, but AtomPub
> > the RFC5023 publishing protocol as implemented notably in GData and
> > lots of other places, and do generic Web-resource CRUD where the
> > resources happen to represent cloud infrastructure objects.  Thus you
> > outsource most of the work of CRUD specification.  Then, you layer
> > cloud-specific stuff on top of that.  Then collections of servers and
> > clusters and networks and so on are perforce represented as Atom Feeds.
> >
> > Is that the essence of it?  -Tim
> > _______________________________________________
> > 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/20090512/c8e8f073/attachment.html 