On Wed, Jun 28, 2006 at 11:24:53AM -0400, Sean Dague wrote:
> 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 glad ;-) We look forward to getting this out as an open specification so
that guys like you can get cracking on it!
> 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.
I'll have a think about this. To address the large-scale issue, the intention
is that OVAs can include answers to interactive questions, which the sysadmin
would specify once before rollout. A "preinstaller" tool would take the OVA
and tweak it as specified by the sysadmin to match the cluster. Of course,
OVA authors ought to be made aware that customers are always going to welcome
a non-interactive install than an interactive one.
> 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.
Rather than adding more XML tags, and turning into Apache Ant, I'd like to
specify a script library, required to be present in all installers, and
available to all OVAs. If we get these scripts right, then the effect should
be the same, as far as OVA authors are concerned, but the DTD for the ova.xml
isn't enormous. Your example would turn into:
<script name="fix-ntp" script="library/property-replacer">
<param>/etc/ntp.conf</param>
</script>
> 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.
The script will have the whole filesystem available as (for example)
/var/lib/ova/fs/crm-root -- the install script can mount and edit those
filesystems however they wish.
> 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.
Yes, they are non-interactive -- I'll put that in the spec, thanks. The
scripts themselves are running in a separate VM from the installer, so there's
not a lot to interact with ;-)
> Discussion welcomed. I'm very keen on helping this proposal mature and
> become an open standard.
Looking forward to it!
Ewan.
signature.asc
Description: Digital signature
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home