As anyone who's been following Rawhide knows, kickstart has been
undergoing a whole lot of work recently. This work has been a complete
rewrite of the kickstart file parser and data representation in anaconda
due to a couple realizations:
(1) anaconda and s-c-kickstart use completely different code bases. The
biggest problem here is that s-c-kickstart is falling farther and
farther out of sync with anaconda as to what is supported and what's
not.
(2) There are some long-standing bugs in kickstart that cannot be fixed
because the current code is sort of tough to work with. One example
of this is post scripts in include files all get executed in the
chroot environment, regardless of what you want.
(3) We don't have any validation tools right now besides writing a
kickstart file and cramming it through anaconda to see if it works
or not.
(4) Even within anaconda, there are multiple kickstart file parsers.
(5) s-c-kickstart doesn't understand all the options that kickstart
supports so if you take an existing file and run it through the
program, what you get out will have lots of data stripped (if
it even reads in the file at all).
Okay, enough rationale. My main idea was to create a single new
codebase that handles all the reading and writing of kickstart files and
to make that code generic enough to where it's not a pain to adapt it to
your uses. Therefore, I present the new pykickstart package in Rawhide.
It's been in the works within anaconda for a couple weeks now but I have
finally broken it out into its own package so you can use it for your
own purposes.
As always, the documentation is a bit light at the moment but that will
be coming soon. The code is pretty well commented so it should be
reasonably easy to follow, but here's an outline of the core:
- KickstartData is a class containing a variety of attributes that
represents the kickstart file. Wherever possible, things are
represented in some real type instead of just a string. There are
a variety of other Kickstart*Data classes found in data.py. These
are meant to be put in the lists in KickstartData.
- KickstartParser is the central class. It is essentially a state
machine that transitions on seeing the various sections of the
kickstart file. Functions are run upon state transitions, and these
functions may be overridden in a subclass of KickstartParser if you
need specialized behavior. The core function of readKickstart should
be generic enough to never need overriding, unless you are doing
something really crazy. If it's not flexible enough, this is probably
a bug on my part.
- KickstartHandlers deal with all the commands found in the command
section of your kickstart file. Each command has its own handling
function that deals with the legal options for the command and sets
values in KickstartData appropriately. Again, you may subclass
KickstartHandlers to do whatever you would like. If you want to
make your own subclass handlers, it is a good idea to call the
superclass handler first to set KickstartData. Then, do whatever
you would like.
- We are using all sorts of features from OptionParser, which I am
not going to go into here. However, one of the nice features is
the ability to mark options as deprecated.
- KickstartWriter takes a KickstartData object and spits out a file.
It similarly has handlers for each command, though I haven't done
nearly as much with it as I have with the front end.
So real quick: how would you go about using all this stuff? I'm glad
you asked.
from pykickstart.parser import *
from pykickstart.data import *
ksdata = KickstartData()
kshandlers = KickstartHandlers(ksdata)
ksparser = KickstartParser(ksdata, kshandlers)
ksparser.readKickstart("ks.cfg")
There you have it. You've now got ksdata populated and ready for use.
Oh, you might also want to handle the various exceptions that can be
thrown.
How would you go about extending pykickstart for your own purposes? I'm
going to save that for another long email. Or, you can look at
kickstart.py in anaconda and see what's going on. It's really not too
difficult. I think this is going to result in being able to make a lot
of new stuff around kickstart pretty easily. My first goal is getting
s-c-kickstart fixed up to use pykickstart (ugh, this is lots of work).
My second goal is making a ksvalidator. That should be really simple.
Oh, and a warning. This is all still in a lot of flux and before FC5, I
might totally rewrite parts of the API. Nothing is stable yet and
shouldn't be taken as such. Feel free to experiment with it, but
understand I might get a crazy idea and redo something.
So, thoughts?
- Chris
