Frank Ludolph wrote: > Ethan Quach wrote: >> Frank, >> >> Thanks for the feedback. All in all, I'm leaning toward 2, >> but with some comments below ... >> >> >> >> Frank Ludolph wrote: >>> Ethan Quach wrote: >>>> This is the proposed syntax: >>>> >>>> >>>> installadm list [ [-m] <svcname> | -c | -r ] >>>> >>>> Lists information about the install services that have >>>> been setup on this system. Information for all install >>>> services will given if a specific svcname is not provided. >>>> With the '-m' option, manifest information will also be >>>> given, but can only be used when a specific svcname is >>>> provided. The '-c' option will list all clients that >>>> have been created on this server. The '-r' option will >>>> list information for remote install services in addition >>>> to the local ones. >>>> >>>> >>>> -m svcname Lists all manifest information, including >>>> the manifest criteria, for the install >>>> service specified. >>>> >>>> -c Lists all clients that have been created >>>> on this server, and the install service >>>> and imagepath used with each client. >>>> >>>> -r Lists basic information for remote >>>> services as well as local services. >>>> >>> CLIP isn't supportive of mutually exclusive options, suggesting the >>> use of multiple subcommands instead. Here are a couple of alternatives. >>> >>> Alternative 1: logically identical to the above >>> >>> installadm list-services [-r] Lists basic info for all >>> local services >>> -r adds basic info for >>> remote services >>> installadm list-manifests <svcname> Lists info for each >>> manifest, grouped by >>> service >> >> Could <svcname> be optional here? > If <svcname> is optional then it should be [-n <svcname>] >> >>> installadm list-clients Lists clients and their >>> install service and >>> imagepath >> >> Since we're not using an option to denote clients anymore, could >> this now be: >> >> installadm list-clients [<svcname>] >> >> to report clients belonging only to the specified service? > As above, if it is optional it should be [-n <svcname>]
With these two additions, alternative 1 becomes very straightforward, but I still can't get behind having three different subcommands for listing information, so unless somebody else has an opinion on this, lets go with 2 below. >> >> >>> >>> Alternative 2: >>> >>> installadm list [-m] [-c] [-n <svcname>] See below >>> installadm list-remote [-n <svcname>] Lists basic info for >>> remote service(s) >> >> I'd hate to have a separate subcommand just for this one case. Could >> we create the mutual exclusive -r just for this one case? >> >> installadm list [[-m][-c] | [-r]] [-n <svcname>] >> >> i.e. if you want remote services, you can't get manifest or client >> information.. > I would still prefer the separate subcommand, but what you suggest is > probably acceptable. In fact I expect that there will be an > enhancement request to enable listing of manifest and client info from > remote services as well which would result in > > installadm list [-m] [-c] [-r] [-n <svcname>] > That sounds reasonable, but for now, you're okay if we do the mutual exclusive format, right? >> >>> >>> Examples: >>> installadm list Lists basic info for >>> local services >>> installadm list -n <svcname> Lists basic info for >>> named (local) service >>> installadm list -m -n <svcname> Lists info for each >>> manifest of named >>> service >>> installadm list -m Lists info for each >>> manifest, grouped >>> by service >>> installadm list -c Lists info for all >>> clients >>> installadm list -c -n <svcname> Lists info for all >>> clients of named >>> service >>> installadm list -c -m -n <svcname> Lists info for each >>> manifest of named >>> service >>> followed by client >>> info >>> installadm list -c -m Lists manifest and >>> client >>> info grouped by >>> service >> >> The output for this last one will look awkward because we're >> giving two sets of data, each with their own data columns, grouped >> by one other set of data. I'm thinking that the output would be >> unscalable going across because some columns will apply to Manifests >> while some apply to Clients. e.g. ... Thoughts? >> >> >> # installadm list -c -m >> Service Manifest Client Imagepath >> ------- -------- ------ --------- >> service1 >> manifest1 (default) >> manifest2 >> manifest3 >> >> client1 /export/aiimages/b107 >> client2 /export/aiimages/RC2 >> >> service2 >> manifest1 >> manifest2 (default) >> >> client1 /export/aiimages/foo >> client2 /export/home/user/ai_image >> client3 /export/aiimages/bar >> >> service3 >> manifest1 (default) >> >> client1 /export/home/user2/2008.11 >> client2 /export/aiimages/b107 >> > I agree it looks a bit awkward. A couple of alternatives: > > Alternative 1: Compact but maybe subject to confusion about implied > relationship of manifests to clients - there isn't any > > # installadm list -c -m > Service |Manifests |Clients Imagepath > ------- |-------- |------ --------- > service1 |manifest1 (default) |client1 /export/aiimages/b107 > | |client2 /export/aiimages/RC2 > | | > service2 |manifest1 |client1 /export/aiimages/foo > |manifest2 (default) |client2 /export/home/user/ai_image > | |client3 /export/aiimages/bar > | | > service3 |manifest1 (default) |client1 /export/home/user2/2008.11 > | |client2 /export/aiimages/b107 > > Alternative 2: More straightforward but basically just an installadm > list -m followed by an installadm list -c > > # installadm list -c -m > > Service Manifest > ------- -------- > service1 manifest1 (default) > manifest2 > manifest3 > service2 manifest1 > manifest2 (default) > service3 manifest1 (default) > > Service Client Imagepath > ------- ------ --------- > service1 client1 /export/aiimages/b107 > client2 /export/aiimages/RC2 > service2 client1 /export/aiimages/foo > client2 /export/home/user/ai_image > client3 /export/aiimages/bar > service3 client1 /export/home/user2/2008.11 > client2 /export/aiimages/b107 > > Since service and manifest names are likely to be longer than shown in > the examples, alternative 2 might be the best way to go for now. Also > the easiest to implement. ;-) Yes I agree alternative 2, of these two output versions, would be less problematic I think. thanks, -ethan
