-
Bug
-
Resolution: Done-Errata
-
Major
-
4.10.0, 4.14.0
-
Quality / Stability / Reliability
-
False
-
-
None
-
Important
-
No
-
None
-
Rejected
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
It seems that we don't correctly update the network data secret version in the PreprovisioningImage, resulting in BMO assuming that the image is still stale, while the image-customization-controller assumes it's done. As a result, the host is stuck in inspecting.
How reproducible:
What I think I did is to add a network data secret to a host which already has a preprovisioningimage previously created. I need to check if I can repeat it.
Actual results:
Host in inspecting, BMO logs show
{"level":"info","ts":"2023-05-11T11:52:52.348Z","logger":"controllers.BareMetalHost","msg":"network data in pre-provisioning image is out of date","baremetalhost":"openshift-machine-api/oste
st-extraworker-0","provisioningState":"inspecting","latestVersion":"9055823","currentVersion":"9055820"}
Indeed, the image has the old version:
status:
architecture: x86_64
conditions:
- lastTransitionTime: "2023-05-11T11:27:51Z"
message: Generated image
observedGeneration: 1
reason: ImageSuccess
status: "True"
type: Ready
- lastTransitionTime: "2023-05-11T11:27:51Z"
message: ""
observedGeneration: 1
reason: ImageSuccess
status: "False"
type: Error
format: iso
imageUrl: http://metal3-image-customization-service.openshift-machine-api.svc.cluster.local/231b39d5-1b83-484c-9096-aa87c56a222a
networkData:
name: ostest-extraworker-0-network-config-secret
version: "9055820"
What I find puzzling is that we even have two versions of the secret. I only created it once.
- blocks
-
-
- Closed
-
- clones
-
-
- Closed
-
- is blocked by
-
-
- Closed
-
- is cloned by
-
-
- Closed
-
- links to
-
RHBA-2023:5321
OpenShift Container Platform 4.12.z bug fix update
