> In s.2.2 it says minor versions are compatible, so in that case there > won't be a need to have both '4.0' and '4.1' at the same time. Only > '4' and in some future a '5'. True?
correct. Would /usr/collectd/4/.. (just a major number for version) be acceptable in the Solaris scheme of things? > While I assume collectd won't be a component with first tier support, > still, integrating the component and plugins into OpenSolaris sets > some level of presumption that they do work properly in OpenSolaris. > > Do they all work properly in OpenSolaris? It would indeed be a tough job for us to figure out if each of these components is available for opensolaris and what configuration is needed to get collectd to monitor the same. Do you believe it makes more sense to only include those plugins wjhich we can guarantee will work? If so, the plugin list will become very small. > If I install, say, nginx from the unsupported /webstack repo today and > then install the collectd package, will the nginx plugin in collectd > work out of the box with my nginx instance? > > Or do I (the customer) need to do something? Edit some config? The plugin will need to be enabled in collectd.conf and each of the plugins have their own configuration which is specified in the collectd documentation: http://collectd.org/wiki/index.php/Table_of_Plugins. They can do this configuration directly in collectd.conf or add a plugin.conf snippet which they drop in conf.d, both should work. > (in conf.d) - So customers need to manually create these plugin config > files? How will they know how to do that? Would it be sensible to > include either samples or commented-out copies? For each of the plugins, there are commented out sample entries for plugin configuration in collectd.conf. > Please add a paragraph in the spec explaining how this works, from > customer perspective. will do. > How and where are these enabled by default? Can customer disable some > of the default ones? How? I would've guessed they are enabled via > corresponding config files in conf.d, but above it stated that there > are no config files out of the box. All configuration is in collectd.conf. Any plugin can be enabled or disabled by commenting/uncommenting the LoadPlugin directive in collectd.conf. > Are customers expected to edit the main config file directly? Or > should they restrict themselves to modifying content under conf.d? either should work, as with apache httpd.conf. > These questions are meant to point to a gap in coverage in the spec on > the topic of plugin & configuration management. I suggest adding > content in s.2.3 providing a summary on how it all works. will do. > In Solaris binaries which are not typically intended for being run > manually from a shell (for example, daemon binaries typically started > by smf, like here) live in lib. Will move the collectd binary to /usr/collectd4/lib. > Don't let the ./configure stage autodetect which plugins end up > getting built. Instead, explicitly --enable or --disable the ones you > specifically want and don't want. Yes this makes for a very long > ./configure line. Take a look at e.g. PHP build in SFW for an example. It simply seemed easier to allow all plugins to be built and we then pick and choose which plugins get bundled using the package prototype. I will send out an updated spec soon. Praveen
