I'm thinking that initially we could have some sort of "exclude_list"
file,  but as I ponder the more general issue of all this "one off"
image customization, do we trust image creators enough to have more
than just a simple list of filenames or boolean go/no-go indicators in
the image?   Initially, having a 'vcl-capture-exclude-files' control
to enable/disable parts of the capture process would be relatively
safe,  but I think eventually we could include more extensive
user-exits that might override or extend default VCL functions like
capture, preload, and image startup/shutdown, without having to modify
VCL itself.

We could hide these image exits in /opt/vcl/ or whatever,  but I'm
thinking we might treat these per-image configuration extensions as
files in a hidden directory like /root/.vcloptions or c:\vcloptions .
   The hidden / dot-file convention makes it like other image
personalization configuration files, and makes it easier to hold onto
changes if you create a new edition of an image and need to tweak
things again.   Most image customizers wouldn't touch any of this, but
this mechanism could be very handy for handling edge-cases or
bleeding-edge software.

I think I like  more comprehensive user-exits, it can also make
adopting a new or strange Linux (or other OS) easier for end-users,
rather than having them promote their code into VCL itself.    Over
time, VCL can adopt some of the better ideas into new base VCL modules
so that the per-image customizations can be reduced.

  One additional feature might be to put some flag in the ImageProfile
to indicate "disallow vcl user exits" so that if someone truly screws
something up maybe we can recover without delving into raw VMware /
KVM.

Reply via email to