moving kickstart forward

[Josef Bacik]

On 03/02/2016 11:54 AM, Chris Lumens wrote:
> Hey everyone, I've been maintaining pykickstart and kickstart support in
> anaconda in general for a very long time now, though I've not been very
> active on this list.
>
> I'm going to be looking at kickstart exclusively for the forseeable
> future.  Specifically, my focus is going to be on widening its adoption
> and making it more useful to everyone.  The first step in this process
> is information gathering.
>
> Here's what I would like to know from you guys:
>
> * How do you use kickstart right now?  What work flows do you have
> around it?  Do you generate kickstart files from some process?  Do you
> store them in version control?
>
> * What do you do in your kickstart files?  Do you have extensive %pre
> and %post sections?  If so, what kinds of things are you doing in them?
> Are you doing anything that would be generally useful that I should be
> doing for you?  Do you ever use %traceback?  Do you have unusual stuff
> going on in %packages?
>
> * What can I do to make your life easier?  What annoys you about
> kickstart right now?  What do you wish it did?  What do you wish it
> didn't do?  Would making it more like a language be helpful?  Would
> making it easier to define site-specific commands be helpful?
>
> I know this is all really vague stuff, but I am just starting out on
> this project.  I don't even really know where this is going to take me
> yet.
>
> I'd also like to emphasize that whatever I end up doing, I want to keep
> compatibility with kickstart as it exists today.  That's something I
> take seriously in pykickstart.
>

Ran this by our provisioning team inside Facebook and our main guy in 
charge of anaconda had a few things, I've quoted them here


"""
- Actually document %traceback like it's a real thing. While it was 
mentioned on a list long ago that it was intended mainly for debugging 
and not really mentioned anywhere else I think it's potentially quite 
useful for recording tracebacks and sending them to a logging/build server.

- Better high-level logging of the overall kickstart process somewhere, 
maybe to a separate log file (then we could tail/scribe_cat it).
Examples "starting pre, partitioning X,Y,Z, installing package X, 
packages finished, installing bootloader" Syslog is too verbose and 
you'd have to regex out the interesting bits. (this is exactly what 
cobbler's anamon does)

- Timing metrics would be handy, we fake this roughly in pre/post 
scripts. e.g. "took X to install Y package" or "took Y to install all 
packages"

Also as a data point for them, we use a ton of %pre scripts to setup 
hardware RAIDs for various vendors, e.g. HP, LSI/MegaRaid, or Fusion IO 
cards.

Ideally I'd like to make all of that somebody else's problem so we just 
say "give me X devices with Y config" without writing lots of copypasta 
bash, but I don't have any ideas how to make this better. They probably 
don't want to write a lot of vendor-specific tools.
"""

And then I'll add onto that with just one thing

- Better testing.

We recently transitioned off of centos6 to centos7's anaconda and it 
took us a good 6 months to get everything working again.  We're in the 
process of moving to the latest version of anaconda altogether.  A lot 
of those where anaconda specific issues, but some of them where problems 
with kickstart.  The most specific example I can think of was this

https://github.com/josefbacik/pykickstart/commit/0736fbc111a40b95fde59039829c7cdb50bcabde

We have ipv6 everywhere internally and probably half of our clusters are 
ipv6 only.  It's not hard to setup ipv6 only environments with VM's, it 
would be nice to see this stuff better tested between releases to make 
sure the basic functionality is working, it would save us lots of time 
running down regressions.

By and large the kickstart part of our provisioning has been probably 
the most stable part of our whole provisioning workflow.  Sure we have 
huge %pre and %post scripts but I don't think there's a lot you can add 
that would be generic.  I know there are storage management projects at 
Red Hat around making the different RAID vendors able to be configured 
through one tool, it would be nice to see that integrated whenever it 
becomes usable.  Thanks,

Josef