-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] providers/vmware: add an experimental rd-net-kargs #379
Conversation
This adds initial/experimental support for bootstrapping the network in the initrd. It is meant to support weird cloud providers where DHCP is not available or not usable. This feature is currently reachable as a dedicated `exp rd-net-bootstrap` subcommand. The first provider where this logic is required is `ibmcloud-classic`.
In prior discussion we debated whether or not these networking parameters should be "apply once" or be applied every boot. I thought we'd leaned towards "apply once" - which argues for doing this more as part of Ignition, right? But, I guess nothing technically stops us from doing "configure once" stuff in afterburn too, it just blurs the architecture diagrams. |
fdcc7d1
to
fff7e63
Compare
Ok(HashMap::new()) | ||
} | ||
|
||
fn hostname(&self) -> Result<Option<String>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can implement this right? See openshift/machine-config-operator#1579
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've replied there. The TLDR is that we can but we shouldn't.
This is for platforms where either:
- network auto-configuration is performed via DHCP and a cloud-channel for the hostname
- network auto-configuration happens via some custom protocol, which includes the hostname
Other cases are owned already by 1) dracut kargs and 2) Ignition.
Closing this stale WIP in favor of #404. |
Temporarily based on #362 for quicker development.