You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chukwa.apache.org by "Ari Rabkin (JIRA)" <ji...@apache.org> on 2010/09/29 22:45:35 UTC
[jira] Created: (CHUKWA-527) stronger configuration checking
stronger configuration checking
-------------------------------
Key: CHUKWA-527
URL: https://issues.apache.org/jira/browse/CHUKWA-527
Project: Chukwa
Issue Type: New Feature
Components: data collection, documentation
Reporter: Ari Rabkin
Assignee: Ari Rabkin
Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
In particular, this will flag and log cases where:
An option is set in the Chukwa config files that is never read by Chukwa.
A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHUKWA-527) stronger configuration checking
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ari Rabkin updated CHUKWA-527:
------------------------------
Attachment: options.dict
This is my listing of automatically inferred Chukwa options, along with types. Idea is that if it's mostly auto-generated, it should be easier to keep up to date.
I can also generate separate dictionaries for each component, if that would be viewed as a significant change.
Next step is adding the functionality to do the checking.
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
> Attachments: options.dict
>
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHUKWA-527) stronger configuration checking
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ari Rabkin updated CHUKWA-527:
------------------------------
Status: Patch Available (was: Open)
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
> Attachments: CHUKWA-527.patch, confspellcheck.jar, options.dict
>
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHUKWA-527) stronger configuration checking
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916286#action_12916286 ]
Ari Rabkin commented on CHUKWA-527:
-----------------------------------
The context here is that my ongoing research is on flagging and fixing these kinds of bugs, so I have a tool for it that I want to test. I figured the Chukwa community would be a friendly place to try it, and would benefit from it.
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHUKWA-527) stronger configuration checking
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ari Rabkin updated CHUKWA-527:
------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
Alright. I am committing this. Let me know if something explodes.
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
> Attachments: CHUKWA-527.patch, confspellcheck.jar, options.dict
>
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHUKWA-527) stronger configuration checking
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ari Rabkin updated CHUKWA-527:
------------------------------
Attachment: confspellcheck.jar
CHUKWA-527.patch
Includes three things:
- A configuration spellcheck library, written by me. I intend to release source code to it, but do not wish to integrate the sourcecode into Chukwa.
- A set of "spellcheck files" specifying existing Chukwa options.
- Minor modifications to ChukwaAgent, CollectorStub, and ChukwaConfig to invoke the library with the appropriate sets of options.
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
> Attachments: CHUKWA-527.patch, confspellcheck.jar, options.dict
>
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHUKWA-527) stronger configuration checking
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ari Rabkin updated CHUKWA-527:
------------------------------
Attachment: options.dict
This is my listing of automatically inferred Chukwa options, along with types. Idea is that if it's mostly auto-generated, it should be easier to keep up to date.
I can also generate separate dictionaries for each component, if that would be viewed as a significant improvement on one big list.
Next step is adding the functionality to do the checking.
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
> Attachments: options.dict
>
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHUKWA-527) stronger configuration checking
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920030#action_12920030 ]
Ari Rabkin commented on CHUKWA-527:
-----------------------------------
See http://code.google.com/p/jchord/source/browse/#svn/trunk/conf_spellchecker for source code and license information for the configuration spellcheck library.
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
> Attachments: CHUKWA-527.patch, confspellcheck.jar, options.dict
>
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHUKWA-527) stronger configuration checking
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ari Rabkin updated CHUKWA-527:
------------------------------
Attachment: (was: options.dict)
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
> Attachments: options.dict
>
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHUKWA-527) stronger configuration checking
Posted by "Bill Graham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916360#action_12916360 ]
Bill Graham commented on CHUKWA-527:
------------------------------------
+1. It would be nice to have this output also dump out configs that are used and have this functionality available for each Chukwa component (i.e., Demuxer, Agent, Collector, etc).
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHUKWA-527) stronger configuration checking
Posted by "Eric Yang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920034#action_12920034 ]
Eric Yang commented on CHUKWA-527:
----------------------------------
Looks good so far. Need the following:
- confspellchecker-LICENSE.txt in lib.
- A wiki page to add new config to .dict file.
+1 when the above requirements are met.
> stronger configuration checking
> -------------------------------
>
> Key: CHUKWA-527
> URL: https://issues.apache.org/jira/browse/CHUKWA-527
> Project: Chukwa
> Issue Type: New Feature
> Components: data collection, documentation
> Reporter: Ari Rabkin
> Assignee: Ari Rabkin
> Attachments: CHUKWA-527.patch, confspellcheck.jar, options.dict
>
>
> Chukwa has many configuration options, and it's easy to mis-set them. I'd like to contribute a module for doing stronger static checks of configuration at startup.
> In particular, this will flag and log cases where:
> An option is set in the Chukwa config files that is never read by Chukwa.
> A non-numeric value is used for a numeric parameter, non-boolean value for boolean parameter, etc.
> The table of options and types is automatically generated and then human-checked. It should be easy to keep it up to date.
> The changes to the Chukwa codebase should be quite modest: one new Jar, and a handful of lines to invoke that Jar on startup.
> Does this sound like a thing people would like to see?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.