Repository navigation
Conversation
|
Skipping CI for Draft Pull Request. |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 40m 31s |
11ad381 to
0f63525
Compare
|
Build succeeded (check pipeline). ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 24m 31s |
0f63525 to
1e26e8b
Compare
|
Build succeeded (check pipeline). ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 08m 15s |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 16m 30s |
358be02 to
8855f0e
Compare
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? |
srac0
changed the title
In adoption HCI scenarios where Ceph MON IPs are assigned to compute nodes, these IPs are not persisted in NetworkManager profiles. After a compute node reboot, the IPs must be manually re-applied to the storage VLAN interface to restore Ceph connectivity. This change adds an optional feature to automate that step. Signed-off-by: Samuel Rac <srac@redhat.com>
8855f0e to
7f6b00e
Compare
A leftover ceph controller manager can become active after adoption and report no capacity. Detect that exact daemon and fail it so a another standby controller takes over. Signed-off-by: Samuel Rac <srac@redhat.com>
7f6b00e to
1ef09af
Compare
|
[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 |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 5h 15m 50s |
|
recheck |
|
/retest-required |
|
Build failed (check pipeline). Post ❌ openstack-k8s-operators-content-provider FAILURE in 5m 42s |
|
recheck |
|
Build succeeded (check pipeline). ✔️ openstack-k8s-operators-content-provider SUCCESS in 16h 38m 09s |
| - name: Re-apply Ceph MON IPs after compute reboot | ||
| when: cifmw_update_reapply_ceph_mon_ips | default(false) | ||
| block: | ||
| - name: Extract Ceph storage-net IPs from os-net-config |
There was a problem hiding this comment.
I'm wondering if there's a special reason why we use shell + ssh to grep the ip address instead of a delegate_to and loop through the target nodes that are supposed to be part of the ceph cluster.
@ciecierski Maybe you're using an inventory that has localhost only?
There was a problem hiding this comment.
We have an inventory, but the update role does not have a mapping from each compute to its migrated MON IP. That address is recorded in the compute’s updated /etc/os-net-config/config.yaml, which is why the task reads the file on the target host.
| ssh -i {{ cifmw_update_ansible_ssh_private_key_file }} | ||
| -o BatchMode=yes -o ConnectTimeout=10 -o StrictHostKeyChecking=no | ||
| {{ cifmw_update_hypervisor_short_name }} | ||
| "sudo ip addr add {{ item }} dev vlan{{ cifmw_update_ceph_storage_vlan_id }}" |
There was a problem hiding this comment.
wondering if this config should be persisted in os-net-config [1] and use it instead of ip a a but I definitely miss context here.
There was a problem hiding this comment.
I tried applying config.yaml with os-net-config on an adopted compute. The call failed because it selected nmstate, while NetworkManager marks br-ex as strictly unmanaged. During Ceph MON migration (in data-plane-adoption), manual_migration is set to true so it uses ip addr add instead of os-net-config. For this rolling CI reboot, I propose restoring only the MON address with ip addr add. Persistent profile configuration can be addressed in the adoption networking flow.
|
Build succeeded (check pipeline). ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 19m 58s |
f97e1ea to
1ef09af
Compare
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 41m 25s |
|
recheck |
|
Build succeeded (check pipeline). ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 33m 11s |
This branch has not been deployed
3 participants
No description provided.