Anaconda accessibility improvements

ALVA braille terminal, CC-BY-SA via Wikipedia.

Good news: We have started working on accessibility of Anaconda! For start, the braille terminals now somewhat work in text mode.

Current state

On the Workstation images, accessibility already was at the same level as a finished system would offer. Workstation media run a full Gnome session, with Orca available. The installer does not have to do anything. However, for the Server images the situation is different. The environment is heavily reduced: no sound, no Gnome, no Orca. That also means, no accessibility. Let’s change that!

Advertisement

Anaconda debugging and testing – part 1.

Anaconda is quite a complex project with a variety of dependencies on system tools and libraries. Additionally, there are installation mods (graphical, text and non-interactive) and these can be controlled manually, partially (default configuration preset) or fully automatic. Users can also run the Anaconda application locally too to create installation media.
Thanks to this complexity it is not an easy task to just do the required changes and run Anaconda to test it. To test Anaconda properly it is required to run it many times with all the modifications. In addition Anaconda is supported on a variety of platforms and it behaves differently on each. To have a really good feeling that everything is tested then the test should have been done on all the supported platforms, including IBM Z systems and Power PC. And yes, not even developers are able to handle that. For most of the common changes, luckily a simple x64 Virtual Machine is a good enough solution.

To cover these issues, we (Anaconda developers) are investing quite a lot of our time to make this situation better. For example we are working on the Anaconda modularization effort. Thanks to this effort, developers can connect to modules and play with them. Also thanks to modularization, we have much greater test coverage than before. We have automatic installation tests called kickstart tests. Aside from that, we have unit tests, and we test if RPM files were created successfully.

In this article I want to create a short tutorial about tools which should help with debugging and development of Anaconda. I will describe useful methods to get your changes into the installation environment and how to test them easily with all your required use cases. Because this topic is quite big I will split it into a few articles.

Anaconda: A Look Back at 10 Fedora Releases with New UI

Fedora 28 is on the horizon. This will mark the 10-release anniversary of anaconda’s new UI.

Back in November 2012, when I joined Red Hat, the team was knee-deep in the midst of Fedora 18 Beta, as well as RHEL-7.0. It was a mad scramble, because this was it — Fedora 18 and RHEL-7.0 were the releases where the new UI for anaconda would debut, and that bugzilla treadmill was on fire from the speed with which users and QE reported bugs.
“Things are a little crazy right now,” said everyone on the team as they welcomed me.
“Oh,” I said. “Well as long as it’s only a little.”

It was very overwhelming, but while puttering away as fast as I could get up to speed, I also observed the team triage a huge amount of those bugs and fix a good percentage of them. To set some context here, the team managed to fix a ton of those bugs and continue implementing features, while also working on RHEL-7.0, RHEL-6.4, RHEL-5.9, and of course Rawhide.

What is the next step in Anaconda modularization?

As the modularization of Anaconda is under heavy development, you might want to know what is the status of this project.

The goal for Fedora 28 is to remove the kickstart data object from the UI. This can be easily done command by command, until the kickstart data object is completely useless and can be removed. Each kickstart command will be moved to a DBus module. A module will parse and generate one or more kickstart commands and provide an API for accessing and changing the command’s options and values. This API will be used by the UI to access the kickstart data.

Right now, we are ready to begin using the Timezone module and we’ve already begun working on the Network and User modules. We have significant extended the support for working with DBus in Anaconda via the pydbus package. We are also working on additional improvements for pykickstart, which are required for our use cases, such as adding extra attributes to kickstart errors and providing a minimal kickstart handler.

Once the kickstart data is handled by modules, we will begin removing the storage and package handling objects from the UI. This will require careful and significant work, since we will have to move around all of the logic for storage configuration and the packaging to modules. These are, by far, the most complex parts of our code base, so it is unlikely that the storage and package handling objects will be replaced with modules in Fedora 28. Once the storage and package handling modules have been completed, we should be able to move the remaining back-end logic from the UI to their own modules. The ultimate goal is for a UI-less installation, since it should be possible to install the OS without a UI at all.

Simpleline – new way how to write your Text UI

Simpleline is a text UI framework. Originally a part of the Anaconda installer project. It is designed to be used with line-based machines and tools (e.g. serial console) so that every new line it appended to the bottom of the screen. Printed lines are never rewritten!

Storage module

One of the biggest challenges of Anaconda modularization will be system storage configuration. Anaconda heavily depends on the Blivet’s storage object that is accessible from almost every class. For the modularization, we will keep the storage object in a storage module, so the module will need to provide the necessary functionality for other Anaconda modules. This is the first draft of the storage module and its submodules.