Skip to content

Design

Jump to bottom Edit New page
Michal Toman edited this page Jun 29, 2013 · 11 revisions

FAF 0 (Original design)

You can see the original design document here: https://github.com/abrt/abrt/blob/master/doc/project/abrt.pdf?raw=true. There are several problems with the original design:

  • New problem types are appearing, they can not be easily added. All the problems are processed by the same logic at the moment.
  • Even non-linux operating systems need to be somehow handled (see OS plugins below).
  • The whole service is more or less a monolithic app (even though in theory it should not be, the implementation is). The deployment and maintenance is not an easy job at all.
  • Although the design is OS-independent, the implementation is based on Fedora workflows. Adding support for another OS requires changes throughout the whole system.

FAF 1 (Pluginable architecture)

The new pluginable architecture comes hand-in-hand with the design of uReport2. The basic idea is that the core is just a "glue" operating the plugins, which contain the main logic.

The core

The core consists of 2 parts:

Storage

A storage combining a relational database and a filesystem storage has been designed. The database is an entry point holding all the relational data. An object in the database may have one or more LOB-s (Large OBjects) associated with itself. Rather than being saved into the database, these will be written as files into a directory on the filesystem, but still identified by the primary key of the "parent" database object. Although modern database engines also support saving large files into the database (as BLOB/CLOB), this brings two major problems: performance and the difficulty of accessing the file by other applications.

The pyfaf library

A python library providing basic operations (loading plugins, parsing command line arguments, uReport processing, ...) and providing an API for accessing the storage.

WebUI

Simplistic, with two basic ideas

  • Developer - get as many information about the problems as possible, distinguish important problems
  • Manager - graphs & stats

Plugins

Plugins are python classes with well defined API. There is no plan to add support for other programming languages. If you really want to use something custom, you can always do that and create minimalistic python bindings.

There are 5 types of plugins:

Action plugins

The whole machinery is controlled by a single executable faf. Action plugins may be implemented to extend its functionality, e.g.

  • downloading packages
  • downloading OS metadata
  • reporting bugs
  • ...

See https://github.com/abrt/faf/wiki/Action-Plugins for information about the API.

OS plugins

Each operating system has its specific properties to consider while debugging the problems. Each of these needs to be treated separately.

OS to consider:

  • Fedora
  • openSUSE
  • Ubuntu
  • Debian
  • Android
  • Windows*
  • Mac*
  • whatever you like

* Mostly by request from Java people, because they have the majority of their users running these systems. They can only be supported in a limited way (problem P happened on system S and that's it), unless a reciprocal interest shows up.

See https://github.com/abrt/faf/wiki/Operating-System-Plugins for information about the API.

Repository plugins

Every bug report is filed against a software that needed to be published to get to users (packaged in an operating system, tarballed on a website, provided via an online marketplace...). FAF needs to track these repositories to have an overview of released versions and to be able to associate each report to the exact version of software and its related dependencies.

Different types of repositories may be considered:

  • Yum
  • Apt
  • Open Build Service
  • Eclipse
  • Gnome Extensions
  • JBoss community repos
  • ...

See https://github.com/abrt/faf/wiki/Repository-Plugins for information about the API.

Problem plugins

Each problem type needs to be treated separately. There were attempts to handle all problems in the same way, because the majority of them looks similar (a backtrace & some metadata), but this resulted in a plenty of hacks within the code and actually more pain than gain.

Problem types to consider (these where I remember at least one person being interested in):

  • Binary crashes (especially C/C++)
  • Unhandled python exceptions
  • Kerneloops
  • X.org crashes
  • Unhandled Java Exceptions
  • JBoss problems
  • Eclipse plugin errors
  • SELinux AVC denials
  • Android app crashes
  • whatever you like

See https://github.com/abrt/faf/wiki/Problem-Plugins for information about the API.

Bug tracker plugins

Although it may seem that bug tracker should be a part of OS plugin, there are few problems with that approach:

  • An OS may not have its own bug tracker
  • More OS may share the same bug tracker
  • An upstream project may want to bypass the OS-specific bug tracker and report directly to its own
  • Another instance of faf may be considered a bug tracker as well

Bug trackers to consider:

  • Another faf instance
  • Bugzilla (GNOME, Red Hat, ...)
  • Launchpad
  • whatever you like

See https://github.com/abrt/faf/wiki/Bug-Tracker-Plugins for information about the API.

Add a custom footer
Add a custom sidebar
Clone this wiki locally