> I have spent a large chunk of my weekend
> [2] roughing up the API and rather than bundling everything in together
> have so far opted for a core + extensions approach.
> ...
> [2] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/APIDesign
Minor comments:
- I like the extension approach
Great! I was trying to come up with a way for us to have a minimalist core API (basically telling you how to find an end point, authenticate to it and interact with it) and then extend it where necessary. There's limitless possibilites for this architecture, though I've resisted the urge to list them for fear of being accused of trying to boil the ocean ;)
- do you intent to hook GLUE into the <Info> part in your
XML example, or into similar places in the API?
Optionally at least?
<Info>4Gb, 2 CPU, 1 disk, 2 nic virtual machine</Info>
That's actually embedded OVF - what specifically did you have in mind?
- why the purl.org/occi namespace? OGF has an established
namespace for XML schemata, see http://schemas.ogf.org/,
and GFD.84 on http://www.ogf.org/docs/?cp
purl.org gives us a simple way to collaboratively develop the namespace while allowing for third party extensions, but I'm not particularly religious about it - we can migrate once the API settles down if we decide that's the best thing to do.
A question about the machine control extension: I am not
overly familiar with the capabilities offerred by the
various discussed backends, but is a 'CLONE' operation
something which is being considered? That would be
basically a CREATE op which refers to a running instance
instead of reffering to an image and instance description
(or whatever your CREATE needs as input). How would that
map to your state machine? As suspend/resume (for the time
a snapshot is taken)? Similar for 'MIGRATE'...
So my thoughts so far were that templates would be exposed as "ghosts" that would be missing "start", "stop", etc. actuators, rather having only "deploy" (ala Sun Cloud API). "clone" to me sounds like taking a copy of something that exists rather than instantiating something that is abstract, though perhaps something like this would be useful for snapshotting (ultimately we're going to have to run through various clients and see what functionality we're missing).
Sorry if that question is off target...
Definitely not - it's great to see some discussion kicking off already (we're still in the process of officially announcing the working group!).
Sam