Fundamentally right now, if you want to use Clevis+Tang, you need to represent the network state as kernel cmdline options; you can't encode the static IP in `/etc/sysconfig/network-scripts` because that only affects the real root filesystem. Or to state this more obviously: the IP information in `/etc` is encrypted by LUKS, but we need the IP information to access the key. We have added some basic support to inject a subset of network configuration into the initramfs, but for now I'd go with encoding into the kernel cmdline. Hmm...we have special afterburn guestinfo injection for static IP: see the docs bits in https://github.com/openshift/installer/pull/3533/files and https://coreos.github.io/afterburn/usage/initrd-network-cmdline/#vmware which...I'm not sure made it to the official docs yet. But it also only works on the initial boot by design right now. Perhaps we could make it an option to make it persist to the kernel cmdline.
Hey @jima - How are you configuring network right now? i.e. where and how do you specify the IP address when provisioning the machine?
We use upstream terraform script to deploy ocp for upi-on-vsphere . You can refer to [1] to get ifcfg configuration file [1]https://github.com/openshift/installer/blob/release-4.7/upi/vsphere/vm/ifcfg.tmpl
Got ya. Yeah I'm not sure of the best way forward for you right now but it may work to just specify extra kernel arguments into what you're already doing: ``` kernelArguments: - rd.neednet=1 - ip=10.10.10.10::10.10.10.1:255.255.255.0::ens192:none:8.8.8.8 ``` Where you can get populate the ip= string from something like this short bash script: ``` ip='10.10.10.10' gateway='10.10.10.1' netmask='255.255.255.0' hostname='' interface='ens192' nameserver='8.8.8.8' echo "ip=${ip}::${gateway}:${netmask}:${hostname}:${interface}:none:${nameserver}" ```
upstream issue to discuss this problem: https://bugzilla.redhat.com/show_bug.cgi?id=1975701
The upstream issue is actually https://github.com/coreos/fedora-coreos-tracker/issues/886.
Shoot - really messed up that copy/pasta - 🤪
Created https://github.com/openshift/openshift-docs/pull/37356 to add the known issue and workaround to the 4.9 release notes: https://github.com/openshift/openshift-docs/pull/37356. Changing to ON_QA. @jima - please review for QE. Thanks!
I have also created https://github.com/openshift/openshift-docs/pull/37362 to update the 4.8+ product docs and have tagged QE and SMEs for review.
Bob, thanks to update release notes and product docs, I added some comments in above PRs. Since doc PRs just highlight and provide the workaround to avoid the issue, but not fix the issue from code, it's better to use this bug to track the code fixing, so change back the status to NEW.
Thank you for the feedback, @jima - makes sense to me. I'll address your feedback in my PRs referenced above and leave this BZ status for the RHCOS coding professionals :).
It appears this has transitioned to a Docs issue, with Bob working on it. I've changed the subcomponent + assignee accordingly.
Looks like I was misguided; this is still and issue and maps to https://issues.redhat.com/browse/GRPA-4048
A Known Issue was added in the OCP 4.9 Release Notes: https://github.com/openshift/openshift-docs/pull/37558. It was determined however that a workaround should not be included in the RN because it requires a Support Exception. Therefore, I closed the workaround PR: https://github.com/openshift/openshift-docs/pull/37362
The RFE tracking implementation for this feature is https://issues.redhat.com/browse/RFE-1764 The Epic on the CoreOS board is https://issues.redhat.com/browse/COS-886 Upstream tracking issue is https://github.com/coreos/fedora-coreos-tracker/issues/886 Will close this one.