On Thu, 2010-07-08 at 14:27 +0200, Karel Klic wrote:
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.
Can you describe what we want to offer to GUI and CLI users?
This needs to be described (written down),
so far it exists only in our heads.
I was under impression that we want *mostly automated* bug reporting.
Seems like you want more like *manual bug reporting* instead. For
example, it seems you want reporting to be completely customizable on
the user side. This is news to me.
So, what are our goal(s)?
Before we can meaningfully discuss the design, we need to discuss what
we want to achieve, which use cases.
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,
In general, I feel that writing things with "custom wizard
step in the GUI" _across dbus link_ is an exercise in self-inflicted
PITA. It is hard enough to write such things even without inter-process
communication, throw in that and you have major programmatic disaster
on your hands. Endless hard to debug bugs. A lot of frustrated users.
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.
What periodic refreshing? I don't understand.
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).
1. I don't understand what you mean by (=autoreport).
2. How exactly do you propose to move reporting and collectinfo to GUI?
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://").
That's what I was talking about: simple operations suddenly morph
into god-awful, complex things. In this case, you spawn entire process
in order to add a single flag to crash dump. Care to imagine how many
lines of code that would be, on both sides? fork, exec, error checks,
command line parsing... how many possibilities to have bugs? leaks?
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/.
What is abrtd autoreporter?
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.
Complexity, complexity, complexity. I don't like complexity.
Why do we have server-side configuration then, at all,
if we then talk to client side about every setting
and every option?
Let's just copy entire crash dump to user side, and let it deal with it
*locally*, not *across dbus and god know what else*. Bingo. No abrtd,
abrt-server, no IPC needed. It's all in ~/abrt/spool/CRASHDUMP dir.
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.
--
vda