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
_______________________________________________
Kickstart-list mailing list
Kickstart-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list
