From Wed Jan 14 15:41:41 2009 Date: Wed, 14 Jan 2009 15:41:41 -0800 (PST) From: Postmaster Subject: Message from mail server Content-Length: 94 Mime-Version: 1.0 Status: RO X-IMAP: 1231976501 15 Delete. This is a system message. --END+PSEUDO-- From gjelinek@sac.sfbay.sun.com Thu Jan 8 11:57:24 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08JvN9h007397 for ; Thu, 8 Jan 2009 11:57:24 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n08JvMZd022478; Thu, 8 Jan 2009 19:57:22 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD6003014RM0G00@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 12:57:22 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD600D104RLU7E0@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 12:57:21 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n08JvHbx040889; Thu, 08 Jan 2009 11:57:17 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08JvGYM007392; Thu, 08 Jan 2009 11:57:16 -0800 (PST) Received: (from gjelinek@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n08JvGNr007388; Thu, 08 Jan 2009 11:57:16 -0800 (PST) Date: Thu, 08 Jan 2009 11:57:16 -0800 (PST) From: Gerald Jelinek Subject: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] To: PSARC-ext@sun.com Cc: Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Content-Length: 4751 Status: RO X-Status: $$$$ X-UID: 0000000001 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 From gdamore@sun.com Thu Jan 8 12:44:03 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08Ki22Z026572 for ; Thu, 8 Jan 2009 12:44:03 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n08Khve3019035; Thu, 8 Jan 2009 20:44:01 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD6009016XCVC00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 12:44:00 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD600LVI6XBC1B0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 12:43:59 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n08KhxiE022725; Thu, 08 Jan 2009 12:43:59 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD6006016PE0Q00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Thu, 08 Jan 2009 12:43:59 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD6004TO6XARR80@fe-sfbay-09.sun.com>; Thu, 08 Jan 2009 12:43:59 -0800 (PST) Date: Thu, 08 Jan 2009 12:34:47 -0800 From: "Garrett D'Amore" Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Gerald Jelinek Cc: PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <49666367.2050104@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Content-Length: 6149 Status: RO X-Status: $$$$ X-UID: 0000000002 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 > > From carlsonj@phorcys.east.sun.com Thu Jan 8 13:01:50 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08L1nsc027493 for ; Thu, 8 Jan 2009 13:01:49 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n08L1DXA029528; Thu, 8 Jan 2009 21:01:46 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD600C1F7QU7M00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 13:01:42 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD600L667QUBWC0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 13:01:42 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n08L1ehm016259; Thu, 08 Jan 2009 16:01:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n08L1eiR016256; Thu, 08 Jan 2009 16:01:40 -0500 (EST) Date: Thu, 08 Jan 2009 16:01:40 -0500 From: James Carlson Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <49666367.2050104@sun.com> To: "Garrett D'Amore" Cc: Gerald Jelinek , PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <18790.27060.922451.793767@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <49666367.2050104@sun.com> Content-Length: 1245 Status: RO X-Status: $$$$ X-UID: 0000000003 Garrett D'Amore writes: > 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? I don't see the problem you do. Who cares about the numbering system used for patch IDs, and how is any numbering choice for a patch an architectural issue to begin with? I see it as only goodness -- it makes it clear (to anyone who cares) that these are very special "patches" and don't really exist anywhere other than inside the fiction of updates. > 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. Likely because it requires zero change in the tools. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Gerald.Jelinek@sun.com Thu Jan 8 13:28:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08LSkLk027771 for ; Thu, 8 Jan 2009 13:28:46 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n08LSPZj021239; Fri, 9 Jan 2009 05:28:45 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD600B058ZWNR00@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 14:28:44 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD6004O18ZUHG50@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 14:28:42 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n08LSgjT028951; Thu, 08 Jan 2009 21:28:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD600A0187PJ600@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM); Thu, 08 Jan 2009 14:28:42 -0700 (MST) Received: from [192.168.0.11] ([206.53.29.107]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD600JQW8YPNS70@mail-amer.sun.com>; Thu, 08 Jan 2009 14:28:02 -0700 (MST) Date: Thu, 08 Jan 2009 14:28:01 -0700 From: Jerry Jelinek Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <49666367.2050104@sun.com> Sender: Gerald.Jelinek@sun.com To: "Garrett D'Amore" Cc: Gerald Jelinek , PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <49666FE1.6080703@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <49666367.2050104@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 1874 Status: RO X-Status: $$$$ X-UID: 0000000004 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? Patch IDs currently start with a leading '1' and we at almost 40,000 right now, so we've made ~40k patches over the course of Sun's life. I'm not sure when patches were introduced; 20 years ago? Maybe someone I cc'ed knows. Since patch IDs started with 1 and we've carved out 9, that leaves ~760k to go, so while this was discussed, it was not considered to be an issue. > 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? This was discussed among the group but was not the chosen alternative. > 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. I don't recall all of the reasons why this idea wasn't the preferred solution, but I cc'ed most everyone who was involved in these discussions so hopefully one of them will chime in. Thanks, Jerry From Dave.Hamaker@sun.com Thu Jan 8 13:43:20 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08LhKl7028108 for ; Thu, 8 Jan 2009 13:43:20 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n08LhIbS026186; Thu, 8 Jan 2009 14:43:19 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD600D099O61J00@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 14:43:18 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD6004889O5H260@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 14:43:17 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n08LhHs2029318; Thu, 08 Jan 2009 13:43:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD60050197BTD00@fe-sfbay-09.sun.com> (original mail from Dave.Hamaker@Sun.COM); Thu, 08 Jan 2009 13:43:17 -0800 (PST) Received: from [129.146.106.155] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD600HV29NTNY00@fe-sfbay-09.sun.com>; Thu, 08 Jan 2009 13:43:08 -0800 (PST) Date: Thu, 08 Jan 2009 13:43:06 -0800 From: Dave Hamaker Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <49666367.2050104@sun.com> Sender: Dave.Hamaker@sun.com To: "Garrett D'Amore" Cc: Gerald Jelinek , PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Reply-to: Dave.Hamaker@sun.com Message-id: <4966736A.60303@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <49666367.2050104@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Content-Length: 6755 Status: RO X-Status: $$$$ X-UID: 0000000005 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 >> >> > From bart.smaalders@sun.com Thu Jan 8 13:52:19 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08LqIdU028467 for ; Thu, 8 Jan 2009 13:52:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n08Lpolo001355; Thu, 8 Jan 2009 21:52:13 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD600D0BA2YVE00@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 14:52:10 -0700 (MST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD6004LQA2XHH60@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 14:52:09 -0700 (MST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id n08Lq92a007005; Thu, 08 Jan 2009 21:52:09 +0000 (GMT) Date: Thu, 08 Jan 2009 13:52:08 -0800 From: Bart Smaalders Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <4966736A.60303@Sun.COM> To: Dave.Hamaker@sun.com Cc: "Garrett D'Amore" , Gerald Jelinek , PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <49667588.90103@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <49666367.2050104@sun.com> <4966736A.60303@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Content-Length: 692 Status: RO X-Status: $$$$ X-UID: 0000000006 Dave Hamaker wrote: > 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 Given that we won't be using patch-ids for Solaris 11 forward, all concerns about running out of ids seem groundless given statistics over the last 18 years.... - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Jonathan.Obrien@sun.com Thu Jan 8 14:53:16 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08MrFNM000494 for ; Thu, 8 Jan 2009 14:53:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n08Mr9qv002234; Fri, 9 Jan 2009 06:53:14 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD600J0FCWQOZ00@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 15:53:14 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD6004ANCWQH6A0@brm-avmta-1.central.sun.com>; Thu, 08 Jan 2009 15:53:14 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n08MrEJG007801; Thu, 08 Jan 2009 14:53:14 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD600B01COFBI00@fe-sfbay-09.sun.com> (original mail from Jonathan.Obrien@Sun.COM); Thu, 08 Jan 2009 14:53:13 -0800 (PST) Received: from [129.146.116.249] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD600B7TCWLN4E0@fe-sfbay-09.sun.com>; Thu, 08 Jan 2009 14:53:09 -0800 (PST) Date: Thu, 08 Jan 2009 14:53:10 -0800 From: "Jonathan O'Brien" Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> Sender: Jonathan.Obrien@sun.com To: Gerald Jelinek Cc: PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <496683D6.4090006@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Content-Length: 342 Status: RO X-Status: $$$$ X-UID: 0000000007 Gerald Jelinek wrote: > > EXPORTED INTERFACES > > Patch ID range 9xxxxx Committed > reserved for special patches > Fujitsu has been known to release patches with IDs in the range of 9xxxxx. I don't think they ever asked anyone if they could do this, but you may not want to risk colliding with their patches. jonathan From Gerald.Jelinek@sun.com Thu Jan 8 15:18:26 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08NIPdf001566 for ; Thu, 8 Jan 2009 15:18:25 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n08NIO0M011793; Thu, 8 Jan 2009 16:18:25 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD60060DE2NON00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 15:18:23 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD600FXPE2M1T90@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 15:18:23 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n08NIM1F023561; Thu, 08 Jan 2009 23:18:22 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD600L01DK13800@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM); Thu, 08 Jan 2009 16:18:22 -0700 (MST) Received: from [192.168.0.11] ([206.53.29.107]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD600G27E2BJF40@mail-amer.sun.com>; Thu, 08 Jan 2009 16:18:12 -0700 (MST) Date: Thu, 08 Jan 2009 16:18:11 -0700 From: Jerry Jelinek Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <496683D6.4090006@sun.com> Sender: Gerald.Jelinek@sun.com To: "Jonathan O'Brien" Cc: Gerald Jelinek , PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <496689B3.7080405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <496683D6.4090006@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 750 Status: RO X-Status: $$$$ X-UID: 0000000008 Jonathan O'Brien wrote: > > Gerald Jelinek wrote: >> >> EXPORTED INTERFACES >> >> Patch ID range 9xxxxx Committed >> reserved for special patches >> > > Fujitsu has been known to release patches with IDs in > the range of 9xxxxx. I don't think they ever asked > anyone if they could do this, but you may not want to > risk colliding with their patches. Jonathan, Thanks for this information. Do you know any more about this? Did Fujitsu just usurp part of the patch ID namespace or is there some group within Sun that we need to talk to about this? Do all of their patches begin with 9 or are they all over the map? Depending on what we can find out about this, we may need to consider a different solution. Thanks, Jerry From Jonathan.Obrien@sun.com Thu Jan 8 15:42:45 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n08Ngif3002386 for ; Thu, 8 Jan 2009 15:42:44 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n08NgiN1024319; Thu, 8 Jan 2009 15:42:44 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD600A07F78CY00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 15:42:44 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD600FQJF771LB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 15:42:43 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n08NghLw012904; Thu, 08 Jan 2009 15:42:43 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD600501EZQX500@fe-sfbay-10.sun.com> (original mail from Jonathan.Obrien@Sun.COM); Thu, 08 Jan 2009 15:42:43 -0800 (PST) Received: from [129.146.116.249] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD600A1CF75IU00@fe-sfbay-10.sun.com>; Thu, 08 Jan 2009 15:42:42 -0800 (PST) Date: Thu, 08 Jan 2009 15:42:43 -0800 From: "Jonathan O'Brien" Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <496689B3.7080405@sun.com> Sender: Jonathan.Obrien@sun.com To: Jerry Jelinek Cc: Gerald Jelinek , PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <49668F73.90206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <496683D6.4090006@sun.com> <496689B3.7080405@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Content-Length: 929 Status: RO X-Status: $$$$ X-UID: 0000000009 Jerry Jelinek wrote: > Jonathan O'Brien wrote: >> >> Gerald Jelinek wrote: >>> >>> EXPORTED INTERFACES >>> >>> Patch ID range 9xxxxx Committed >>> reserved for special patches >>> >> >> Fujitsu has been known to release patches with IDs in >> the range of 9xxxxx. I don't think they ever asked >> anyone if they could do this, but you may not want to >> risk colliding with their patches. > > > Thanks for this information. Do you know any more > about this? Did Fujitsu just usurp part of the patch > ID namespace or is there some group within Sun that > we need to talk to about this? Do all of their patches > begin with 9 or are they all over the map? Depending > on what we can find out about this, we may need to > consider a different solution. I've asked Fujitsu to clarify, but the people in the US do not know all the details. They are going to ask FJ Japan and will get back to us. jonathan From gdamore@sun.com Thu Jan 8 17:01:10 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0911ABK021291 for ; Thu, 8 Jan 2009 17:01:10 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n091160h029841; Thu, 8 Jan 2009 17:01:10 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD600L01ITYAO00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 17:01:10 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD600H4EITX9SB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 17:01:09 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n09119WM025002; Thu, 08 Jan 2009 17:01:09 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD600101IPO9U00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Thu, 08 Jan 2009 17:01:09 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD600JOBITN7O90@fe-sfbay-10.sun.com>; Thu, 08 Jan 2009 17:00:59 -0800 (PST) Date: Thu, 08 Jan 2009 16:51:48 -0800 From: "Garrett D'Amore" Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <49666FE1.6080703@sun.com> Sender: Garrett.Damore@sun.com To: Jerry Jelinek Cc: Gerald Jelinek , PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <49669FA4.3020808@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <49666367.2050104@sun.com> <49666FE1.6080703@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Content-Length: 882 Status: RO X-Status: $$$$ X-UID: 0000000010 Jerry Jelinek wrote: > 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? > > Patch IDs currently start with a leading '1' and we at almost > 40,000 right now, so we've made ~40k patches over the course > of Sun's life. I'm not sure when patches were introduced; 20 years > ago? Maybe someone I cc'ed knows. Since patch IDs started with 1 and > we've carved out 9, that leaves ~760k to go, so while this was discussed, > it was not considered to be an issue. Okay, given that... I'm much happier to give this the +1. :-) I *hope* we won't still be using the current patch system before we run out of patch ids. :-) -- Garrett From gdamore@sun.com Thu Jan 8 17:04:12 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0914BxZ021347 for ; Thu, 8 Jan 2009 17:04:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n09140nq023509; Fri, 9 Jan 2009 01:04:10 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD600L0JIYWM500@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 17:04:08 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD600HGSIYV9SC0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Jan 2009 17:04:07 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n09146uv020359; Thu, 08 Jan 2009 17:04:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD600G01IX4KE00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Thu, 08 Jan 2009 17:04:06 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD6006UVIYPBVA0@fe-sfbay-09.sun.com>; Thu, 08 Jan 2009 17:04:02 -0800 (PST) Date: Thu, 08 Jan 2009 16:54:50 -0800 From: "Garrett D'Amore" Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <49667588.90103@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: Dave.Hamaker@sun.com, Gerald Jelinek , PSARC-ext@sun.com, Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <4966A05A.2050801@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <49666367.2050104@sun.com> <4966736A.60303@Sun.COM> <49667588.90103@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Content-Length: 1009 Status: RO X-Status: $$$$ X-UID: 0000000011 Bart Smaalders wrote: > Dave Hamaker wrote: >> 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 > > Given that we won't be using patch-ids for Solaris 11 forward, all > concerns about running out of ids seem groundless given statistics > over the last 18 years.... What we will, or will not, be doing for Solaris 11 is nothing except pure conjecture at this point, particularly since there are no plans (at least none that I'm aware of, and I believe none public in any case), for Solaris 11. Whether a hypothetical Solaris 11 release would be based on OpenSolaris and IPS remains to be seen. That said, given the statistics, I agree that the concern now appears groundless. :-) -- Garrett > > - Bart > > From ceri@submonkey.net Fri Jan 9 03:06:13 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n09B6C4F005774 for ; Fri, 9 Jan 2009 03:06:12 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n09B5uM6025514; Fri, 9 Jan 2009 11:06:09 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD700K1YAU80S00@nwk-avmta-2.sfbay.sun.com>; Fri, 09 Jan 2009 03:06:08 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD700CALAU7EUA0@nwk-avmta-2.sfbay.sun.com>; Fri, 09 Jan 2009 03:06:07 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n09B0Za6019154; Fri, 09 Jan 2009 11:06:07 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-1929301; Fri, 09 Jan 2009 11:06:07 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-99427; Fri, 09 Jan 2009 11:06:07 +0000 (Z) Received: from scuttle.submonkey.net ([208.111.43.184] [208.111.43.184]) by relay1ib.sun.com with ESMTP id BT-MMP-21322087; Fri, 09 Jan 2009 11:06:06 +0000 (Z) Received: from cpc1-cdif1-0-0-cust63.cdif.cable.ntl.com ([81.104.164.64] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LLFBm-0004rO-3z; Fri, 09 Jan 2009 11:06:06 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LLFBj-000NEh-P6; Fri, 09 Jan 2009 11:06:03 +0000 Date: Fri, 09 Jan 2009 11:06:03 +0000 From: Ceri Davies Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <18790.27060.922451.793767@gargle.gargle.HOWL> Sender: Ceri Davies To: James Carlson Cc: "Garrett D'Amore" , Ondrej.Kubecka@sun.com, update_re@sun.com, Jaromir.Sedlacek@sun.com, PSARC-ext@sun.com, Gerald Jelinek , Roisin.Doran@sun.com, Gerry.Haskins@sun.com Message-id: <20090109110603.GB41514@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=0.0/5.0, scanned in 0.091sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <49666367.2050104@sun.com> <18790.27060.922451.793767@gargle.gargle.HOWL> User-Agent: Mutt/1.5.18 (2008-05-17) Content-Length: 1407 Status: RO X-Status: $$$$ X-UID: 0000000012 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 08, 2009 at 04:01:40PM -0500, James Carlson wrote: > Garrett D'Amore writes: > > I think it doesn't qualify for automatic approval. I suspect the=20 > > special numbering will be the cause of some consternation. I'm not sur= e=20 > > what number we're up to on our patching, but when will we run into the= =20 > > problem where our patch numbers don't work? >=20 > I don't see the problem you do. Who cares about the numbering system > used for patch IDs, and how is any numbering choice for a patch an > architectural issue to begin with? >=20 > I see it as only goodness -- it makes it clear (to anyone who cares) > that these are very special "patches" and don't really exist anywhere > other than inside the fiction of updates. A prefix, such as we already get with IDRxxxxxx-xx, would make it equally clear, if not clearer. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFJZy+bocfcwTS3JF8RAtPjAKCrbljFyaVVz0qY4dCqTRezXwZY5wCgxfBk vnSwDt2YhNq6Ab5z+HVXNxw= =iGRh -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From Gerry.Haskins@sun.com Fri Jan 9 03:58:47 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n09Bwlxw006490 for ; Fri, 9 Jan 2009 03:58:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n09Bwk00004072; Fri, 9 Jan 2009 03:58:47 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KD70000BD9HKL00@nwk-avmta-2.sfbay.sun.com>; Fri, 09 Jan 2009 03:58:29 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD700CRID9EEXD0@nwk-avmta-2.sfbay.sun.com>; Fri, 09 Jan 2009 03:58:27 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n09BwQ5C022215; Fri, 09 Jan 2009 11:58:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD700D01CDVUN00@fe-emea-09.sun.com> (original mail from Gerry.Haskins@Sun.COM); Fri, 09 Jan 2009 11:58:26 +0000 (GMT) Received: from [129.156.220.75] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD700C9BD906700@fe-emea-09.sun.com>; Fri, 09 Jan 2009 11:58:13 +0000 (GMT) Date: Fri, 09 Jan 2009 11:58:12 +0000 From: Gerry.Haskins@sun.com Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <20090109110603.GB41514@submonkey.net> Sender: Gerry.Haskins@sun.com To: Ceri Davies Cc: James Carlson , "Garrett D'Amore" , Ondrej.Kubecka@sun.com, update_re@sun.com, Jaromir.Sedlacek@sun.com, PSARC-ext@sun.com, Gerald Jelinek , Roisin.Doran@sun.com Message-id: <49673BD4.2050508@Sun.COM> MIME-version: 1.0 Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <49666367.2050104@sun.com> <18790.27060.922451.793767@gargle.gargle.HOWL> <20090109110603.GB41514@submonkey.net> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Content-Length: 4370 Status: RO X-Status: $$$$ X-UID: 0000000013 Hi Folks!

We're not going to run out of patch numbers in our lifetime.

We're currently up to 140xxx, (started at 100000 many many years ago), and we release approximately 4,500 patches a year and a couple of thousand IDRs.

Adding another prefix analogous to "IDR" would be considerably more work as a large number of tools would need to be modified to accept the new prefix - patchadd, patchrm, the Patch Pipeline, the Freshbitting process used to pre-apply patches into Solaris Update release images, Patch System Test tools, getpatchid, and probably also xVM Ops Center, Update Connection, smpatch, Update Manager, third party tools such as 'pca', etc.

Using the 900xxx number range makes such patches more obvious than they currently are (currently there's no special designation at all except the words "script patch" or "special patch" in the patch README file).  Using the 900xxx range presents a reasonable compromise between being able to easily identify such patches to enable "Update on Attach" to work as intended, and the work necessary to implement such an identification scheme - only getpatchid needs to be modified to produce 900xxx number for such patches.  The 900xxx route enables us to remove a major barrier to the correct operation of "Update on Attach" as quickly as possible.

BTW: "Update on Attach" looks like a really promising way to remove some major customer patching dissatisfiers around Zones. 

Firstly it can be used to clean-up systems where the non-global zone's patch level has gotten out-of-sync with respect to the global zone, for example due to the non-global zone running out of space during patch application.  This has been problematic to recover from up until now.   With "Update on Attach", the customer can simply sort out the space issue, detach the non-global zone, reattach using "Update on Attach", and the non-global zone's patch level with be automagically updated to the same level as the global zone. 

Secondly, and even more important, "Update on Attach" looks like it has great potential to solve the key customer dissatisfier of zones patching performance.  This is a huge problem for customers with limited maintenance windows.  "Update on Attach" looks to be considerably more performant than even the zones parallel patching solution we're working on with Install Sustaining.  With "Update on Attach", the user can detach the non-global zones, patch the global zone, then reattach the non-global zones and "Update on Attach" will automagically bring the non-global zones up to the same level as the global zone far, far faster than via patchadd. 

So it's important we remove this special patch barrier to "Update on Attach" as soon as possible to enable customers to leverage this cool feature to its full potential.

Best Wishes,

Gerry.
(Director, Software Patch Services)

On 01/09/09 11:06, Ceri Davies wrote: 
On Thu, Jan 08, 2009 at 04:01:40PM -0500, James Carlson wrote:
  
Garrett D'Amore writes:
    
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?
      
I don't see the problem you do.  Who cares about the numbering system
used for patch IDs, and how is any numbering choice for a patch an
architectural issue to begin with?

I see it as only goodness -- it makes it clear (to anyone who cares)
that these are very special "patches" and don't really exist anywhere
other than inside the fiction of updates.
    

A prefix, such as we already get with IDRxxxxxx-xx, would make it equally
clear, if not clearer.

Ceri
From Gerald.Jelinek@sun.com Tue Jan 13 12:59:47 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0DKxkRY010424 for ; Tue, 13 Jan 2009 12:59:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0DKxYCD000550; Tue, 13 Jan 2009 20:59:45 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDF00C05GZLP200@brm-avmta-1.central.sun.com>; Tue, 13 Jan 2009 13:59:45 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDF008QWGZLG040@brm-avmta-1.central.sun.com>; Tue, 13 Jan 2009 13:59:45 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0DKxjf5024580; Tue, 13 Jan 2009 20:59:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDF00C01FPMKZ00@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM); Tue, 13 Jan 2009 13:59:45 -0700 (MST) Received: from [192.168.0.11] ([206.53.29.107]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDF00A2CGZ4A9E0@mail-amer.sun.com>; Tue, 13 Jan 2009 13:59:30 -0700 (MST) Date: Tue, 13 Jan 2009 13:59:28 -0700 From: Jerry Jelinek Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <49668F73.90206@sun.com> Sender: Gerald.Jelinek@sun.com To: PSARC-ext@sun.com Cc: "Jonathan O'Brien" , Gerald Jelinek , Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <496D00B0.7080809@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <496683D6.4090006@sun.com> <496689B3.7080405@sun.com> <49668F73.90206@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 5239 Status: RO X-Status: $$$$ X-UID: 0000000014 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 From gdamore@sun.com Tue Jan 13 13:02:30 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0DL2UIf010659 for ; Tue, 13 Jan 2009 13:02:30 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0DL28K0020492; Tue, 13 Jan 2009 13:02:30 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDF00807H42K600@nwk-avmta-2.sfbay.sun.com>; Tue, 13 Jan 2009 13:02:26 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDF00310H40Q980@nwk-avmta-2.sfbay.sun.com>; Tue, 13 Jan 2009 13:02:24 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0DL2O3l012222; Tue, 13 Jan 2009 13:02:24 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDF00201H09FF00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Tue, 13 Jan 2009 13:02:24 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDF006RVH3UJLE0@fe-sfbay-10.sun.com>; Tue, 13 Jan 2009 13:02:19 -0800 (PST) Date: Tue, 13 Jan 2009 12:52:48 -0800 From: "Garrett D'Amore" Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <496D00B0.7080809@sun.com> Sender: Garrett.Damore@sun.com To: Jerry Jelinek Cc: PSARC-ext@sun.com, "Jonathan O'Brien" , Gerald Jelinek , Gerry.Haskins@sun.com, Jaromir.Sedlacek@sun.com, Ondrej.Kubecka@sun.com, Roisin.Doran@sun.com, update_re@sun.com Message-id: <496CFF20.9050602@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> <496683D6.4090006@sun.com> <496689B3.7080405@sun.com> <49668F73.90206@sun.com> <496D00B0.7080809@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Content-Length: 5520 Status: RO X-Status: $$$$ X-UID: 0000000015 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 From Gerald.Jelinek@Sun.COM Tue Jan 20 06:17:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0KEHpwl026608 for ; Tue, 20 Jan 2009 06:17:52 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0KEHmNQ017252; Tue, 20 Jan 2009 14:17:50 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDR00601X1QSO00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Jan 2009 06:17:50 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDR004XIX1PVF30@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Jan 2009 06:17:49 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0KEHnjw016766; Tue, 20 Jan 2009 14:17:49 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDR00J01WB08200@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM); Tue, 20 Jan 2009 07:17:49 -0700 (MST) Received: from [192.168.0.11] ([206.53.29.107]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDR00B04X1M4NC0@mail-amer.sun.com>; Tue, 20 Jan 2009 07:17:47 -0700 (MST) Date: Tue, 20 Jan 2009 07:17:46 -0700 From: Jerry Jelinek Subject: Re: Identifying special patches [PSARC/2009/012 FastTrack timeout 01/16/2009] In-reply-to: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> Sender: Gerald.Jelinek@Sun.COM To: PSARC-ext@Sun.COM Cc: Gerry.Haskins@Sun.COM, Jaromir.Sedlacek@Sun.COM, Ondrej.Kubecka@Sun.COM, Roisin.Doran@Sun.COM, update_re@Sun.COM Message-id: <4975DD0A.6000609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901081957.n08JvGNr007388@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Status: RO Content-Length: 97 This case timed out last Friday with no objections. I marked it closed approved. Thanks, Jerry