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 >>
