docs/user/vsphere: Add static IP via Afterburn info #4121
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/assign jcpowermac |
|
Also installer team: We should think about a way to use this in IPI scenarios. Anything of this form will require something like extending install-config with "per node configuration" which also gets into openshift/machine-config-operator#1720 |
docs/user/vsphere/install_upi.md
Outdated
| ### Configuring RHCOS VMs with static IP addresses | ||
|
|
||
| As of OpenShift 4.6, you may use a new `guestinfo.afterburn.initrd.network-kargs` to configure static IP addressing. | ||
| The CoreOS "afterburn" component will lookup for the well-known key `guestinfo.afterburn.initrd.network-kargs` and use its value instead of the default. |
There was a problem hiding this comment.
So this only sets the first boot and what about after that??
Should we show a complete example here?
There was a problem hiding this comment.
Hmm you're right, we may need to document here how to also embed the static addressing in the Ignition config to persist for subsequent boots. I will get back to you on this.
There was a problem hiding this comment.
Hmm that is a good point what if I have to re-address my RHCOS virtual machine?
There was a problem hiding this comment.
Create a new machine, i.e. reprovision.
There was a problem hiding this comment.
This plugs into the same flow as the bare-metal one: kargs should get translated into NM configuration in the initramfs, and that is forwarded to the real rootfs.
There was a problem hiding this comment.
This plugs into the same flow as the bare-metal one: kargs should get translated into NM configuration in the initramfs, and that is forwarded to the real rootfs.
OK cool, that's what I hoped but I wasn't entirely sure if kargs injected by cmdline.d worked the same in that respect as actual kargs.
(Did you test that?)
|
The PR seems fine to me as far as documentation. My only concern is the confusion between our current terraform ip addressing and the addition of the extra config. Was static addressing a feature for 4.6? I only see this possible for 4.6 in UPI with documentation change but I doubt QE has tested it. I also think we should be updating the UPI terraform template to replace our current method of addressing (which is different than #3533). And is something we should already be testing in CI for 4.6?
Based that is a guest's extra config I would think MAO be a better location at least for compute. |
"per node configuration" is something I'm not on board at all for configuration using IPI, IMO that goes against what we want the experience to look like for self-managing autoscaling default experience for IPI clusters. If we can look at how to allow users to provider the installer will a range of IP addresses that the cluster can use to add static ip to one of the Machine created that is something I'm more inclined towards as next steps.
|
Completely agree. I am hoping this operator that metal uses might help with that but it is certainly not something that I have had a chance to investigate: |
Yeah...I think we may need to create a term like "external-installer-automated-provisioned-infrastructure" (extIPI? dunno) - basically people who are automating UPI installs (much like we are in CI for UPI). In some scenarios it's OK not to have autoscaling/machineAPI. You're probably right that extIPI wouldn't be provided by Anyways I think we're all agreed let's just target this for UPI. |
|
/test e2e-azure |
cgwalters
force-pushed
the
vsphere-upi-document-afterburn-static-ip
branch
from
086fc19 to
a2a6b8c
Compare
I didn't test this myself, but we should have landed the work for 4.6. This is much more ergonomic for users than appending to the Ignition configs, and also solves the core problem that we need networking set up in the initramfs to fetch the real config from the Machine Config Server.
cgwalters
force-pushed
the
vsphere-upi-document-afterburn-static-ip
branch
from
a2a6b8c to
2a388aa
Compare
|
OK I noticed there were two existing sections on static IP and hostname; I consolidated them and replaced with this. However, clearly this would be much more compelling if we updated the existing Terraform code for UPI vSphere with static IPs to use this...I don't speak TF well enough to do that myself. |
Yes, it was part of https://github.com/openshift/enhancements/blob/master/enhancements/rhcos/static-networking-enhancements.md
Agree.
Yes to both! I know we're somewhat late in the cycle now but this is a big ergonomic and implementation benefit for vSphere UPI. Would you have a few cycles to look at this? |
|
@cgwalters: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
| ] | ||
| }, | ||
| } | ||
| govc vm.power -on "${VM_NAME}" |
There was a problem hiding this comment.
govc is a community tool (offered by vsphere).
Who supports the use/distribution and maintenance of this tool?
There was a problem hiding this comment.
I think UPI installations may necessarily involve some tools not shipped by Red Hat. The goal here is more to outline suggested approaches, not to require any specific tooling. However we probably should have guidance on this. I don't have expertise in vSphere enough to say, but I'm sure there are alternatives to using govc that we could discuss in a separate section.
|
/uncc |
|
I'm trying what's described here in #3533, but it's still not working. |
|
FYI this worked for me on OKD: Creates /etc/NetworkManager/system-connections/default_connection.nmconnection with Works fine, even though no dns-search/domain is set so short name resolution does not work. And interface=ens192 may be a good idea if using multiple interfaces. |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci-robot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I didn't test this myself, but we should have landed the work
for 4.6.