Below are the notes from our version compatibility meeting...
-evan
Who:
Keith, Sarah, Jack, Karen, Ethan, Sue, and Clay
What:
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?
- schema and the manifest?
Where do the version data come from? (booted system, packages we're installing?)
How those versions kept up to date?
What constitutes a version?
- 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. The use of a package here is to provide the data to any installer so that
it knows it's limits.
Scope:
------
Want to maintain client 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).
Limit the "window" of incompatibility as much as possible.
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 is an idea of how to work around around what may be needed when installing
a new installer. (placed here as a place holder for the thought...)
Clay has done:
1) beadm clone,
2) pkg install "entire" of a different build version,
3) bootadm to update the boot archive.
and had success, although it is not supported.
What does compatibility mean?
- What items are part of compatibility?
- anything that would prevent a successful install.
- Zpool version mismatch can cause failure (It did in B96 for example.)
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 zfs or zpool version update.
- Not sure if IPS versioning is a problem or not, but probably not
an issue.
- ETC...
Forward compatibility:
------------------------------------
- strict only support same build
- Look at version of what's being installed - limit it to
same thing only.
- Dynamically adjusting client to make install possible or
limiting the window of incompatibility.
- Idea: use "pkg install entire" to get the down-reved
installed client up to the version requested?
- pit-falls we could end up with?
- specified range we can install.
- always download everything?
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 ZFS snapshot to a v14 zpool.
- Can dynamically adjust the client down without causing
problems on the newly installed system. Once the system
is booted the zpool can be updated.
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. For example installgrub from the can be used to new bits can
be used to update the grub version if needed (be_activate does this now).
AI: look into the stuff we do before the bits get layed down, and the stuff
done after the bits get laid down. (Start at liborchestrator)
- Karen to look at stuff before the bits go down.
- Evan to look at stuff after the bits go down.
