From sacadmin Wed Jan 9 10:54:04 2008 Received: from absurd.sfbay.sun.com (absurd [129.146.228.172]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09Is4i3001891; Wed, 9 Jan 2008 10:54:04 -0800 (PST) Received: from absurd.sfbay.sun.com (localhost [127.0.0.1]) by absurd.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09Is47d007449; Wed, 9 Jan 2008 10:54:04 -0800 (PST) Received: (from lianep@localhost) by absurd.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m09Is3uA007445; Wed, 9 Jan 2008 10:54:03 -0800 (PST) Date: Wed, 9 Jan 2008 10:54:03 -0800 (PST) From: Liane Praza Message-Id: <200801091854.m09Is3uA007445@absurd.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: Alan.Maguire@sun.com Subject: svccfg refresh subcommand [PSARC/2008/015 Self Review] Status: RO Content-Length: 561 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: svccfg refresh subcommand 1.2. Name of Document Author/Supplier: Author: Alan Maguire 1.3 Date of This Document: 09 January, 2008 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: Automatic 6.6. ARC Exposure: open From liane.praza@sun.com Wed Jan 9 11:02:05 2008 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 m09J24xS002424 for ; Wed, 9 Jan 2008 11:02:04 -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 m09J1vW6018321; Thu, 10 Jan 2008 03:02:01 +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 <0JUE00D0B4V92H00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 11:01:57 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE002H74V97370@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 11:01:57 -0800 (PST) Received: from [129.146.228.172] (absurd.SFBay.Sun.COM [129.146.228.172]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09J1vmj907885; Wed, 09 Jan 2008 11:01:57 -0800 (PST) Date: Wed, 09 Jan 2008 11:01:57 -0800 From: Liane Praza Subject: 2008/015 svccfg refresh subcommand To: psarc-ext@sun.com Cc: Alan Maguire Message-id: <47851A25.4060606@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 User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 2426 I'm filing this on behalf of Alan Maguire. I've submitted it as Closed-Approved-Automatic, as I believe it's an obvious change. However, if there's non-trivial discussion or concern, we'd be happy to convert it back to a fasttrack. liane --- svccfg refresh subcommand Alan Maguire 1/9/2008 1. Introduction Introduce a "refresh" subcommand to svccfg to allow updates to the "running" snapshot of an instance when the service's restarter isn't available. 2. Technical Description SMF's restarters operate on the "running" snapshot of service instances in order to ensure configuration is complete and consistent over the lifetime of a service. This "running" snapshot is taken at three points: - by svc.startd when the service is started and no running snapshot is yet available, and - by svc.startd in response to a "svcadm refresh" request, and - by svc.startd in response to a "svccfg import" request. Currently, svccfg has an environment variable and a "repository" subcommand to allow configuration manipulation on an alternate repository. All manipulation is possible using svccfg except for the final commit of current configuration changes into the running snapshot. This is an oversight, because offline manipulation of the repository does not allow a manual commit. We propose to introduce a new "refresh" subcommand to svccfg(1M). If svccfg is operating on the repository for the live system, this subcommand will invoke svcadm refresh to accomplish the standard refresh actions (rotate the snapshot and invoke the refresh method). If svccfg is operating on an alternate repository, only the snapshot will be rotated. 3. Interface Table Interface Stability Binding --------- --------- ------- refresh subcommand for svccfg(1M) Committed Patch 4. References PSARC 2002/547 Greenline 5. manpage diffs + Instance commands + refresh + If the chosen repository (selected by the "repository" + command) is not the active repository, this command will + update the Running snapshot for the selected instance in + the specified repository. If no alternate repository is + specified, this command is the equivalent of "svcadm + refresh". From carlsonj@phorcys.east.sun.com Wed Jan 9 11:21:03 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09JL3aA003251 for ; Wed, 9 Jan 2008 11:21:03 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09JKuaf028137; Wed, 9 Jan 2008 11:21:01 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE002375R0AA00@brm-avmta-1.central.sun.com>; Wed, 09 Jan 2008 12:21:00 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE00E855QZMT80@brm-avmta-1.central.sun.com>; Wed, 09 Jan 2008 12:20:59 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09JJejN014499; Wed, 09 Jan 2008 14:19:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m09JJe6g014496; Wed, 09 Jan 2008 14:19:40 -0500 (EST) Date: Wed, 09 Jan 2008 14:19:39 -0500 From: James Carlson Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <47851A25.4060606@sun.com> To: Liane Praza Cc: psarc-ext@sun.com, Alan Maguire Message-id: <18309.7755.793435.715150@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47851A25.4060606@sun.com> Status: RO Content-Length: 3314 Liane Praza writes: > I'm filing this on behalf of Alan Maguire. I've submitted it as > Closed-Approved-Automatic, as I believe it's an obvious change. > However, if there's non-trivial discussion or concern, we'd be happy > to convert it back to a fasttrack. I hope this is just trivial discussion (;-}), but it seems to me that having both "svccfg refresh" and "svcadm refresh" is potentially confusing for administrators. I suspect that they're confused about the cfg/adm split already (we've certainly seen confusion with the zone* commands), and this just adds a little fuel. If svccfg provides all the needed functionality Is it possible to work towards > liane > > --- > svccfg refresh subcommand > Alan Maguire > 1/9/2008 > > 1. Introduction > > Introduce a "refresh" subcommand to svccfg to allow updates to the > "running" snapshot of an instance when the service's restarter isn't > available. > > 2. Technical Description > > SMF's restarters operate on the "running" snapshot of service > instances in order to ensure configuration is complete and > consistent over the lifetime of a service. This "running" > snapshot is taken at three points: > - by svc.startd when the service is started and no > running snapshot is yet available, and > - by svc.startd in response to a "svcadm refresh" request, and > - by svc.startd in response to a "svccfg import" request. > > Currently, svccfg has an environment variable and a "repository" > subcommand to allow configuration manipulation on an alternate > repository. All manipulation is possible using svccfg except for > the final commit of current configuration changes into the running > snapshot. > > This is an oversight, because offline manipulation of the repository > does not allow a manual commit. We propose to introduce a new > "refresh" subcommand to svccfg(1M). If svccfg is operating on > the repository for the live system, this subcommand will > invoke svcadm refresh to accomplish the standard refresh actions > (rotate the snapshot and invoke the refresh method). If svccfg > is operating on an alternate repository, only the snapshot will > be rotated. > > 3. Interface Table > > Interface Stability Binding > --------- --------- ------- > refresh subcommand for svccfg(1M) Committed Patch > > 4. References > > PSARC 2002/547 Greenline > > 5. manpage diffs > > + Instance commands > + refresh > + If the chosen repository (selected by the "repository" > + command) is not the active repository, this command will > + update the Running snapshot for the selected instance in > + the specified repository. If no alternate repository is > + specified, this command is the equivalent of "svcadm > + refresh". > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Wed Jan 9 11:23:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09JN7H1003283 for ; Wed, 9 Jan 2008 11:23:07 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09JN3Cw028827; Wed, 9 Jan 2008 11:23:06 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE004015UG3A00@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 11:23:04 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE003DG5UF5H20@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 11:23:03 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09JLh5s014514; Wed, 09 Jan 2008 14:21:44 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m09JLhkN014511; Wed, 09 Jan 2008 14:21:43 -0500 (EST) Date: Wed, 09 Jan 2008 14:21:40 -0500 From: James Carlson Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <18309.7755.793435.715150@gargle.gargle.HOWL> To: Liane Praza , psarc-ext@sun.com, Alan Maguire Message-id: <18309.7876.828575.204222@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47851A25.4060606@sun.com> <18309.7755.793435.715150@gargle.gargle.HOWL> Status: RO Content-Length: 1122 [sorry ... hit 'send' too quickly] James Carlson writes: > Liane Praza writes: > > I'm filing this on behalf of Alan Maguire. I've submitted it as > > Closed-Approved-Automatic, as I believe it's an obvious change. > > However, if there's non-trivial discussion or concern, we'd be happy > > to convert it back to a fasttrack. > > I hope this is just trivial discussion (;-}), but it seems to me that > having both "svccfg refresh" and "svcadm refresh" is potentially > confusing for administrators. I suspect that they're confused about > the cfg/adm split already (we've certainly seen confusion with the > zone* commands), and this just adds a little fuel. If the definition of the "svccfg refresh" user interface provides all the needed functionality needed for a generic SMF "refresh" operation, and it seems it does, then is it possible to work towards making "svcadm refresh" obsolete? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From liane.praza@sun.com Wed Jan 9 11:47:09 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09Jl94G004149 for ; Wed, 9 Jan 2008 11:47:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09Jl1SN000442; Wed, 9 Jan 2008 12:47:07 -0700 (MST) 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 <0JUE0051B6YI8D00@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 11:47:06 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE003V76YG5E50@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 11:47:04 -0800 (PST) Received: from [129.146.228.172] (absurd.SFBay.Sun.COM [129.146.228.172]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09Jl4GQ915892; Wed, 09 Jan 2008 11:47:04 -0800 (PST) Date: Wed, 09 Jan 2008 11:47:04 -0800 From: Liane Praza Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <18309.7876.828575.204222@gargle.gargle.HOWL> To: James Carlson Cc: psarc-ext@sun.com, Alan Maguire Message-id: <478524B8.2030006@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: <47851A25.4060606@sun.com> <18309.7755.793435.715150@gargle.gargle.HOWL> <18309.7876.828575.204222@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1692 James Carlson wrote: > [sorry ... hit 'send' too quickly] > > James Carlson writes: >> Liane Praza writes: >>> I'm filing this on behalf of Alan Maguire. I've submitted it as >>> Closed-Approved-Automatic, as I believe it's an obvious change. >>> However, if there's non-trivial discussion or concern, we'd be happy >>> to convert it back to a fasttrack. >> I hope this is just trivial discussion (;-}), but it seems to me that >> having both "svccfg refresh" and "svcadm refresh" is potentially >> confusing for administrators. I suspect that they're confused about >> the cfg/adm split already (we've certainly seen confusion with the >> zone* commands), and this just adds a little fuel. > > If the definition of the "svccfg refresh" user interface provides all > the needed functionality needed for a generic SMF "refresh" operation, > and it seems it does, then is it possible to work towards making > "svcadm refresh" obsolete? It's possible, but I'm not sure it's desirable. It seems frustrating to have "svcadm restart" and then have to remember that "refresh", which is often a (mentally) related operation to "restart" is done using a different command, with a significantly different syntax. It'd also need to stay around for compatibility's sake, so wouldn't buy us much more than a stern warning in the svcadm manpage that the subcommand could go away in the future. I'm not sure that warning would lead to more customer satisfaction. If you're generally concerned about the usabilty of the *adm/*cfg command split, I'd think a piecemeal approach to trying to change it would be more likely to make things worse rather than better in terms of confusion. liane From carlsonj@phorcys.east.sun.com Wed Jan 9 12:19:03 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09KJ32X005531 for ; Wed, 9 Jan 2008 12:19:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09KIwAv010992; Wed, 9 Jan 2008 12:18:59 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE006038FLEH00@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 12:18:57 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE0035V8FJ6290@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 12:18:56 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09KHafR014890; Wed, 09 Jan 2008 15:17:36 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m09KHaVJ014887; Wed, 09 Jan 2008 15:17:36 -0500 (EST) Date: Wed, 09 Jan 2008 15:17:32 -0500 From: James Carlson Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <478524B8.2030006@sun.com> To: Liane Praza Cc: psarc-ext@sun.com, Alan Maguire Message-id: <18309.11228.29868.45407@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47851A25.4060606@sun.com> <18309.7755.793435.715150@gargle.gargle.HOWL> <18309.7876.828575.204222@gargle.gargle.HOWL> <478524B8.2030006@sun.com> Status: RO Content-Length: 2110 Liane Praza writes: > James Carlson wrote: > > If the definition of the "svccfg refresh" user interface provides all > > the needed functionality needed for a generic SMF "refresh" operation, > > and it seems it does, then is it possible to work towards making > > "svcadm refresh" obsolete? > > It's possible, but I'm not sure it's desirable. > > It seems frustrating to have "svcadm restart" and then have to remember > that "refresh", which is often a (mentally) related operation to > "restart" is done using a different command, with a significantly > different syntax. ... and a bit worse that "refresh" and "restart" are separate, with related ordinary word meanings, and I suspect most mortals are unable to recall which is which. But that's a bit beside the point. > It'd also need to stay around for compatibility's > sake, so wouldn't buy us much more than a stern warning in the svcadm > manpage that the subcommand could go away in the future. I'm not sure > that warning would lead to more customer satisfaction. The ultimate goal would be to provide a cleaner functional separation, so that all parameter-related things end up in svccfg (including 'refresh' snapshot manipulation), and that operational state bits end up in svcadm ... assuming a far-future removal of "svcadm refresh." > If you're generally concerned about the usabilty of the *adm/*cfg > command split, I'd think a piecemeal approach to trying to change it > would be more likely to make things worse rather than better in terms of > confusion. A piecemeal approach to usability was not quite what I was suggesting. It seems that the project rightly recognizes that 'refresh' is more related to parameter configuration than to service state, but that it doesn't go the whole way there. It seems you disagree, though, and I don't really have strong feelings on it, so I'll fold. :-/ -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Wed Jan 9 12:36:08 2008 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 m09Ka7CM006151 for ; Wed, 9 Jan 2008 12:36:08 -0800 (PST) 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 m09KZvW3024226; Thu, 10 Jan 2008 04:36:00 +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 <0JUE0070D97Y1U00@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 12:35:58 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE0037997X5DB0@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 12:35:57 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m09KZvoJ000853; Wed, 09 Jan 2008 14:35:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m09KZvW1000852; Wed, 09 Jan 2008 14:35:57 -0600 (CST) Date: Wed, 09 Jan 2008 14:35:57 -0600 From: Nicolas Williams Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <478524B8.2030006@sun.com> To: Liane Praza Cc: James Carlson , psarc-ext@sun.com, Alan Maguire Mail-followup-to: Liane Praza , James Carlson , psarc-ext@sun.com, Alan Maguire Message-id: <20080109203556.GC810@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: <47851A25.4060606@sun.com> <18309.7755.793435.715150@gargle.gargle.HOWL> <18309.7876.828575.204222@gargle.gargle.HOWL> <478524B8.2030006@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1028 On Wed, Jan 09, 2008 at 11:47:04AM -0800, Liane Praza wrote: > James Carlson wrote: > >> I hope this is just trivial discussion (;-}), but it seems to me that > >> having both "svccfg refresh" and "svcadm refresh" is potentially > >> confusing for administrators. I suspect that they're confused about > >> the cfg/adm split already (we've certainly seen confusion with the > >> zone* commands), and this just adds a little fuel. > > > > If the definition of the "svccfg refresh" user interface provides all > > the needed functionality needed for a generic SMF "refresh" operation, > > and it seems it does, then is it possible to work towards making > > "svcadm refresh" obsolete? > > It's possible, but I'm not sure it's desirable. > > [...] My suggestion is that if we do anything in this direction that we do this: leave svcadm as is (don't obsolete any part of it), and add some svcadm functionality to svccfg, so you can refresh/restart/enable/ disable/clear/degrade/restore services straight from svccfg. Nico -- From Nicolas.Williams@sun.com Wed Jan 9 12:39:04 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09Kd4Da006338 for ; Wed, 9 Jan 2008 12:39:04 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09KcwAF014977; Wed, 9 Jan 2008 13:39:02 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE00M0J9D19Z00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 12:39:01 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE002R69D07CC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 12:39:00 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m09KcxuP000862; Wed, 09 Jan 2008 14:38:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m09KcxVY000861; Wed, 09 Jan 2008 14:38:59 -0600 (CST) Date: Wed, 09 Jan 2008 14:38:59 -0600 From: Nicolas Williams Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <18309.11228.29868.45407@gargle.gargle.HOWL> To: James Carlson Cc: Liane Praza , psarc-ext@sun.com, Alan Maguire Mail-followup-to: James Carlson , Liane Praza , psarc-ext@sun.com, Alan Maguire Message-id: <20080109203859.GD810@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: <47851A25.4060606@sun.com> <18309.7755.793435.715150@gargle.gargle.HOWL> <18309.7876.828575.204222@gargle.gargle.HOWL> <478524B8.2030006@sun.com> <18309.11228.29868.45407@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 413 I like the refresh/restart split. Refresh implies that running service state/config can be updated without disruption. Restart implies that processes will exit/be killed and be restarted. The distinction makes a difference in terms of reliability. We should strive to provide useful refresh methods so that restarts can be avoided. But we must provide start/stop (and, therefore, restart) methods. Nico -- From liane.praza@sun.com Wed Jan 9 13:19:55 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09LJtfC010819 for ; Wed, 9 Jan 2008 13:19:55 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09LJo7h025493; Wed, 9 Jan 2008 14:19:52 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE00322B922B00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 13:19:50 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE002NVB917GE0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 13:19:50 -0800 (PST) Received: from [129.146.228.172] (absurd.SFBay.Sun.COM [129.146.228.172]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09LJni6928720; Wed, 09 Jan 2008 13:19:49 -0800 (PST) Date: Wed, 09 Jan 2008 13:19:46 -0800 From: Liane Praza Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <18309.11228.29868.45407@gargle.gargle.HOWL> To: James Carlson Cc: psarc-ext@sun.com, Alan Maguire Message-id: <47853A72.5090605@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: <47851A25.4060606@sun.com> <18309.7755.793435.715150@gargle.gargle.HOWL> <18309.7876.828575.204222@gargle.gargle.HOWL> <478524B8.2030006@sun.com> <18309.11228.29868.45407@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 3026 James Carlson wrote: > Liane Praza writes: >> James Carlson wrote: >>> If the definition of the "svccfg refresh" user interface provides all >>> the needed functionality needed for a generic SMF "refresh" operation, >>> and it seems it does, then is it possible to work towards making >>> "svcadm refresh" obsolete? >> It's possible, but I'm not sure it's desirable. >> >> It seems frustrating to have "svcadm restart" and then have to remember >> that "refresh", which is often a (mentally) related operation to >> "restart" is done using a different command, with a significantly >> different syntax. > > ... and a bit worse that "refresh" and "restart" are separate, with > related ordinary word meanings, and I suspect most mortals are unable > to recall which is which. But that's a bit beside the point. > >> It'd also need to stay around for compatibility's >> sake, so wouldn't buy us much more than a stern warning in the svcadm >> manpage that the subcommand could go away in the future. I'm not sure >> that warning would lead to more customer satisfaction. > > The ultimate goal would be to provide a cleaner functional separation, > so that all parameter-related things end up in svccfg (including > 'refresh' snapshot manipulation), and that operational state bits end > up in svcadm ... assuming a far-future removal of "svcadm refresh." But there's often a refresh method too, which makes it operational as well for a running system. I'm not convinced this would make a cleaner functional separation -- just a different one, while obsoleting the one many have become familiar with. Refresh often works for non-SMF configuration as well, which means that we'd be introducing a requirement to interact with svccfg for a common set of services which have no such operational requirement today. >> If you're generally concerned about the usabilty of the *adm/*cfg >> command split, I'd think a piecemeal approach to trying to change it >> would be more likely to make things worse rather than better in terms of >> confusion. > > A piecemeal approach to usability was not quite what I was suggesting. > It seems that the project rightly recognizes that 'refresh' is more > related to parameter configuration than to service state, but that it > doesn't go the whole way there. > > It seems you disagree, though, and I don't really have strong feelings > on it, so I'll fold. :-/ I'm not convinced that the choice to obsolete svcadm refresh is obvious, thus my bias would be to preserve existing, well-known interface. If anyone thinks that a few more days of discussion will help clarify we can convert to a fasttrack, but I admit I suspect this is a personal preference type of discussion. If it's clear it's a more natural administrative model, we'll see advice on public mailing lists and in documentation move rapidly away from svcadm refresh, and I'll be happy to file the obsolescence case if that happens. I'm always happy to obsolete things people don't use. :) liane From gww@eng.sun.com Wed Jan 9 13:23:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09LN6eD010894 for ; Wed, 9 Jan 2008 13:23:06 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09LN66Q026322 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 9 Jan 2008 14:23:06 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE00B03BEEHD00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 14:23:02 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE00EK0BEEMYE0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 14:23:02 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m09LN0R0001176; Wed, 09 Jan 2008 13:23:00 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m09LM4iK013931; Wed, 09 Jan 2008 13:22:04 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m09LM4G1013930; Wed, 09 Jan 2008 13:22:04 -0800 (PST) Date: Wed, 09 Jan 2008 13:22:04 -0800 (PST) From: Gary Winiger Subject: Re: 2008/015 svccfg refresh subcommand To: psarc-ext@sun.com, liane.praza@sun.com Cc: Alan.Maguire@sun.com Message-id: <200801092122.m09LM4G1013930@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 580 > This is an oversight, because offline manipulation of the repository > does not allow a manual commit. We propose to introduce a new > "refresh" subcommand to svccfg(1M). If svccfg is operating on > the repository for the live system, this subcommand will > invoke svcadm refresh to accomplish the standard refresh actions Leaving the discussion of confusion to others ;-{, I have a nit question: Now that audit is being done by svc.configd, is there a new interface that needs to be audited relative to introducing the svccfg refresh subcommand? Gary.. From jgh@wizmail.org Wed Jan 9 13:25:49 2008 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 m09LPmiB011099 for ; Wed, 9 Jan 2008 13:25:49 -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 m09LPaDi011895 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 10 Jan 2008 05:25:47 +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 <0JUE00301BIXOR00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 13:25:45 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE0036GBIXJ100@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 13:25:45 -0800 (PST) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m09LPdOp012699 for ; Wed, 09 Jan 2008 21:25:45 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay12i.sun.com with ESMTP id BT-MMP-102362 for psarc-ext@sun.com; Wed, 09 Jan 2008 21:25:39 +0000 (Z) Received: from relay17i.sun.com (relay17i.sun.com [129.179.4.127]) by mmp11es.sun.com with ESMTP id BT-MMP-111180 for psarc-ext@sun.com; Wed, 09 Jan 2008 21:25:39 +0000 (Z) Received: from wizmail.org ([217.146.104.199] [217.146.104.199]) by relay1ib.sun.com with ESMTP id BT-MMP-841639 for psarc-ext@sun.com; Wed, 09 Jan 2008 21:25:38 +0000 (Z) Received: from ebony.jgh.adsl.wizards.co.uk ([217.146.123.59]) (from_AS 16353) by wizmail.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.67) id 1JCiQb-0005K2-0X (return-path ); Wed, 09 Jan 2008 21:25:37 +0000 Date: Wed, 09 Jan 2008 21:25:35 +0000 From: Jeremy Harris Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <20080109203859.GD810@Sun.COM> To: psarc-ext@sun.com Message-id: <47853BCF.5020004@wizmail.org> 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 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.375sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47851A25.4060606@sun.com> <18309.7755.793435.715150@gargle.gargle.HOWL> <18309.7876.828575.204222@gargle.gargle.HOWL> <478524B8.2030006@sun.com> <18309.11228.29868.45407@gargle.gargle.HOWL> <20080109203859.GD810@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071115 Fedora/2.0.0.9-1.fc7 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 Status: RO Content-Length: 486 Nicolas Williams wrote: > I like the refresh/restart split. > > Refresh implies that running service state/config can be updated without > disruption. Restart implies that processes will exit/be killed and be > restarted. The distinction makes a difference in terms of reliability. It sounds like it behaves much as a "service foo reload" in RedHat. Was any thought given to using the same word for the subcommand? Is it too late to change? Or accept a synonym? Cheers, Jeremy From liane.praza@sun.com Wed Jan 9 13:45:51 2008 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 m09LjoAh011875 for ; Wed, 9 Jan 2008 13:45:51 -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 m09Ljbrp019830; Thu, 10 Jan 2008 05:45:48 +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 <0JUE00505CG7Q000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 13:45:43 -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 <0JUE0039CCG7J430@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 13:45:43 -0800 (PST) Received: from [129.146.228.172] (absurd.SFBay.Sun.COM [129.146.228.172]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09Ljht6933598; Wed, 09 Jan 2008 13:45:43 -0800 (PST) Date: Wed, 09 Jan 2008 13:45:43 -0800 From: Liane Praza Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <200801092122.m09LM4G1013930@marduk.eng.sun.com> To: Gary Winiger Cc: psarc-ext@sun.com, Alan.Maguire@sun.com Message-id: <47854087.9040903@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: <200801092122.m09LM4G1013930@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 922 Gary Winiger wrote: >> This is an oversight, because offline manipulation of the repository >> does not allow a manual commit. We propose to introduce a new >> "refresh" subcommand to svccfg(1M). If svccfg is operating on >> the repository for the live system, this subcommand will >> invoke svcadm refresh to accomplish the standard refresh actions > > Leaving the discussion of confusion to others ;-{, I have > a nit question: Now that audit is being done by svc.configd, > is there a new interface that needs to be audited relative > to introducing the svccfg refresh subcommand? I just confirmed with Tom that nothing new is needed in code or in the audit records. Auditing is done by configd, not the individual commands. The svccfg refresh action for the system repository will be audited with the standard ADT_smf_refresh path. Actions on offline repositories aren't audited. liane From carlsonj@phorcys.east.sun.com Wed Jan 9 13:52:47 2008 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 m09Lql7e011979 for ; Wed, 9 Jan 2008 13:52:47 -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 m09LqiP8022745; Wed, 9 Jan 2008 13:52:44 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE0060FCRUB000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 13:52:42 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE003SICRUJ530@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Jan 2008 13:52:42 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09LpN50008280; Wed, 09 Jan 2008 16:51:23 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m09LpM3n008274; Wed, 09 Jan 2008 16:51:22 -0500 (EST) Date: Wed, 09 Jan 2008 16:51:17 -0500 From: James Carlson Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <47853A72.5090605@sun.com> To: Liane Praza Cc: psarc-ext@sun.com, Alan Maguire Message-id: <18309.16853.875192.630278@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47851A25.4060606@sun.com> <18309.7755.793435.715150@gargle.gargle.HOWL> <18309.7876.828575.204222@gargle.gargle.HOWL> <478524B8.2030006@sun.com> <18309.11228.29868.45407@gargle.gargle.HOWL> <47853A72.5090605@sun.com> Status: RO Content-Length: 1645 Liane Praza writes: > James Carlson wrote: > Refresh often works for non-SMF configuration as well, which means that > we'd be introducing a requirement to interact with svccfg for a common > set of services which have no such operational requirement today. OK; good point. I wasn't looking at the foreign restarters. > > It seems you disagree, though, and I don't really have strong feelings > > on it, so I'll fold. :-/ > > I'm not convinced that the choice to obsolete svcadm refresh is obvious, > thus my bias would be to preserve existing, well-known interface. The fuzzy line for me was the idea of having the same subcommand in two very closely related administrative commands. > If anyone thinks that a few more days of discussion will help clarify we > can convert to a fasttrack, but I admit I suspect this is a personal > preference type of discussion. Probably so. I've at least convinced myself that if it is a problem, it can be fixed just as easily later, so I don't need to see a timer here. (Plus, I know I'd be holding up something pretty important for a concern that's pretty marginal ...) > If it's clear it's a more natural administrative model, we'll see advice > on public mailing lists and in documentation move rapidly away from > svcadm refresh, and I'll be happy to file the obsolescence case if that > happens. I'm always happy to obsolete things people don't use. :) ;-} -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From liane.praza@sun.com Wed Jan 9 14:12:33 2008 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 m09MCWpd013478 for ; Wed, 9 Jan 2008 14:12:33 -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 m09MCQlG000824 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 10 Jan 2008 06:12:31 +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 <0JUE00805DOT4400@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 14:12:29 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE0036QDORJ470@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 14:12:27 -0800 (PST) Received: from [129.146.228.172] (absurd.SFBay.Sun.COM [129.146.228.172]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09MCMXK937990; Wed, 09 Jan 2008 14:12:22 -0800 (PST) Date: Wed, 09 Jan 2008 14:12:22 -0800 From: Liane Praza Subject: Re: 2008/015 svccfg refresh subcommand In-reply-to: <47853BCF.5020004@wizmail.org> To: Jeremy Harris Cc: psarc-ext@sun.com Message-id: <478546C6.8040905@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: <47851A25.4060606@sun.com> <18309.7755.793435.715150@gargle.gargle.HOWL> <18309.7876.828575.204222@gargle.gargle.HOWL> <478524B8.2030006@sun.com> <18309.11228.29868.45407@gargle.gargle.HOWL> <20080109203859.GD810@Sun.COM> <47853BCF.5020004@wizmail.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1799 Jeremy Harris wrote: > Nicolas Williams wrote: >> I like the refresh/restart split. >> >> Refresh implies that running service state/config can be updated without >> disruption. Restart implies that processes will exit/be killed and be >> restarted. The distinction makes a difference in terms of reliability. > > It sounds like it behaves much as a "service foo reload" in RedHat. > Was any thought given to using the same word for the subcommand? > Is it too late to change? Or accept a synonym? The original verbs were finalized in 2003, so we weren't planning on changing them as part of this case. :) I don't think diverging to conform with RedHat rather than our other existing commands, methods, and library interfaces is a good idea. (But don't think that's what you were suggesting either.) As to synonyms -- it's always possible, but would probably be a separate case, as the verbs appear in a number of places and it'd be good to do an evaluation of how similar they really are, whether there are others in the RedHat command set which are also worth aliasing, and whether there are any other OSes it'd be good to bridge the gap with. (This is one area pretty much every OS and big distro has their own system and command set for these days.) If I was on ARC, I probably wouldn't accept one synonym without an evaluation of why the full synonym set wasn't being explored. I'm not personally inclined to drive such an effort, as I'm not sure there's huge benefit in differently named (and probably subtly differently behaving) commands having matching verbs/subcommands. However, you might find people who agree that this is important enough to contribute to making it happen either on smf-discuss or sysadmin-discuss if you do want to explore it further. liane