Hi Evan.
I may not be able to make that time as I have an appointment
beforehand. Is it possible to change to 11 AM PT or later please?
Thanks,
Jack
On 05/13/09 09:04, Evan Layton wrote:
> 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.
>
