search

operator-framework / ansible-operator-plugins

Experimental extraction/refactoring of the Operator SDK's ansible operator plugin
Apache License 2.0
9 stars 20 forks source link

Add ansible watch config to run for every update type #30

Open jutley opened 1 year ago

jutley commented 1 year ago

Feature Request

Describe the problem you need a feature to resolve.

I would like to run my playbook in response to all changes of the parent resource, including labels. In my situation, it is important that labels on the parent resource get propagated to its children. However, this isn't currently possible. In the current implementation, reconciliation only happens when the resource generation or annotations (optionally) change. There is no way to trigger reconciliation based on any other changes, such as the labels or (very generically) the resourceVersion.

Describe the solution you'd like.

I would like a new configuration to be available similar to watchAnnotationsChanges but for other change types. I can see that this is implemented using AnnotationChangedPredicate, and there does seem to be a LabelChangedPredicate and ResourceVersionChangedPredicate.

The more types of changes the user enables, the more careful they will need to be about creating reconciliation loops. This is especially true if reconciliation happened with every resourceVersion change. Despite this, I think it is valuable to offer these features and warn the users rather than make it impossible.

jberkhahn commented 1 year ago

This sounds like a reasonable change, would you be able to submit a PR implementing it? It seems like you would just have to add an if statement right next to the Annotations one in your first link that sets the LabelChangedPredicate, and add an Option that controls whether it fires or not.

Think you could do that? Otherwise it might be a while until we can prioritize someone on our end to implement this.

jutley commented 1 year ago

We have started to look at Kopf as the platform for implementing our controllers, but we are not fully decided. If we decide to stick with using the ansible-operator, then I can implement this PR. I agree that it shouldn't be hard at all. If we move forward with Kopf then I don't expect to get around to this issue since my org won't get any benefit from the patch.

But keeping the issue around may save the next person some effort in discovering and implementing the fix!

gaelgatelement commented 5 months ago

I proposed this feature in the following PR : https://github.com/operator-framework/ansible-operator-plugins/pull/65