On 10/23/2015 09:31 PM, Sankarshan Mukhopadhyay wrote:
On Fri, Oct 23, 2015 at 4:16 PM, Aravinda <avishwan@xxxxxxxxxx> wrote:
Initial idea for Tools Framework:
---------------------------------
A Shell/Python script which looks for the tool in plugins sub directory, if
exists pass all the arguments and call that script.
`glustertool help` triggers a python Script plugins/help.py which reads
plugins.yml file to get the list of tools and help messages associated
with it.
No restrictions on the choice of programming language to create
tool. It can be bash, Python, Go, Rust, awk, sed etc.
Challenges:
- Each plugin may have different dependencies, installing all tools
may install all the dependencies.
- Multiple programming languages, may be difficult to maintain/build.
- Maintenance of Third party tools.
- Creating Plugins registry to discover tools created by other developers.
Diagnostics and remediation become important when a higher level
abstraction (eg. a management construct for Gluster deployments are
involved). What your thoughts on such frameworks being able to consume
the logs; identify the possible issues and recommend a fix/solution?
Does this proposal anticipate such a progression?
Older idea on this was, to consume the logs and filter based on the
message IDs for those situations that can be remedied. The logs are
hence the point where the event for consumption is generated.
Also, the higher level abstraction uses these logs, it can *watch* based
on message ID filters that are of interest to it, than parse the log
message entirely to gain insight on the issue.
Do you see this as a viable option?
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
