Hi @Javatar81 , not sure if I'm following every aspect of this, but are you suggesting that the controller would update the ClusterServiceVersion related to itself? So would update the ClusterServiceVersion.spec.customresourcedefinitions.required ?

Hi @csviri no I am not suggesting this since the CSV is static and it would not make sense to update it at runtime. I just propose to omit the CRD from the ClusterServiceVersion.spec.customresourcedefinitions.required array if it is defined as an optional dependency.

I think this makes sense, yes and covers rather common use cases.

Ok so was confused about OLM part, since it's not related to the core. But otherwise this makes completely sense.

just a note: for standalone workflows this won't work / not sure if we want to actually support it there explicitly.

Ok so was confused about OLM part, since it's not related to the core. But otherwise this makes completely sense.

👍🏼

just a note: for standalone workflows this won't work / not sure if we want to actually support it there explicitly.

Why not? Could you elaborate why?

Why not? Could you elaborate why?

So there is now no layer where that is processed properly, where this would create the activation condition. But will take a look maybe could be added elegantly also there.

Just a note: since checking if the CRD is present, ideally there is an informer for CRD-s registered. This could be done seamlessly in the background if there is at least one dependent with optional=true. But also could be just checked directly if the informer is not desired (like no right to watch? ). For this we would need a feature flag similar to this:
#1898

This would look like:

@ControllerConfiguration(
    workflow = @Workflow( 
          registerCRDInformerEventSource = false,
          dependents = {
              @Dependent(...),
              @Dependent(...)}
    )

(by default would be true)

If there is no Informer for CRD, would be good to have an option to configure the refresh interval.

Regarding a the refresh we might want to provide some sensible default but a customizable solution, similar to retries.
To be honest the usefulness dynamic part of the activation condition will be (in my experience) limited to for the initialization phase, so the CRDs that a platform usually support does not change that frequently, so would be reasonable. But the ordering of CRD apply and operator installation might matter, so what by default make sense to me is like:

checking the CRD every 15s seconds for 10 minutes for example; then just check it in every hour or so.