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
