I would like to have a meeting on Thursday 5/14 at 10am PT to discuss the
Version Compatibility work. Please let me know as soon as possible if this time
doesn't work so we can find a better time for everyone.
The agenda will cover the following:
- go over Ethan's installer compatibility write-up. (While this
only covers the current package-based installs it is a good
place to start)
- please read over this write-up and be ready to discuss.
- What does compatibility mean
- what needs to change in the current problem statement.
- go over other questions:
1) How do we determine which version we are running the
install on vs which version we're installing.
2) How do we determine what makes the OS versions compatible?
3) How do we keep track of which OS version is compatible
with installing which OS versions?
4) Do we know what the use cases are (see bug 7838 for some of
this but more related to manifests).
5) What are the incompatibilities?
6) How do we handle these incompatibilities? (errors, warnings,
take corrective actions if possible...)
- What overlaps do we think we may have with the XML parsing work.
This refers to forward and backward compatibility of manifests.
- open discussion
Teleconf number:
Internal extension x44405
US-based: 866-545-5220
International: 213-787-0527
PC: 6343344#
Thanks,
-evan
====================================================================
Proposal for installer compatibility with pkg-based installed bits.
(Fom March 23rd)
As discussed in the meeting today, bug 7837 has been filed to
address handling this issue long term.
Bug 7838 is filed to log the installer and installed system's
build numbers in the install_log. This one will be fixed for
this release.
AI docs will also be updated to note this.
thanks,
-ethan
Ethan Quach wrote:
>
> thoughts welcomed on this ...
>
> thanks,
> -ethan
>
>
> Problem/Background
> ----------------------------------
> With pkg-based installs, we've run into some incompatibility
> problems as we've released later development builds that
> aren't compatible with older installers, as seen in a few posts
> from early triers of AI. This will be an on-going issue as we
> develop new features into the installer, and we currently don't
> handle this as nicely or intelligently as we could.
>
>
> Proposed Solutions
> -------------------------------
> [0*] Download the installer from pkg branch requested to be
> installed. This solution involves extreme refactoring of the
> installer architecture to dummy-down the install media, and
> to store the real guts of the installer elsewhere. This solution
> is not being considered for this proposal, but isn't precluded
> from any future rework.
>
>
> [1] A simple, conservative, solution to this problem would be to
> restrict that install media only be able to support pkg-based
> installs for packages of the same build as was used to build the
> install media.
>
> Since in most cases, a random development build N install
> image could potentially, and usually likely, be able to install
> pkg-based bits of build N+1 for example, the enforcement could
> be lightweight --perhaps just a warning message on the console
> and/or log. E.g.
>
> WARNING: The build of the packages being installed, build X,
> is not supported by this installer which was built using build Y.
> Install will proceed, however the installed system is not
> guaranteed to be installed properly.
>
>
> [2] Embed variability into the process such that the install image
> is able to determine if the pkg branch being requested to be
> installed is supported by it. For example, use an install image
> built from build N to do a pkg-based install of build N+2. The
> installer knows its able to support this scenario and allows the
> install to complete with no warnings. This provides more support
> flexibility to the user, but requires a little more upfront work from
> development.
>
>
> Initial Impl. Details for [2]
> ------------------------------------------
> The install image built with build X is obviously built before future
> builds, build X+1, build X+2, ... etc, so it is impossible to directly
> embed into the installer what builds it can support. So this
> compatibility knowledge must be placed with the packaged install
> bits themselves. So the proposal here is to create a new package,
> SUNWinstall_compat, which for each build will define which
> builds of the installer is able to support installing that build. The
> new package would contain a simple text file with
>
> MIN_INSTALL_COMPAT_BUILD=
> MAX_INSTALL_COMPAT_BUILD=
>
>
> 2.1 Installer changes
> The installer will be enhanced to download the requested build's
> SUNWinstall_compat package first, then check that the build it
> was built with falls within the MIN and MAX value.
>
> if (requested build has no SUNWinstall_compat package)
> WARNING: no SUNWinstall_compat pkg found. Install will
> proceed, but ...
>
> else if (install image build is out of range of MIN and MAX)
> WARNING: this install image is not supported to install
> build X. Install will proceed, but ....
>
>
> 2.2 SUNWinstall_compat package
> The new SUNWinstall_compat package will deliver a text file
> with the MIN and MAX build numbers defining which builds of
> the install image are supported to install that build of the
> packages. This package is not installed on the installed machine.
>
> MIN_INSTALL_COMPAT_BUILD=[integer: 0,infinity]
> MIX_INSTALL_COMPAT_BUILD=[integer: 0,infinity]
>
> The MIN_INSTALL_COMPAT_BUILD value needs to be updated
> only when known Flag Days occur for the Installer installing
> pkg-based bits. For example, if in build 115, we need to make
> changes in ICT to support pkg-based installing of build 115, then
> we update the MIN_INSTALL_COMPAT_BUILD value in build 115
> to be 115. Any previous build installer will now emit a WARNING
> when they pkg-base install bld 115. If we happen to forget to
> update this file for build 115, its easily back-publishable since its
> just a text file.
>
> The MAX_INSTALL_COMPAT_BUILD value should always be left
> as infinity for new builds. This value is useful only to be
> backpublished when we know of changes to the installer that
> prevent it from being able to install some older build.
> For example, if in build 120, we make changes to the installer
> such that it can no longer pkg-base install build 111 on back,
> then we backpublish the SUNWinstall_compat package for builds
> 111 on back to have a MAX value of 119 (or back until we hit some
> build that already has a value for MAX)
>
>
> Issues
> ----------
> [2] assumes one shared base of installer tools wrt pkg-based
> installs. i.e. a LiveCD pkg-based installer and the AI pkg-based
> installer wouldn't have different installer compatibility boundaries.
> Otherwise separate sets of MIN and MAX values would have to
> be defined for each pkg-based installer.
