On Thu, Jun 22, 2006 at 02:30:52PM +0100, Ewan Mellor wrote:
> Attached is a preview of the Open Virtual Appliance specification. We've been
> working on this for a little while now, and it's ready to open up to wider
> discussion and collaboration.
>
> The intention here is to produce a transport format for a Virtual Appliance --
> a collection of virtual machines that together, from the customer's point of
> view, provide a single useful facility.
>
> This document has a restrictive licence and disclaimer, which we've put on
> whilst it is being reviewed. When released, the document and the
> specification will have some form of free document licence, possibly the GNU
> FDL, with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
> Texts.
>
> Your comments are more than welcome.
>
> Ewan.
Ewan,
I spent some time reading the spec yesterday, and have some comments /
questions on it, mostly on the customization side. Before I get started,
I'd have to commend you and Andrew at taking a very reasonable stab at this
problem, and I like where this is headed. :) Most of the document is
straight up sensible to me, so I'll only focus on the areas that I think
need some more thought or other approaches.
I'm not very keen on the <prompt> model that is laid out. What I think
that leads to is an overuse of trying to get interactive user input at
deploy time. This causes the solution to be less useful on large scale roll
out, as interactive user input doesn't scale.
Instead I'd suggest moving most of the prompt attributes into the
<properties> tag. Properties would specify all the meta information around
them, and if someone really wanted to create an interactive element to them,
they could still do it, but it wouldn't imply that was the way to address
the problem.
On the scripts side, while it is good to have arbitrary script running to
accomplish anything, one of RPMs failings is the fact that a lot of what
happens in there is pretty repetitive, and it would have made sense to make
some common operations.
For instance, on the ntp-server prompt-values it would seem to have
something like:
<replace>
<file name="/etc/ntp.conf" fs="crm-root" property="ntp-server"/>
</replace>
This would tell the processor that crm-root's /etc/ntp.conf may be tagged as
so:
...
# server clock.via.net
server %!% ntp-server %!%
...
And that the ntp-server value should be replaced. (All syntax is mutable at
this point, but it seemed like a concrete example would be helpful.)
As some large percent of scripts are probably doing file modifications,
explicitly creating a call out for that would probably be good.
From the script perspective it seems that only a very small amount of the
root ends up writable (unless I am reading it wrong), which means
modifications to /etc don't seem like an option. Did I miss something, or
was that intentional.
Also, is there an edict that scripts are non interactive? That has been RPM
policy for a long time, and it makes automating processes much easier. I'd
really suggest that it also end up as policy in this spec.
Discussion welcomed. I'm very keen on helping this proposal mature and
become an open standard.
-Sean
--
Sean Dague
IBM Linux Technology Center email: japh@xxxxxxxxxx
Open Hypervisor Team alt: sldague@xxxxxxxxxx
pgp9xLmKIwhry.pgp
Description: PGP signature
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home