Update docs for beta ClusterResourceSet

Author: mboersma

config/manager/manager.yaml

@@ -23,7 +23,7 @@ spec:
             - "--leader-elect"
             - "--diagnostics-address=${CAPI_DIAGNOSTICS_ADDRESS:=:8443}"
             - "--insecure-diagnostics=${CAPI_INSECURE_DIAGNOSTICS:=false}"
-            - "--feature-gates=MachinePool=${EXP_MACHINE_POOL:=false},ClusterResourceSet=${EXP_CLUSTER_RESOURCE_SET:=false},ClusterTopology=${CLUSTER_TOPOLOGY:=false},RuntimeSDK=${EXP_RUNTIME_SDK:=false},MachineSetPreflightChecks=${EXP_MACHINE_SET_PREFLIGHT_CHECKS:=false}"
+            - "--feature-gates=MachinePool=${EXP_MACHINE_POOL:=false},ClusterResourceSet=${EXP_CLUSTER_RESOURCE_SET:=true},ClusterTopology=${CLUSTER_TOPOLOGY:=false},RuntimeSDK=${EXP_RUNTIME_SDK:=false},MachineSetPreflightChecks=${EXP_MACHINE_SET_PREFLIGHT_CHECKS:=false}"
           image: controller:latest
           name: manager
           env:

docs/book/src/developer/testing.md

@@ -27,8 +27,8 @@ if this is not possible, a viable solution is to use mocks (e.g CAPA).
 
 ### Generic providers
 When writing tests core Cluster API contributors should ensure that the code works with any providers, and thus it is required
-to not use any specific provider implementation. Instead, the so-called generic providers e.g. "GenericInfrastructureCluster" 
-should be used because they implement the plain Cluster API contract. This prevents tests from relying on assumptions that 
+to not use any specific provider implementation. Instead, the so-called generic providers e.g. "GenericInfrastructureCluster"
+should be used because they implement the plain Cluster API contract. This prevents tests from relying on assumptions that
 may not hold true in all cases.
 
 Please note that in the long term we would like to improve the implementation of generic providers, centralizing
