From sacadmin Mon Oct 29 06:44:31 2007 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 l9TDiV2g009156; Mon, 29 Oct 2007 06:44:31 -0700 (PDT) Received: (from gjelinek@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l9TDiVgh009152; Mon, 29 Oct 2007 06:44:31 -0700 (PDT) Date: Mon, 29 Oct 2007 06:44:31 -0700 (PDT) From: Gerald Jelinek Message-Id: <200710291344.l9TDiVgh009152@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: zone update on attach [PSARC/2007/621 FastTrack timeout 10/05/2007] Status: RO Content-Length: 559 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: zone update on attach 1.2. Name of Document Author/Supplier: Author: Gerald Jelinek 1.3 Date of This Document: 29 October, 2007 4. Technical Description See the case directory for more detail 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 sacadmin Mon Oct 29 06:52:19 2007 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9TDqJ0q009206; Mon, 29 Oct 2007 06:52:19 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9TDmkG8036146; Mon, 29 Oct 2007 06:48:46 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9TDmkvl020879; Mon, 29 Oct 2007 13:48:46 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 <0JQO00401E788W00@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM); Mon, 29 Oct 2007 07:48:46 -0600 (MDT) Received: from [10.7.251.2] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQO0041NED5FVG0@mail-amer.sun.com>; Mon, 29 Oct 2007 07:48:42 -0600 (MDT) Date: Mon, 29 Oct 2007 07:45:28 -0600 From: Jerry Jelinek Subject: Re: zone update on attach [PSARC/2007/621 FastTrack timeout 10/05/2007] In-reply-to: <200710291344.l9TDiVgh009152@sac.sfbay.sun.com> Sender: Gerald.Jelinek@Sun.COM To: PSARC@sac.sfbay.sun.com Cc: Gerald Jelinek Message-id: <4725E3F8.8080607@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200710291344.l9TDiVgh009152@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 8119 I am sponsoring this fast-track for myself. There is a contract associated with this case and I have placed a copy in the case directory. I will have the appropriate managers email the case with their approval. Thanks, Jerry --- SUMMARY: This fast-track enhances the Solaris Zones [1] subsystem to address existing RFEs [2,3] requesting the ability to update a non-global zone when migrating from one machine to another. Currently when we migrate a zone we validate that the destination host has the same pkg versions and patches for the zone-dependent packages as were installed on the source host. This is described in the zone migration ARC case [4]. While this is safe and ensures that the new host is capable of properly supporting the zone, it is also very restrictive. With this enhancement, if the new host has higher versions of the zone-dependent pkgs, or higher versions of patches for those pkgs, then when we attach the zone to the new host we will enable an update of the pkgs and pkg metadata within the zone to match the new host. Patch binding is requested for this "update on attach" capability. The stability of these interfaces is documented in the interface table below. DETAILS: "Update on attach" is different from a traditional zone upgrade. In the traditional upgrade all native zones are upgraded as part of upgrading the base system using a standard Solaris media image as the source for the pkgs to upgrade to. Pkg operations on pkgs with the SUNW_ALLZONES attribute set must be run from the global zone, the operation will be performed on all native zones, and this behavior is built-in to the pkg commands. With "update on attach" we are only updating a single zone. We cannot depend on the basic pkg behavior which updates all zones when a pkg is installed in the global zone. We cannot use standard Solaris media since the host can have a variety of patches installed which have updated the base system pkgs beyond any specific Solaris release. Instead what we want to do is similar to what happens when a zone is initially installed. The spooled pkg data and global zone files are the source for installing the zone. In this way the zone is installed with the correct pkg versions along with any patches that have been applied to those pkgs. We can do something similar for "update on attach". The zone 'attach' validation already generates a list of mismatched pkg versions and patches. We can use this information to determine which dependent pkgs need to be updated so that the zone can run properly on the new host. We will remove the obsolete versions of those pkgs and install the up-to-date version using the pkg data spooled in the global zone. This procedure will preserve any editable or volatile files that are delivered by these pkgs. The normal pkg install scripts and class action scripts are run as part of this process so any updates performed by these scripts will take place. As described in [4] the dependent pkgs are those that have the SUNW_PKG_ALLZONES=true pkg attribute as well as any pkgs installed in an inherited-pkg-dir. Only these pkgs will be updated to match the new host. We will ensure that we will only update a zone to a host running the same or later version of the dependent pkgs. For example, if the new host has a mix of higher and lower version patches as compared to the source host then we will not allow an update during the attach. By default the zone will not be updated during attach. Instead, the existing output listing the pkgs that are out of sync will continue to be printed. We will add a new option (-u) to the 'zoneadm attach' subcommand. When this option is used then zoneadm will update the necessary pkgs during the attach (assuming there are any to update). Because the zone has previously booted and run on the source host it is possible that there could be security issues with directly accessing the zone's filesystem to remove and add pkgs to the zone. To protect against this the pkg operations will be performed within the scratch zone [5]. The scratch zone was defined to address this specific issue for upgrading zones. We cannot use the pkgrm(1M) and pkgadd(1M) commands to update the zone while running within the scratch zone. Those commands explicitly disallow removing or adding a pkg with the SUNW_ALLZONES attribute set unless running in the global zone. Instead we will use the /usr/sadm/install/bin/pkgremove and /usr/sadm/install/bin/pkginstall commands directly. The pkgrm and pkgadd commands are wrappers to those commands. Those commands were formerly part of the ON consolidation but moved to the Install consolidation as part of [6]. That case documents man pages for pkgremove and pkginstall but no such man pages exist. No stability level is documented for these two commands so we're assuming these are consolidation private and a contract is needed to directly use these commands. The command line options being used are: /usr/sadm/install/bin/pkgremove: -a same as public pkgrm option -F private - used by upgrade to suppress actual removal of files delivered by the pkg -M same as public pkgrm option -n same as public pkgrm option -O inherited-filesystem={IPD} private - used to specify the zone's inherited-pkg-dir entries -R same as public pkgrm option /usr/sadm/install/bin/pkginstall: -a same as public pkgrm option -C private - disable checksums since files are installed via a separate copy from the global zone -h private - enable hollow pkg support -N pkgadd private - error msgs use use the name "pkgadd" instead of "pkginstall" -n same as public pkgrm option -O addzonename private - error msgs include zonename -O inherited-filesystem={IPD} private - used to specify the zone's inherited-pkg-dir entries -R same as public pkgrm option -S private - suppress copyright output -t private - suppress spooled pkg creation -z private - install zone pkg data from spooled pkg data EXPORTED INTERFACES zoneadm attach option [-u] Evolving IMPORTED INTERFACES pkgremove, pkginstall and their options described in this case Contracted Consolidation Private REFERENCES 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 2. RFE: zoneadm attach should patch/update the zone to the new hosts level Bugid 6480464 http://bugs.opensolaris.org/view_bug.do?bug_id=6480464 3. RFE: zoneadm detach/attach should work between sun4u and sun4v architecture Bugid 6576592 http://bugs.opensolaris.org/view_bug.do?bug_id=6576592 4. PSARC/2006/030 Zone migration 5. PSARC/2005/474 Zones Upgrade 6. PSARC/2002/274 Move SVr4 Packaging from ON to ADMIN From sacadmin Mon Oct 29 07:11:54 2007 Received: from uask4it.sfbay.sun.com (uask4it [10.7.80.228]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9TEBsgb009647 for ; Mon, 29 Oct 2007 07:11:54 -0700 (PDT) Received: from jerri-ann-meyers-computer.local (punchin-client-10-7-250-39.SFBay.Sun.COM [10.7.250.39]) by uask4it.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l9TE7Jd3011347; Mon, 29 Oct 2007 07:07:20 -0700 (PDT) Message-ID: <4725E96C.5090805@sun.com> Date: Mon, 29 Oct 2007 07:08:44 -0700 From: Jerri-Ann Meyer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com, Jerry Jelinek , "Eric J. Ray" Subject: zone update on attach [PSARC/2007/621 FastTrack timeout 10/05/2007] Content-Type: multipart/mixed; boundary="------------070909080606060603090207" Status: RO Content-Length: 4803 This is a multi-part message in MIME format. --------------070909080606060603090207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I approve this contract. jerri-ann --------------070909080606060603090207 Content-Type: text/plain; name="contract2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="contract2.txt" CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: [The number is assigned by the ARC CASE owner, and has the format CASE-sequence within case; for example, XXARC/1901/952-03. Sequence begins at 01 in each case.] 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris Consolidation: Install Department or Group: Install Bugtraq Category/SubCategory: Responsible Manager: Eric Ray 3. The CONSUMER is identified by the following: Product or Bundle: Solaris Consolidation: ON Department or Group: Zones Bugtraq Category/SubCategory: Responsible Manager: Jerri-Ann Meyer 4. The INTERFACES are: /usr/sadm/install/bin/pkgremove Contracted Unstable /usr/sadm/install/bin/pkginstall use of cmds and options described in this ARC case 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing these INTERFACES is: PSARC/2002/274 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _N_ 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will expose INTERFACES to a PARTNER, which is external to Sun, namely: Name of Company: Name of Department or Group within Company: Responsible Manager: _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same consolidation, they have the option of arranging for simultaneous conversion to the new interfaces. If this is not possible, or if they are not in the same consolidation, then SUPPLIER will either make best effort to work with CONSUMER so that CONSUMER can detect which version of INTERFACES is being supplied, or else SUPPLIER will make best effort to supply both old and new versions of INTERFACES. If SUPPLIER cannot make both versions of INTERFACES available, and SUPPLIER and CONSUMER cannot devise a method whereby CONSUMER can detect which version of INTERFACES is being supplied, and the old version of CONSUMER will not run with the new version of SUPPLIER, then either the EOL process must be followed by SUPPLIER, or else a major release of SUPPLIER will be required, or the change will not be allowed. 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make best effort to accommodate such changes, which shall then be treated in accordance with paragraph 7 above. 9. Notwithstanding paragraphs 7 and 8, a change to any portion of the INTERFACES shall be regarded as a completely new set of INTERFACES which require both ARC approval and execution of a new contract. 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: An ARC case. The Install group wiil notify the Zones group if any changes to these interfaces are planned. 11. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: An ARC case. 12. This contract is not valid until "signed" via agreement from the SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by this contract. E-mail agreement to the contract should be archived in the mail archive of CASE; verbal agreement to the contract should be noted in the meeting minutes. This contract remains valid until superseded or invalidated. For SUPPLIER: Eric Ray Date: For CONSUMER: Jerri-Ann Meyer Date: For ARC: Jerry Jelinek Date: A copy of this contract shall be deposited in the CASE directory as "contract-1" or in a "contracts" subdirectory. 13. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: --------------070909080606060603090207-- From Gerald.Jelinek@Sun.COM Mon Oct 29 07:17:36 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 l9TEHZ6F009725 for ; Mon, 29 Oct 2007 07:17:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9TEE0Iv021569 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 29 Oct 2007 22:14:01 +0800 (SGT) 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 <0JQO0030JFJAFY00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 29 Oct 2007 07:13:58 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQO00KO5FJ9L970@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 29 Oct 2007 07:13:57 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9TEDvAI022439 for ; Mon, 29 Oct 2007 14:13:57 +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 <0JQO00G01EQG4K00@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 29 Oct 2007 08:13:57 -0600 (MDT) Received: from [10.7.251.2] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQO00491FIXFZD0@mail-amer.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 29 Oct 2007 08:13:50 -0600 (MDT) Date: Mon, 29 Oct 2007 08:10:32 -0600 From: Jerry Jelinek Subject: Re: zone update on attach [PSARC/2007/621 FastTrack timeout 10/05/2007] Sender: Gerald.Jelinek@Sun.COM To: PSARC-EXT@Sun.COM Cc: Jerry Jelinek Message-id: <4725E9D8.4030004@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 User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 8170 [Sorry for any duplicates, resending to psarc-ext] I am sponsoring this fast-track for myself. There is a contract associated with this case and I have placed a copy in the case directory. I will have the appropriate managers email the case with their approval. Thanks, Jerry --- SUMMARY: This fast-track enhances the Solaris Zones [1] subsystem to address existing RFEs [2,3] requesting the ability to update a non-global zone when migrating from one machine to another. Currently when we migrate a zone we validate that the destination host has the same pkg versions and patches for the zone-dependent packages as were installed on the source host. This is described in the zone migration ARC case [4]. While this is safe and ensures that the new host is capable of properly supporting the zone, it is also very restrictive. With this enhancement, if the new host has higher versions of the zone-dependent pkgs, or higher versions of patches for those pkgs, then when we attach the zone to the new host we will enable an update of the pkgs and pkg metadata within the zone to match the new host. Patch binding is requested for this "update on attach" capability. The stability of these interfaces is documented in the interface table below. DETAILS: "Update on attach" is different from a traditional zone upgrade. In the traditional upgrade all native zones are upgraded as part of upgrading the base system using a standard Solaris media image as the source for the pkgs to upgrade to. Pkg operations on pkgs with the SUNW_ALLZONES attribute set must be run from the global zone, the operation will be performed on all native zones, and this behavior is built-in to the pkg commands. With "update on attach" we are only updating a single zone. We cannot depend on the basic pkg behavior which updates all zones when a pkg is installed in the global zone. We cannot use standard Solaris media since the host can have a variety of patches installed which have updated the base system pkgs beyond any specific Solaris release. Instead what we want to do is similar to what happens when a zone is initially installed. The spooled pkg data and global zone files are the source for installing the zone. In this way the zone is installed with the correct pkg versions along with any patches that have been applied to those pkgs. We can do something similar for "update on attach". The zone 'attach' validation already generates a list of mismatched pkg versions and patches. We can use this information to determine which dependent pkgs need to be updated so that the zone can run properly on the new host. We will remove the obsolete versions of those pkgs and install the up-to-date version using the pkg data spooled in the global zone. This procedure will preserve any editable or volatile files that are delivered by these pkgs. The normal pkg install scripts and class action scripts are run as part of this process so any updates performed by these scripts will take place. As described in [4] the dependent pkgs are those that have the SUNW_PKG_ALLZONES=true pkg attribute as well as any pkgs installed in an inherited-pkg-dir. Only these pkgs will be updated to match the new host. We will ensure that we will only update a zone to a host running the same or later version of the dependent pkgs. For example, if the new host has a mix of higher and lower version patches as compared to the source host then we will not allow an update during the attach. By default the zone will not be updated during attach. Instead, the existing output listing the pkgs that are out of sync will continue to be printed. We will add a new option (-u) to the 'zoneadm attach' subcommand. When this option is used then zoneadm will update the necessary pkgs during the attach (assuming there are any to update). Because the zone has previously booted and run on the source host it is possible that there could be security issues with directly accessing the zone's filesystem to remove and add pkgs to the zone. To protect against this the pkg operations will be performed within the scratch zone [5]. The scratch zone was defined to address this specific issue for upgrading zones. We cannot use the pkgrm(1M) and pkgadd(1M) commands to update the zone while running within the scratch zone. Those commands explicitly disallow removing or adding a pkg with the SUNW_ALLZONES attribute set unless running in the global zone. Instead we will use the /usr/sadm/install/bin/pkgremove and /usr/sadm/install/bin/pkginstall commands directly. The pkgrm and pkgadd commands are wrappers to those commands. Those commands were formerly part of the ON consolidation but moved to the Install consolidation as part of [6]. That case documents man pages for pkgremove and pkginstall but no such man pages exist. No stability level is documented for these two commands so we're assuming these are consolidation private and a contract is needed to directly use these commands. The command line options being used are: /usr/sadm/install/bin/pkgremove: -a same as public pkgrm option -F private - used by upgrade to suppress actual removal of files delivered by the pkg -M same as public pkgrm option -n same as public pkgrm option -O inherited-filesystem={IPD} private - used to specify the zone's inherited-pkg-dir entries -R same as public pkgrm option /usr/sadm/install/bin/pkginstall: -a same as public pkgrm option -C private - disable checksums since files are installed via a separate copy from the global zone -h private - enable hollow pkg support -N pkgadd private - error msgs use use the name "pkgadd" instead of "pkginstall" -n same as public pkgrm option -O addzonename private - error msgs include zonename -O inherited-filesystem={IPD} private - used to specify the zone's inherited-pkg-dir entries -R same as public pkgrm option -S private - suppress copyright output -t private - suppress spooled pkg creation -z private - install zone pkg data from spooled pkg data EXPORTED INTERFACES zoneadm attach option [-u] Evolving IMPORTED INTERFACES pkgremove, pkginstall and their options described in this case Contracted Consolidation Private REFERENCES 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 2. RFE: zoneadm attach should patch/update the zone to the new hosts level Bugid 6480464 http://bugs.opensolaris.org/view_bug.do?bug_id=6480464 3. RFE: zoneadm detach/attach should work between sun4u and sun4v architecture Bugid 6576592 http://bugs.opensolaris.org/view_bug.do?bug_id=6576592 4. PSARC/2006/030 Zone migration 5. PSARC/2005/474 Zones Upgrade 6. PSARC/2002/274 Move SVr4 Packaging from ON to ADMIN From sacadmin Tue Oct 30 05:19:19 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk [129.146.11.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9UCJJCt010717 for ; Tue, 30 Oct 2007 05:19:19 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9UCFjPv005783 for ; Tue, 30 Oct 2007 05:15:45 -0700 (PDT) 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 l9UCFiik022741 for ; Tue, 30 Oct 2007 12:15:45 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 <0JQQ00A014OH1Q00@mail-amer.sun.com> (original mail from Eric.Ray@sun.com) for psarc@sac.eng.sun.com; Tue, 30 Oct 2007 06:15:44 -0600 (MDT) Received: from Macintosh.local ([38.99.84.34]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQQ0037W4Q78HC0@mail-amer.sun.com> for psarc@sac.eng.sun.com; Tue, 30 Oct 2007 06:15:44 -0600 (MDT) Date: Tue, 30 Oct 2007 06:15:42 -0600 From: Eric Ray Subject: zone update on attach [PSARC/2007/621 FastTrack timeout 10/05/2007] Sender: Eric.Ray@sun.com To: psarc@sac.sfbay.sun.com Message-id: <4727206E.5060504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807) Status: RO Content-Length: 218 Approve. Please let me know if you have questions or need more information. Thanks, Eric -- Eric J. Ray Software Engineering Manager Solaris Install Sun Microsystems 303-223-7843 (direct)/x81067 eric.ray@sun.com From Gerald.Jelinek@sun.com Mon Nov 5 11:15:55 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA5JFtoY012876 for ; Mon, 5 Nov 2007 11:15:55 -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 lA5JCHIN000790 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 5 Nov 2007 11:12:17 -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 <0JR100E0LS0HPQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 05 Nov 2007 11:12:17 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR100HQMS0DW1D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 05 Nov 2007 11:12:13 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA5JCD46009679 for ; Mon, 05 Nov 2007 19:12:13 +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 <0JR100901RCSYN00@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 05 Nov 2007 12:12:13 -0700 (MST) Received: from [10.7.251.2] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR1004VDS029ZE0@mail-amer.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 05 Nov 2007 12:12:03 -0700 (MST) Date: Mon, 05 Nov 2007 12:08:31 -0700 From: Jerry Jelinek Subject: Re: zone update on attach [PSARC/2007/621 FastTrack timeout 10/05/2007] In-reply-to: <4725E9D8.4030004@sun.com> Sender: Gerald.Jelinek@sun.com To: PSARC-EXT@sun.com Cc: Jerry Jelinek Message-id: <472F6A2F.7060607@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: <4725E9D8.4030004@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 150 This fast-track has timed out with no comments and the contract has been approved by both managers so I am marking it closed approved. Thanks, Jerry