Kindly review the updated draft case attached. I have tried my best to 
include all the collectd plugin dependencies as imported interfaces. 
However, for some of the dependencies (e.g: |getutxent|), I wasn't able 
to find the corresponding ARC case, so I haven't included them in the 
ARC case.

Regards
Amit
On 11/04/09 21:16, Amit Gupta wrote:
> 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
>>
>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
>
>
> 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/20091105/a2a3ac14/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/20091105/a2a3ac14/attachment.txt>

Reply via email to