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.
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
> >
>
