Rewriting Anaconda

a retrospective by David Cantrell

(presentation revision 0)


technical challenges faced during the rewrite

what we learned

unique challenges for an installer

history of Anaconda releases

how Anaconda is a successful open source project


Who am I

David Cantrell

manager of the installer team at Red Hat

BS in Computer Science from Georgia Tech

My History with Linux

Projects i've worked on

Slackware Linux • AfterStep • Python • Fedora
Red Hat Enterprise Linux • anaconda • procps • GNU parted
pyparted • ISC DHCP • NetworkManager  Common Desktop Environment

What Does an OS Installer Do?

Find itself

Find your storage devices

Use your storage devices in the manner you describe

Transfer the operating system to the storage devices

Prepare that operating system to boot on its own

Common Questions

How hard can an installer really be?

But can't you just use live images?

Or the cloud?

Anaconda Goals

Support the use cases of Fedora and RHEL

Look nice and fit well with the rest of the OS

Form positive first opinion of the release

Gain active contributors outside of the full time development team

Anaconda Statistics

First commit was in April 1999

More than 14 years of continual development

433 unique authors

39,253 lines of code

25,768 commits

64% of the code is Python

Highest LOC: Nov 2002 at 88,765

2nd Highest LOC: Feb 2012 at 80,562

Visual History of Anaconda

Red Hat Enterprise Linux 2.1

February 2002

Red Hat Linux 8.0

September 2002

Red Hat Linux 9.0

March 2003

Red Hat Enterprise Linux 3

October 2003

Red Hat Enterprise Linux 4

February 2005

Red Hat Enterprise Linux 5

March 2007

Red Hat Enterprise Linux 6

November 2010

Fedora 18

January 2013

Fedora 19 Beta

May 2013

Unique Development Limitations

Installer releases are tied to the OS release schedule

Bugs are "not allowed" can't patch the installer

Delays in our development affect the entire project

Starting the Discussion

FUDCon Tempe 2011

Brainstorming on what we could and could not do

Large decisions made, but bulk of work postponed

Large Decisions

We will continue using Python

We will use GTK+ 3.x for the graphical interface

We will continue using git and existing patch process

Back to Design

Return to design meetings later in 2011

Long meetings detailing the UX of each screen idea

Difficulty balancing advanced vs. new user ideas

Why is this part not in the open?

What's In The Rewrite

The goal was the UI, but that affects everything

New backend subsystems (except storage)

Existing GUI and TUI were removed

New GUI using GTK+ 3.x and new console-only TUI

Parallel execution of background tasks

Boot directly in to anaconda, no more loader

Iterative Design Process

Establish regular communication

Discussions should take place in one location

Summarize decisions and discussions

Explain the design decision


anaconda-devel mailing list

fedora devel mailing list

Basis Coding

Lower contributor barrier to entry

Indirectly marks some things as final

Helps guide your contributors

Keep Contributors Active

Your contributors are only as active as you keep them

Recognize contributions and contributors

Be careful with harsh feedback

Anaconda Rewrite Through Releases

F-16: backend rewrite

F-17: parallel development

F-18: new UI goes in to rawhide

F-19: revision and polish

F-next: ...


How did users react?

Did users and contributors listen?

Did contributors defend decisions?


Overestimate time required for everything

Communicate early and often

Software is hard, pie is good