On Fri, 2011-01-07 at 15:29 +0100, Jiri Moskovcak wrote:
This is the list of feature to complete for ABRT 2.0, once this list is finish we'll done with 2.0. The list is probably not complete, so please add anything you think is missing. I'd also like to ask you to add some comments about how far the feature (you're working on is) and what it depends on, so I can then make it into nice roadmap...
= ABRT 2.0 Features (what we need) = ... /etc/abrt/conf.d/ directory (devels can drop there configuration for their packages) --> provide a way for maintainers to blacklist their packages without changes into abrt package
Let's perform a bit of brainstorming on this.
Fragment of current default /etc/abrt/abrt_event.conf:
# abrt-action-analyze-c needs package name, save package data first EVENT=post-create abrt-action-save-package-data EVENT=post-create analyzer=CCpp abrt-action-analyze-c EVENT=post-create analyzer=Python abrt-action-analyze-python EVENT=post-create analyzer=Kerneloops abrt-action-analyze-oops
A few ideas how to extend it to pick up config files from a subdir so that other packages can add/modify post-create event handling:
(1) [include] /etc/abrt/event.post-create.d/
(2) EVENT=post-create abrt-handle-crashdump -d "$DUMP_DIR" -e "$EVENT" -c /etc/abrt/event.post-create.d/
(3) EVENT=post-create for f in /etc/abrt/event.post-create.d/* do test -f "$f" || continue abrt-handle-crashdump -d "$DUMP_DIR" -e "$EVENT" -c "$f" || break done
Relative pros and cons: Proposal (1) - new directive "[include] DIR" or "include GLOB_PATTERN" - allows to statically determine whether a particular dump dir has any defined "post-create" event handler(s) - config file parser can walk included config files and find out whether there is a handler. For "post-create" event it's not that important, but for "report[_FOO]" events it is: client programs do this in order to determine which report events make sense for a particular dump dir. The importance of this depends on whether we envision packages to add their own configs with handling for *reporting* events (as opposed to "post-create" even and such). Do we?
Proposals (2) and (3) are similar: instead of making config parser more complex, they use the power of modularity which new event-based processing gave us. They both need abrt-handle-crashdump to be extended with -c CONF_FILE or -c CONF_FILE_OR_DIR option. Another useful extension is to allow action to be written in multi-line form, as shown in proposal (3). On the minus side, they might look ugly. Do they look ugly to you?
What else we might want/need? Consider the case when packages can add additional data-collecting steps, but they do not know *when* this data-collecting should happen - immediately after crash (post-create event) or at the point when user selects the crash for reporting ([re]analyze events)? Proposal (2) can handle this situation by "redirecting" one event to another, something like this:
EVENT=post-create abrt-handle-crashdump -d "$DUMP_DIR" -e collect-data -c /etc/abrt/event.collect-data.d/
, making it possible for admin to change when to do data-collecting by a single edit - changing EVENT=post-create to, say, EVENT=analyze.
Whereas proposal (1) can't do this, and needs even more syntax changes to make it possible.
That's all from me for now. Your thoughts on this? As a minimum, indicate which of proposals 1/2/3 looks best (or "least ugly") to you.
On 01/11/2011 04:54 PM, Denys Vlasenko wrote:
On Fri, 2011-01-07 at 15:29 +0100, Jiri Moskovcak wrote:
This is the list of feature to complete for ABRT 2.0, once this list is finish we'll done with 2.0. The list is probably not complete, so please add anything you think is missing. I'd also like to ask you to add some comments about how far the feature (you're working on is) and what it depends on, so I can then make it into nice roadmap...
= ABRT 2.0 Features (what we need) = ... /etc/abrt/conf.d/ directory (devels can drop there configuration for their packages) --> provide a way for maintainers to blacklist their packages without changes into abrt package
Let's perform a bit of brainstorming on this.
Fragment of current default /etc/abrt/abrt_event.conf:
# abrt-action-analyze-c needs package name, save package data first EVENT=post-create abrt-action-save-package-data EVENT=post-create analyzer=CCpp abrt-action-analyze-c EVENT=post-create analyzer=Python abrt-action-analyze-python EVENT=post-create analyzer=Kerneloops abrt-action-analyze-oops
A few ideas how to extend it to pick up config files from a subdir so that other packages can add/modify post-create event handling:
(1) [include] /etc/abrt/event.post-create.d/
- my idea was that we'd have a /etc/abrt/events.d/ containing files with the same syntax as abrt_event.conf, so maintainers can override any event they want - one problem with this is how we decide whether to add the specific event handler to the default one and where to use only the specific one
(2) EVENT=post-create abrt-handle-crashdump -d "$DUMP_DIR" -e "$EVENT" -c /etc/abrt/event.post-create.d/
(3) EVENT=post-create for f in /etc/abrt/event.post-create.d/* do test -f "$f" || continue abrt-handle-crashdump -d "$DUMP_DIR" -e "$EVENT" -c "$f" || break done
Relative pros and cons: Proposal (1) - new directive "[include] DIR" or "include GLOB_PATTERN" - allows to statically determine whether a particular dump dir has any defined "post-create" event handler(s) - config file parser can walk included config files and find out whether there is a handler.
- I prefer this solution with a minor change - I would hardcode the path into the config parser and wouldn't use the [include] directive (I don't think we would use a multiple directories or am I missing something?)
For "post-create" event it's not that important, but for "report[_FOO]" events it is: client programs do this in order to determine which report events make sense for a particular dump dir. The importance of this depends on whether we envision packages to add their own configs with handling for *reporting* events (as opposed to "post-create" even and such). Do we?
- yes, we do, as this was part of the RFE(but discussed in other thread) - real life use case: - maintainer of evolution prefers all evolution bugs to be reported and handled upstream - he claims that it doesn't have any downstream patches - he can negotiate reporting ABRT bug to upstream with upstream - right now he spends a lot of time by just going thru Fedora bugs and copying them to upstream bz
- if we enable
Proposals (2) and (3) are similar: instead of making config parser more complex, they use the power of modularity which new event-based processing gave us. They both need abrt-handle-crashdump to be extended with -c CONF_FILE or -c CONF_FILE_OR_DIR option. Another useful extension is to allow action to be written in multi-line form, as shown in proposal (3). On the minus side, they might look ugly. Do they look ugly to you?
What else we might want/need? Consider the case when packages can add additional data-collecting steps, but they do not know *when* this data-collecting should happen - immediately after crash (post-create event) or at the point when user selects the crash for reporting ([re]analyze events)? Proposal (2) can handle this situation by "redirecting" one event to another, something like this:
EVENT=post-create abrt-handle-crashdump -d "$DUMP_DIR" -e collect-data -c /etc/abrt/event.collect-data.d/
, making it possible for admin to change when to do data-collecting by a single edit - changing EVENT=post-create to, say, EVENT=analyze.
Whereas proposal (1) can't do this, and needs even more syntax changes to make it possible.
That's all from me for now. Your thoughts on this? As a minimum, indicate which of proposals 1/2/3 looks best (or "least ugly") to you.
- definitely not 3
Dne 11.1.2011 16:54, Denys Vlasenko napsal(a):
A few ideas how to extend it to pick up config files from a subdir so that other packages can add/modify post-create event handling:
(1) [include] /etc/abrt/event.post-create.d/
It's good to keep the possibility to statically analyze the config file(s) when we already use it. I don't see the disadvantage of this proposal (extending the parser and adding "magic" lines) as too much limiting.
What about merging all event.*.d/ directories into a single one? We can include only events of a particular type from all files:
[include] EVENT=post-create /etc/abrt/events.d/
More fine-grained configuration (redirection of one event to another event):
[include] EVENT=post-create SOURCE_EVENT=collect_data /etc/abrt/events.d/
(2) EVENT=post-create abrt-handle-crashdump -d "$DUMP_DIR" -e "$EVENT" -c /etc/abrt/event.post-create.d/
We probably need to statically determine whether a particular dump has any defined reporting events, as you write in the comment about proposal (1). Otherwise it looks nice.
(3) EVENT=post-create for f in /etc/abrt/event.post-create.d/* do test -f "$f" || continue abrt-handle-crashdump -d "$DUMP_DIR" -e "$EVENT" -c "$f" || break done
The possibility to write multi-line commands improves readability indeed.
Karel
crash-catcher@lists.fedorahosted.org
-
Denys Vlasenko -
Jiri Moskovcak -
Karel Klic