[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

new kickstart work



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]