From blu@sac.sfbay.sun.com Fri Dec 14 06:43:04 2007 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 lBEEh3ZJ008371 for ; Fri, 14 Dec 2007 06:43: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 lBEEggRl024804; Fri, 14 Dec 2007 14:43:02 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 <0JT100C01NJNOQ00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Dec 2007 06:42:59 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT100MMONJMBU90@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Dec 2007 06:42:58 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBEEgqP7044469; Fri, 14 Dec 2007 06:42:52 -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 lBEEZLee008281; Fri, 14 Dec 2007 06:35:21 -0800 (PST) Received: (from blu@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lBEEZL5p008277; Fri, 14 Dec 2007 06:35:21 -0800 (PST) Date: Fri, 14 Dec 2007 06:35:21 -0800 (PST) From: Brian Utterback Subject: Re-syncing out-of-sync zones [PSARC/2007/691 FastTrack timeout 12/21/2007] To: PSARC-ext@sun.com Cc: Nagaraj.Yedathore@sun.com, Stuart.Clayton@sun.com Message-id: <200712141435.lBEEZL5p008277@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 6049 I am sponsoring this Fasttrack on behalf of Nagaraj Yedathore. The exposure is open. Patch binding is requested. The case times out on December 21. Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Re-syncing out-of-sync zones 1.2. Name of Document Author/Supplier: Author: Nagaraj Yedathore 1.3 Date of This Document: 14 December, 2007 4. Technical Description Summary ------- This proposed enhancement will allow the patching utility to add or remove global patches to or from non-global zones that have become out of step with the global zone following error conditions encountered during global patching operations. Problem ------- The "pdo" binary, which provides the "patchadd" and "patchrm" user commands, handles the application and removal of global patches by first carrying out the operation on the global zone itself, and then each of the non-global zones in turn. However, when a failure occurs in any of the non-global zones, pdo tolerates it by reporting the error, but continues the operation in any further zones. This leads to two situations in which the patch level in a non-global zone can be out of step with the global zone: 1/ If a "patchadd" fails in one of the non-global zones, that zone will then be missing the patch which is present in the global zone, and will be behind the global patch level. 2/ If a "patchrm" fails in one of the non-global zones, that zone will then retain the patch which has been removed from the global zone, and will be ahead of the global patch level. The problem then is that when "patchadd" or "patchrm" are run again, "pdo" performs dependency checks on the requested patching operation before starting the operation in the non-global zones, but these checks only account for the global zone. Because of an implicit assumption that the patch levels in the non-global zones will always match those in the global zone, "pdo" then incorrectly assumes that the requested operation is unnecessary, and exits without taking any action. In the case of global patches, "pdo" cannot be run individually in non-global zones, so the only way for this to be corrected is to either reverse and repeat the patching operation, or to uninstall and then reinstall the non-global zone. Neither of these options is generally attractive, but the problem is particularly difficult when the patch in question is the Kernel update patch. Solution -------- The "pdo" implementations of "patchadd" and "patchrm" support an undocumented feature which allows the patching of particular named zones via a "zonelist" argument. For example, the following command line would be used to add the patch "123456-78" to only zones "zone1" and "zone2": # patchadd -O "zonelist=zone1 zone2" 123456-78 However, in the case of global patches, "pdo" detects that a patching operation is being attempted non-globally, and displays an error message before exiting without allowing the operation. The proposal is therefore to add a further option which can be specified alongside the "zonelist" in order to indicate that the dependency checks in the global zone should be ignored, because an attempt is being made to re-synchronize a non-global zone whose patch state must not be assumed to match that of the global zone. In this case, "pdo" will start the patching operation in the indicated non-global zones, where dependency checking is then done on a zone-specific basis before any further action is taken. The new proposed argument is "-O retry", and would be added to the existing code which parses the "zonelist" argument such that it could be specified either by itself, or with a "," separator as shown: # patchadd -O retry -O "zonelist=zone1 zone2" 123456-78 . . . or . . . # patchadd -O "zonelist=zone1 zone2,retry" 123456-78 In addition, since it may not always be known which zones are out of step with the global zone, it it propsed that the "retry" argument will automatically imply a "zonelist" consisting of all the non-global zones on the system if no other "zonelist" argument is explicitly specified. For example: # patchadd -O retry 123456-78 This will exploit the fact that dependency checks are run in the non-global zones before the patching operations are carried out, so by requesting the operation in every zone only those which are found to be out of step will be updated. Finally, because of a peculiarity in the way that "pdo" handles information about the status of requested patch operations, the global zone must specifically be barred from the "zonelist" when the "retry" option is used, otherwise the effect of the "retry" option will be negated. To summarize, the "-O retry" option will: 1/ Apply to both "patchadd" and "patchrm" commands. 2/ Prevent dependency checking in the global zone, allowing the patching operations to be passed to the non-global zones where specific dependency checks are done anyway. 3/ Allow the patching operations to be run on any non-global zones specified via the "zonelist" argument, or all non-global zones on the system by default. 4/ Prevent the global zone from being included in a "zonelist" by displaying an error message and exiting. Interfaces ---------- Interface Stability Description ========= ========= =========== option -O retry Uncommitted Allow "patchadd" and "patchrm" to carry out patching operations on global patches in separate non-global zones. References ---------- RFE 6540979: "patchadd RFE to incrementally patch non global zones that are out of sync with the global zone." 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: admininstall 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From edward.pilatowicz@sun.com Fri Dec 14 09:47:43 2007 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 lBEHlgFR010906 for ; Fri, 14 Dec 2007 09:47:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBEHlXn4005660; Sat, 15 Dec 2007 01:47:38 +0800 (SGT) 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 <0JT100C1LW3AUS00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Dec 2007 09:47:34 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT100BQ6W39CB00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Dec 2007 09:47:33 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBEHlXZ0383211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2007 09:47:33 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id lBEHlX0m383210; Fri, 14 Dec 2007 09:47:33 -0800 (PST) Date: Fri, 14 Dec 2007 09:47:33 -0800 From: Edward Pilatowicz Subject: Re: Re-syncing out-of-sync zones [PSARC/2007/691 FastTrack timeout 12/21/2007] In-reply-to: <200712141435.lBEEZL5p008277@sac.sfbay.sun.com> To: Brian Utterback Cc: psarc-ext@sun.com, Nagaraj.Yedathore@sun.com, Stuart.Clayton@sun.com Message-id: <20071214174733.GA374066@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712141435.lBEEZL5p008277@sac.sfbay.sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 7167 this case seems to have a lot of overlap with: PSARC/2007/621 zone update on attach 6480464 RFE: zoneadm attach should patch/update the zone to the new hosts level has this case been discussed with with Jerry? I see that the intended commitment level is "Uncommitted". so what is the planned usage for this new flag? If it's only going to be used internally by tools shipped from sun then it sounds like it might be ok (althought you should still talk to jerry), but if we're expecting customers to use these new options then i'm not sure it's the right approach. perhaps if patching of a zone fails the zone should be automatically detached, and then the patch re-application could be handled automatically by PSARC/2007/621 (which is a public and committed interface). ed On Fri, Dec 14, 2007 at 06:35:21AM -0800, Brian Utterback wrote: > > I am sponsoring this Fasttrack on behalf of Nagaraj Yedathore. The exposure > is open. Patch binding is requested. The case times out on December 21. > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Re-syncing out-of-sync zones > 1.2. Name of Document Author/Supplier: > Author: Nagaraj Yedathore > 1.3 Date of This Document: > 14 December, 2007 > 4. Technical Description > Summary > ------- > > This proposed enhancement will allow the patching utility to add or > remove global patches to or from non-global zones that have become out > of step with the global zone following error conditions encountered > during global patching operations. > > Problem > ------- > > The "pdo" binary, which provides the "patchadd" and "patchrm" user > commands, handles the application and removal of global patches by first > carrying out the operation on the global zone itself, and then each of > the non-global zones in turn. > > However, when a failure occurs in any of the non-global zones, pdo > tolerates it by reporting the error, but continues the operation in > any further zones. > > This leads to two situations in which the patch level in a non-global > zone can be out of step with the global zone: > > 1/ If a "patchadd" fails in one of the non-global zones, that zone > will then be missing the patch which is present in the global zone, > and will be behind the global patch level. > > 2/ If a "patchrm" fails in one of the non-global zones, that zone will > then retain the patch which has been removed from the global zone, > and will be ahead of the global patch level. > > The problem then is that when "patchadd" or "patchrm" are run again, > "pdo" performs dependency checks on the requested patching operation > before starting the operation in the non-global zones, but these > checks only account for the global zone. Because of an implicit > assumption that the patch levels in the non-global zones will always > match those in the global zone, "pdo" then incorrectly assumes that > the requested operation is unnecessary, and exits without taking any > action. > > In the case of global patches, "pdo" cannot be run individually in > non-global zones, so the only way for this to be corrected is to > either reverse and repeat the patching operation, or to uninstall and > then reinstall the non-global zone. Neither of these options is > generally attractive, but the problem is particularly difficult when > the patch in question is the Kernel update patch. > > Solution > -------- > > The "pdo" implementations of "patchadd" and "patchrm" support an > undocumented feature which allows the patching of particular named > zones via a "zonelist" argument. For example, the following command > line would be used to add the patch "123456-78" to only zones "zone1" > and "zone2": > > # patchadd -O "zonelist=zone1 zone2" 123456-78 > > However, in the case of global patches, "pdo" detects that a patching > operation is being attempted non-globally, and displays an error > message before exiting without allowing the operation. > > The proposal is therefore to add a further option which can be > specified alongside the "zonelist" in order to indicate that the > dependency checks in the global zone should be ignored, because an > attempt is being made to re-synchronize a non-global zone whose patch > state must not be assumed to match that of the global zone. In this > case, "pdo" will start the patching operation in the indicated > non-global zones, where dependency checking is then done on a > zone-specific basis before any further action is taken. > > The new proposed argument is "-O retry", and would be added to the > existing code which parses the "zonelist" argument such that it could be > specified either by itself, or with a "," separator as shown: > > # patchadd -O retry -O "zonelist=zone1 zone2" 123456-78 > > . . . or . . . > > # patchadd -O "zonelist=zone1 zone2,retry" 123456-78 > > In addition, since it may not always be known which zones are out of > step with the global zone, it it propsed that the "retry" argument > will automatically imply a "zonelist" consisting of all the non-global > zones on the system if no other "zonelist" argument is explicitly > specified. For example: > > # patchadd -O retry 123456-78 > > This will exploit the fact that dependency checks are run in the > non-global zones before the patching operations are carried out, so by > requesting the operation in every zone only those which are found to > be out of step will be updated. > > Finally, because of a peculiarity in the way that "pdo" handles > information about the status of requested patch operations, the global > zone must specifically be barred from the "zonelist" when the "retry" > option is used, otherwise the effect of the "retry" option will be > negated. > > To summarize, the "-O retry" option will: > > 1/ Apply to both "patchadd" and "patchrm" commands. > > 2/ Prevent dependency checking in the global zone, allowing the > patching operations to be passed to the non-global zones where > specific dependency checks are done anyway. > > 3/ Allow the patching operations to be run on any non-global zones > specified via the "zonelist" argument, or all non-global zones on > the system by default. > > 4/ Prevent the global zone from being included in a "zonelist" by > displaying an error message and exiting. > > > Interfaces > ---------- > > Interface Stability Description > ========= ========= =========== > > option -O retry Uncommitted Allow "patchadd" and "patchrm" > to carry out patching operations > on global patches in separate > non-global zones. > > > References > ---------- > > RFE 6540979: "patchadd RFE to incrementally patch non global zones > that are out of sync with the global zone." > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > admininstall > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open From isaac@sun.com Fri Dec 14 10:22:26 2007 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 lBEIMQGn011444 for ; Fri, 14 Dec 2007 10:22:26 -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 lBEIMOb7027957 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 14 Dec 2007 18:22:24 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 <0JT10050TXPB3N00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Dec 2007 10:22:23 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT10005PXP7F480@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Dec 2007 10:22:19 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBEIMJO3002504 for ; Fri, 14 Dec 2007 18:22:19 +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 <0JT100I01XH1YI00@mail-amer.sun.com> (original mail from isaac@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Dec 2007 11:22:18 -0700 (MST) Received: from [10.71.132.133] (mobile-032-138-164-121.mycingular.net [32.138.164.121]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT10012WXOCHYB0@mail-amer.sun.com>; Fri, 14 Dec 2007 11:22:02 -0700 (MST) Date: Fri, 14 Dec 2007 13:21:24 -0500 From: Isaac Subject: Re: Re-syncing out-of-sync zones [PSARC/2007/691 FastTrack timeout 12/21/2007] In-reply-to: <20071214174733.GA374066@eng.sun.com> Sender: Isaac.Rozenfeld@sun.com To: Edward Pilatowicz Cc: Brian Utterback , "psarc-ext@sun.com" , "Nagaraj.Yedathore@Sun.COM" , "Stuart.Clayton@Sun.COM" Message-id: MIME-version: 1.0 X-Mailer: iPhone Mail (1C28) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712141435.lBEEZL5p008277@sac.sfbay.sun.com> <20071214174733.GA374066@eng.sun.com> Status: RO Content-Length: 7619 I propose that, if patching a zone fails, the decision to detach it would not be automatic. Thx, Isaac On Dec 14, 2007, at 12:47 PM, Edward Pilatowicz wrote: > this case seems to have a lot of overlap with: > PSARC/2007/621 zone update on attach > 6480464 RFE: zoneadm attach should patch/update the zone to the > new hosts level > has this case been discussed with with Jerry? > > I see that the intended commitment level is "Uncommitted". so what is > the planned usage for this new flag? If it's only going to be used > internally by tools shipped from sun then it sounds like it might be > ok > (althought you should still talk to jerry), but if we're expecting > customers > to use these new options then i'm not sure it's the right approach. > perhaps > if patching of a zone fails the zone should be automatically > detached, and > then the patch re-application could be handled automatically by > PSARC/2007/621 > (which is a public and committed interface). > > ed > > On Fri, Dec 14, 2007 at 06:35:21AM -0800, Brian Utterback wrote: >> >> I am sponsoring this Fasttrack on behalf of Nagaraj Yedathore. The >> exposure >> is open. Patch binding is requested. The case times out on December >> 21. >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Re-syncing out-of-sync zones >> 1.2. Name of Document Author/Supplier: >> Author: Nagaraj Yedathore >> 1.3 Date of This Document: >> 14 December, 2007 >> 4. Technical Description >> Summary >> ------- >> >> This proposed enhancement will allow the patching utility to add or >> remove global patches to or from non-global zones that have become >> out >> of step with the global zone following error conditions encountered >> during global patching operations. >> >> Problem >> ------- >> >> The "pdo" binary, which provides the "patchadd" and "patchrm" user >> commands, handles the application and removal of global patches by >> first >> carrying out the operation on the global zone itself, and then each >> of >> the non-global zones in turn. >> >> However, when a failure occurs in any of the non-global zones, pdo >> tolerates it by reporting the error, but continues the operation in >> any further zones. >> >> This leads to two situations in which the patch level in a non-global >> zone can be out of step with the global zone: >> >> 1/ If a "patchadd" fails in one of the non-global zones, that zone >> will then be missing the patch which is present in the global zone, >> and will be behind the global patch level. >> >> 2/ If a "patchrm" fails in one of the non-global zones, that zone >> will >> then retain the patch which has been removed from the global zone, >> and will be ahead of the global patch level. >> >> The problem then is that when "patchadd" or "patchrm" are run again, >> "pdo" performs dependency checks on the requested patching operation >> before starting the operation in the non-global zones, but these >> checks only account for the global zone. Because of an implicit >> assumption that the patch levels in the non-global zones will always >> match those in the global zone, "pdo" then incorrectly assumes that >> the requested operation is unnecessary, and exits without taking any >> action. >> >> In the case of global patches, "pdo" cannot be run individually in >> non-global zones, so the only way for this to be corrected is to >> either reverse and repeat the patching operation, or to uninstall and >> then reinstall the non-global zone. Neither of these options is >> generally attractive, but the problem is particularly difficult when >> the patch in question is the Kernel update patch. >> >> Solution >> -------- >> >> The "pdo" implementations of "patchadd" and "patchrm" support an >> undocumented feature which allows the patching of particular named >> zones via a "zonelist" argument. For example, the following command >> line would be used to add the patch "123456-78" to only zones "zone1" >> and "zone2": >> >> # patchadd -O "zonelist=zone1 zone2" 123456-78 >> >> However, in the case of global patches, "pdo" detects that a patching >> operation is being attempted non-globally, and displays an error >> message before exiting without allowing the operation. >> >> The proposal is therefore to add a further option which can be >> specified alongside the "zonelist" in order to indicate that the >> dependency checks in the global zone should be ignored, because an >> attempt is being made to re-synchronize a non-global zone whose patch >> state must not be assumed to match that of the global zone. In this >> case, "pdo" will start the patching operation in the indicated >> non-global zones, where dependency checking is then done on a >> zone-specific basis before any further action is taken. >> >> The new proposed argument is "-O retry", and would be added to the >> existing code which parses the "zonelist" argument such that it >> could be >> specified either by itself, or with a "," separator as shown: >> >> # patchadd -O retry -O "zonelist=zone1 zone2" 123456-78 >> >> . . . or . . . >> >> # patchadd -O "zonelist=zone1 zone2,retry" 123456-78 >> >> In addition, since it may not always be known which zones are out of >> step with the global zone, it it propsed that the "retry" argument >> will automatically imply a "zonelist" consisting of all the non- >> global >> zones on the system if no other "zonelist" argument is explicitly >> specified. For example: >> >> # patchadd -O retry 123456-78 >> >> This will exploit the fact that dependency checks are run in the >> non-global zones before the patching operations are carried out, so >> by >> requesting the operation in every zone only those which are found to >> be out of step will be updated. >> >> Finally, because of a peculiarity in the way that "pdo" handles >> information about the status of requested patch operations, the >> global >> zone must specifically be barred from the "zonelist" when the "retry" >> option is used, otherwise the effect of the "retry" option will be >> negated. >> >> To summarize, the "-O retry" option will: >> >> 1/ Apply to both "patchadd" and "patchrm" commands. >> >> 2/ Prevent dependency checking in the global zone, allowing the >> patching operations to be passed to the non-global zones where >> specific dependency checks are done anyway. >> >> 3/ Allow the patching operations to be run on any non-global zones >> specified via the "zonelist" argument, or all non-global zones on >> the system by default. >> >> 4/ Prevent the global zone from being included in a "zonelist" by >> displaying an error message and exiting. >> >> >> Interfaces >> ---------- >> >> Interface Stability Description >> ========= ========= =========== >> >> option -O retry Uncommitted Allow "patchadd" and "patchrm" >> to carry out patching operations >> on global patches in separate >> non-global zones. >> >> >> References >> ---------- >> >> RFE 6540979: "patchadd RFE to incrementally patch non global zones >> that are out of sync with the global zone." >> >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> admininstall >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open From Nagaraj.Yedathore@sun.com Tue Dec 18 06:22:59 2007 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 lBIEMwNw017782 for ; Tue, 18 Dec 2007 06:22:59 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBIEMp8u013861 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 18 Dec 2007 22:22:57 +0800 (SGT) 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 <0JT90071X1A6ZB00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 06:22:54 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT9005BR1A5AO80@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 06:22:54 -0800 (PST) Received: from fe-apac-01.sun.com (fe-apac-01.sun.com [192.18.19.172] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBIEMqTQ025653 for ; Tue, 18 Dec 2007 14:22:52 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JT900M01043QT00@mail-apac.sun.com> (original mail from Nagaraj.Yedathore@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 22:22:52 +0800 (SGT) Received: from [129.158.226.97] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JT900KTT1A3BZ42@mail-apac.sun.com>; Tue, 18 Dec 2007 22:22:52 +0800 (SGT) Date: Tue, 18 Dec 2007 19:54:43 +0530 From: Nagaraj Yedathore Subject: Re: Re-syncing out-of-sync zones [PSARC/2007/691 FastTrack timeout 12/21/2007] In-reply-to: <20071214174733.GA374066@eng.sun.com> Sender: Nagaraj.Yedathore@sun.com To: Edward Pilatowicz Cc: Brian Utterback , psarc-ext@sun.com, Stuart.Clayton@sun.com Message-id: <4767D82B.5020407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712141435.lBEEZL5p008277@sac.sfbay.sun.com> <20071214174733.GA374066@eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 8276 Ed, That's a good point. We will discuss with Jerry if that can resolve the problem. But a few points. The retry option is not a public interface and used only for the administration purpose. The reason for our case is the support requirement is to be able to apply patches to non-global zones that are already present in the global zone following an installation failure. With this in mind, It would not be appropriate to automatically detach the non-global zone when a patch failure occurs because action will generally be needed to clear the cause of the patch failure before the patch can be re-applied. The other factor is that, we need updating the zone to a patch level on a selective basis. Upon zone attach if a zone if scheduled for an update of a bunch of patches with various complexity while the requirement may not have update to that extent. Thanks, Nagaraj. Edward Pilatowicz wrote: > this case seems to have a lot of overlap with: > PSARC/2007/621 zone update on attach > 6480464 RFE: zoneadm attach should patch/update the zone to the new hosts level > has this case been discussed with with Jerry? > > I see that the intended commitment level is "Uncommitted". so what is > the planned usage for this new flag? If it's only going to be used > internally by tools shipped from sun then it sounds like it might be ok > (althought you should still talk to jerry), but if we're expecting customers > to use these new options then i'm not sure it's the right approach. perhaps > if patching of a zone fails the zone should be automatically detached, and > then the patch re-application could be handled automatically by PSARC/2007/621 > (which is a public and committed interface). > > ed > > On Fri, Dec 14, 2007 at 06:35:21AM -0800, Brian Utterback wrote: > >> I am sponsoring this Fasttrack on behalf of Nagaraj Yedathore. The exposure >> is open. Patch binding is requested. The case times out on December 21. >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Re-syncing out-of-sync zones >> 1.2. Name of Document Author/Supplier: >> Author: Nagaraj Yedathore >> 1.3 Date of This Document: >> 14 December, 2007 >> 4. Technical Description >> Summary >> ------- >> >> This proposed enhancement will allow the patching utility to add or >> remove global patches to or from non-global zones that have become out >> of step with the global zone following error conditions encountered >> during global patching operations. >> >> Problem >> ------- >> >> The "pdo" binary, which provides the "patchadd" and "patchrm" user >> commands, handles the application and removal of global patches by first >> carrying out the operation on the global zone itself, and then each of >> the non-global zones in turn. >> >> However, when a failure occurs in any of the non-global zones, pdo >> tolerates it by reporting the error, but continues the operation in >> any further zones. >> >> This leads to two situations in which the patch level in a non-global >> zone can be out of step with the global zone: >> >> 1/ If a "patchadd" fails in one of the non-global zones, that zone >> will then be missing the patch which is present in the global zone, >> and will be behind the global patch level. >> >> 2/ If a "patchrm" fails in one of the non-global zones, that zone will >> then retain the patch which has been removed from the global zone, >> and will be ahead of the global patch level. >> >> The problem then is that when "patchadd" or "patchrm" are run again, >> "pdo" performs dependency checks on the requested patching operation >> before starting the operation in the non-global zones, but these >> checks only account for the global zone. Because of an implicit >> assumption that the patch levels in the non-global zones will always >> match those in the global zone, "pdo" then incorrectly assumes that >> the requested operation is unnecessary, and exits without taking any >> action. >> >> In the case of global patches, "pdo" cannot be run individually in >> non-global zones, so the only way for this to be corrected is to >> either reverse and repeat the patching operation, or to uninstall and >> then reinstall the non-global zone. Neither of these options is >> generally attractive, but the problem is particularly difficult when >> the patch in question is the Kernel update patch. >> >> Solution >> -------- >> >> The "pdo" implementations of "patchadd" and "patchrm" support an >> undocumented feature which allows the patching of particular named >> zones via a "zonelist" argument. For example, the following command >> line would be used to add the patch "123456-78" to only zones "zone1" >> and "zone2": >> >> # patchadd -O "zonelist=zone1 zone2" 123456-78 >> >> However, in the case of global patches, "pdo" detects that a patching >> operation is being attempted non-globally, and displays an error >> message before exiting without allowing the operation. >> >> The proposal is therefore to add a further option which can be >> specified alongside the "zonelist" in order to indicate that the >> dependency checks in the global zone should be ignored, because an >> attempt is being made to re-synchronize a non-global zone whose patch >> state must not be assumed to match that of the global zone. In this >> case, "pdo" will start the patching operation in the indicated >> non-global zones, where dependency checking is then done on a >> zone-specific basis before any further action is taken. >> >> The new proposed argument is "-O retry", and would be added to the >> existing code which parses the "zonelist" argument such that it could be >> specified either by itself, or with a "," separator as shown: >> >> # patchadd -O retry -O "zonelist=zone1 zone2" 123456-78 >> >> . . . or . . . >> >> # patchadd -O "zonelist=zone1 zone2,retry" 123456-78 >> >> In addition, since it may not always be known which zones are out of >> step with the global zone, it it propsed that the "retry" argument >> will automatically imply a "zonelist" consisting of all the non-global >> zones on the system if no other "zonelist" argument is explicitly >> specified. For example: >> >> # patchadd -O retry 123456-78 >> >> This will exploit the fact that dependency checks are run in the >> non-global zones before the patching operations are carried out, so by >> requesting the operation in every zone only those which are found to >> be out of step will be updated. >> >> Finally, because of a peculiarity in the way that "pdo" handles >> information about the status of requested patch operations, the global >> zone must specifically be barred from the "zonelist" when the "retry" >> option is used, otherwise the effect of the "retry" option will be >> negated. >> >> To summarize, the "-O retry" option will: >> >> 1/ Apply to both "patchadd" and "patchrm" commands. >> >> 2/ Prevent dependency checking in the global zone, allowing the >> patching operations to be passed to the non-global zones where >> specific dependency checks are done anyway. >> >> 3/ Allow the patching operations to be run on any non-global zones >> specified via the "zonelist" argument, or all non-global zones on >> the system by default. >> >> 4/ Prevent the global zone from being included in a "zonelist" by >> displaying an error message and exiting. >> >> >> Interfaces >> ---------- >> >> Interface Stability Description >> ========= ========= =========== >> >> option -O retry Uncommitted Allow "patchadd" and "patchrm" >> to carry out patching operations >> on global patches in separate >> non-global zones. >> >> >> References >> ---------- >> >> RFE 6540979: "patchadd RFE to incrementally patch non global zones >> that are out of sync with the global zone." >> >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> admininstall >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> From brian.utterback@sun.com Tue Jan 22 08:12:40 2008 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 m0MGCdFj010528 for ; Tue, 22 Jan 2008 08:12:40 -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 m0MGCSl3029860 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 22 Jan 2008 16:12:38 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 <0JV10001LZP1YZ00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Jan 2008 08:12:37 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV1000RMZOYJ010@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Jan 2008 08:12:34 -0800 (PST) Received: from [129.148.226.14] (sr1-unsh01-04.East.Sun.COM [129.148.226.14]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0MGCUFO031391; Tue, 22 Jan 2008 11:12:31 -0500 (EST) Date: Tue, 22 Jan 2008 11:12:30 -0500 From: Brian Utterback Subject: Re: Re-syncing out-of-sync zones [PSARC/2007/691 FastTrack timeout 12/21/2007] In-reply-to: To: "psarc-ext@sun.com" Cc: "Nagaraj.Yedathore@Sun.COM" , "Stuart.Clayton@Sun.COM" Message-id: <479615EE.1010400@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712141435.lBEEZL5p008277@sac.sfbay.sun.com> <20071214174733.GA374066@eng.sun.com> User-Agent: Thunderbird 2.0.0.12pre (X11/20080120) Status: RO Content-Length: 8149 The timer has expired and I just received word that the project team has resolved the outstanding issues, so I am marking this as closed approved. Isaac wrote: > I propose that, if patching a zone fails, the decision to detach it > would not be automatic. > > Thx, > Isaac > > On Dec 14, 2007, at 12:47 PM, Edward Pilatowicz > wrote: > >> this case seems to have a lot of overlap with: >> PSARC/2007/621 zone update on attach >> 6480464 RFE: zoneadm attach should patch/update the zone to the new >> hosts level >> has this case been discussed with with Jerry? >> >> I see that the intended commitment level is "Uncommitted". so what is >> the planned usage for this new flag? If it's only going to be used >> internally by tools shipped from sun then it sounds like it might be ok >> (althought you should still talk to jerry), but if we're expecting >> customers >> to use these new options then i'm not sure it's the right approach. >> perhaps >> if patching of a zone fails the zone should be automatically detached, >> and >> then the patch re-application could be handled automatically by >> PSARC/2007/621 >> (which is a public and committed interface). >> >> ed >> >> On Fri, Dec 14, 2007 at 06:35:21AM -0800, Brian Utterback wrote: >>> >>> I am sponsoring this Fasttrack on behalf of Nagaraj Yedathore. The >>> exposure >>> is open. Patch binding is requested. The case times out on December 21. >>> >>> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >>> This information is Copyright 2007 Sun Microsystems >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Re-syncing out-of-sync zones >>> 1.2. Name of Document Author/Supplier: >>> Author: Nagaraj Yedathore >>> 1.3 Date of This Document: >>> 14 December, 2007 >>> 4. Technical Description >>> Summary >>> ------- >>> >>> This proposed enhancement will allow the patching utility to add or >>> remove global patches to or from non-global zones that have become out >>> of step with the global zone following error conditions encountered >>> during global patching operations. >>> >>> Problem >>> ------- >>> >>> The "pdo" binary, which provides the "patchadd" and "patchrm" user >>> commands, handles the application and removal of global patches by first >>> carrying out the operation on the global zone itself, and then each of >>> the non-global zones in turn. >>> >>> However, when a failure occurs in any of the non-global zones, pdo >>> tolerates it by reporting the error, but continues the operation in >>> any further zones. >>> >>> This leads to two situations in which the patch level in a non-global >>> zone can be out of step with the global zone: >>> >>> 1/ If a "patchadd" fails in one of the non-global zones, that zone >>> will then be missing the patch which is present in the global zone, >>> and will be behind the global patch level. >>> >>> 2/ If a "patchrm" fails in one of the non-global zones, that zone will >>> then retain the patch which has been removed from the global zone, >>> and will be ahead of the global patch level. >>> >>> The problem then is that when "patchadd" or "patchrm" are run again, >>> "pdo" performs dependency checks on the requested patching operation >>> before starting the operation in the non-global zones, but these >>> checks only account for the global zone. Because of an implicit >>> assumption that the patch levels in the non-global zones will always >>> match those in the global zone, "pdo" then incorrectly assumes that >>> the requested operation is unnecessary, and exits without taking any >>> action. >>> >>> In the case of global patches, "pdo" cannot be run individually in >>> non-global zones, so the only way for this to be corrected is to >>> either reverse and repeat the patching operation, or to uninstall and >>> then reinstall the non-global zone. Neither of these options is >>> generally attractive, but the problem is particularly difficult when >>> the patch in question is the Kernel update patch. >>> >>> Solution >>> -------- >>> >>> The "pdo" implementations of "patchadd" and "patchrm" support an >>> undocumented feature which allows the patching of particular named >>> zones via a "zonelist" argument. For example, the following command >>> line would be used to add the patch "123456-78" to only zones "zone1" >>> and "zone2": >>> >>> # patchadd -O "zonelist=zone1 zone2" 123456-78 >>> >>> However, in the case of global patches, "pdo" detects that a patching >>> operation is being attempted non-globally, and displays an error >>> message before exiting without allowing the operation. >>> >>> The proposal is therefore to add a further option which can be >>> specified alongside the "zonelist" in order to indicate that the >>> dependency checks in the global zone should be ignored, because an >>> attempt is being made to re-synchronize a non-global zone whose patch >>> state must not be assumed to match that of the global zone. In this >>> case, "pdo" will start the patching operation in the indicated >>> non-global zones, where dependency checking is then done on a >>> zone-specific basis before any further action is taken. >>> >>> The new proposed argument is "-O retry", and would be added to the >>> existing code which parses the "zonelist" argument such that it could be >>> specified either by itself, or with a "," separator as shown: >>> >>> # patchadd -O retry -O "zonelist=zone1 zone2" 123456-78 >>> >>> . . . or . . . >>> >>> # patchadd -O "zonelist=zone1 zone2,retry" 123456-78 >>> >>> In addition, since it may not always be known which zones are out of >>> step with the global zone, it it propsed that the "retry" argument >>> will automatically imply a "zonelist" consisting of all the non-global >>> zones on the system if no other "zonelist" argument is explicitly >>> specified. For example: >>> >>> # patchadd -O retry 123456-78 >>> >>> This will exploit the fact that dependency checks are run in the >>> non-global zones before the patching operations are carried out, so by >>> requesting the operation in every zone only those which are found to >>> be out of step will be updated. >>> >>> Finally, because of a peculiarity in the way that "pdo" handles >>> information about the status of requested patch operations, the global >>> zone must specifically be barred from the "zonelist" when the "retry" >>> option is used, otherwise the effect of the "retry" option will be >>> negated. >>> >>> To summarize, the "-O retry" option will: >>> >>> 1/ Apply to both "patchadd" and "patchrm" commands. >>> >>> 2/ Prevent dependency checking in the global zone, allowing the >>> patching operations to be passed to the non-global zones where >>> specific dependency checks are done anyway. >>> >>> 3/ Allow the patching operations to be run on any non-global zones >>> specified via the "zonelist" argument, or all non-global zones on >>> the system by default. >>> >>> 4/ Prevent the global zone from being included in a "zonelist" by >>> displaying an error message and exiting. >>> >>> >>> Interfaces >>> ---------- >>> >>> Interface Stability Description >>> ========= ========= =========== >>> >>> option -O retry Uncommitted Allow "patchadd" and "patchrm" >>> to carry out patching operations >>> on global patches in separate >>> non-global zones. >>> >>> >>> References >>> ---------- >>> >>> RFE 6540979: "patchadd RFE to incrementally patch non global zones >>> that are out of sync with the global zone." >>> >>> >>> 6. Resources and Schedule >>> 6.4. Steering Committee requested information >>> 6.4.1. Consolidation C-team Name: >>> admininstall >>> 6.5. ARC review type: FastTrack >>> 6.6. ARC Exposure: open -- blu "Mr. Jefferson, build up that wall!" ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom