I have done some modifications to the directory and file structure, for instance, added libcollectdclient.so.0.0.0 to the file layout which was missed out in the earlier draft. Do find the updated spec attached for review.
Regards Amit On 10/17/09 00:10, Praveen Chandrasekharan wrote: > 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 > ------------------------------------------------------------------------ > > _______________________________________________ > > > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/webstack-discuss/attachments/20091029/35dd3d72/attachment.html> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: collectd-draft-arc.txt URL: <http://mail.opensolaris.org/pipermail/webstack-discuss/attachments/20091029/35dd3d72/attachment.txt>
