Niall Power wrote: > 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?
While I'm not positive from your description, I suspect you're running into the "multiple manifests, one service" problem, 6517953. It's a priority for us to fix after the current round of issues/features we're working on. Try it with defining everything in one manifest for now rather than using separate manifests for the plug-ins. If that works, it will confirm you're hitting this bug. liane
