Ethan Quach wrote: > > > Frank Ludolph wrote: >> Ethan Quach wrote: >>> >>>> >>>> - The above two imply that criteria could be administered >>>> subsequent to a manifest being published. Given that criteria are >>>> an external entity from the actual install manifest (the ai_manifest), >>>> I think this makes sense. Perhaps we add a couple new >>>> subcommands to enable this? (This assumes that the list of 'criteria' >>>> is an interface we export, and is not customizable. I didn't see >>>> anything in the design doc to say otherwise.) >>>> >>>> installadm set-criteria -n <svcname> -m <manifest_name> name=value >>>> >>>> installadm get-criteria -n <svcname> -m <manifest_name> [name] > > I just realized that we should probably also implement a > 'del-criteria' (or 'unset-criteria') subcommand so that users can > delete criterias on the command line as well. It would take the > same arguments as 'set-criteria' maybe clear-criteria? > >>>> >>>> >>>> - Be able to view the contents of a published manifest. Perhaps: >>>> >>>> installadm export-manifest -n <svcname> -m <manifest_name> [-o >>>> file] >>>> >>>> >>>> - Being able to edit the attributes of a published manifest would >>>> seem like a natural follow-on to the above, but I don't have any >>>> evidence yet that this is required. Given the ability to export the >>>> contents of a manifest, it should suffice for now to just export a >>>> manifest to file, make edits, and re-publish. >>> >>> If a manifest gets republished (i.e. we readd a manifest to a service >>> that already has that manifest name), we'll check if the criterion >>> for the already published manifest matches that of the one being >>> added. If they differ, ask user which one they want. >> It would probably be a good idea to do this only if the current >> manifest has been altered using the set-criteria command so that the >> user is queried only when appropriate. Perhaps a flag could be set in >> the current manifest by the set-criteria command. > > I don't really see that having edited a criteria by the 'set-criteria' > command as being special. My goal of creating subcommands to > externally administer the criteria was so that a user could start > out with a null criteria, add/remove criteria on the fly, and it > resulting in the same thing. We're trying to warn the user who is unaware of a prior 'set-criteria' that is about to be overwritten. If the two sets of criteria are different only because the the combined manifest was edited, then the criteria change is explicitly intended and we don't have to be concerned about accidentally overriding a set-criteria. Warning the user that they edited a file is irritating. > >>> ... >>> >>> >>> For all of the installadm subcommands, the main operand shouldn't >>> need an option identifier. For example, >>> >>> installadm list -n <svcname> >>> >>> should be >>> >>> installadm list <svcname> >> Since all installadm subcommands, except delete-client, help, and >> version, require svcname I suggest that it be made an operand for all >> commands and all other arguments be options. > > The new [set|get]-criteria subcommands we're proposing > don't follow this convention. The svcname is specified as an > option in those cases. I was suggesting that those be changed too: installadm set-criteria -m <manifest_name> -p name=value svcname
installadm get-criteria -m <manifest_name> -p [name] svcname where -p can be repeated for multiple properties > >> For backward compatiblity -n svcname could continue to be accepted. > > I'd even venture to support not needing this backwards > compatibility. What we've released on only a preview of AI, > so changes like these are fair game I would think. OK > >> "Installadm help subcommand" would not be affected. "Delete-client >> mac_addr" would be changed to "delete-client -e mac_addr" to be >> consistent with "create-client -e mac_addr ..." and the use of >> svcname as the only command operand. > > Shouldn't the concept of the "command operand" depend on the > subcommand? For the case of create-client, the service is more > like a supporting option, and the client is the main operand, so I > was thinking create-client to become > > create-client ... [-t <imagepath>] -n <svcname> <client_ID> You could do that, but the syntax is easier to remember when the operand is the same across subcommands, and virtually all commands, including create-client require <svcname>. Also, I don't quite understand why -t is required since each service has only one <imagepath>, right? Frank
