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.