@@ -46,11 +46,11 @@ the test cluster.
 With this approach it is possible to interact with Cluster API almost like in a real environment, by creating/updating
 Kubernetes objects and waiting for the controllers to take action. See the [quick reference](#quick-reference) below for more details.
 
-Also in case of integration tests, considerations about [mocking external APIs](#mocking-external-apis) and usage of [generic providers](#generic-providers) apply. 
+Also in case of integration tests, considerations about [mocking external APIs](#mocking-external-apis) and usage of [generic providers](#generic-providers) apply.
 
 ## Fuzzing tests
 
-Fuzzing tests automatically inject randomly generated inputs, often invalid or with unexpected values, into functions to discover vulnerabilities. 
+Fuzzing tests automatically inject randomly generated inputs, often invalid or with unexpected values, into functions to discover vulnerabilities.
 
 Two different types of fuzzing are currently being used on the Cluster API repository:
 
@@ -78,7 +78,7 @@ In light of continuing improving our practice around this ambitious goal, we are
 
 Each contribution in growing this set of utilities or their adoption across the codebase is more than welcome!
 
-Another consideration that can help in improving test maintainability is the idea of testing "by layers"; this idea could 
+Another consideration that can help in improving test maintainability is the idea of testing "by layers"; this idea could
 apply whenever we are testing "higher-level" functions that internally uses one or more "lower-level" functions;
 in order to avoid writing/maintaining redundant tests, whenever possible contributors should take care of testing
 _only_ the logic that is implemented in the "higher-level" function, delegating the test function called internally
@@ -243,28 +243,27 @@ Execute the run configuration with `Debug`.
 
 <h1>Tips</h1>
 
-The e2e tests create a new management cluster with kind on each run. To avoid this and speed up the test execution the tests can 
+The e2e tests create a new management cluster with kind on each run. To avoid this and speed up the test execution the tests can
 also be run against a management cluster created by [tilt](./tilt.md):
 ```bash
 # Create a kind cluster
 ./hack/kind-install-for-capd.sh
 # Set up the management cluster via tilt
-tilt up 
+tilt up
 ```
 Now you can start the e2e test via IDE as described above but with the additional `-e2e.use-existing-cluster=true` flag.
 
 **Note**: This can also be used to debug controllers during e2e tests as described in [Developing Cluster API with Tilt](./tilt.md#wiring-up-debuggers).
 
-The e2e tests also create a local clusterctl repository. After it has been created on a first test execution this step can also be 
-skipped by setting `-e2e.clusterctl-config=<ARTIFACTS>/repository/clusterctl-config.yaml`. This also works with a clusterctl repository created 
+The e2e tests also create a local clusterctl repository. After it has been created on a first test execution this step can also be
+skipped by setting `-e2e.clusterctl-config=<ARTIFACTS>/repository/clusterctl-config.yaml`. This also works with a clusterctl repository created
 via [Create the local repository](http://localhost:3000/clusterctl/developers.html#create-the-local-repository).
 
 **Feature gates**: E2E tests often use features which need to be enabled first. Make sure to enable the feature gates in the tilt settings file:
 ```yaml
 kustomize_substitutions:
   CLUSTER_TOPOLOGY: "true"
   EXP_MACHINE_POOL: "true"
-  EXP_CLUSTER_RESOURCE_SET: "true"
   EXP_KUBEADM_BOOTSTRAP_FORMAT_IGNITION: "true"
   EXP_RUNTIME_SDK: "true"
   EXP_MACHINE_SET_PREFLIGHT_CHECKS: "true"
@@ -352,7 +351,7 @@ As alternative to loki, JSON logs can be visualized with a human readable timest
 
    The `(. | tostring)` part could also be customized to only output parts of the JSON logline.
    E.g.:
-  
+
    * `(.err)` to only output the error message part.
    * `(.msg)` to only output the message part.
    * `(.controller + " " + .msg)` to output the controller name and message part.
@@ -405,7 +404,7 @@ func TestMain(m *testing.M) {
 ```
 
 Most notably, [envtest] provides not only a real API server to use during testing, but it offers the opportunity
-to configure one or more controllers to run against the test cluster, as well as creating informers index. 
+to configure one or more controllers to run against the test cluster, as well as creating informers index.
 
 ```golang
 func TestMain(m *testing.M) {
@@ -423,7 +422,7 @@ func TestMain(m *testing.M) {
 		if err := index.AddDefaultIndexes(ctx, mgr); err != nil {
 		panic(fmt.Sprintf("unable to setup index: %v", err))
 	}
-    
+
     // Run tests
 	...
 }
@@ -440,8 +439,8 @@ should take care in ensuring each test runs in isolation from the others, by:
 - Avoiding object name conflict.
 
 Developers should also be aware of the fact that the informers cache used to access the [envtest]
-depends on actual etcd watches/API calls for updates, and thus it could happen that after creating 
-or deleting objects the cache takes a few milliseconds to get updated. This can lead to test flakes, 
+depends on actual etcd watches/API calls for updates, and thus it could happen that after creating
+or deleting objects the cache takes a few milliseconds to get updated. This can lead to test flakes,
 and thus it always recommended to use patterns like create and wait or delete and wait; Cluster API env
 test provides a set of utils for this scope.
 
@@ -530,7 +529,7 @@ comes with a set of limitations that could hamper the validity of a test, most n
   of the test objects.
 - the [fakeclient] does not use a cache based on informers/API calls/etcd watches, so the test written in this way
   can't help in surfacing race conditions related to how those components behave in real cluster.
-- there is no support for cache index/operations using cache indexes. 
+- there is no support for cache index/operations using cache indexes.
 
 Accordingly, using [fakeclient] is not suitable for all the use cases, so in some cases contributors will be required
 to use [envtest] instead. In case of doubts about which one to use when writing tests, don't hesitate to ask for

docs/book/src/developer/tilt.md

@@ -46,7 +46,7 @@ enable_providers:
 - kubeadm-control-plane
 ```
 
-To use tilt to launch a provider with its own repo, using Cluster API Provider AWS here, `tilt-settings.yaml` should look like: 
+To use tilt to launch a provider with its own repo, using Cluster API Provider AWS here, `tilt-settings.yaml` should look like:
 
 ```yaml
 default_registry: gcr.io/your-project-name-here
@@ -109,7 +109,6 @@ provider's yaml. These substitutions are also used when deploying cluster templa
 kustomize_substitutions:
   CLUSTER_TOPOLOGY: "true"
   EXP_MACHINE_POOL: "true"
-  EXP_CLUSTER_RESOURCE_SET: "true"
   EXP_KUBEADM_BOOTSTRAP_FORMAT_IGNITION: "true"
   EXP_RUNTIME_SDK: "true"
   EXP_MACHINE_SET_PREFLIGHT_CHECKS: "true"
@@ -409,7 +408,7 @@ build it.
 **live_reload_deps**: a list of files/directories to watch. If any of them changes, Tilt rebuilds the manager binary
 for the provider and performs a live update of the running container.
 
-**version**: allows to define the version to be used for the Provider CR. If empty, a default version will 
+**version**: allows to define the version to be used for the Provider CR. If empty, a default version will
 be used.
 
 **additional_docker_helper_commands** (String, default=""): Additional commands to be run in the helper image

docs/book/src/tasks/experimental-features/cluster-resource-set.md

@@ -1,4 +1,4 @@
-# Experimental Feature: ClusterResourceSet (alpha)
+# Experimental Feature: ClusterResourceSet (beta)
 
 The `ClusterResourceSet` feature is introduced to provide a way to automatically apply a set of resources (such as CNI/CSI) defined by users to matching newly-created/existing clusters.
 

docs/book/src/tasks/experimental-features/experimental-features.md

@@ -8,15 +8,15 @@ temporary location for features which will be moved to their permanent locations
 Users can enable/disable features by setting OS environment variables before running `clusterctl init`, e.g.:
 
 ```yaml
-export EXP_CLUSTER_RESOURCE_SET=true
+export EXP_RUNTIME_SDK=true
 
 clusterctl init --infrastructure vsphere
 ```
 
 As an alternative to environment variables, it is also possible to set variables in the clusterctl config file located at `$XDG_CONFIG_HOME/cluster-api/clusterctl.yaml`, e.g.:
 ```yaml
 # Values for environment variable substitution
-EXP_CLUSTER_RESOURCE_SET: "true"
+EXP_RUNTIME_SDK: "true"
 ```
 In case a variable is defined in both the config file and as an OS environment variable, the environment variable takes precedence.
 For more information on how to set variables for clusterctl, see [clusterctl Configuration File](../../clusterctl/configuration.md)
@@ -30,7 +30,6 @@ As an example, Cluster API Provider Azure (CAPZ) has support for MachinePool thr
 One way is to set experimental variables on the clusterctl config file. For CAPI, these configs are under ./test/e2e/config/... such as `docker.yaml`:
 ```yaml
 variables:
-  EXP_CLUSTER_RESOURCE_SET: "true"
   EXP_MACHINE_POOL: "true"
   CLUSTER_TOPOLOGY: "true"
   EXP_RUNTIME_SDK: "true"
@@ -45,7 +44,6 @@ On development environments started with `Tilt`, features can be enabled by sett
 
 ```yaml
 kustomize_substitutions:
-  EXP_CLUSTER_RESOURCE_SET: 'true'
   EXP_MACHINE_POOL: 'true'
   CLUSTER_TOPOLOGY: 'true'
   EXP_RUNTIME_SDK: 'true'

docs/book/src/user/quick-start.md

@@ -746,7 +746,6 @@ project][Proxmox getting started guide].
 
 Please follow the Cluster API Provider for [Cloud Director Getting Started Guide](https://github.com/vmware/cluster-api-provider-cloud-director/blob/main/README.md)
 
-EXP_CLUSTER_RESOURCE_SET: "true"
 ```bash
 # Initialize the management cluster
 clusterctl init --infrastructure vcd

test/e2e/config/docker.yaml

@@ -332,7 +332,6 @@ variables:
   AUTOSCALER_WORKLOAD: "./data/autoscaler/autoscaler-to-workload-workload.yaml"
   NODE_DRAIN_TIMEOUT: "60s"
   # Enabling the feature flags by setting the env variables.
-  EXP_CLUSTER_RESOURCE_SET: "true"
   EXP_KUBEADM_BOOTSTRAP_FORMAT_IGNITION: "true"
   EXP_MACHINE_POOL: "true"
   CLUSTER_TOPOLOGY: "true"