I am attaching an updated spec draft which hopefully addresses most of the review comments.
Praveen Chandrasekharan wrote: >> 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 > _______________________________________________ > > > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: collectd-draft-arc.txt URL: <http://mail.opensolaris.org/pipermail/webstack-discuss/attachments/20091017/253e961f/attachment.txt>
