On 07/07/2010 03:28 PM, Denys Vlasenko wrote:
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 / ...
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
Here are some thoughts how we could evolve abrt-handle-crashdump:
This config file can be used as an effective way how to support 3rd
party plugins: custom reporters, custom collectinfo steps, custom shell
scripts -- whatever a power user or admin wants. It allows a good degree
of customization by env. variables and parameters, but it does not allow
everything we want to offer to GUI and CLI users on the desktop. In
other words: abrt-handle-crashdump would still support all the stages as
proposed, but we would use them only for stuff which does not need user
configuration and intervention.
So we would not use it for our Bugzilla plugin, bug status updates and
so on, but if someone want to write a custom collectinfo/reporter, or
enable our reporter this way, the possibility is there and it is usable.
The plugin entered here just cannot have a GUI settings, custom wizard
step in the GUI, bug status refreshing, and custom CLI stuff like "ask
for password if it's missing", but you can write a plugin which does a
lot of things with the debugdump directory and that's it.
We can handle the configuration of our complex, GUI/CLI-interacting
plugins with periodic background refreshing and whatever else will be
needed closer to the processes which uses them. It would allow us to
provide greater degree of customization (as expected by GUI users, and
differently by CLI users). Reporting and collectinfo can be moved to
GUI, CLI and abrtd (=autoreport). The only action we need from
abrt-handle-crashdump is to mark the crashdump as reported (e.g. call
`abrt-handle-crashdump DUMPDIR --mark-as-reported` via abrt-server), and
store some information (abrt-handle-crashdump DUMPDIR --store
"bugzilla_id" "560874" --store "bugzilla_status"
"NEW" --store
"bugzilla_url" "http://").
GUI would store its enabled reporters and their settings in /etc/abrt/
and GConf, CLI in /etc/abrt/ and ~/.abrt/, abrtd autoreporter in
/etc/abrt/. We can later decide to support custom GUI for plugins, but
we can implement it in the GUI (as a plugin to GUI, not to the ABRT core
system). The same thing with the CLI.
GUI would run the plugins at is sees fit (for example Jiri can decide to
refresh Bugzilla statuses every 20 minutes in GUI, so he sends a
hardcoded request "RefreshBugzillaStatuses" to abrt-server via
abrt-dbus, and abrt-server runs `abrt-bugzilla DUMPDIR --refresh-status`
for every crash which has a bugzilla_url and bugzilla_bug_id in the
DUMPDIR).
So the logic deciding which reporters and which reporter settings are to
be used with certain crash would be in the GUI and CLI. Some of the
logic would fit to abrt-server, or we can share some code between the
GUI and CLI using a library or a shell script. This way we will be able
to implement requests like "KDE crashes should go to KDE Bugzilla
preferrably, but keep the option to submit them to Fedora Bugzilla"
(abrt-server code) and "Firefox crash with non-free plugin should
display a message box asking user to disable the plugin" (GUI code and
different CLI code) by hardcoded functions (or by plugins to abrt-server
and abrt-gui and abrt-cli if we will have the manpower to do this). It
is the most effective system because the requests like this does not
have to fit in to some configuration table or neat, polished design, nor
solve the GUI provided by a plugin and things like this. The GUI stuff
for plugins is implemented in GUI, and the GUI would not show it when
the plugin is not available. CLI the same way. Plugins are just
command-line applications.