From sacadmin Fri Jun 9 14:30:52 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k59LUpc8015594 for ; Fri, 9 Jun 2006 14:30:52 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k59LVYco002589 for ; Fri, 9 Jun 2006 17:31:34 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k59LVYNx002586; Fri, 9 Jun 2006 17:31:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17545.59574.499666.649801@gargle.gargle.HOWL> Date: Fri, 9 Jun 2006 17:31:34 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com Subject: 2006/387 Zones Features For Zulu X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 7639 I'm sponsoring this fast-track request for myself. The timer is set to 06/16/2006. The release binding asserted is "Patch/Micro." The stability of the interfaces varies (see below). The final change documented (for parseable output) is the only one that stretches the meaning of patch binding; please pay particular attention to that. The document described here is a derivative of a proposal that has been circulated in the Zones and Zulu communities, and reflects input from them. It's not identical, as I've redrafted it for this audience, so please do read closely if you saw the other version. Background ---------- The changes described in "Zones Upgrade Permanent Solution (Zulu)" (PSARC 2006/167) assume a certain amount of functionality from within the Operating System / Networking (ON) consolidation. Without these features, the Install gate (and Zulu) will be faced with complex dependencies on ON internal data structures and file formats. Currently, Install does have access to private ON interfaces, via contracts established in "Admin/Install Zones Support" (PSARC 2003/460). One of the goals of this project is to minimize any new library dependencies and, to the extent possible, pave the way for removing all of them in the future. Features In Zonecfg ------------------- -R Contracted Consolidation Private As with the other zones-related utilities, zonecfg needs a "-R" option to access alternate root environments. For the time being, the access to this option will be kept under wraps. An updated contract for this interface will be deposited with this case. One of the risks with this feature is that the zones configuration files in the alternate root specified might not be the same (private) version as the running system. The existing "-R" option on zoneadm also has this issue, and the problem is at least centralized in libzonecfg. A future project may complete this functionality and promote it as a stable interface. set -F zonepath= Contracted Project Private This new flag (-F) allows lucopy to change the path of a zone after performing the copy operation. Unlike the regular "set zonepath" operation, it does not check the zone state; it "forces" the operation. Unlike the existing "zoneadm move" command, the actual data are not moved or copied, just the path recorded in the database is changed. Note that the path given must be absolute; meaning that it must include the path to the alternate root itself. The path printed by "zonecfg -R -z info zonepath" will also be absolute and start with the alternate root. This should be a private feature as it relies on actions (copying zone data) that can't necessarily be supported in this manner. The documented way to change a zone path is via the "zoneadm move" option. This is used only in the case zones that exist on shared file systems. Zones on unshared file systems do not change in path during LU operations. Thus, it will be limited to just the "-R" case and won't allow the path on the running system to be altered. It is expected that when ZFS is integrated into Install, Zones using ZFS will have substantially different features (using snapshot/clone operations) and will thus be able to avoid path changes. Features In Zoneadm ------------------- zoneadm [-R path] -z zone state incomplete Stable This allows lucopy to mark damaged zones (those that cannot be replicated properly) as 'incomplete'. It's probably a useful feature in general for administrative software that uses Zones under the covers, so making it public seems reasonable. Note that only the "state" and "list" subcommands will be documented as supporting this "-R" option. The mount/unmount subcommands introduced by Ashanti (PSARC 2005/474) are still not ready for wider use. zoneadm [-u uuid-match] list Stable Two separate features are added to the "list" subfunction to enable matching based on UUID (universally unique identifiers). The zone UUID is used to ensure that the zone against which we're synchronizing is the same one that we previously copied. Both features described here will work in the global zone and in non-global zones. Naturally, the non-global zones will only be able to access information about themselves, and not about any other zone on the system. The separate identifier is needed because zones can be uninstalled and reinstalled under the same name (with different contents), and can be renamed (without changing contents). The zone name is thus an unstable handle for the zone. Note that because S10 shipped without UUIDs on zones, and because of CR 6379341, inactive BEs may not necessarily have values to match. Any running system with this new feature will (necessarily) have the fix for those problems, and thus have reliable UUIDs. -u uuid-match This feature enables matching based on the UUID. If the UUID string to match is zero-length, then it is treated as though the option were not present. (I.e., it has no effect.) If both -u and -z are present, then the match is done based on the UUID first. If a zone with the specified UUID is found, it is used, and the -z parameter is ignored. If no zone is found by UUID, then the system searches by zone name instead. This matching logic is identical to the existing "/b" mount logic in zoneadmd that provides access to the running zone from within a scratch zone. It is possible for the user to go out of his way to fool this logic, but the result can only be a false match against an uninstalled zone (lacking a UUID), and no synchronization is ever done (or possible) with an uninstalled zone. Note that the option preceeds the subcommand because the "-z" option also preceeds the subcommand. Standard style would place the option after the subcommand, but adding a new feature that's logically similar but differing in usage would be more confusing. list The UUID is added as the fifth field (after path) in the "zoneadm list -p" output. It is not administratively significant, and thus is not listed with "zoneadm list -v." By allowing this to work in non-global zones, this feature also fixes: 6365741 RFE: add unique identifier to facilitate asset tracking (similar to hostid) zoneadm list -p Stable The output format for this feature is not always parseable, though it was documented that way. 6431731 zoneadm list -p (parseable) output isn't Part of this project will be to make the output parseable so that the UUID can be extracted reliably, and document the escaping mechanism. If the path name contains embedded colons, those will be escaped using "\:" in the output. This allows the resulting string to be parsed properly using "IFS=: read" in the shell, which respects that form of escaping. Note that since the existing output format doesn't properly support its own field delimiters, it seems unlikely that any customer has come to depend on this problem. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Jun 12 01:44:33 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5C8iXDJ027320 for ; Mon, 12 Jun 2006 01:44:33 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5C8iW4c009663 for ; Mon, 12 Jun 2006 01:44:32 -0700 (PDT) Received: from d1-emea-04.sun.com ([192.18.2.114]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5C8iQaB015727 for ; Mon, 12 Jun 2006 09:44:26 +0100 (BST) Received: from conversion-daemon.d1-emea-04.sun.com by d1-emea-04.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0Q00H01O6IOZ00@d1-emea-04.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 12 Jun 2006 09:44:26 +0100 (BST) Received: from [129.156.173.21] by d1-emea-04.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0Q00AN5OA1Q440@d1-emea-04.sun.com> for psarc@sac.sfbay.sun.com; Mon, 12 Jun 2006 09:44:25 +0100 (BST) Date: Mon, 12 Jun 2006 09:44:25 +0100 From: Darren J Moffat Subject: Re: 2006/387 Zones Features For Zulu In-reply-to: <17545.59574.499666.649801@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: psarc@sac.sfbay.sun.com Message-id: <448D2969.9030401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <17545.59574.499666.649801@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.2 (X11/20060515) Status: RO Content-Length: 651 James Carlson wrote: > Features In Zonecfg > ------------------- > > -R Yeah! > Contracted Consolidation Private > > As with the other zones-related utilities, zonecfg needs a "-R" > option to access alternate root environments. For the time being, > the access to this option will be kept under wraps. An updated > contract for this interface will be deposited with this case. :-( > A future project may complete this functionality and promote it as > a stable interface. Please do, either that or provide an even better way for zones to be created during Jumpstart finish scripts. -- Darren J Moffat From sacadmin Mon Jun 12 05:16:45 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5CCGiOV002157 for ; Mon, 12 Jun 2006 05:16:45 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5CCHU3v005132; Mon, 12 Jun 2006 08:17:30 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5CCHUcq005129; Mon, 12 Jun 2006 08:17:30 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17549.23386.513624.66553@gargle.gargle.HOWL> Date: Mon, 12 Jun 2006 08:17:30 -0400 From: James Carlson To: Darren J Moffat Cc: psarc@sac.sfbay.sun.com Subject: Re: 2006/387 Zones Features For Zulu In-Reply-To: Darren J Moffat's message of 12 June 2006 09:44:25 References: <17545.59574.499666.649801@gargle.gargle.HOWL> <448D2969.9030401@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 910 Darren J Moffat writes: > > A future project may complete this functionality and promote it as > > a stable interface. > > Please do, either that or provide an even better way for zones > to be created during Jumpstart finish scripts. I think there are some things that still need to be worked out here. In particular, folks using -R on zonecfg and zoneadm are going to expect to be able to create and destroy zones on alternate roots. We have no way of doing this today, so the feature isn't as useful as one might expect. I'd rather not expose it before we're clear on exactly what "it" is. Though, yeah, I'd very much like to see these new features publicly documented. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Jun 22 11:28:14 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MISDxb025662 for ; Thu, 22 Jun 2006 11:28:13 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5MISDTN023876 for ; Thu, 22 Jun 2006 11:28:13 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MISDfX011350 for ; Thu, 22 Jun 2006 12:28:13 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1900M01XYHE600@mail-amer.sun.com> (original mail from Eric.Ray@sun.com) for psarc@sac.sfbay.sun.com; Thu, 22 Jun 2006 12:28:13 -0600 (MDT) Received: from [129.146.229.93] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1900A3CXYQVTU2@mail-amer.sun.com>; Thu, 22 Jun 2006 12:28:04 -0600 (MDT) Date: Thu, 22 Jun 2006 11:25:49 -0700 From: Eric Ray Subject: Re: [resend] ARC contract for 2006/387 Zones Features For Zulu In-reply-to: <200606221224.k5MCOUI6010023@phorcys.East.Sun.COM> Sender: Eric.Ray@sun.com To: psarc@sac.sfbay.sun.com Cc: allan.mckillop@sun.com, James.D.Carlson@sun.com, david.comay@sun.com, Dave.Miner@sun.com Message-id: <449AE0AD.4050704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <200606221224.k5MCOUI6010023@phorcys.East.Sun.COM> User-Agent: Mail/News 1.5.0.2 (X11/20060419) Status: RO Content-Length: 6606 I agree. Eric Ray James Carlson wrote: > [Retrying because there was no response to my previous message. I > need a response -- to deny or approve -- from each of you in order to > move this case forward. Thanks.] > > > I need both of you to review the contract listed below, and send back > an "I agree" message, copying psarc@sac.sfbay. (Replying should do > the right thing, as I've set the Reply-To field on this message.) > > I've placed the bulk of the burden on Install to document and test > these features. The intent is eventually to use these features to > supplant the more onerous contract on libzonecfg that's already in > 2003/460 and 2005/474, and promote these interfaces to Public > stability so that we need as few contracts between Zones and Install > as possible. > > If necessary, please do consult with David Comay or other experts in > the area as needed. > > > > @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2006/387-01 > > 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: ON > Department or Group: Kernel Networking > Bugster Category/SubCategory: utility/zones > Responsible Manager: Allan McKillop > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: Install > Department or Group: KISS > Bugster Category/SubCategory: sysadmin/zones > Responsible Manager: Eric Ray > > 4. The INTERFACES are: > > zonecfg -R Consolidation Private 2006/387 > zonecfg set -F zonepath= > Project Private 2006/387 > zonecfg info fs output Unstable 2002/174* > > [*] The output format of this command was not documented, and is > presumed to be Unstable. > > 5. The ARC controlling these INTERFACES is: PSARC > > 6. The CASE describing these INTERFACES is: > > 2006/387 Zones Features For Zulu > 2002/174 Virtualization and Namespace Isolation in Solaris > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _Y_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > In a Minor release of Solaris. > > _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: > > CONSUMER and SUPPLIER intend to promote these interfaces and > the non-libzonecfg interfaces from PSARC/2005/474-02 as Public > when possible in the future, and to cancel this contract at > that time. > > CONSUMER commits to removing its reliance on the private > libzonecfg interfaces described in contracts PSARC/2003/460-02 > and PSARC/2005/474-02, and supplanting with the features > described here and the non-libzonecfg interfaces from > "Zones Upgrade (Ashanti and Zulu)" (PSARC 2005/474). > > SUPPLIER will obtain approval of CONSUMER for changes to > interfaces described in this contract. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > CONSUMER will support the features. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > CONSUMER will supply documentation. (The materials for this > case provide that documentation.) > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > CONSUMER will test the interfaces. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > May be terminated by mutual consent, or unilaterally by the > SUPPLIER if compatible interfaces are made Public. > > 15. 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: Date: > For CONSUMER: Date: > For ARC: Date: > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > -- Eric J. Ray Software Engineering Manager Solaris Install, OPG Sun Microsystems 303-223-7843 (direct)/x81067 eric.ray@sun.com From sacadmin Sat Jun 24 13:04:58 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5OK4v3o011206 for ; Sat, 24 Jun 2006 13:04:57 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5OK5p0L017562 for ; Sat, 24 Jun 2006 16:05:53 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5OK5nsu017558; Sat, 24 Jun 2006 16:05:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17565.39708.884665.923900@gargle.gargle.HOWL> Date: Sat, 24 Jun 2006 16:05:48 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com Subject: 2006/387 Zones Features For Zulu (minor update) X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 669 During code review, one of the reviewers asked that I make the zonecfg 'state' command more verb-like to match its behavior. I agreed, so the new command is: zoneadm [-R path] -z zone setstate incomplete Also, a clarification: the new zoneadm "[-u uuid-match]" flag works in all cases where "[-z zone-name]" would work. The intended usage, though, is with the "list" subcommand. (The case is still open, pending the contract on zonecfg.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Jun 26 02:11:59 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5Q9BxB2019859 for ; Mon, 26 Jun 2006 02:11:59 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5Q9BwFA019668 for ; Mon, 26 Jun 2006 02:11:58 -0700 (PDT) Received: from d1-emea-03.sun.com ([192.18.2.113]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5Q9BqHj024028 for ; Mon, 26 Jun 2006 10:11:52 +0100 (BST) Received: from conversion-daemon.d1-emea-03.sun.com by d1-emea-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1G00G01MLHMC00@d1-emea-03.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 26 Jun 2006 10:11:52 +0100 (BST) Received: from [129.150.120.103] by d1-emea-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1G009WNMVRCR00@d1-emea-03.sun.com> for psarc@sac.sfbay.sun.com; Mon, 26 Jun 2006 10:11:52 +0100 (BST) Date: Mon, 26 Jun 2006 10:10:15 +0100 From: Darren J Moffat Subject: Re: 2006/387 Zones Features For Zulu (minor update) In-reply-to: <17565.39708.884665.923900@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: psarc@sac.sfbay.sun.com Message-id: <449FA477.9070800@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <17565.39708.884665.923900@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.2 (X11/20060515) Status: RO Content-Length: 504 James Carlson wrote: > During code review, one of the reviewers asked that I make the zonecfg > 'state' command more verb-like to match its behavior. I agreed, so > the new command is: > > zoneadm [-R path] -z zone setstate incomplete Was the following considered: zoneadm [-R path] -z zone set state=incomplete Which would more more consistent with zonecfg and other recent utilities. It also give scope for future things that can be set with zoneadm rather than zonecfg. -- Darren J Moffat From sacadmin Mon Jun 26 03:40:01 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5QAe04G021791 for ; Mon, 26 Jun 2006 03:40:01 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5QAevAb019121; Mon, 26 Jun 2006 06:40:58 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5QAeugW019116; Mon, 26 Jun 2006 06:40:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17567.47540.568337.777991@gargle.gargle.HOWL> Date: Mon, 26 Jun 2006 06:40:52 -0400 From: James Carlson To: Darren J Moffat Cc: psarc@sac.sfbay.sun.com Subject: Re: 2006/387 Zones Features For Zulu (minor update) In-Reply-To: Darren J Moffat's message of 26 June 2006 10:10:15 References: <17565.39708.884665.923900@gargle.gargle.HOWL> <449FA477.9070800@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1704 Darren J Moffat writes: > Was the following considered: > > zoneadm [-R path] -z zone set state=incomplete Yes. > Which would more more consistent with zonecfg and other recent > utilities. It also give scope for future things that can be set with > zoneadm rather than zonecfg. The problem is that it really doesn't match the structure of the existing command, and that in general, 'set' operations take place within zonecfg. There aren't other things that you would or should "set" from zoneadm. Having a generalized 'set' command would make it appear as though we're planning to add other things that you could also set from here, and that's not the case. The zone 'state' is a bit of an oddball, in that the state is set by this action-oriented (rather than configuration-oriented) command. The other state-setting commands in zoneadm include 'boot,' and 'halt.' If there were a way to say "make incomplete" without having the word "state" somewhere in there, I'd be all for it. (Note that it's likely that we'll have one other command here to mean "remove incompleteness." That's likely to be "setstate installed.") "Setstate" can be documented as a special subcommand that deals with the administrative completeness of the zone, and isn't as general-purpose as I think "set state=" otherwise implies. I think, in retrospect, it would have been much clearer for users to have a single command to administer zones rather than two. But that's not what we have. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Jun 26 03:48:49 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5QAmmqf021934 for ; Mon, 26 Jun 2006 03:48:48 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5QAmmcM021493 for ; Mon, 26 Jun 2006 03:48:48 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5QAmg85008904 for ; Mon, 26 Jun 2006 11:48:42 +0100 (BST) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1G00M01R8KE600@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 26 Jun 2006 11:48:42 +0100 (BST) Received: from [129.150.120.103] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1G00BP2RD5V020@d1-emea-10.sun.com> for psarc@sac.sfbay.sun.com; Mon, 26 Jun 2006 11:48:42 +0100 (BST) Date: Mon, 26 Jun 2006 11:47:05 +0100 From: Darren J Moffat Subject: Re: 2006/387 Zones Features For Zulu (minor update) In-reply-to: <17567.47540.568337.777991@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: psarc@sac.sfbay.sun.com Message-id: <449FBB29.8010709@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <17565.39708.884665.923900@gargle.gargle.HOWL> <449FA477.9070800@Sun.COM> <17567.47540.568337.777991@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.2 (X11/20060515) Status: RO Content-Length: 553 Thanks for the background on why set key=value is not appropriate I'm happy with that. I'd like to offer one other suggestion then.... The svcadm(1m) model has svcadm mark What about having zoneadm -z zone mark That allows you to have installed and incomplete but doesn't imply a general purpose key=value setting ability. If is is to stay as setstate, shouldn't that be set-state, which is the style that dladm(1m), bootadm(1m) see to be following for multi word subcommands (or is that sub-commands :-)). -- Darren J Moffat From sacadmin Mon Jun 26 03:55:33 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5QAtXxw022704 for ; Mon, 26 Jun 2006 03:55:33 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5QAuVNS019219; Mon, 26 Jun 2006 06:56:31 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5QAuUr7019216; Mon, 26 Jun 2006 06:56:30 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17567.48478.314853.166831@gargle.gargle.HOWL> Date: Mon, 26 Jun 2006 06:56:30 -0400 From: James Carlson To: Darren J Moffat Cc: psarc@sac.sfbay.sun.com Subject: Re: 2006/387 Zones Features For Zulu (minor update) In-Reply-To: Darren J Moffat's message of 26 June 2006 11:47:05 References: <17565.39708.884665.923900@gargle.gargle.HOWL> <449FA477.9070800@Sun.COM> <17567.47540.568337.777991@gargle.gargle.HOWL> <449FBB29.8010709@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1184 Darren J Moffat writes: > zoneadm -z zone mark > > That allows you to have installed and incomplete but doesn't imply a > general purpose key=value setting ability. I think this falls in the category of discussions that would have been great ... two weeks ago. > If is is to stay as setstate, shouldn't that be set-state, which is the > style that dladm(1m), bootadm(1m) see to be following for multi word > subcommands (or is that sub-commands :-)). Fine. I will change this subcommand to 'mark,' and update all of the other parts of this project that are now in progress. In particular, because this is coming in late, this means that I have to cook up a new batch of bits for all of the Zulu gatelings who will be hit by this flag day. (Made particularly painful by the deep entanglement of Zones and ZFS ... every build seems to have a different set of incompatible library changes.) Can we please, please, please let the paint dry now? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Jun 26 03:58:58 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5QAwwcF022720 for ; Mon, 26 Jun 2006 03:58:58 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k5QAwvmB023779 for ; Mon, 26 Jun 2006 03:58:57 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119] (may be forged)) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5QAwpJo017135 for ; Mon, 26 Jun 2006 11:58:51 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1G00101RQSH400@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 26 Jun 2006 11:58:51 +0100 (BST) Received: from [129.150.120.103] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1G006QORU2RD20@d1-emea-09.sun.com> for psarc@sac.sfbay.sun.com; Mon, 26 Jun 2006 11:58:51 +0100 (BST) Date: Mon, 26 Jun 2006 11:57:15 +0100 From: Darren J Moffat Subject: Re: 2006/387 Zones Features For Zulu (minor update) In-reply-to: <17567.48478.314853.166831@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: psarc@sac.sfbay.sun.com Message-id: <449FBD8B.20709@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <17565.39708.884665.923900@gargle.gargle.HOWL> <449FA477.9070800@Sun.COM> <17567.47540.568337.777991@gargle.gargle.HOWL> <449FBB29.8010709@Sun.COM> <17567.48478.314853.166831@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.2 (X11/20060515) Status: RO Content-Length: 1184 James Carlson wrote: > Darren J Moffat writes: >> zoneadm -z zone mark >> >> That allows you to have installed and incomplete but doesn't imply a >> general purpose key=value setting ability. > > I think this falls in the category of discussions that would have been > great ... two weeks ago. Sorry! >> If is is to stay as setstate, shouldn't that be set-state, which is the >> style that dladm(1m), bootadm(1m) see to be following for multi word >> subcommands (or is that sub-commands :-)). > > Fine. I will change this subcommand to 'mark,' and update all of the > other parts of this project that are now in progress. > In particular, because this is coming in late, this means that I have > to cook up a new batch of bits for all of the Zulu gatelings who will > be hit by this flag day. (Made particularly painful by the deep > entanglement of Zones and ZFS ... every build seems to have a > different set of incompatible library changes.) If this is really that hard to do and things will be late as a result I'll just hold my nose on the setstate proposal and let it be. > Can we please, please, please let the paint dry now? Sure. -- Darren J Moffat From sacadmin Mon Jun 26 04:04:45 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5QB4ihd022860 for ; Mon, 26 Jun 2006 04:04:44 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5QB5gFm019263; Mon, 26 Jun 2006 07:05:42 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5QB5giS019260; Mon, 26 Jun 2006 07:05:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17567.49030.469618.335202@gargle.gargle.HOWL> Date: Mon, 26 Jun 2006 07:05:42 -0400 From: James Carlson To: Darren J Moffat Cc: psarc@sac.sfbay.sun.com Subject: Re: 2006/387 Zones Features For Zulu (minor update) In-Reply-To: Darren J Moffat's message of 26 June 2006 11:57:15 References: <17565.39708.884665.923900@gargle.gargle.HOWL> <449FA477.9070800@Sun.COM> <17567.47540.568337.777991@gargle.gargle.HOWL> <449FBB29.8010709@Sun.COM> <17567.48478.314853.166831@gargle.gargle.HOWL> <449FBD8B.20709@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 462 Darren J Moffat writes: > If this is really that hard to do and things will be late as a result > I'll just hold my nose on the setstate proposal and let it be. No, you don't get to change your mind again. ;-} It's "mark incomplete." -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Jun 27 22:18:48 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5S5ImO7008395 for ; Tue, 27 Jun 2006 22:18:48 -0700 (PDT) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5S5IloA804262 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Jun 2006 22:18:47 -0700 (PDT) Received: (from allan@localhost) by jurassic.eng.sun.com (8.13.6+Sun/8.13.5/Submit) id k5S5Il83804260; Tue, 27 Jun 2006 22:18:47 -0700 (PDT) Date: Tue, 27 Jun 2006 22:18:47 -0700 From: Allan McKillop To: psarc@sac.sfbay.sun.com Cc: "Eric J. Ray" , zones-core@sun.com Subject: Re: [resend] ARC contract for 2006/387 Zones Features For Zulu Message-ID: <20060628051847.GA804158@eng.sun.com> Reply-To: Allan McKillop References: <200606221224.k5MCOUI6010023@phorcys.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606221224.k5MCOUI6010023@phorcys.East.Sun.COM> User-Agent: Mutt/1.4.2.1i Organization: Solaris Kernel Development; Sun Microsystems, Inc. Status: RO Content-Length: 6514 I approve. --allan * James Carlson [2006-06-22 05:23]: > [Retrying because there was no response to my previous message. I > need a response -- to deny or approve -- from each of you in order to > move this case forward. Thanks.] > > > I need both of you to review the contract listed below, and send back > an "I agree" message, copying psarc@sac.sfbay. (Replying should do > the right thing, as I've set the Reply-To field on this message.) > > I've placed the bulk of the burden on Install to document and test > these features. The intent is eventually to use these features to > supplant the more onerous contract on libzonecfg that's already in > 2003/460 and 2005/474, and promote these interfaces to Public > stability so that we need as few contracts between Zones and Install > as possible. > > If necessary, please do consult with David Comay or other experts in > the area as needed. > > > > @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2006/387-01 > > 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: ON > Department or Group: Kernel Networking > Bugster Category/SubCategory: utility/zones > Responsible Manager: Allan McKillop > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: Install > Department or Group: KISS > Bugster Category/SubCategory: sysadmin/zones > Responsible Manager: Eric Ray > > 4. The INTERFACES are: > > zonecfg -R Consolidation Private 2006/387 > zonecfg set -F zonepath= > Project Private 2006/387 > zonecfg info fs output Unstable 2002/174* > > [*] The output format of this command was not documented, and is > presumed to be Unstable. > > 5. The ARC controlling these INTERFACES is: PSARC > > 6. The CASE describing these INTERFACES is: > > 2006/387 Zones Features For Zulu > 2002/174 Virtualization and Namespace Isolation in Solaris > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _Y_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > In a Minor release of Solaris. > > _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: > > CONSUMER and SUPPLIER intend to promote these interfaces and > the non-libzonecfg interfaces from PSARC/2005/474-02 as Public > when possible in the future, and to cancel this contract at > that time. > > CONSUMER commits to removing its reliance on the private > libzonecfg interfaces described in contracts PSARC/2003/460-02 > and PSARC/2005/474-02, and supplanting with the features > described here and the non-libzonecfg interfaces from > "Zones Upgrade (Ashanti and Zulu)" (PSARC 2005/474). > > SUPPLIER will obtain approval of CONSUMER for changes to > interfaces described in this contract. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > CONSUMER will support the features. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > CONSUMER will supply documentation. (The materials for this > case provide that documentation.) > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > CONSUMER will test the interfaces. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > May be terminated by mutual consent, or unilaterally by the > SUPPLIER if compatible interfaces are made Public. > > 15. 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: Date: > For CONSUMER: Date: > For ARC: Date: > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > From sacadmin Wed Jun 28 05:03:15 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SC3EB1021903 for ; Wed, 28 Jun 2006 05:03:15 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5SC4DFO027102 for ; Wed, 28 Jun 2006 08:04:14 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5SC4Cx2027099; Wed, 28 Jun 2006 08:04:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17570.28732.595082.945359@gargle.gargle.HOWL> Date: Wed, 28 Jun 2006 08:04:12 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com Subject: Re: [resend] ARC contract for 2006/387 Zones Features For Zulu In-Reply-To: Allan McKillop's message of 27 June 2006 22:18:47 References: <200606221224.k5MCOUI6010023@phorcys.East.Sun.COM> <20060628051847.GA804158@eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 527 Allan McKillop writes: > I approve. ... and with that, I've deposited a final version of the specification in the case directory as 'spec.txt' (it differs from the original only in the renaming of the zoneadm 'state' subcommand to 'mark'), marked the contract as signed, and marked this case approved. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677