[occi-wg] Scheduling parameters
samj at samj.net
Tue Apr 14 07:24:34 CDT 2009
On Tue, Apr 14, 2009 at 2:09 PM, Andre Merzky <andre at merzky.net> wrote:
> > I have spent a large chunk of my weekend
> >  roughing up the API and rather than bundling everything in together
> > have so far opted for a core + extensions approach.
> > ...
> > 
> 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!).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the occi-wg