>Hah, anamon. Oh, that brings up memories. :) It's not fantastic but cobbler had it and the benefit over the logging command is that it was easy to add our own custom log files that we generate. > >> - We call out to specific webhooks in both %pre and %post, as part of >> our orchestration triggers/process > >Is this something we could do for you, or is it so very specific that >there'd be no point? I don't think there'd be much point. These are really just curl commands out to specific URLs that then trigger further actions in our orchestration. There could be something to specify URLs to call at certain stages, but it's nothing that's needed, since curl does the job just fine. >> In %post: >> - Adding custom yum repos that we want for the installation only > >This behavior changes all the time. On master at least, what should be >happening is that your repo is only used for installation unless you use >repo --install. So you should be able to use the repo command for this >(depending on what release you are targeting). I believe we do use the repo command. > >> - Continuing to send off logs to some out of band logging mechanism > >Are you able to use the logging command here? If not, is there >something we could add to it to make it more useful? We send off custom logs that are generated via things like our chef-solo run. If the logging command supported this, it'd be more useful. > >> 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 ) > >I don't know if this will help you, but at least in RHEL 7.2 and recent >Fedoras, ipmitool is present. Yeah, it's useful for 7.2, unfortunately we're still stuck on older OS releases for some of our builds ( all the way back to 5.10 ). > >We've taken steps across several releases (going back into RHEL6 at >least) to let you specify disks in other formats besides simply >/dev/sda. You can use /dev/disk/by-id/whatever, for instance. >Basically you can use anything that udev sets up. Has any of this been >useful in dealing with disk ordering problems? Not really. Our issue is that we have various different hardware configs and a generic kickstart, so there's no way to really say that the by-id is going to be the same across all those systems. We were using --onbiosdisk=80, but this failed because on certain hardware platforms, anaconda fails to discover the right edd info. One of the biggest issues we've had with disk ordering is when using Dell systems w/ their PERC HW controller - in certain setups, we have a few logical drives, and the rest of the drives are configured as JBOD (just bunch of disks). We get random results with this - the logical drive ends up being anything from /dev/sda to /dev/sdi. _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
