-
Bug
-
Resolution: Not a Bug
-
Normal
-
None
-
4.19
-
Quality / Stability / Reliability
-
False
-
-
3
-
Critical
-
None
-
None
-
None
-
Rejected
-
Metal Platform 277, Metal Platform 278
-
2
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
Installing a BareMetal IPI cluster using provisioningNetwork set to `Managed`, gets the cluster installed successfully and a route is created via the provisioning IP on the pod scheduling the metal3 pod. ~~~ Working state; Route created - 192.168.xx.0/20 dev --readacted-- proto kernel scope link src 192.168.xx.10 metal3-static-ip-set container - initContainers: - resources: .. name: metal3-static-ip-set command: - /set-static-ip env: - name: PROVISIONING_IP value: 192.168.xx.10/20 - name: PROVISIONING_INTERFACE ~~~ But, after switching from provisioningNetwork `Managed` to `Unmanaged`, there is no route created via the provisioning IP. Also the metal3-static-ip-set yaml has incorrect subnet set for provisioning network. The expected on is /20, but it gets /32. ~~~ No route created with unmanaged ProvisioningNetwork : .. spec: .. provisioningIP: 192.168.xx.10 provisioningNetwork: Unmanaged provisioningNetworkCIDR: 192.168.xx.0/20 .. initContainers: - resources: .. name: metal3-static-ip-set command: - /set-static-ip env: - name: PROVISIONING_IP value: 192.168.xx.10 - name: PROVISIONING_INTERFACE .. ~~~
Version-Release number of selected component (if applicable):
How reproducible:
Install a BareMetal IPI cluster with ProvisioningNetwork set to Managed. Change the provisioningNetwork to unmanaged as a day 2 activity.
Steps to Reproduce:
1. Install a BareMetal IPI cluster with ProvisioningNetwork set to Managed. 2. Change the provisioningNetwork to unmanaged 3. Check the routes in node scheduling metal3 pod.
Actual results:
A route through provisioning IP does not get created
Expected results:
A route should still get created after switching the provisioningNetwork to unmanaged
Additional info:
- Created a slack thread in the forum-ocp-metal-platform https://redhat-internal.slack.com/archives/CFP6ST0A3/p1757830363760039 - The customer is in a secured environment, hence cannot share logs.