Clay,
You are making your case for limited number of fixed criteria
parameters. How is this extensible?
Clay Baenziger wrote:
> Hrm...
> Yeah, I'm not sure that an admin is going to want to keep the
> criteria manifest file around that they used for adding criteria X many
> months ago -- to me that'd be difficult; especially difficult in a lab
> environment like I've worked in at Sun, or a even university environment
> as I came from before.
>
I don't come across system administrators who threw away their
configuration information after finishing the configuration. Tell me why
you want to add a manifest using a criteria and remove it using an
instance. Why don't you list your manifests based on criteria file? How
are you going to accommodate SC manifest in this case?
I think we should treat a criteria along with AI and SC manifest a a
single entity. This is the input to 'installadm add' and this is the
input for 'installadm remove'. Your model ask the user to add using the
criteria but remove it using the manifest and instance, which is not a
sound user interface design. If the admin is not going to remember the
criteria, how is he/she going to remember the manifests?
Please don't try to change the user interface to suit your
implementation. We have decided that the user is going to use criteria
with pointers to AI manifests and SC manifests. Continue to use the same
decision for remove and list command.
We can discuss after this release is completed whether we need the
flexibilty.
Thanks,
Sundar
> If you see the output of print-manifest you'll see it lists
> criteria and instances in a clean format, so does the webserver. I can
> have remove-manifest accept either an instance or criteria manifest if we
> really want, as I have preliminary support for that in the database
> routines but I think it's a far less useful way to dell.
> See below for my example of list-manifests output:
> [3] transsiberian# /usr/sbin/installadm/list-manifests -c
> /tmp/var/AI_service_1/
> Manifest Instance arch MAC IPv4 product manufacturer
> -----------------------------------------------------------------------------
> manifest1.xml:
> 0 amd64 C0FFEE00 - - -
> C0FFEEFF -
> -
> 1 sun4u 172020024000 - -
> 172020027255
> 2 amd64 - ultra 40 sun microsystems
> -
> -
> 3 sun4u C1FFEEFE - - -
> -
> manifest2.xml:
> 0 amd64 - vgn-g2aans sony corporation
> -
> 1 sun4v C0FFEE00 - - -
> -
>
> Thank you,
> Clay
>
> On Wed, 15 Oct 2008, Sundar Yamunachari wrote:
>
>
>> Clay Baenziger wrote:
>>
>>> Hello,
>>> I'm thinking how to go about integrating the hopefully soon to be
>>> available print-manifests and delete-manifest commands into installadm.
>>> The usage I have for each is:
>>> delete-manifest [-i instance] manifest A/I_service_dir
>>> print-manifests [-c] A/I_service_dir
>>>
>>>
>> These are the usage of you internal scripts. In the installadm, the
>> usage for add and remove manifest are:
>>
>> installadm add -m manifest -n svcname
>>
>> installadm remove -m manifest -n svcname
>>
>> This manifest is the criteria and it contains pointer to AI manifest and
>> SC manifests. This usage is consistent for add and remove Why you need
>> an instance in remove? How do you explain the instance to the user. We
>> are not getting the instance from them. How do the admin know how an
>> instance correspond to a manifest?
>>
>> My suggestion is to keep it simple for the user. You keep track of the
>> criteria file and the manifests (parts of criteria). Use it to remove.
>> Don't show instances to the user because you created the instance to
>> manage it efficiently.
>>
>> The same applies for 'installadm list -n svcname'. Give the list of AI
>> criteria and manifests to the user. I don't want to complicate the user
>> interface.
>>
>>
>>
>>> These options provide flexibility, but that wasn't planned in installadm.
>>> For delete-manifest it allows one to delete a specific set of criteria for
>>> a particular manifest (opposed to every criteria set for that manifest).
>>> For print-manifest -c prints the criteria and instances out opposed to
>>> just the manifest names. It seems this provides significant benefit for
>>> admins, but how should installadm offer it?
>>>
>>>
>> We are deleting manifest here. We are deleting only the criteria. If the
>> AI manifests are used by other criteria, we don't delete them. If the
>> criteria being deleted is only one uses a specific manifest, we can
>> delete the manifests.
>>
>>> Right now there's installadm list with the usage "list [-n <svcname>]"
>>> which is overloaded to mean provide a service and get manifests for that
>>> service otherwise get a list of services. Would it make sense to change
>>> the usage to "list [-n <svcname> [-c]]"?
>>>
>>>
>> I think by default you should print criteria and manifest names.
>> Criteria is only one user provides to 'installadm add' command.
>>
>>> Otherwise, for remove the usage is: "remove -m <manifest> -n
>>> <svcname>". I don't believe there's any overloading planned, but perhaps
>>> I'm wrong? If not I'd propose changing remove to have the usage "remove
>>> -m <manifest> [-i <instance>] -n <svcname>" to allow an admin to remove
>>> either an enitre manifest or just one criteria set for that manifest.
>>>
>>>
>> Again the admin is adding/deleting only criteria. Importing the
>> manifests is what your program does to keep track of the manifests. So I
>> don't think any change in installadm remove/list is needed.
>>
>> Thanks,
>> Sundar
>>
>>> Thank you,
>>> Clay
>>> _______________________________________________
>>> caiman-discuss mailing list
>>> caiman-discuss at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>
>>>
