Expose dependent configuration for the case where we have several dependents of the same type

@sebastienblanc

How do dependents work when we have more than one secondary resource (like having 3 deployments) ?

Thinking about this, I see two kinds of multiple dependents of same type:

fixed : the number of dependents is know at build time and a discriminating name should be enough. Dependents may be optional if the spec do not require it.
dynamic : the number of dependents is known at reconcile time and depends on the spec of the CR. This is often the case when a CR is a group. After having done such an operator, I do not think it is a good practice. The only pros is that it reduces the number of CRs. Having a lot of CRs and using PerResourcePolling with a low POLL_PERIOD could take down an external system.

Yes, I tend to think that we should limit ourselves to the fixed case as a start and see how it goes and if we need to make it more dynamic.

@csviri

@csviri can you please point out the documentation or example code to see how this is working? Thanks a lot in advance!

@csviri

@csviri can you please point out the documentation or example code to see how this is working? Thanks a lot in advance!

Note that this is on next branch, and the api is going to change probably a little.

@csviri

Thanks for the pointer @csviri , does it make sense to provide "default" discriminators based on something pretty standard like labels?

usually I think that would be based on rather some naming convention of the resource. So not sure. Might be if we seem some patterns.

@csviri

@csviri is this feature available now? If yes, could you please share some example code? (sorry, but example you've shared above is not very clear)

@bachmanity1

@bachmanity1 no, it will come with 4.1 (see milestone). It will be documented for that release too.

@bachmanity1

@bachmanity1 no, it will come with 4.1 (see milestone). It will be documented for that release too.

ok, got it. Thanks for quick reply.

Navigation Menu