-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
4.12.z
-
Quality / Stability / Reliability
-
False
-
-
None
-
Moderate
-
No
-
None
-
None
-
None
-
None
-
?
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
When deploying shift on stack using provider network defined for the baremetal (ironic), the installer will fail with inability to reach external glance service for the ignition. Since both external and BareMetal networks are defined on the controllers the async routing/networking get created, where request will come on one interface (external) but will try to get out on another (baremetal network).
Version-Release number of selected component (if applicable):
OSP17.0.1 OCP4.12
How reproducible:
When provider network for ironic is used and OSP controllers are shared with ironic services
Steps to Reproduce:
1. deploy OSP with ironic enabled 2. define a provider network for baremetal provisioning 3. use the baremetal network as a provider network to create OCP on top of OSP
Actual results:
ignition fetch failed
Expected results:
success
Additional info:
I was not getting this issues in previous releases probably for one of the following reasons: - We used to support net-ansible ml2 plugin for BM (which I had configured) to manage my networking for the baremetal. In this case network was changed to something that was not already defined on the controllers after coreos image got deployed - the ignition file has been hosted in the past on the swift which might have not had the async routing issues Workaround: - relax the kernel routing policies on the controllers with: echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter (or to specific interface) - deploy dedicated ironic conductor/inspector nodes in OSP that are not on the same network as regular controllers - implement net-ansible or other viable ml2 neutron plugin for baremetal that allows for multitenancy on BM