To make it formal: +1.
-- Garrett
Jerry Jelinek wrote:
> During the email discussion for this case last
> week it was discovered that Fujitsu has issued
> their patches in the 9xxxxx range that we were
> originally proposing for special patches.
>
> We have exchanged email off-line with Fujitsu and
> they are only using the 9xxxxx range for their
> patches. They plan to continue to use that range
> for their patches.
>
> Internally we have discussed this and we are simply
> changing the range for special patches to be the
> 8xxxxx range. I have included a new draft of the
> proposal which specifies this. As was previously
> noted, moving into this range does not significantly
> impact the consumption of patch IDs over the course of
> their expected lifetime.
>
> Because this is such a small change to the proposal,
> I left the timeout for the 16th, but I can extend it
> if anyone needs more time.
>
> Thanks,
> Jerry
>
> ---
>
> 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 8 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 8xxxxx. 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.
>
> Originally the intent was to use patches in the 9xxxxx range but
> during
> the course of this case it was discovered that Fujitsu is issuing
> their
> patches in the 9xxxxx range. This should be noted for any future
> project
> wishing to consume the patch ID namespace.
>
> 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 8xxxxx 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 8xxxxx 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 8xxxxx range
> Bugid 6791625 http://bugs.opensolaris.org/view_bug.do?bug_id=6791625
