Thanks Jyri for looking into the ARC case. Updated ARC case is attached.
Do find my comments inline.
On 10/15/09 10:20, Jyri Virkki wrote:
> Amit Gupta wrote:
>
>> /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.
>
IMO /usr/$component/$version gives the impression to the users that the
multiple 4.x releases will sit under /usr/collectd. Since the collectd's
minor versions (4.x) and patchlevels (4.x.x) are guaranteed to be
compatible (per collectd FAQ) , we have opted for /usr/collectd4. If you
feel that /usr/$component/$version makes it more consistent (with
Solaris as a whole), we can change this to /usr/collectd/4.0. Note that
collectd 4.8.1 will also be installed into this same directory since we
don't need a separate directory for each minor/patch version of 4.x.
>> 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.
>
I just followed the apache/lighttpd ARC cases and they don't seem to
list the modules as well. I have included the plug-ins list in the
updated ARC case, however, there are lot of plug-ins which gets build by
default and I don't not have much idea about some of these plugins, for
instance, multimeter, olsrd, TeamSpaekk2 and so on. Kindly have a look
at the list and let me know if including all the plugins make sense.
> 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?
>
I have noticed that the folks seem to be building some of these
components on OpenSolaris (e.g: openvpn), so does it make sense to have
these plugins delivered in any case? Even if nginx is not part of
OpenSolaris, some folks may build it themselves or get it from the
webstack repo.
>> 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.)
>
Thanks for catching it.
>
>
>> 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?)
>
conf.d has been added on the lines of apache to make it easy to include
configuration directives by just dropping config snippets.
>> 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?
>
By default, there are no plugin config files.
> 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?
> 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)?
>
Only few plugins are enabled by default. I have included the list of
plug-ins which gets enabled by default in the ARC case.
> (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.
>
This has already been done in my recent draft. I have added the
configure flags, we have used, instead.
> 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.
>
This is being taken care of.
> 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.
>
I looked into the other SFW components and it seems that lighttpd has
lighttpd in sbin, apache2 has httpd in bin, mysql has mysqld in bin and
so on. So, I am not sure what is the right location for collectd?
> 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.
>
This won't be needed.
>
>
>> /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.
>
I have noticed this in the lighttpd ARC case, so I have mentioned it in
here too. I have removed them in the updated ARC case. Does it make
sense to include the directory for the man pages?.
>
>
>> 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).
>
As you have mentioned, everything can be configured via collectd.conf.
> What is the runtime user of collectd?
>
Right now I am assuming runtime user to be root but there is no reason
for it to run as root. What is the recommended runtime user for
collectd? Should it be collectd?. If yes, how do we create this user on
OpenSolaris?
> What privileges it needs if any?
>
No particular privileges that I know off.
Regards
Amit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/webstack-discuss/attachments/20091015/12a5b98e/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/20091015/12a5b98e/attachment.txt>
