[Xen-API] Re: Open Virtual Appliance preview

[Sean Dague <japh@xxxxxxxxxx>]

On Wed, Jun 28, 2006 at 04:49:13PM +0100, Ewan Mellor wrote:
<snip>
> > 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!

Any ETAs on that? ;)

> > 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.

One of the things I think that will make OVA successful is if there is a
seperation between the What and the How, and leave the How up to someone
else.

In the current form you specify both "what" as properties, and "how" to fill
them in as prompts.  This already starts to dictate implementation, which
builds more assumptions into the model, and less flexibility.  If you just
specify "what" needs to be filled in, and leave the rest as an exercise to
the user, I think it is a better approach.
 
> > 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>

So, again, it is "what" vs. "how".  If we know there needs to be file level
replaces with a <replace> stanza, many people can write different ways that
fulfill that.  Which means you could have a perl solution on Linux/UNIX, and
a C# solution on Win32, and a Objective C solution on Mac OSX.  

If you go down a standard script route, then you'll be limitting platforms
that this supports, as how is presuposed, and you'd really need to also add
exact behavior of those scripts into the spec.

I think that anything which happens often enough to get a "standard script",
should really get a set of standard tags instead, and an example standard
script could be provided.  This will allow complete replacement of the
standard script if there were specific needs by the end user (like small
memory contraints, or some platform specific features).

> > 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.

Ok, I saw that only /mnt, /tmp, and some /var dirs were mounted.  Perhaps
the wording could be cleaned up there to make ti more clear.

> > 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 ;-)

While true, you be surprised what people will do without guidelines. ;)

> > Discussion welcomed.  I'm very keen on helping this proposal mature and
> > become an open standard.
> 
> Looking forward to it!
> 
> Ewan.

        -Sean

-- 
Sean Dague
IBM Linux Technology Center                     email: japh@xxxxxxxxxx
Open Hypervisor Team                           alt: sldague@xxxxxxxxxx

Attachment: pgpx9W2dCkCgF.pgp
Description: PGP signature

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api