Repository navigation
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
belolipa
added
do-not-merge/work-in-progress
and removed
do-not-merge/work-in-progress
labels
|
/retest |
The OCP bootstrap pulls the release image from the dev-scripts local release/mirror registry on the hypervisor. dev-scripts (openstack-k8s-operators#1922, commit 08f6e3c) opens that registry port only on the firewalld 'public' zone, and dev-scripts openstack-k8s-operators#1975 opens it on the IPv4 'libvirt-to-host' policy. On single-stack IPv6 (NAT64) jobs the OCP nodes reach the host registry through the 'libvirt' zone instead, so neither of those covers them: the bootstrap gets "connection refused" reaching the registry, node-image-pull wedges at boot, bootkube never starts and the API VIP never floats, so the install times out with "no route to host" on the API endpoint. Open 5000/tcp on the libvirt zone alongside the temporary vBMC rule, before running devscripts. Gate it on cifmw_use_nat64 so only IPv6/NAT64 jobs are affected (the same flag nat64_appliance itself is gated on); every IPv4 job is untouched and remains covered by dev-scripts openstack-k8s-operators#1975. Unlike the vBMC port it is kept for the whole deploy, since the cluster pulls from the registry throughout. Verified live on an affected uni04delta-ipv6 hypervisor: opening the port let node-image-pull complete, bootkube/kubelet start, etcd + kube-apiserver come up and the API VIP float within minutes. Related: OSPCIX-1526, OSPCIX-1469 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Oleg Belolipetskii <obelolip@redhat.com>
39a57e7 to
078597f
Compare
|
Build succeeded (check pipeline). ✔️ openstack-k8s-operators-content-provider SUCCESS in 1h 51m 15s |
This branch has not been deployed
1 participant
The OCP bootstrap pulls the release image from the dev-scripts local release/mirror registry on the hypervisor. dev-scripts (#1922, commit 08f6e3c) opens that registry port only on the firewalld 'public' zone, and dev-scripts #1975 opens it on the IPv4 'libvirt-to-host' policy.
On single-stack IPv6 (NAT64) jobs the OCP nodes reach the host registry through the 'libvirt' zone instead, so neither of those covers them: the bootstrap gets "connection refused" reaching the registry, node-image-pull wedges at boot, bootkube never starts and the API VIP never floats, so the install times out with "no route to host" on the API endpoint.
Open 5000/tcp on the libvirt zone alongside the temporary vBMC rule, before running devscripts. Gate it on cifmw_use_nat64 so only IPv6/NAT64 jobs are affected (the same flag nat64_appliance itself is gated on); every IPv4 job is untouched and remains covered by dev-scripts #1975. Unlike the vBMC port it is kept for the whole deploy, since the cluster pulls from the registry throughout.
Verified live on an affected uni04delta-ipv6 hypervisor: opening the port let node-image-pull complete, bootkube/kubelet start, etcd + kube-apiserver come up and the API VIP float within minutes.
Related: OSPCIX-1526