Enhanced local IT setup (#899)

* Enhanced local IT setup

* Removed MCC from non-gardener-setup script

* Removed MCC from non-gardener-setup script

* Update hack/non_gardener_local_setup.sh

Co-authored-by: Aaron Francis Fernandes <79958509+aaronfern@users.noreply.github.com>

* Improved the IT test docs.

* Improved the IT test docs.

---------

Co-authored-by: Aaron Francis Fernandes <79958509+aaronfern@users.noreply.github.com>

Author: sssash18

docs/development/integration_tests.md

@@ -8,50 +8,20 @@ Integration tests for `machine-controller-manager-provider-{provider-name}` can
 
 1. Clone the repository `machine-controller-manager-provider-{provider-name}` on the local system.
 1. Navigate to `machine-controller-manager-provider-{provider-name}` directory and create a `dev` sub-directory in it.
-1. Create a `.env` file at the root of the `machine-controller-manager-provider-{provider-name}` project. This file serves as an environments file where all key-value pairs that are used in the `Makefile` are defined.
-1. Copy the kubeconfig of the Control Cluster into `dev/control-kubeconfig.yaml` and add an entry in the `.env` file with `CONTROL_KUBECONFIG=dev/control-kubeconfig.yaml`. 
-1. Add `CONTROL_NAMESPACE=<namespace of the control cluster>` to the `.env` file. This is the namespace that is used to deploy all resources and run tests.
-1. (optional) Copy the kubeconfig of the Target Cluster into `dev/target-kubeconfig.yaml` and add an entry in the `.env` file with `TARGET_KUBECONFIG=dev/target-kubeconfig.yaml`.
 1. If the tags on instances & associated resources on the provider are of `String` type (for example, GCP tags on its instances are of type `String` and not key-value pair) then add `TAGS_ARE_STRINGS := true` in the `Makefile` and export it. For GCP this has already been hard coded in the `Makefile`.
-1. If the intention is to run any controllers in the control cluster, then `.env` should have at least one of `MCM_IMAGE` and `MC_IMAGE` defined. These images will be used along with `kubernetes/deployment.yaml` to deploy/update controllers in the Control Cluster. If the intention is to run the controllers locally then remove `MCM_IMAGE` and `MC_IMAGE` key-value pairs defined in `.env` and set `MACHINE_CONTROLLER_MANAGER_DEPLOYMENT_NAME=machine-controller-manager` in the `Makefile` file.
-1. In order to apply the CRDs when the Control Cluster is a Gardener Shoot or if none of the controller images are specified, `machine-controller-manager` repository will be cloned automatically. Incase, this repository already exists in local system, then create a softlink as below which helps to test changes in `machine-controller-manager` quickly.
-    ```bash
-    ln -sf <path-for-machine-controller-manager-repo> dev/mcm
-    ``` 
-1. Please pass `TARGET_CLUSTER_NAME` in the `.env` file. It will be used to initialize the orphan resource tracker. Keep it as the cluster name whose kubeconfig is specified in the `TARGET_KUBECONFIG` variable.
- 
-## Scenario based additional configurations
-### Gardener Shoot as the Control Cluster 
-
-If the Control Cluster is a Gardener Shoot cluster then,
-
-1. Deploy a `Secret` named `test-mc-secret` (that contains the provider secret and cloud-config) in the `default` namespace of the Control Cluster.
-1. Create a `dev/machineclassv1.yaml` file in the cloned repository and add an entry in the `.env` file with `MACHINECLASS_V1=dev/machineclassv1.yaml`. The name of the `MachineClass` itself should be `test-mc-v1`. The value of `providerSpec.secretRef.name` should be `test-mc-secret`. 
-1. (Optional) Create an additional `dev/machineclassv2.yaml` file similar to above but with a bigger machine type and add an entry in the `.env` file with `MACHINECLASS_V2=dev/machineclassv2.yaml`.
-
-### Gardener Seed as the Control Cluster 
-
-If the Control Cluster is a Gardener SEED cluster, then the suite ideally employs the already existing `MachineClass` and Secrets. However,
-
-1. Define the variable `IS_CONTROL_CLUSTER_SEED` in the `.env` file and set it to `true`. 
-`Warning:` Make sure to set the `CONTROL_NAMESPACE` variable to the shoot namespace where the control plane of the target resides.
-1. (Optional) User can employ a custom `MachineClass` for the tests using below steps:
-    1. Deploy a `Secret` named `test-mc-secret` (that contains the provider secret and cloud-config) in the shoot namespace of the Control Cluster. That is, the value of `metadata.namespace` should be `technicalID` of the Shoot and it will be of the pattern `shoot--<project>--<shoot-name>`.
-    1. Create a `dev/machineclassv1.yaml` file and add an entry in the `.env` file with `MACHINECLASS_V1=dev/machineclassv1.yaml`.
-        1. `providerSpec.secretRef.name` should refer the secret created in the previous step.
-        1. `metadata.namespace` and `providerSpec.secretRef.namespace` should be `technicalID` (`shoot--<project>--<shoot-name>`) of the shoot.
-        1.  The name of the `MachineClass` itself should be `test-mc-v1`.
 
 ## Running the tests
 
-1. There is a rule `test-integration` in the `Makefile`, which can be used to start the integration test:
+1. There is a rule `test-integration` in the `Makefile` of the provider repository, which can be used to start the integration test:
     ```bash
     $ make test-integration 
-    Starting integration tests...
-    Running Suite: Controller Suite
-    ===============================
     ```
-1. The controllers log files (`mcm_process.log` and `mc_process.log`) are stored in `.ci/controllers-test/logs` repo and can be used later.
+1. This will ask for additional inputs. Most of them are self explanatory except:
+ - The script assumes that both the control and target clusters are already being created.
+ - In case of non-gardener setup (control cluster is not a gardener seed), the name of the machineclass must be `test-mc-v1` and the value of `providerSpec.secretRef.name` should be `test-mc-secret`.
+ - In case of azure, `TARGET_CLUSTER_NAME` must be same as the name of the Azure ResourceGroup for the cluster.
+ - If you are deploying the secret manually, a `Secret` named `test-mc-secret` (that contains the provider secret and cloud-config) in the `default` namespace of the Control Cluster should be created.
+3. The controllers log files (`mcm_process.log` and `mc_process.log`) are stored in `.ci/controllers-test/logs` repo and can be used later.
 ## Adding Integration Tests for new providers
 
 For a new provider, Running Integration tests works with no changes. But for the orphan resource test cases to work correctly, the provider-specific API calls and the Resource Tracker Interface (RTI) should be implemented. Please check [`machine-controller-manager-provider-aws`](https://github.com/gardener/machine-controller-manager-provider-aws/blob/master/test/integration/provider/) for reference.

hack/gardener_local_setup.sh

@@ -197,7 +197,8 @@ function set_makefile_env() {
   target_project_dir="$1"
   target_kube_config_path="$2"
   {
-    printf "\n%s" "CONTROL_NAMESPACE=shoot--${PROJECT}--${SHOOT}"
+    printf "\n%s" "IS_CONTROL_CLUSTER_SEED=true" >"${target_project_dir}/.env"
+    printf "\n%s" "CONTROL_CLUSTER_NAMESPACE=shoot--${PROJECT}--${SHOOT}" >> "${target_project_dir}/.env"
     printf "\n%s" "CONTROL_KUBECONFIG=${target_kube_config_path}/kubeconfig_control.yaml" >>"${target_project_dir}/.env"
     printf "\n%s" "TARGET_KUBECONFIG=${target_kube_config_path}/kubeconfig_target.yaml" >>"${target_project_dir}/.env"
   } >>"${target_project_dir}/.env"

hack/non_gardener_local_setup.sh

@@ -120,7 +120,12 @@ function copy_kubeconfigs_to_provider_mcm() {
 
 function scale_down_mcm() {
   echo "scaling down deployment/machine-controller-manager to 0..."
+  set +e
   KUBECONFIG="${CONTROL_KUBECONFIG_PATH}" kubectl -n "${NAMESPACE}" scale deployment/machine-controller-manager --replicas=0
+  if [[ $? -ne 0 ]]; then
+    echo "deployment/machine-controller-manager does not exist or failed to scale down to 0"
+  fi
+  set -e
 }
 
 # create_makefile_env creates a .env file that will get copied to both mcm and mcm-provider project directories for their
@@ -132,7 +137,8 @@ function set_makefile_env() {
 
   local target_project_dir="$1"
   {
-    printf "\n%s" "CONTROL_NAMESPACE=${NAMESPACE}"
+    printf "\n%s" "IS_CONTROL_CLUSTER_SEED=false" > "${target_project_dir}/.env"
+    printf "\n%s" "CONTROL_CLUSTER_NAMESPACE=${NAMESPACE}" >> "${target_project_dir}/.env"
     printf "\n%s" "CONTROL_KUBECONFIG=${CONTROL_KUBECONFIG_PATH}" >>"${target_project_dir}/.env"
     printf "\n%s" "TARGET_KUBECONFIG=${TARGET_KUBECONFIG_PATH}" >>"${target_project_dir}/.env"
   } >>"${target_project_dir}/.env"