Here's a high flying proposal for fixing 7218. The plan is to discuss
this at tomorrow's brown
bag.
Jean
The following is a high level view of my thoughts for a more robust SMF
implementation for AI. It's based heavily on share manager.
1) The service will be installed disabled. To enable the admin will either
svcadm enable <svcname> or the initial call to installadm create-service
will
enable the SMF service.
2) The general idea is to optionally allow multiple instances of the
service.
There will always be the default instance and then we may allow the user
to specify groupings. This would involve adding a flag to the command line.
Something like -g. Each grouping would be another SMF instance. This
would be nice in that it may help performance and it would be nice for
observability. You could do things like groupings of sparc or intel or
Jean_systems/Sundar_systems/dave_systems etc. As mentioned this would be
optional and if we had issues with time constraints could be added later.
3) Associated with each SMF instance would be property groups. Each
property group would relate to what we call an install service. If there
is not -g specified on the create-service command line, the default
instance is used to associate the property group with. If there is a -g
specified, then the instance is created if it doesn't exist. The
property group is then associated with the instance that corresponds to
the -g value.
4) Associated with each property group would be SMF properties. This is
the data now stored in the service_data file.
Visual representation of the above:
Instance default Jean_systems
Sundar_systems
Property group nv_109 4488_fix 1041_fix
6293_sparc_fix
Properties status=on status=off status=on status=on
manifest=? .... ..... ....
....
5) We need to modify the rest of the installadm commands to use the smf
properties. If we implement the -g option that would need to be taken
into account also.
