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' >>> >>> >>> - 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. >> ... >> >> >> 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. > 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. > "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> thanks, -ethan
