generated from kubernetes/kubernetes-template-project
-
Notifications
You must be signed in to change notification settings - Fork 468
Open
Labels
kind/bugCategorizes issue or PR as related to a bug.Categorizes issue or PR as related to a bug.lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.Denotes an issue or PR has remained open with no activity and has become stale.
Description
Environment
- Make target:
make build-node-ova-vsphere-rhel-8 - Run using container image? (Y/N): Yes
- Image Builder version: cluster-node-image-builder-amd64:v0.1.41
- Environment vars:
N/A (DNS not statically injected)
- Vars file:
N/A
What steps did you take and what happened?
$ make build-node-ova-vsphere-rhel-8
After provisioning a workload cluster with the built image, we observed that /etc/resolv.conf on the nodes contains two unexpected DNS nameserver entries that were not defined in:
- The bootstrap data
- The cloud-init config
- The image builder’s packer-node.json template
Example /etc/resolv.conf:
; Created by cloud-init automatically, do not edit.
Generated by NetworkManager
search foo.bar local
nameserver 10.x.x.1
nameserver 10.x.x.2
These nameservers are not intended to be in the final image. We suspect they might be inherited from the DHCP scope of the CI build environment, but they should not persist into the template that gets reused for provisioning clusters.
What did you expect to happen?
A Red Hat node image built by image-builder that does not include unintended DNS entries in /etc/resolv.conf.
Relevant log output
Log Output
<!--
If you have any relevant build logs that could help debug this issue please include them here
but MAKE SURE ANY SENSITIVE INFO IS REMOVED!
-->
Anything else you would like to add?
It would be helpful to know:
- If others have observed this behavior
- If there's a preferred method to ensure DHCP-provided nameservers don’t persist in the final image (e.g., clean-up hooks or known practices)
We're currently working around this by removing /etc/resolv.conf in a final Ansible step, but we'd prefer a cleaner solution integrated into the build pipeline.
/kind bug
Metadata
Metadata
Assignees
Labels
kind/bugCategorizes issue or PR as related to a bug.Categorizes issue or PR as related to a bug.lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.Denotes an issue or PR has remained open with no activity and has become stale.