# `clusterctl alpha topology plan` support for RuntimeSDK * RuntimeSDK feature gate * clusterctl should hard-core the feature gate to be enabled while running the command. * Is there any other option? * Only for Topology Mutation hooks right? * Do we care about Lifecycle hooks? If we do, there is probably no additional work needed to make it work. * **Calling Lifecycle hooks can be dangerous**: * Lifecycle hooks are designed to have some kind of side effects like: install add-ons on a cluster, delete applications from a cluster, interact with the cloud to do some prep actions. * We do not want the dry run to trigger any of these actions. * 2 options: * Simply skip the lifecycle hooks in the reconciler when doing dryrun * I am +1 on this. Simple. * Add a `Dryrun` field to the lifecycle hooks request objects that will be set to trure. The extension hook handler should/shouldn't do the appropriate action if `Dryrun` is true. * I am -1 on this. Has dependendcy on extension authors to support this case. There is no way for us to know if they dont and it could result in unexpected actions on the cluster. * We need a `catalog` in clusterctl and register the runtimehooksv1 * We need a RuntimeClient in clusterctl * This comes with a registry that should eventually be warmed up * Connectivity to Extension Servers * It is best if we can use `ExtensionConfig` as input so that we can reuse the same mechanism in cases where we are working with a real management cluster and cases where we are not. * Discovery should not update the real objects in the API server. * The fake client setup that we have should already take care of this. * The `ExtensionConfig` gives us connectivity to extension servers in 2 ways: * Reference to a Kubernetes Service * In this case we can do a "kubectl port-froward" to the service. * We can reuse the technique used in KCP to port-forward and connect to the etcd pod. * Modify the ExtensionConfig to use `URL` instead of `Service` and save this extension config if our dryrunclient. This will eventually get pickedup by warmup and update the registry accordingly. * URL: * We can use the ExtensionConfig as is. * [**Check this**] What if the URL is a `docker.for.mac.localhost` kind of URL? * After we modifty the ExtensionConfigs to all be URLs we should run warmup. * After warmup we can now trigger the Reconciler and the controller should be able to establish connection to the Extension Servers. * Before the command exits stop all the port-forwardings. --- #### Side idea on defaulting and validation: * How about doing dryrun apply on all the object in the input? This wil run the defaulting and validation webhook on all the objects and we are no longer limited to running defaulting and validation on only Cluster and ClusterClasses. * Much better UX for users using the command. The requirement to already have the templates defaulted is not great. * This only works when working with a real management cluster and initialized with the required providers. * When not working with a real management cluster we can show a message in the output that roughly says _"No management cluster detected. These results are an approximation. For better results run against a management cluster."_ * In most cases the users already need a management cluster to get defaulted and validated templates in the first place. * The difference of UX and output between working with an without a management cluster increases. * Increased support surface. We have to keep supporting 2 different ways of doing dryrun.