A tighter integration between admission-controller-framework and java-operator-sdk projects.

[morhidi]

Hi folks,

we are using the admission-controller-framework in the Flink Kubernetes Operator's Webhook component. We ended up writing our own custom logic to find related CRs, a.k.a secondary/primary resources in JOSDK, during validation. It would be great to see some of the great features already implemented in JOSDK, e.g. dynamic namespace change, etc added to the admission controller. I was wondering if there were any plans for a more tighter integration between the admission-controller-framework and java-operator-sdk projects?

Thanks,
Matyas

[csviri]

In the first round would rather just add support for this feature to the admission controller - managed informers for now that can also follow namespace configs. We can see if there is reason to share code, since the domain is quite different in general. Even if some use cases using admission controller with operators together might sound tempting to replicate some logic, however there is not something like secondary resources (again in general).

But let see how that evolves on long term. Might make sense to have a tighter integration eventually.

[metacosm]

Agreed, though to play the devil's advocate, I could foresee a validation hook needing to check secondary resources in some complex use cases but let's cross that bridge when we get there, if we get there.

[csviri]

Yes, that is the intention, just not sure if we want to introduce the same concepts/notions or domain language. So secondary resource make sense to an operator. For an admission controller this is much more open I think, so typically it also watches secondary resources if validates the custom resource, but also like watching config maps to customize validation, etc. Maybe would call it related resources?

Also there is no evening involved at all, just the cache is used, and the secondary indexes.