Subject: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009]
To:      PSARC-ext@Sun.Com
Cc:      Gerry.Haskins@Sun.COM, Ondrej.Kubecka@Sun.COM, update_re@sun.com, Jaromir.Sedlacek@Sun.COM, Roisin.Doran@Sun.COM
Bcc:     one-pager-list@sac.sfbay one-pager-log@sac.sfbay sac-bar@sac.sfbay

I'm sponsoring this for myself.  This might qualify
as closed approved automatic since there isn't much
architecture here, but I gave it a week to be safe.

Thanks,
Jerry

Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
	 Identifying special patches
    1.2. Name of Document Author/Supplier:
	 Author:  Gerald Jelinek
    1.3  Date of This Document:
	08 January, 2009
4. Technical Description
SUMMARY: 

    This fast-track documents a new convention used for patch IDs on Solaris.
    There is no pre-existing architecture to build on that has been documented 
    in this area, so this case is being filed to publically record a
    new convention which reserves the patch ID namespace beginning with
    the number 9 for "special patches".

    Patch binding is requested for the code using this new convention.
    The stability of this interface is committed.

DETAILS:

    There has been a long-standing practice by gatekeepers and the release
    process to create a "special patch" as a bookkeeping mechanism when a
    modification outside of a normal engineering delivery is made to
    a product being released.  These special patches are created with a
    standard patch ID and appear on end-user systems as an installed patch.
    However, the special patches are never actually released to customers as
    a downloadable patch, they only show up as metadata on an installed system
    (e.g. special patches appear to be installed on systems running Solaris 10
    Update releases).  Special patches are intended from the start to never be
    released to customers as real patches.

    This causes a problem for the Solaris Zones [1] "update on attach"
    feature [2] since the special patches appear as a dead-end during
    the validation.  This happens because we do not allow a user to
    downgrade their system, so a missing patch appears as a downgrade.
    For example, if a system with a zone was running S10u5, then the S10u5
    special patches would appear to be installed in that zone.  If you then
    tried to migrate the zone to a S10u6 system, the S10u5 special patches
    would not be on the u6 system, so "update on attach" sees those as
    missing patches, treats this as a downgrade and prevents the migration.
    Because there is no way for a customer to get the special patches to
    install onto the u6 system, and because the special patches are never
    obsoleted in a subsequent release, the zone migration is at a dead-end.

    The problem from the "update on attach" perspective is that special
    patches look just like normal patches.  Some way is needed to identify
    these patches as bookkeeping, and not patches that need to be validated
    during a zone migration.  During discussions with all of the interested
    parties (RE, gatekeeping, patch test) a variety of solutions were
    considered to address this.  In the end, all parties agreed to a simple
    solution which makes special patches self-identifying by creating these
    patches in the patch ID range 9xxxxx.  This solution was agreed to have an
    acceptable impact on the existing processes and teams which deal with
    patches.  Everyone involved recognized that this is not the cleanest
    architecture, but it is also recognized that there is no architecture for
    special patches.  A more complex design and implementation for handling
    this in all impacted areas is not considered a feasible alternative.

    Up to this point the zone "update on attach" code has kept a blacklist
    of special patches, but this is not maintainable going forward.  The zones
    code will be modified to ignore patches in this new range during the
    validation phase of a zone migration.

    The patch and gatekeeping teams are modifying their tools and processes
    to generate special patches in the 9xxxxx range and audit for this
    in the patch pipeline.  A test patch in this range has been generated
    and tested throughout the pipeline to ensure that all existing tools
    work correctly with patches in this range.

EXPORTED INTERFACES

    Patch ID range 9xxxxx            Committed
    reserved for special patches

IMPORTED INTERFACES

    None

REFERENCES

1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
2. PSARC 2007/621 zone update on attach
3. 'update on attach' should ignore special patches in 9xxxxx range
   Bugid 6791625 http://bugs.opensolaris.org/view_bug.do?bug_id=6791625

6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open