-
Notifications
You must be signed in to change notification settings - Fork 254
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] Send full ignition to hosts #455
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kirankt 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 |
Hi @kirankt. Thanks for your PR. I'm waiting for a metal3-io member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
…reates a config drive WIP
/hold I don't think this is the right place for this. baremetal-operator is not an OpenShift specific component, and this problem is an OpenShift problem. It should be solved at a layer outside of this and sorted out before config is given to the BMO. |
I chose this spot because its the nearest (and most convenient) point to creation of the config drive. The problem is that when the user-data secret assets are created in the installer, the (bootstrap node and) MCS haven't started yet. To be frank, I'm not 100% sure where this might be moved. I'm also not sure what the history is regarding the use of CAPBM v1alpha1 in BMO, but we might move this logic into CAPM3 v1alpha2 or newer. This might be a good place but it would mean that we'll some significant code refactor in the installer: |
It seems like the user data secret given to the BMO could just contain the full config if that's what we wanted? Anyway, let's discuss elsewhere and can come back here if there is a general baremetal-operator enhancement to propose. /close |
@russellb: 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. |
In OpenShift, I think the problem is the BareMetalHost gets created before the full ignition is available by the installer. It might be challenging to refactor that. I think this could be done in a generic way in the BMO that lets one represent user data as a URL instead of a secret reference. Although, I agree the ignition-specific code isn't really appropriate to Metal3. |
Today, the installer uses a stub ignition that simply points to the full rendered ignition hosted by the bootstrap. However, the full ignition may contain configuration to configure network interfaces with bonding, vlans, etc.
That means the full ignition would need to be sent to the masters instead of the stub, because the hosts may not have network connectivity until after ignition is run. This PR enables the baremetal platform to optionally send full ignition to masters.
Creating this PR to foster dialog to see if this is the correct approach or if there is a better way.
WIP
openshift/installer#3276
openshift-metal3/terraform-provider-ironic#38