Reconciliation on owned resources changes

[evhen14]

Hi maintainers,

Is there a plan to support notifications for changes in owned resources? For example, is it possible to implement a CronJob controller similar to the example in KubeBuilder? If yes, then what mechanism should be used?

Best regards

[buehler]

Hey @evhen14

What do you mean by changes in owned resources?
To see if the resource changed? KubeOps did support this, but the effort to keep up with Kubernetes' changes was too high. Also, they purpose to use desired state as the pattern to go. Meaning, every reconcile loop, you may check your resources if they are what they should be (desired manifest), and change them if needed.

[evhen14]

Thanks for your fast reply.

Let's assume I want to write CronJob controller. In this case, the cronJob owns the job(s) it created. So, I want the reconcile method for the CronJob to be triggered whenever there is any change to the jobs is "owns".

In golang controller-runtime they have "Owns" method on a manager. You can see more details here: https://book.kubebuilder.io/reference/watching-resources/operator-managed.html

[jackmtpt]

Is there any update on this? The Owns() behaviour is exactly what I need for my operator.

I have two CRDs, A and B. The controller for A uses the properties on an instance of that resource to create a set of B resources, and I need the A controller's reconciliation loop to be triggered whenever an instance of B owned by that A changes state.

[buehler]

As far as I know, this is not possible with the standard API. You have a watcher for resource A, therefore, each change in an A resource will trigger a reconciliation loop. As long as you do not have a watcher (and a controller) for B, there will be no reconciliation.

However, if I understand you correctly, you could have an operator with controllers for A and B (which is possible). And then, when an A is created, you make your B resources. And each change in B will trigger a reconciliation in the same operator.

[jackmtpt]

I do indeed have a controller for B. Suppose that an instance of B is deleted - is the idea then that the B controller would have to look at the properties on the deleted resource, find which A owned it, and then trigger the same logic that the A controller had initially used to create it?

If so, is the proper way to do that:

• BController DeletedAsync() examines the labels on the deleted B to find the owned-by label that the A controller adds to the B when it's created, and fetches the A resource from the API Server.
• DeletedAsync() then calls into AController ReconcileAsync() with the retrieved instance of A
• AController can then create a new B to replace the deleted one.

That feels like it's open to a race condition if e.g. the A is simultaneously modified - AController ReconcileAsync() would then get called automatically and it might decide that it needs to create a new B as well. I suppose it would then be sufficient to just put a lock around all of the ReconcileAsync logic to fix that?

[buehler]

Hey @jackmtpt
When you use "owned by" references in resources, they should be deleted when the owner is removed (by the Kubernetes API). So, they should not be deleted on their own (other than user error).

Nonetheless, you are correct. The controller for A will trigger a reconcile at some point (for example after the re-execution of the watch timeout), or at a defined interval (via re-queue logic). Then, the reconciliation for A takes place and discovers that some B are missing. It then must take actions to have the desired state by creating B's according to the manifest.