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