On 11/04/09 09:26, Jyri Virkki wrote: > Amit Gupta wrote: > >> Deliver collectd 4.8.x into OpenSolaris >> 25 September 2009 >> > > Please update the timestamp whenever a new revision is sent, the > date versioning only helps if it is changed along with doc changes... > > >> 2.1. Key objects >> >> /usr/collectd4/lib/*.so >> These are the collectd plugins .so files. >> > > nit: As noted later these are Project Private, so no real need to > highlight them in s.2.1 > Will do. > > >> Note that in many cases, these are just sample directives and will need >> to be modified based on site specific configuration. Detailed documentation >> > > Is the config file as-is from upstream or is there anything that can > be done to the copy delivered by this package to make sections > be preconfigured (even if commented out) for OpenSolaris? > We are indeed planning to patch the collectd.conf to get it working for OpenSolaris with minimal changes. > I assume some configuration is inherently customer-specific but to the > extent that it is possible, the delivered config should be tuned for > OpenSolaris so it will "just work" out of the box (or at least require > minimal manual intervention to work) as soon as customer uncomments it. > Yeah, that is the intention. > >> Other plugins can be enabled in one of the following two ways: >> * By adding/uncommenting the plugin configuration directives in >> collectd.conf >> * By dropping a .conf file having the necessary plugin configuration >> directives into the /etc/collectd4/conf.d >> > > What happens if a plugin is configured in both places? Do you expect > this overlap to be a problem in practice? > There is no issue even if the plugin is configured in both places. > For other packages it is most convenient to drop a config file into > the conf.d directory. > > > >> The following configure flags are used to build collectd: >> >> ./configure --prefix=/usr/collectd4 --sysconfdir=/etc/collectd4 \ >> --localstatedir=/var/collectd4 --disable-dns --with-java=/usr/java >> > > ARC case doesn't need to cover build system detail like this. > Okay. > At a code review level, as noted before it'll be more reliable to > enable and disable the chosen plugins instead of letting ./configure > work it out which can lead to silent changes over time. > Unfortunately, there is no configure flag to disable all the plugins and then enable only those plugins which are desired. This means that we need to have multiple enable-<plugin> as well as disable-<plugin> configure flags. The easier approach I can think of is to let the configure build all the plugins, however the collectd package will pick up only the plugins it needs to ship. > >> 5.2. Imported Interfaces >> >> libcurl Volatile PSARC/2007/165 >> libmysqlclient Committed LSARC 2009/062 >> libnetsnmp Uncommitted LSARC/2008/355 >> librrd Uncommitted LSARC/2008/129 >> libpq Uncommitted LSARC/2009/349 >> Java SE 6 Committed PSARC/2006/430 >> > > Also every interface used by the included plugins their data > collection is an imported interface. Fortunately looks like collectd > upstream has this info conveniently documented already. > > I only looked at a few, like Apache and CPU: > > http://collectd.org/wiki/index.php/Plugin:Apache > * Output format of mod_status > * libcurl > > http://collectd.org/wiki/index.php/Plugin:CPU > * kstat_read(3KSTAT) > > So, for each included plugin list those dependencies in the imported > interfaces. > I am not sure if I will be able to find the ARC case for each of these dependencies. I will give a try.
I will be sending out the updated ARC case soon. Regards Amit > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/webstack-discuss/attachments/20091104/d6c9a428/attachment.html>
