In order to reduce the scope of what we are forced to support until a v2 release of OLM, should we proactively reject helm charts that ultimately include chart hooks in their manifests?
Supporting helm chart hooks generally means that we are using helm's libraries to manage the lifecycle of the objects, which has other implications (e.g. see #923).
It also means that there are additional complexities due to the stages introduced by chart hooks (e.g. it is generally not acceptable to block in a Reconcile implementation).
NOTE: This is not immediately important while we are only supporting registry+v1 bundles because operator-controller generates helm charts on-the-fly from registry+v1 bundle content, and it does not use chart hooks.
In order to reduce the scope of what we are forced to support until a v2 release of OLM, should we proactively reject helm charts that ultimately include chart hooks in their manifests?
Supporting helm chart hooks generally means that we are using helm's libraries to manage the lifecycle of the objects, which has other implications (e.g. see #923).
It also means that there are additional complexities due to the stages introduced by chart hooks (e.g. it is generally not acceptable to block in a
Reconcileimplementation).NOTE: This is not immediately important while we are only supporting registry+v1 bundles because
operator-controllergenerates helm charts on-the-fly from registry+v1 bundle content, and it does not use chart hooks.