Yes, thanks Evan!
Jack
On 05/13/09 09:56, Evan Layton wrote:
> Yes we can move it. Does 11:30am PST work ok?
>
> Sent from my iPhone
>
> On May 13, 2009, at 10:46 AM, Jack Schwartz <Jack.A.Schwartz at Sun.COM>
> wrote:
>
>> 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.
>>>
>>
