Reasonable concerns.
Patches essentially started at 100000-01. The highest-numbered patch
which has been submitted to this point is right now 137283-01. There
is probably a bigger risk of running out of 9-series numbers first, but
8-series numbers certainly would still be available even if that did
occur.
-Dave
Garrett D'Amore wrote:
> 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
>>
>>
>
