I think it doesn't qualify for automatic approval. I suspect the
special numbering will be the cause of some consternation. I'm not sure
what number we're up to on our patching, but when will we run into the
problem where our patch numbers don't work?
What about expanding on the idea used by T-patches, where a special
prefix is used instead... ("Sxxxxxx" or somesuch), that lives outside of
the numeric space associated with patch numbers?
Of course, since we have no architecture (nor product!) for patching
anything more recent than S10, maybe its not an issue. (It seems like
IPS changes the paradigm of patching in non-trivial ways, such that it
isn't clear to me if it makes sense to patch a Nevada system using
normal patches. If we ever release a Solaris 11 built upon SXCE instead
of OpenSolaris then the problem may remain...)
If the idea of using a special patch prefix letter (outside of the
numbering space) is not acceptable for some reason, then I'm willing to
hold my nose and give this a +1. I'd still like confirmation from the
project team as to whether the idea was considered, and if it was
rejected, I'd like to know why.
-- Garrett
Gerald Jelinek wrote:
> 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
>
>
