I think the answer to this is No, based on the experimentation I have done but I'd like to ask just before I give up on the idea.
I'm trying to design a simple plugin framework for time-slider that allows extra functionality to be hooked in. Currently the FMRI for time-slider is: svc://application/time-slider:default My idea is to use the following FMRI for plugins: svc://application/time-slider/plugin:rsync svc://application/time-slider/plugin:zfssend etc. The plugin template is defined by the plugin's manifest file, and each plugin is represented by an instance of the plugin service (rsync, zfssend etc) The time-slider service daemon scans for enabled plugins, and reads some standard configuration configuration properties from each instance such as a command path to execute the plugin. This seems like a nice solution to me since it enables plugins to be created, imported, monitored and managed in a consistent and familiar way without needing to reinvent wheels and allows a well structured and defined configuration mechanism. This takes care of things from the time-slider service end, but obviously each plugin is going to potentially need to store some unique configuration specific to that instance only and it would be ideal if it could store this configuration data within in a property group. For example, a plugin that implemented remote replication using zfs send might like to provide an option to send incremental or complete snapshot streams and it would be ideal if it could store that configuration within it's own SMF instance. It seems that I can't do this though. From my attempts to define a new property group within the <instance >...</instance> tags, the new property group and properties get ignored when I import the manifest file using svccfg(1) Is what I am attempting to do possible? Or would it require a unique service defined for each plugin rather than using instances of the same service? Thanks, Niall -- This message posted from opensolaris.org
