Bug 2112817 - BMAC reconcile loop never stops after changes
Summary: BMAC reconcile loop never stops after changes
Keywords:
Status: ON_QA
Alias: None
Product: Red Hat Advanced Cluster Management for Kubernetes
Classification: Red Hat
Component: Infrastructure Operator
Version: rhacm-2.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: rhacm-2.5
Assignee: Mat Kowalski
QA Contact: Chad Crum
URL:
Whiteboard:
Depends On: 2112321
Blocks: 2113981
TreeView+ depends on / blocked
 
Reported: 2022-08-01 08:28 UTC by Mat Kowalski
Modified: 2023-05-15 18:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2112321
Environment:
Last Closed:
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift assisted-service pull 4212 0 None open Bug 2112817: Stop reconcile loop after changing CR inside BMAC 2022-08-01 08:30:20 UTC
Github stolostron backlog issues 24744 0 None None None 2022-08-01 11:09:16 UTC
Red Hat Issue Tracker MGMTBUGSM-493 0 None None None 2022-08-01 08:42:57 UTC

Description Mat Kowalski 2022-08-01 08:28:31 UTC 
+++ This bug was initially created as a clone of Bug #2112321 +++

In multiple places inside BMAC we are changing state of the CR and mark the result as `dirty: true`. This is later handled by 2 following approaches

1) reconcileComplete{dirty: true}
2) reconcileComplete{dirty: true, stop: true}

Given that we should be stopping reconcile loop after every change made, in order to avoid errors like

```
Operation cannot be fulfilled on baremetalhosts.metal3.io [...]: the object has been modified; please apply your changes to the latest version and try again
```

we should only use `dirty: true` together with `stop: true`. Currently using (1) leads to some unexpected races when objects are modified (or not) multiple times in the same loop.
Note You need to log in before you can comment on or make changes to this bug.