Amit Gupta wrote:
>
> I have updated the draft ARC case. Please do review.
> Deliver collectd 4.8.x into OpenSolaris
> 25 September 2009
> /usr/collectd4/
The trend is towards /usr/$component/$version/ although we (Solaris as
a whole) hasn't been very consistent. We can just file the case with
that path, with a note to discuss it during ARC review.
> 2.2. Versioning
Good section, summarizes the important info perfectly.
> 2.3 Loadable Plugins
>
> collectd ships with a number of loadable plugins which are enabled
> through directives in the config file. Some of these plugins have
> library dependencies that must be satisfied through build time packag
> options (supplied to the configure script). An example is mysql.so
> which has a dependency on the mysql client libraries.
>
> Support for loadable plugins and other features is enabled at
> build time through flags to the configure script.
The above is fine as background explanation, but more concretely what
really matters is which plugins will you be delivering now.
Add a paragraph (or list, whatever works best) which documents the
plugins which will be delivered by the integration of this project
('project' meaning the work covered by this ARC case).
I see there is a list of *.so files in the Appendix, I assume these
correspond to the plugins? Still, you should highlight the supported
list here.
Also, I see in the Appendix list some plugins which do not correspond
to anything available in OpenSolaris, for example nginx.so. What does
it mean to deliver the collectd plugin for components which don't
[yet] exist on the platform?
> The default configuration file provided with this integration
> should work out of the box.
I hope so too, but we need to make sure! (And say so in the ARC case.)
> In addition, a directory conf.d will be created in /etc/collectd4
In the appendix it says:
> /etc/collectd4
> /collectd.conf
Does this mean there is a directory called
/etc/collectd4/conf.d/
and a file called
/etc/collectd4/collectd.conf
(note the appendix doesn't mention conf.d though, so maybe a typo?)
> This directory will be used for plugin configuration files so that the
> the plugins can be loaded without modifying the main configuration file.
Will these plugin config files be typically modified by customers?
Or are they static/private to the package? Or are they interfaces for
customers?
Do the delivered config files enable all the plugins all the time? Is
there a cost (memory, performance, other?) to having all the plugins
enabled all the time? And what about enabling plugins which don't
correspond to anything available on the system (like nginx)?
(Same goes for plugins for components which are available for
OpenSolaris but may not necessarily be installed on every customer
machine.)
Adding several paragraphs in section 2.3 explaining how all this ties
together will be helpful.
> 2.7 Build features
>
> See Appendix 2 for a list of features that collectd can be built
> with.
>
> Build time package selection determines which collectd loadable
> plugins
> are available to the user at runtime. A complete list of collectd
> modules is available on the http://collectd.org
Remove Appendix 2 and the text above. The info in Appendix 2 is low
level implementation/build detail.
What matters for the ARC case are the plugins and features which you
decide to deliver; document those.
> /usr/collectd4/sbin/collectdmon uncommitted executable
> /usr/collectd4/sbin/collectd uncommitted executable
The case doesn't yet have any coverage of these, add a section
documenting each.
The smf service just starts collectd, right? So collect probably
belongs in /usr/collectd4/lib not in sbin, as it is not a CLI system
administrators typically run by hand.
collectdmon appears to be a wrapper to start/restart collectd, in
other words, it duplicated what smf does. Is it needed in OpenSolaris?
Whether you decide to include it or not, document both the command and
the decision and why.
> /usr/collectd4/man/man1/collectd.1 uncommitted man page
> /usr/collectd4/man/man1/collectdmon.1 uncommitted man page
Don't list man pages in the interfaces, those are only for humans to read.
> svc:/application/monitoring/collectd4:default committed FMRI
Will the smf service have any configurable attributes?
Looks like everything can be configured in the config file, so probably
no need for any smf attributes (but give it a thought).
What is the runtime user of collectd?
What privileges it needs if any?
--
Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
