On 09/14/10 01:00 PM, Sue Sohn wrote:
 > The main issue I'm having here is this:
 > I let users add custom manifests for clients they are installing, but
 > the script that wraps around it uses the -c to set the criteria.
 >
 > If another person goes and uses that same machine, I want to remove that
 > manifest so that the default is used- however, to do so, I need to know
 > what it is called.
 >
 > So my solution right now is to name the manifest ai_<ip_addr> - in that
 > way, if I have the hostname, I know the ip address and can see if there
 > is a manifest that needs to be removed.

You could continue to use the internal name attribute to do the same
thing as
you've been doing (but see below).

 Yes - it just means I have to do more processing of the manifest file.

And when the name changed with the other changes for manifests in 147, it meant by script had to be updated. It would be nice to have a CLI that is consistent to do this.


 > What would be handy here:
 >
 > 1) Something like 'installadm delete-manifest -n <service> -c
 > <criteria>' where that criteria is same as was used for add - in that
 > case, I care less what the manifest is called as I can then just put in
 > the same criteria as I used when adding it.

Interesting idea.

I think it would be very handy to be able to delete a manifest with the same mechanism you used to add it - just something about that symmetry is nice, and many other commands do something similar.


 > 2) Related to that, have installadm list -m have some option to show
 > what criteria is used for each manifest - I'm getting around this right
 > now by using the ip address in the manifest name. It seems like
 > installadm knows this, as if I try to add a new manifest for a system
 > that already has one set up, it will generate an error about the
conflict.

As Clay mentioned, you can see the criteria for each manifest in a given
service
by using the command:

installadm list -m -n <svcname>

Yes - I see that. I would note that the padding of the IP addresses with 0 is probably broken:

ai_10.5.233.117.xml   ipv4 = 010.005.233.117

It's broken in the sense that most all utilities will treat such padded addresses as octal (ping, telnet, probably everything that uses standard library routines). So if I do that installadm list and decide to cut/paste the address to see if it is up, I end up pinging the wrong host.

I can understand the desire to make it look nice and be formatted, but that padding also makes processing a little harder, as now the script would have to take the non padded IP address and pad it.


 > 3) Have an option to add-manifest for it to use that as the manifest
 > name instead of pulling it either out of the file name or using the file
 > itself.

Actually, one of the things that has always bothered me about installadm
is how
add-manifest uses the -m option one way (manifest file) and how
delete-manifest
(and now set-criteria) use -m another way (manifest name). We could make
things
more consistent by adding a new flag and by changing the usage slightly
as follows:

Current usage:
add-manifest -m <manifest> -n <svcname>
[-c <criteria=value|range> ... | -C <criteria.xml>]

Proposed usage:
add-manifest -f <manifest_file> -n <svcname> [-m <manifest_name>]
[-c <criteria=value|range> ... | -C <criteria.xml>]

The manifest file would now be specified with -f. The -m would be
optional and
could be used to specify the manifest name on the command line, if
desired. The
precedence order for the name would be:
1) -m option, if present
2) internal name attribute, if present
3) filename

Let me know what you think of this approach.

That looks pretty good to me. Consistency is always nice, and -f is used for many utilities to denote input/output file, so that helps it be consistent with other utilities also.

_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

Reply via email to