Enable lifecycle hooks explicitly in the ClusterClass

[killianmuldoon]

Runtime SDK Lifecycle hooks are currently linked to Clusters entirely based on a namespace selector defined in an ExtensionConfig. If an ExtensionConfig has a Lifecycle hook enabled and a Cluster matches the namespace selector of the ExtensionConfig the hook is called.

There should be some way for Cluster or ClusterClass authors to opt in to lifecycle hooks explicitly. This is the case for external patches today which are specified in a ClusterClass as below.

  patches:
  - name: test-patch
    external:
      generateExtension: generate-patches.k8s-upgrade-with-runtimesdk
      validateExtension: validate-topology.k8s-upgrade-with-runtimesdk
      discoverVariablesExtension: discover-variables.k8s-upgrade-with-runtimesdk

The namespace selector is still in place for these extension calls, so a ClusterClass can not use an extension when it doesn't match the namespace selector.

This issue is about considering making Lifecycle hook extensions explicitly in the ClusterClass spec - i.e. adding a new struct under ClusterClass .spec which looks like:

  hooks:
      beforeClusterCreate: 
         - before-cluster-create.first-extension
         - before-cluster-create.second-extension
         - before-cluster-create.third-extension
      afterClusterUpgrade:
         - before-cluster-upgrade.first-extension
         - before-cluster-upgrade.second-extension
      beforeClusterDelete:
         - before-cluster-delete.third-extension

In the above example Clusters created using this ClusterClass will have beforeClusterCreate calls to three extensions, afterClusterUpgrade calls to two extensions, and beforeClusterDelete calls to one extension.

This would allow ClusterClass, and depending on implementation Cluster, authors to have some control over the hooks called in the lifecycle of the objects they control.

/kind api-change
/area runtime-sdk
/area topology

[sbueringer]

/triage accepted

[fabriziopandini]

+1
this seems a good compromise between what we have today and enabling hooks on each cluster

[fabriziopandini]

/priority important-longterm