As a result of yesterday's discussion about abrt2,
here are tentative changes to the "more configurable" part.
On Wed, 2010-07-07 at 15:28 +0200, Denys Vlasenko wrote:
Note: not a lot of configurability is needed for the above programs
-
they do basically the same processing for all use cases.
abrt-handle-crashdump DIR [PARAMS]
Processes given crashdump directory.
[Best to implement as shell script, to make it easier to set up
custom processing? this way, sosreport, filetransfer/ticketuploader
plugins are no longer needed - they can be easily implemented
in shell script]
STAGE: created / uploaded / collectinfo / report / ...
abrt-plugin-ANALYZER
Do we need separate programs for this?
abrt-plugin-REPORTER (bugzilla,rhtsupport)
Used by abrt-handle-crashdump to interface to bug databases.
abrt-backtrace
abrt-debuginfo-install
It is not clear whether we will need abrt-handle-crashdump as a separate
process. It might be useful in this form, but OTOH maybe merging it into
its parent process, abrt-server, will allow better interaction with
client.
How to configure abrt-handle-crashdump?
conf file?
# stage [env vars] cmd [params]
uploaded abrt-action-get-build_ids
uploaded abrt-action-generate-backtrace
created abrt-action-upload ftp://user:pass@host/dir
created abrt-action-sosreport
collectinfo abrt-action-sosreport
collectinfo abrt-action-get-build_ids
collectinfo abrt-action-debuginfo-install
collectinfo FORCE=1 abrt-action-generate-backtrace
report abrt-action-bugzilla
https://bz-web1-test.devel.redhat.com/
report abrt-action-logger
report user_custom_shell_script
The config file is inherently limited in its configurability -
a program/script in its place is always more flexible.
However, such config file *does* allow to just delegate everything
to a script, if admin really wants/needs it:
# stage type cmd [params]
* * big_clever_script_which_does everything
Therefore for now I am sticking to the idea of keeping it.
Changes to its format:
Rename "stage" to "event" - better describes the nature of it.
Add "type" column - it's typical to want to do kerneloops
reporting only for oopses :D
Rename some events.
Add a possibility to have more than one "report_foo" reporting track.
End result:
# event type cmd [params]
post-upload ccpp abrt-action-get-build_ids
post-upload ccpp abrt-action-generate-backtrace
post-create * abrt-action-upload ftp://user:pass@host/dir
post-create * abrt-action-sosreport
post-create oops abrt-action-kerneloops
analyze * abrt-action-sosreport
analyze ccpp abrt-action-get-build_ids
analyze ccpp abrt-action-debuginfo-install
analyze ccpp abrt-action-generate-backtrace
report * abrt-action-bugzilla
https://bz-web1-test.devel.redhat.com/
report oops abrt-action-kerneloops
report * user_custom_shell_script
report_local * abrt-action-logger
report_fedorabz * abrt-action-bugzilla
https://bugzilla.redhat.com/
Every program is run with $1 set to crashdump dir, $2, $3 set as
configured. TODO: decide how to pass additional information
or modifiers, such as "*force* regeneration of backtrace"
(thru environment variables, maybe?
How to run third-party handlers?
What about syntax a-la this to specify mandatory parameters?
report * abrt-action-bugzilla
https://bz-web1-test.devel.redhat.com/
--login=%LOGIN% --pass=%PASS%
--
vda