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
