moving kickstart forward

[Chris Lumens]

> - We are using Jinja to generate the final kickstart from what amounts to
> kickstart snippets.

How did you decide on this template system?  If I wanted to add an
"official" template system that pykickstart runs the input file through,
should I use this one?  Would I make your job harder if I used a
different one?  Should I just stay away from this entirely and let
everyone do what they think is best?

> - in the pre, we're doing all kinds of stuff to automagically determine
> what drives are available, flexible partitioning, determining usb/removable
> drives, as well as setting up your basic installation sources.

I feel like we could take over a lot of this by providing tools for you
to use.  Can you give me more information on what you're doing here?

> - In the post, we do everything.  we tweak bashrc files, setup kiosk
> environments in gnome (which sucks by the way), tweak our environments
> based on project needs, set up security items (firewalls, selinux, pam,
> etc...)  Basically, everything you would normally do on a system after
> install, we do in the post.

A lot of this sounds like it's pretty site-specific.  However the
security stuff we should be able to handle.  What are you doing with
firewalls and selinux that we don't already have options to do?  There's
likely a lot here we don't have options for.  I'd just like to take over
some of this stuff if possible.

> - I would love to see the following available in the PRE:
> -- built in function to identify all removable USB type drives.  I
> currently put these into an array for use later
> -- built in function to identify all drives in available in the system.  I
> currently have a function for this.
> -- built in function to identify the PRIMARY boot drive, since sda is not
> always the first drive. (this is a common issue).  I have a function for
> this as well.
> -- built in command for excluding drives from install/format/clearpart.  I
> have a function to do this as well.  it's messy though at times.

I think we could definitely do this kind of stuff.  I imagine a
"built-in function" taking the form of a command line tool we provide,
though.  We might also be able to extend the current kickstart commands
to provide some of this.  What else would you like to see here?

> -- needs to be a bit easier to determine install source and deal with it
> accordingly.  Lots of issues have been had when trying to install from
> various sources, like usb cdroms, usb drives, cdrom, etc...  Would be nice
> if ks/anaconda just recognized where the source is an adjusted accordingly.

What kind of issues are you seeing?  Where would you like it to be
easier to determine the installation source?  In scripts?  When writing
the kickstart file to begin with?

> -- I've see other users overwrite their own install media.  Should be built
> in protection for this.

As long as you are using the kickstart commands, anaconda will refuse
to partition the device containing the installation source.  If you've
seen this happen, it's a bug in anaconda.  Of course, we can't really
stop you from doing anything in a script.

> -- we often have to go through annoying scripting to get the installation
> media to be properly available in the post.  Should be a built in feature.
> We do this because often in the post we are adding stuff that wasn't
> available.  Has never made much sense to me that the install media wasn't
> already just "available" in the post.

I don't know the status of this in anaconda, but you're right - it
should be available if it's not.  Do you also need a way of knowing what
kind of installation source (DVD, NFS, etc.) you are using, or do you
just care about where it's mounted?

> - making logging easier.  I see a lot of questions about how to log
> everything that's going on.  I know how to do this, but it seems that
> logging everything should be a standard ks/anaconda directive somewhere.

anaconda does an awful lot of logging already.  I tend to think we do
too much - we err on the side of logging just about everything which
makes what's there harder to understand.  What could we do to make
logging easier?

> - Partitioning is sometimes troublesome with errors being very cryptic as
> to why or what ran out of space.  i.e. is it the logvol, pv, or vg that
> wasn't defined with enough space?

The blame for this can be shared among anaconda, pykickstart, and
blivet.  We should probably sit down and review all our error messages
and try to make sense of them.  Also with so many layers, it can be hard
to provide really useful and accurate error messages that aren't also
cryptic.

> - would be nice if when you use options in the partitioning sections that
> if they are incompatible with each other, the dev was informed of the exact
> error.

Sadly, only some of this can be done in pykickstart ahead of time so it
can be caught by ksvalidator before you try to do an installation.  The
rest gets done by anaconda at install-time.  We should definitely go
through and take a look at this, though.  Do you have some examples of
where we're providing some pretty crappy error messages?

> - Some errors that state that there's an issue at line no: xyz are not
> exactly right.  If a dev doesn't know that he has to look at each
> ks-xyz.log file and that the line number is referencing that particular
> %post ks part, the line number is misleading.  In other words, more detail
> in error reporting.

This could definitely use a re-think, you're right.  A lot of the
confusion probably comes from (1) each script getting its own log file
with a funny temporary name, and (2) line numbers of the kickstart file
vs. line numbers of each script.  I'll see if I can't make better sense
of this.

> -  would be nice if there was a better ks GUI tool than
> system-config-kickstart, but I don't know how many would use it.

Yeah, that's on my todo list.  This is my fault, too - I've just let it
rot while I focused on newui in anaconda and then afterwards I've not
been very excited to dive back into UI stuff in another program.  But it
desperately needs work.

> I like KS a lot, but there are always just some cryptic stuff to deal with.
> 
> Thanks for whatever you might do with this!

Sure, there's always something that could be improved.

- Chris