[Ovirt-devel] Ovirt Host Tasks

[Ian Main]

On Mon, 17 Mar 2008 13:59:14 -0400
"Perry N. Myers" <pmyers at redhat.com> wrote:

> Daniel P. Berrange wrote:
> > On Sun, Mar 16, 2008 at 11:43:02PM -0400, Perry N. Myers wrote:
> >> 1. Image Creation:
> >>
> >> a. Integrate whitelist functionality into the image creation
> >>    process to reduce image size.
> >> b. Determine the minimal set of files that the host image needs to
> >>    construct a baseline whitelist.
> > 
> > IMHO, a pure whitelist approach is not very maintainable long term. As
> > we track new Fedora RPM updates, new files often appear & we'll miss them
> > with a pure whitelist. I'd go for a combined white/black list so we can 
> > be broadly inclusive and only do fine grained whitelist in specific areas
> 
> Agreed.  I just use whitelist instead of white/black list because it's 
> shorter to type :)

I think some thought needs to be given to being able to add to, or change the base os to allow debugging and other tools to be present in the image as well.  This can probably just be done with kickstart & white/black changes.

[snip]
 
> >> g. Construct a method for taking an image and adding site specific
> >>    configuration information to it (IP addresses of Ovirt Mgmt Server and
> >>    FreeIPA Server).  This is only necessary to support hosts that require
> >>    static IP configuration -and- do not have persistent storage to store
> >>    configuration information.  (If we decide to support static IP config
> >>    we could make presence of persistent storage a requirement...)
> >>
> >> The goal is to get disk footprint down to something like 32, 64 or 128MB. 
> >>  The base images we build will not be hardware platform specific, so 32MB 
> >> might be a long shot.  But after step e) above, we should fit into 32MB.
> > 
> > 64MB is probably a worthy immediate goal to aim for given that the current 
> > live image is about 85 MB & we know there's stuff that can be killed. 

I wonder if we should create an API for persistent storage?  Given that it sounds like we'll have to support multiple options.  We'll have the ovirt DB storage, no storage, flash storage, maybe vsata etc.  All with its own setup and the operational difference between the DB and some kind of disk.

> Agreed.
> 
> > Again, unless we have compelling hardware use case that requires 32 MB,
> > I'd not bother aiming for the 32MB mark in the short-medium term. There's
> > other more broadly useful stuff we can do....
> 
> Agreed.

I agree as well.  For intitial devel purposes I'd just as soon see us develop the debug/tools image first, and then widdle it down from there as a second step.  This will give us the debug image right away which I think could be useful.

> >> OEM Pre-Install (will always have flash/disk storage)
> >>   DHCP Addressing
> >>     Flash/Disk Storage/TPM
> >>       Auth credentials can be stored in a file or in TPM
> >>   Static Addressing
> >>     Flash/Disk Storage/TPM
> >>       Auth credentials/IP config/Server IPs can be stored in a file
> >>       If TPM is present, can be used to store auth info
> >> IT Install (may not have flash or disk)
> >>   DHCP Addressing
> >>     Flash/Disk Storage/TPM
> >>       Auth credentials can be stored in a file or in TPM
> >>     No Persistent Storage (CD or PXE Boot)
> >>       Auth can be stored in host image (separate image for each host)
> >>       (NOTE: Not secure for PXE boot.  Recommend that we only allow
> >>       CD boot in this case)
> >>   Static Addressing
> >>     Flash/Disk Storage/TPM
> >>       Auth credentials/IP config/Server IPs can be stored in a file
> >>       If TPM is present, can be used to store auth info
> >>     No Persistent Storage (CD or PXE Boot)
> >>       Auth/IP config/Server IPs can be stored in host image (separate
> >>       image for each host)
> >>       (NOTE: Not secure for PXE boot as above)
> > 
> > The 2 PXE boot methods can be secure given a deployment scenario where
> > the network admin has a dedicated PXE management LAN for their hosts.
> > So PXE traffic would be separated from general guest / user traffic.
> > Its probably not viable to mandate separate 'management network' but
> > we should document it as a deployment scenario.

My only thought here is.. how do we implement all these options with a single boot image?  Somehow we'd have to identify up front if persistent storage is available and then allow other options to become available for configuration (static ip etc).  I also think applications should be given access to persistent storage if available. 

One interesting thing would be to use a union filesystem with the os image mounted read only and a writeable fs underneath (maybe only where appropriate.. eg /etc) that would be stored on persistent storage.  This lets you modify the image at runtime, have your changes saved while not changing the original image.. just a thought, not sure if it'd be useful.

[snip]

    Ian