Here's the results of our discussion:
1) The service is installed disabled. It will be enabled on the call to
installadm create-service.
2) When the last install service is disabled, the service will be disabled.
3) If no install services are "on" when svcadm enable of the smf service is
run, a descriptive log message will go to the SMF log and the smf service will
go to maintenance.
4) If the smf service is in maintenance a call to installadm enable will
clear the smf service.
5) Each install service will become a property group.
6) The service data file for the install service will become properties
residing in the appropriate property group.
Open Items: check with SMF group about performance impact (SMF and boot)
for 100's of instances and 100's of property groups. I sent email to
Tom and Tony today.
Next Steps:
- set up a "project" slim_clone
- analyze installadm create-service and delete-service so we know where
we need to make modifications and what those are.
- analyze share manager to see what parts of that code we can use and
how they did things.
- Get a brain dump from Doug on share manager.
Jean
Jean McCormack wrote:
> 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.
>
>
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
