This week in Anaconda

This past weekend was FUDCon and for the first time since expanding to other offices, we had the entire crew in one place. That includes our remotees in Washington, Alabama, and Hawaii; people in other US offices, and the whole group from Brno (which is a very long flight). This was very nice as many of us had never met others before. In particular, I’d never met bcl, mgracik, or akozumpl before this weekend.

Saturday, we gave two anaconda-related presentations. The first was simply a session to meet the team and talk about what we’d done recently:

• I mentioned the storage test stuff (which is in mainline autoqa right now and will be running as soon as they rebuild).
• dlehman talked about his image install support that was mentioned here a couple weeks ago.
• mgracik talked about his lorax project, which completely replaces the way we build installation images. Along the way, someone also suggested lorax could replace livecd-creator or perhaps some of the appliance creator tools. This is pretty brilliant, given that all lorax does is create trimmed down images based on a config file. I’m excited to see some experimentation here.
• akozumpl talked about making the anaconda UI run in a separate thread, an idea he previously mailed out. So far there’s been no responses to his mail, but I think that’s all because we’ve been stunned into silence. Personally, I think there’s some good to come out of doing this (like having a more responsive UI) but threading is always a little scary.
• Speaking of UI, wwoods talked about moving from pygtk to pygi, adding more glade into anaconda, and so forth. Expect to see a whole lot more UI talk in the coming year - we’ve ignored this part of anaconda for far too long.
• rvykydal talked about all his recent networking changes.
• Speaking of livecd, bcl talked about his desire to merge livecd-creator and image install support.
• We did not get to pjones, msivak, or dcantrell. Sorry.

Mo posted a more thorough description of all this, complete with picture.

Sunday we skipped the lightning talks and beginning of the hackfest to have an anaconda feature planning throw down. The end result was that every feature on the feature page now has a target release, owner, and list of associated components. Well, okay, not every feature has a target release. Some we pushed off because they’re either too hard or not well enough understood yet. Overall, it’s a pretty ambitious list, touching almost every area of anaconda (though there’s almost nothing for storage which I suppose is a testament to the quality of the rewrite). I’ll be surprised if we get half these features done, but even if that’s all we do it will still be serious work.

As mentioned before, it looks like the UI is going to be the biggest piece of work in the next year or two. Will already has some interesting ideas for completely changing anaconda away from a wizard style, but I’ll let him expand on that when he’s ready. There’s also all the UI stuff that Mo has previously talked about and mocked up. For whatever reason, we tend to gravitate towards the backend projects and neglect the UI which means we end up looking very dated. I’m hoping we will take care of that this time around.

Other features that generated a lot of discussion were adding wireless support (do we need to make our own NM-aware UI? run a panel? what?), replacing our own custom init with systemd, obsoleting the loader, and replacing package selection with the spin selector.

Monday, we again had our own big anaconda hackfest which was very informal. The biggest thing to come out of that was a lot of discussion about wwoods’s proposed UI, as well as akozumpl’s ideas about replacing dispatch and threading the UI. I’m especially interested in the dispatch work. The dispatcher is a block of code that’s basically a very fancy layer around a basic list, controlling which steps anaconda will run. We spread step adding/skipping all over the place in anaconda so it’s very hard to follow. msivak had a great idea about treating the dispatcher as a queue where each step simply pushes in what to run later. This would mean you’re never really moving back and forth through anaconda, which would seriously clean up our code.

So as you can see, this was a very productive FUDCon for us. We didn’t write any code, but we got a huge number of ideas flowing. It looks to be yet another very busy year in anaconda. And you thought system installation was all figured out.