Amit Gupta wrote: > > >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.
That depends on how you set $version. > Solaris as a whole), we can change this to /usr/collectd/4.0. Note that 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? > 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. I wouldn't know, I'm asking you, it's your component ;-) Does it make sense to include all these unknown plugins? 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? > 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. Will that work? 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? If it works cleanly, seems nice to me to include them. Add a section in the spec to address this topic, explain how things work (or what will work and what won't). > >Will these plugin config files be typically modified by customers? > > By default, there are no plugin config files. (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? Please add a paragraph in the spec explaining how this works, from customer perspective. > Only few plugins are enabled by default. I have included the list of > plug-ins which gets enabled by default in the ARC case. 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. Are customers expected to edit the main config file directly? Or should they restrict themselves to modifying content under conf.d? 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. > >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? 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. (Example: /usr/lib/sendmail - while it can be run manually and even has an extensive set of command line arguments, that's not how it typically gets used. Usually it is started by smf and not by humans.) collectd seems to fall in this category? (I could be wrong, I'm not a collectd user! For all I know it is used from the CLI all the time? If so just document that in the case.) A related point is whether to symlink the executable into /usr/bin or /usr/sbin. If it is typically used from CLI, you'll want to do that. If not, it won't be appropriate. > >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. Ok. Document that in the spec though, don't just silently drop it. That might surprise users who are familiar with collectd on other platforms and may be left wondering what happened to it. > I have removed them in the updated ARC case. Does it make > sense to include the directory for the man pages?. Listing it in the Appendix as you have it is fine, no need for more. > >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? root isn't great. Maybe noaccess, but depend on what privileges it needs. Ideally it should have its own user but that may be tricky until the Solaris builds are all IPS (IPS has an action to create user during pkg install, but there's no way to utilize it right now). > 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. However, not all plugins can be built > on OpenSolaris because of dependencies on external libraries > and hence, only a subset of the plugins will be delivered. 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. The problem with letting ./configure autodetect what to build is that the set of plugins you ship can change over time without anyone knowing, just because someone else added some library to the system. (The above isn't relevant to the ARC case, it is more of a code review comment.) > 5.3. Exported Interfaces Looks good to me. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
