* 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? We use it for our baremetal installations as part of our orchestration process, which is run via Salt Stack. We use Cobbler to generate the kickstart files for us ( which uses the Cheetah templating engine ) and handle the PXE booting. We store the snippets and main KS ( which is really just including the relevant snippets ) in revision control. We build our systems on a dedicated provisioning network before we flip them over to a run network ( after the installation is finished ). * 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? Never knew %traceback existed. Because of our use of Cobbler, it comes prebuilt with some rather lengthy %post and %pre sections. We actually have two main classes of kickstarts - our RAID kickstart and our OS kickstart. In our OS kickstart, some of these things include: In %pre: - Sending logs off the system ( Cobbler accomplishes this via a python script called anamon ). This allows us for remote monitoring of the logs. - We call out to specific webhooks in both %pre and %post, as part of our orchestration triggers/process - We do a bunch of a disk detection. I have a recent thread on here about what we're trying to accomplish - but trying to find the first disk in the BIOS boot order is a *pain* In %packages: - We use -nobase occasionally. - We use -packagename sometimes, although it doesn't always work, because of requirements from other packages ( like back in RHEL5 when wireless-tools always got installed ) In %post: - Adding custom yum repos that we want for the installation only - We yum install Chef from a custom repo, along with a cookbook, and use that for most of the post configuration. There are issues we've encountered doing this. Some services don't like to be started in %post ( iptables, kdump ), so we just enable those services w/out starting them. - Configuring the run time network ( since we're on a provisioning network, we want the network to be configured for when the system reboots ) - Configuring any bonded interfaces - Continuing to send off logs to some out of band logging mechanism - Calling certain webhooks/triggers at the start and the end of %post In our RAID kickstart, we use it as a quick/dirty way of having an OS available to configure the hardware RAID on our different hardware classes. We do it this way because it's difficult to rescan the disks after you configure the RAID and making sure you get the right ordering. So instead, we kickstart, configure the RAID, reboot, and then go into the OS kickstart. In the RAID kickstart, we never go past %pre. But basically, we PXE boot into the KS, download the RAID utilities and the configuration for the specific hardware class from a remote host, configure the hardware RAID, then reboot. There are other steps but they deal mostly with our orchestration process. One of the hangups we've had is that there are no ipmi tools available ( or installable ) in this pseudo-OS environment, so we can't tell the host to PXE boot itself again ( in case the network isn't first in the boot order ). Because of this, we're looking to move away from this configuration and using a real OS ( like alpine, tinylinux or something along the lines of the project hanlon microkernel ) * 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? #1 - Better/consistent documentation about the lesser known features. #2 - Probably the thing that has caused the most headaches is the difficulty in using/starting utilities/services that require kernel modules, such as iptables or ipmi. That and disk detection/boot ordering has proven rather flaky. There's the --onbiosdisk option, but it doesn't always work. I'm not if making it more like a language would be helpful - that would probably depend on entirely how useful the language was. #3 - We probably don't need it because of our use of Cobbler/Cheetah, but perhaps some way of providing an attribute file to download on the kickstart command line, and then being able to use the key=values in that attribute file to templatize/fill in values in the kickstart file. On 3/2/16, 8:54 AM, "kickstart-list-bounces@xxxxxxxxxx on behalf of Chris Lumens" <kickstart-list-bounces@xxxxxxxxxx on behalf of clumens@xxxxxxxxxx> 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. > >- Chris > >_______________________________________________ >Kickstart-list mailing list >Kickstart-list@xxxxxxxxxx >https://www.redhat.com/mailman/listinfo/kickstart-list _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
