-
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.