Ben, Sam, On Fri, May 8, 2009 at 12:20 AM, Sam Johnston <samj@samj.net> wrote:
On 5/8/09, Benjamin Black <b@b3k.us> wrote:
On Thu, May 7, 2009 at 3:45 PM, Sam Johnston <samj@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