Clay,
The installadm is fixed for November and we are not going to change
it. Please stick to current installadm usage call your modules from
installadm. We can revisit this after 11/08 release.
Thanks,
Sundar
Clay Baenziger wrote:
> I don't think I'm making such a case, just that visualizing a lot of
> criteria can be difficult. The nice thing is only those used are
> displayed. (Currently there's not a parseable output option to list-manifests,
> having that means the admin could visualize to their desires.) Obviously,
> adding a criteria is a power-user kind of feature, but one necessary in
> specialized markets (i.e. HPC, universities, within Sun).
>
> Extending the criteria is quite easy, though there are no tools yet
> written. The AI.db SQLite database needs a column added to hold the
> criteria. (If it's a range value two columns need to be added one starting
> with "min" the other starting with "max" for the respective values).
>
> Afterwords, the criteria_schema is a value holder not a checker for if a
> criteria exists and is well formed, that's largely publish-manifest's job.
> So, the admin will make a criteria manifest including this new criteria.
>
> Then publish-manifest will automatically pickup the new criteria from the
> database and allow a manifest with that criteria to be published. Those
> values will be added to the AI.db.
>
> After the AI.db has those criteria in use from the manifest publication,
> the webserver will request those criteria from the AI clients. (The AI
> client I'm largely unfamiliar with, to know what Jan may have done to
> support extensibility yet.) But then, once the criteria is reported it
> will be looked up and the appropriate manifest served out.
>
> The only thing which needs to be spruced up is some way to flag a value as
> hexadecimal. Currently, I've just looked up for the criteria being called
> MAC, that's a kludge and needs to be fixed (i.e. for IPv6 environments). I
> think the two leading options are: (not so clean) to use a criteria suffix
> for its datatype (string, decimal, hex and length, if fixed). The cleaner
> sounding option, is to add a second table to the database
> which would track these options.
>
> Either way, this is not a November deliverable, and is mainly for future
> expansion!
> Thank you,
> Clay
>
> On Wed, 15 Oct 2008, Sundar Yamunachari wrote:
>
>
>> 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
>>>>>
>>>>>
>>>>>
>>
