I put in quite a few hours this week slaving over a hot Wiki, and the results are reflected in a bunch of revisions to the Sun Cloud API spec.
As always, if you’re new to this, the best place to start is with the “Hello Cloud” walk-through.
The biggest changes are those discussed earlier in
Slow REST; when you
change the state of a cloud, it can take a long unpredictable time, so instead
of coming back with
200 OK or
201 Created, all
updates come back with
202 Accepted and give you a
resource whose URI you can poll to see how things are going.
There is lots of room for argument about the details, but we’re pretty convinced that this is going prove a saner programming model for people who want to build reliable cloud clients.
No More Deploys · Earlier revs of the spec had the notion that you would make a bunch of changes to your cloud config, but they wouldn’t take effect, they’d just be in your “model”; then you’d use a “deploy” operation to put them all into effect.
It sounded good in theory, but people who tried to use it found it nightmarish in practice. So as of now, all the “model_status” fields and “deploy” controller URIs are gone.
This doesn’t mean that everything you do has instant effect. For example, there are a few things you can change on a Virtual Machine that won’t take effect until you rebot. Thus, the Virtual Machine model has a new field “updated” which if true says that there are changes pending.
Cloud Standards: More is Better · Which is a good thing, because are there ever a lot! Here at Sun, we’re just trying to build The Simplest Thing That Could Possibly Work. And remember, it’s Creative-Commmons-licensed in a way that means whoever can do whatever with it.
PS: How To Edit a Wiki · When you have to make a lot of big changes, I mean. Hit “edit this page”, copy the wikitext into an Emacs buffer, do the work there, then copy it back into the Wiki. Only way to stay sane IMHO.