Fedora FUDcon Tempe: Meet the Anaconda Team

Here’s my notes from the ‘Meet the Anaconda Team’ session at FUDcon Tempe today. Note that these are notes and not really polished (I apologize, I figured it’s better to post this sooner than wait for perfection lol.)
David Cantrell and Chris Lumens started the session by going around the room and introducing everyone on the team. They talked a bit about their storage testing framework (Chris did a separate session on this), and how Anaconda is pretty hard to get started with as a contributor, but the testing framework is an easy way to get involved – submit test. This can be even more helpful than submitting code patches and the test system is easy to contribute to. I didn’t catch how exactly / where to submit tests though; I didn’t catch Chris’ session on that.
David also pointed out the Anaconda features page on the wiki:
https://fedoraproject.org/wiki/Anaconda/Features
This page is how the team organizes their work. They are open to entertaining ideas for additional features to work on. You can see the UX redesign on the list – this is something I’ve been working on with Luya. 🙂
After pointing that out, various members of the team talked a bit about the stuff they’ve been working on lately:
Will Woods talked about how pygtk is going to go away in general. pygi is coming and with it gobject introspection, which makes API generation automagical. It’s almost exactly the same as using pygtk. If you just change the imports for a given piece of code, it may just work. But theres some knottiness so he is going through all of the UI code to figure out how this migration will work. We have custom widgets that won’t port cleanly, so maybe look at glue and UI code. Different implementation of bindings should use less memory in theory. There will be no pygtk for gtk3, no pygtk for python 3, so we need to do this anyway. For the most part, it’s trivial, except for the difficult pieces. Since we have the UI redesign going on too we’ll get some housekeeping done here and a new UI. When we build out new/different screens, we’ll need to use more glade, too. Procedurally-built UIs suck.
Martin Gracik talked about he is working to solve another problem with anaconda – tree compose (anything involving the tools that generate initial ramdisk and install image / install script)s today – called buildinstall is pretty hacky and involved the creation and maintenance of two manually-maintained static lists- one of packages needed and the list of dependencies (calculated manually – yuck!), then a static list of files that needed to be included in the buildroot. If anything moved (for example, rm moving from /bin/rm to /usr/bin/rm or something like that), the image created wouldn’t work. So Martin Gracik has been heading up lorax, a replacement for buildinstall.
Right now, lorax is a separate python project – which is a big improvement. When we need to change how install images are generated, we can do that independent of a given anaconda release. Lorax is a transparent change but a big step – Fedora 15 will likely be composed using it and it will save a lot of manual maintenance worl – Lorax will make tree composition nicer.
Radek Vykydal is working on network changes for future Fedora releases. Anaconda now uses NetworkManager to handle all of the networking during installation now. Before that, anacondaused libdhcp. We won’t talk about that. Before that it used punk, and we won’t talk about that either. NetworkManager has allowed us to not have to have our own network knowledge, but has introduced some complications. We get wireless support for free using NetworkManager… only for stage II. for stage I, if you don’t want to use NetworkManager’s UI, there’s only basic support. The initial loader – it asks where do you want to install fedora from, what network interface… we have to communicate with NetworkManager behind the scenes and produce our own interface to make that happen. We might move some steps from loader to stage II. A change this work has introduced that a lot of people don’t like – we no longer have the forced configure-your-network screen during installation. You do a network install, and anaconda used to ask you how do you want to set up your network devices. We do that now… nm-connection-editor… but we don’t do it by default. By default, if you used the network during installation, that’s enabled on the target system. So this causes an issue: if you install from optical media, when you boot the desktop it won’t connect to the network by default. This is a call made in favor of server installs where automatically connecting to a network isn’t always a smart thing to do. Radek added back the ability to configure the interfaces, but the default is to mirror the settings used during installation – if you’re using optical media, you’re not using network (unless you configure additional repos which is a way around the issue) so you’re not using network during installation and that is mirrored in the default system configuration. People on servers don’t want to enable all network interfaces on machine by default.
Dave Lehman did a lot of the storage rewrite work that was first available in Fedora 10. Now he is working on enabling install to a disk image file… you can use dd or create a raw file using qemu-image… can pass –image=path/to/that/file… run anaconda from command line and end up with installation sitting in your image file. Working on figuring out how to get that image to work for live cd compose. James Antill asked how is hardware detection / emulation handled, for KVM to be able to boot the imgae. It turns out that eEvery piece of hardware that Fedora supports is in the init.rd and will be detected at boot up. GRUB is on the beginning of the image file – point KVM at it and it should be off and running. Overall we want to make Anaconda as flexible as possible.
Brian Lane has taken over the Live CD pieces for Fedora. The current live cd support we have… is whipped together. His goal is to build on the storage rewrite and Dave’s image install stuff, to try to consolidate install paths to use anaconda to do live media image creation. right know live image installs uses live-image-create, a thin layer on top of pykickstart. It works and is implemented fine, but is sadly a different path so we end up with different installs with different bugs than we would get if anaconda was used. A single code path would be easier to maintain. If we use anaconda to do dvds and live cds and virt, installs will be more reliable / consistent and there will be less problems. The existing livecd install just dd’s the image it booted on, dd is added to target disk, uses resize to fs to grow filesystem. We may not be able to get around that cuz it’s fast and everybody wants fast. Packages makes things slower. Eric Sandeen investigated how this works and found we have two resizes happening: when we create the images to make the isos AND when we are putting it down on the final disk image.
Ales Kozumplik is working on having anaconda run in multiple threads, so anaconda’s UI won’t block anymore while performing various operations. (Yay!)
We finished the session with a group photo! Woo! And those are my notes. Hope they are helpful!