Meeting notes 5/14/2009

Ethan's original email:
version in schema or manifest, version in installer (min and max)
how to determine?  Should be hardcoded?
Dave suggested dynamically updating client to manage incompatibility it might find.

Some questions to consider:
What things need to have versions?
Where do the version data come from? (booted system, packages we're installing?)
How those versions kept up to date?

Installer identifies itself by the build it's in.
Must query outside itself for the versiones it can install.

Can't store min and max in installer itself.  Build X installer may install
build X+n but it can not know "n" in advance.

Humans have to determine the max, then create the package that gives the min/max
data.  

Scope:
--
Want to maintain boot-image/installer compatibility with the bits being
installed.  This is not the same problem as manifest / schema (although schema
may be tied to version of installer).

newer installer / older bits case (going backward):
--
Determine the limiting backward-compatible build by checking old builds to see
if they work.  If they don't, say they are not supported.

Ethan's proposal sent March 23.  When new installer comes out, validate the
old builds which work with it.  For so many builds, set the
MIN/MAX_INSTALL_COMPAT_BUILD value (corresponding to the MIN/MAX build of the
installer that will install that given build).  That value (and a MIN value)
get delivered in a package that's part of the repo for that build.  Since it's
only a text file, it's easy to back-publish to different builds when a new
installer comes out.

Older installer / newer bits case (going forward):
--

Option 1: 1:1 installer build must match build of installed bits. Very limiting.

Option 2: Ethan's proposal sent March 23.  Validate that a new build works,
then set the MAX_INSTALL_COMPAT_BUILD value (corresponding to the MAX build of
the installer will install that build).  That value (and a MIN value) get
delivered in a package that's part of the repo for that build.

Option 3: Upgrading the client to handle incompatible builds can be done on the
fly.  Can download the installer to match the repo we want to install.
Note: requires another level in the installer to update the installer version.)

Going forward, we should try to limit the incompatibility window.  In order to
support installing a new installer, need to make sure the filesystem it would
go into is Read/Write.  Can refactor the bootroot file system layout if
necessary.

Which build version to install:
--
If user specifies build version, that's what we'd use.
Else would default to latest bits to install.

How to determine the version running the install vs the version being installed:
--
Version running the install:
- query client for version it was booted from.
 - installer will be assumed to be the same version as the running system
or
- Use IPS to query the installer package version.

Version being installed:
- IPS requires the version specified in the first package, usually "entire"
- Check the repo if version not specified explicitly.

Note: if we save an archive, need to embed the version in the archive.

On dynamically adjusting the client:
--
This may be needed when installing a new installer.
Clay has done:
  1) beadm clone,
  2) pkg install "entire" of a different build version,
  3) bootadm.
and had success, although it is not supported.
XXX Get with Evan and Karen and clay for details.

Zpool version mismatch can cause failure (It did in B96.)
 Also using 111b installer to install 101 bits: won't boot.
 This is new installer / older SW problem.
It's up to ZFS to make their versions forward / backward compatible.
 Backward compatibility usually works, but there have been hard
  boundaries which required a reinstall.

Not sure if IPS versioning is a problem or not.

Non-pkg installation / replication:
--
This is making a copy of an opensolaris system to use for install.
zfs send generates an archive to send.
With regard to zpool versioning:
 - Its the format of the stream output that matters.
 - Can specify the zpool version when create new zpool.
 - Can install a v13 zpool snapshot to a v14 zpool.
XXX - Can dynamically adjust the client.

If we allow differential copy, must be sure the version of the differences is
the same version of the base.

If we do non-pkg install, what to do about Ethan's idea of a pkg?

After the bits are layed down, can help compatibility by calling the
tools/libraries from the layed-down bits instead of the system area the
client is running from.

Check boot_archive and process for what gets done during an install to check for
compatibilities between what is installed and the system it is installed on.
Currently ICT uses microroot, but maybe can use tools from the bits being
installed instead.

AI: look into the stuff we do before the bits get layed down, and the stuff
done after the bits get layed down.  (Start at liborchestrator)
- Karen to look at stuff before the its go down.
- Evan to look at stuff after the bits go down.