Description of problem: Beaker currently hardcodes many details like - repo url (differs between labs) - lab controller - Beaker Hub URL - machine hostname - recipe ID inside the ks.cfg used for system provision. This ks.cfg then exports these as environment variables on the installed system via profile.d. The problem is when a user needs to use a custom kickstart for installation, either via <kickstart> or ks= passed on kernel command line, this kickstart has no possible way of obtaining the recipe details. This means - non-optimal outside-lab repo url will be used, causing inter-lab traffic - custom /nopxe/ logic that tries every possible labcontroller - hardcoded Hub URL to the main production instance - DHCP hacks to get the hostname (it often is 'localhost') - no way to get recipe ID to ie. simulate a harness / report results The solution is fairly simple - use kernel command line: - pass inst.repo= (and inst.addrepo= for AppStream) instead of 'url' in ks.cfg - (RHEL-6 and older may need method= instead) - pass at least lab controller, recipe id and hostname as ie. beaker.labctl= / beaker.recipeid= / beaker.hostname= Down the road, this could even simplify current Beaker kickstarts, making them more static. On a related note, live systems booted via root=live:http://path/to/image.tgz have the same problem, but those can at least extract the necessary details from the Beaker-provided kickstart, although given the amount of kickstarts Beaker keeps around and their varied %post sections, this is not very reliable and the /proc/cmdline solution described above would be preferred. Version-Release number of selected component (if applicable): Beaker 27.4
Note that other reasonable ways of obtaining Beaker metadata are also perfectly acceptable. Ie. passing just beaker.labctl= and beaker.hostname= via kernel command line and fetching other details like recipe ID, hub URL, etc. via HTTP (curl), to not overload the kernel cmdline too much.
I would say that this part should be redesigned differently. Keeping the box completely during the installation and add Beaker related things later on after installation is done. We can mimic this on image-based provisioned boxes.
Note that there's a big difference between two use cases: UC1: I want Beaker to allocate me (any) machine and PXE-boot it with my specified distrotreeid (distro+arch+variant), but I need to hack the PXE boot process, such as by using my own kickstart to install the system, or by specifying other dracut-supported kernel cmdline options to boot a remote NFS / iSCSI / live / etc. image. UC2: I want Beaker to install a clean OS for me using its own kickstart. You cannot really satisfy UC1 by first installing an OS and stopping before doing any "Beaker related things". .. And this BZ is really about UC1. Beaker already has some tunables, like https://beaker-project.org/docs/user-guide/customizing-installation.html but they are mostly useful for customizing UC2. The good news is that UC1 has very limited interface (basically just kernel command line), so you (Beaker) really just need to do the minimum needed work and get out of the way. Ideally, you would detect if the machine has downloaded kernel+initrd (so no /nopxe/ would be needed), so the installation process wouldn't need any Beaker-specific code, but that's for another RFE. Despite me being within UC1 most of the time for the work I do, it's admittedly not a common use case. However supporting it would bring Beaker machines much closer to actual physically-accessible HW.