2. Architecture of Anaconda
Anaconda is a set of Python modules and scripts. It also uses several external packages and libraries, some of which were created specifically for the installer. Major components of this toolset include the following packages:
pykickstart - used to parse and validate Kickstart files and also to provide a data structure which stores values which drive the installation
yum - the package manager which handles installation of packages and resolving dependencies
blivet - originally split from the anaconda package as pyanaconda.storage; used to handle all activities related to storage management
pyanaconda - package containing the core of the user interface and modules for functionality unique to Anaconda, such as keyboard and timezone selection, network configuration, and user creation, as well as a number of utilities and system-oriented functions
python-meh - contains an exception handler which gathers and stores additional system information in case of a crash and passes this information to the
libreport library, which itself is a part of the
ABRT Project.
The life cycle of data during the installation process is straightforward. If a Kickstart file is provided, it is processed by the pykickstart module and imported into memory as a tree-like structure. If no Kickstart file is provided, an empty tree-like structure is created instead. If the installation is interactive (not all required Kickstart commands have been used), the structure is then updated with choices made by the user in the interactive interface.
Once all required choices are made, the installation process begins and values stored in the structure are used to determine parameters of the installation. The values are also written as a Kickstart file which is saved in the /root/ directory on the installed system; therefore the installation can be replicated automatically by reusing this automatically generated Kickstart file.
Elements of the tree-like structure are defined by the pykickstart package, but some of them can be overriden by modified versions from the pyanaconda.kickstart module. An important rule which governs this behavior is that there is no place to store configuration data, and the installation process is data-driven and relies on transactions as much as possible. This enforces the following features:
every feature of the installer must be supported in Kickstart
there is a single, obvious point in the installation process where changes are written to the target system; before this point, no lasting changes (e.g. formatting storage) are made
every change made manually in the user interface is reflected in the resulting Kickstart file and can be replicated
The fact that the installation is
data-driven means that installation and configuration logic lies within the methods of the items in the tree-like structure. Every item is set up (the
setup method) to modify the runtime environment of the installation if necessary, and then executed (the
execute method) to perform the changes on the target system. These methods are further described in
Section 6, “Writing an Anaconda add-on”.
