Thoughts and Ideas

Notes from 5/21/2009

--
Assumptions:
--
- installer must be is bundled within the booted env
- post-manipulation of the bits are either bundled with the installer, in which
case the installer mismatch cases would handle that.  Or if post-install manipulation of data is bundled with the bits to be installed, then,
we don't need to worry about any mismatch.
- I believe these uses case will apply regardless
pkg-based-install/cpio archive/flash archive.

*NOTE:
Currently the archive/cpio installs relates to how the live CD does an install. The pkg-based install relates to how the Automated installer installs the pkgages. Finally the archive or image based installs are what we are thinking of as those installs done for replication and recovery.

In the case of both the live CD installs and the automated installer using pkg-based installs we would require that the bits that are booted would match those bits being installed on the system.

Use Case 0
--
Same OS version, this implies same installer version, no problem at all.

>

When we say Same OS version do we mean that same OS version booted or the same OS version being installed?

*NOTE:
I also think we need to keep in mind that we're expecting the installer to always be part of the boot image and therefore will always match the OS that was booted.

Use case 1
--

> different OS version, same installer version:

> Problem: modules and libraries the installer uses to select and prepare the install env might affect
the outcome of the installation.
- some of these preparations by the installer will stay after the installation, eg: ZFS version
- some of these preparations by the installer might affect during installation, eg: if the module
used for target discovery was changed, the disk selected might not work as expected.

> Rules for this case <

- If a mis-match between the installer/booted bits is found for ether
  that pkg-based install or the archive/cpio install the installer will
  fail and information will be passed back to the user describing why
  the install failed.
- If this scenario is found for an image based install he image bits
  will be installed on the system.
- Any configuration required will need to be done post installation. This will require that there is something availble such as a transient SMF service that runs on first boot that performs the configration required.

Use Case 2
--

> Booted OS older than OS to be installed: installer in booted env is older than installer that should have been used for installer the OS bits

> Rules for this case <

- If there is a mismatch between the booted OS and the installer the installer will fail and report that the current mis-match is not supported.
- If there is a mis-match between the Booted OS/installer and the OS being installed:
- If the install is archive(cpio) or pkg-based then the install should fail and report that this is not supported. - If the install is image based then we perform the same install steps as described for case 1 for image based installs.

Use Case 3
--

> Booted OS newer than OS to be installed: installer in booted env is newer than the installer
that should have been used for installing the bits.

>  Rules for this case <

- In all cases the installer would fail and the user would be informed that this mis-match happened and that the installer is no backward compatible.

Use Case 4 (I know this is not really a use case, but this is my thought process....)
--
Installer and XML manifests

Installer knows that it can work with schema version X.  Installer will call the parser to validate
a given XML file using the schema X.  If parser validates the XML file, the installer will proceed.

In a future date, if installer is updated, and it now only work with version x+1, installer will call
parser to validate a given XML file using schema x+1.  It's the parser's responsibility to determine
whether the given XML file is OK for schema x+1.

Dependency: It's the parser's responsibility to determine whether schema version X is compabile with
the given XML file.   The given XML file might not be the same version as schema X.

>  Rules for this case <

- This is dependent on what information is passed back the the rest of
the installer from those parts that are dealing with checking the schema
against the manifest.
- If the XML parser returns that these match we continue. - If the XML parser returns that there is an error that can't be handled the information returned from that failure is returned to the user and the install fails. - If the XML parser reports that there is a mismatch that can be handled that is reported to the user and we continue.

Use Case 5
--
Installer booted up in X86, explicitly specify to install some SPARC bits.
Should fail asap.

>  Rules for this case <

- In all instances the installer reports this mismatch in architecture to the user and fails... 

Notes from 5/14/2009

--
Some of the things we would want to do or things we might want to limit:
- When a version mismatch is detected we would want to print out
  or log an warning or error as appropriate. We could then add that
  we are attempting to continue with the install but that a successful
  install is not guaranteed.
- When attempting to continue we would also need to report or log any steps taken to either correct the version mismatch or work around it while attempting to install. - If the version of the installer and/or version of the OS being installed is older than what is booted we fail and report and log that we do not support backward compatibility. - One thought on how to version the OS being installed and determine what type it is would be in include the type and version number of the OS into the version number for the image. - There is still the problem of managing these versions. One way that has been suggested is to provide a package that contains the current version max and min values. However this requires manual intervention to mange the max and min values from release to release. We have not yet thought of a way to manage this versioning automatically.

Some of the things that would cause a version change:
- adding new features to the installer (version change for the
  installer)
- changes to features
- change in the installer would cause an installer version change. - incompatible changes to the underlying libraries would cause a version change that would be a version boundary. This means that at this point the versions would have to match and we could not support anything with a version proceeding this change. We would be able to have the potential to support newer version going forward. - deleted features in the installer. This would also cause a version boundary. - deprecated features in the installer. Since these features would still exist but be older and on a path toward possibly being deleted we would not require a version boundary but would print and log a warning telling the user that this feature is deprecated. - New build of the OS - print and log a warning and attempt to install. Attempting to install may entail updating the installer in the booted environment on the client, etc...