-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
4.19
-
None
-
Quality / Stability / Reliability
-
False
-
-
None
-
Low
-
No
-
None
-
None
-
None
-
None
-
In Progress
-
Release Note Not Required
-
None
-
None
-
None
-
None
-
None
Description of problem:
I've noticed that if you switch the templateVersion of a ProvisioningRequest such that it switches the label controlling policy binding, it's possible to end up in a scenario where the ProvisioningRequest is counted as fulfilled (and updated to be fulfilled at a new timestamp) even though the new policies are not applied on the cluster. This happens when the old policies are all compliant before switching the templateVersion so the ProvisioningRequest controller only checks that the old policies are compliant, not accounting for any updates
Since the ProvisioningRequest controller considers policy configuration complete when all the extant policies for a cluster are fulfilled, not necessarily the new policies, if the ProvisioningRequest reconcile happens before the policies are switched based on the new label, the provisioning phase will switch to fulfilled before turning pending again once the policies propagate
Slack thread (private telco-oran-testing channel)
Version-Release number of selected component (if applicable):
4.18 and 4.19 builds
How reproducible:
Semi-consistently. Depends on the timing of policies but usually shows up at least once a week in CI
Steps to Reproduce:
Covered by automation, this test case is usually the one affected
Actual results:
Compliant immediately after updating label on ClusterInstance but before policies have switched their placement basd on the label
Expected results:
Ideally the ProvisioningRequest does not report fulfilled until the policies that it should start tracking become compliant
Additional info:
