Ansible Operator: Watch for a CRD to trigger reconcile loop for another CRD

86 views
Skip to first unread message

Martin

unread,
May 18, 2024, 4:37:26 AM5/18/24
to Operator Framework
Hi,
we have built an Ansible based operator with two CRDs, CRD A and CRD B and one watch onto each CRD that runs an Ansible role.

We would like to archieve the following: If there is a change in a CR instance of CRD A (ideally we would limit the watch to one attribute in CRD A), a reconcilation run for CRD B should be automatically triggered.

Unfortunately, we are kind of stuck:
- There seems to be a solution for the Go based operator, which we are not using: https://github.com/operator-framework/operator-sdk/issues/3848
- We have tried to use watchDependentResources (https://sdk.operatorframework.io/docs/building-operators/ansible/reference/dependent-watches/) and adding ownerReferences to one CR instance in the hope that this would cause a reconcilation of the owner CR (https://sdk.operatorframework.io/docs/building-operators/ansible/reference/retroactively-owned-resources/). Unfortunately, this does not work for us (no reconcilation triggered). However, we could get this to work if the resource with an owner reference to a CR is a vanilla K8s object (e.g., Pod).
- Right now, we are helping ourselves by modifying the CRs of CRD B in the Ansible role responsible for CRD A, which then triggers a reconcilation but feels very hacky/dirty.

Does anyone have a recommendation onto what would be an elegant solution for our problem?

Thanks,
Martin


John Mazzitelli

unread,
May 18, 2024, 10:47:05 AM5/18/24
to Operator Framework
> Right now, we are helping ourselves by modifying the CRs of CRD B in the Ansible role responsible for CRD A, which then triggers a reconcilation but feels very hacky/dirty.

I've done that before. With a combination of "watchAnnotationsChanges=true" in watches.yaml and my role adding an annotation to the CRs where I want to trigger the reconciliation, I got it to do what I needed (which is basically what you want). I don't see a problem with that. In fact, you could even put something in the annotation's value to indicate things like the reason for and/or the time of the change just for auditing purposes.
Reply all
Reply to author
Forward
0 new messages