[occi-wg] Syntax for attributes on links

[Alexis Richardson]

Ben, Sam,

On Fri, May 8, 2009 at 12:20 AM, Sam Johnston <samj at samj.net> wrote:
> On 5/8/09, Benjamin Black <b at b3k.us> wrote:
>> On Thu, May 7, 2009 at 3:45 PM, Sam Johnston <samj at samj.net> wrote:
>>
>>>
>>> We were talking before about all URLs appearing in the protocol, ...
>>
>> Can you point me to the requirements you've written up for this?
>
> The requirement to link compute, storage and network resources
> together is obvious is it not? Our requirements for migrating and
> shared resources are obvious too but could probably afford to be
> committe to digital ink if they're not already in the wiki.

It's not obvious to me :-)

It would be very good if you could put anything like this in a
suitable page of the wiki.



>> There have (unsurprisingly) been public and private calls to rubber
>>> stamp various APIs but each have their benefits and drawbacks and
>>> we're trying to pick out the best parts. Single entry points,
>>> discovery, controllers and some of the structure came from Sun^W
>>> Oracle Cloud APIs already... the main thing that hasn't (yet) come
>>> across is JSON.
>>>
>>
>> Please refrain from putting words in my mouth.  I am not asking that work be
>> rubber stamped, I am asking that work be adopted as a basis for further
>> work, rather than recreating large portions of it.  Once again, the question
>> goes unanswered.

Ben,

Let me have a go at this one.

When we started this work we were excited by the similarity of the
frameworks people had evolved for their cloud APIs.  See:
http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ

We were all certainly very impressed by the Sun API work.  But I
personally would prefer to hear the Sun design decisions advocated by
someone who understands them in full, which is why I am really pleased
to see Tim B on here.  We need these voices and they don't all arrive
at once.

Leaving aside any licensing questions, which I am sure are easily
solved, the Sun API would IMO be a great "basis" for further work in
the sense that I think you mean.  But I think that for this process to
work then other cloud APIs must also be a basis.  Here I am especially
thinking of GoGrid and ElasticHosts from the service provider side, as
well as work from the OGF community as represented by for example
OpenNebula.  I name these because they are all willing to engage in a
dialogue about their APIs in public.  I'd be happy with something that
was:

a) common
b) open
c) consistent with the aims of those providers

And I would be elated if we also could say:

d) pleasing to a community of end users

I think it is also important to hear from people who are not providing
cloud technology and I like it that Sam has put work into rallying
some of these voices and backing them up with drafts on the wiki.  I'm
not sure if you are currently in the user or provider group, but in
either case please keep contributing.

Do you think it is possible to talk about a common API that has as its
basis the four sources of work I described above, and satisifies a
community of users that is potentially larger than, say, the current
users of any one API?

I think it is.  We made a good start in terms of consensus on the
nouns and verbs at least.

I also think Sam has some good ideas that are worth exploring - for
example the role of feeds, and the role played by Google in the
cloudscape.  I'd like hear more about both of these lines of thought.
But preferably not in such a way that all the issues become entangled
into one.

With regard to the formats issue: we all currently disagree.  That is
ok.  We do need to hammer out a proper requirements list.  It may be
that we have a requirement that pushes us outside the JSON envelope so
to speak.  E.g.: we have talked about playing nicely with OVF and SNIA
and this is certainly part of the spirit of the OCCI charter.  So we
need to work out what that all means and how it may apply in practice.
 I'd like to hear as much as possible about the requirements from Sam
and from others eg Mark M.

I do think that a JSON advocate could very helpfully put some info on the wiki.


> Ok so the attributes will be reviewed against our registry before
> long... already things like "operating system" will likely be added.
> The virtual datacenter structure for both Sun and VMware is too rigid
> for my liking and I'm hoping categories and tags can cover this
> requirement adequately and flexibly. Aside from that we've already
> taken a good deal of inspiration from this source and tim's excellent
> blog post on the subject. Was there something else you wanted us to
> take on board?

Sam, thanks for this.  If you have a moment please could you set out
some requirements in a priority list, so that we can consider them in
isolation?  Happy to wait until after you are back from the weekend...

alexis