Minor updates to integration tests doc (#843)

docs/development/integration_tests.md

@@ -8,26 +8,27 @@ 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. Copy the kubeconfig of Control Cluster from into `dev/control-kubeconfig.yaml`. 
-1. (optional) Copy the kubeconfig of Target Cluster into `dev/target-kubeconfig.yaml` and update the `Makefile` variable `TARGET_KUBECONFIG` to point to `dev/target-kubeconfig.yaml`.
+1. Copy the kubeconfig of the Control Cluster into `dev/control-kubeconfig.yaml` and update the `Makefile` variable `CONTROL_KUBECONFIG` to point to `dev/control-kubeconfig.yaml`. 
+1. Update the `Makefile` variable `CONTROL_NAMESPACE` to a valid namespace of the control cluster. 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 update the `Makefile` variable `TARGET_KUBECONFIG` to point to `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.
-1. Atleast, one of the two controllers' container images must be set in the `Makefile` variables `MCM_IMAGE_TAG` and `MC_IMAGE_TAG` for the controllers to run in the Control Cluster . 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 unset the variables `MCM_IMAGE_TAG` and `MC_IMAGE_TAG` and set variable `MACHINE_CONTROLLER_MANAGER_DEPLOYMENT_NAME := machine-controller-manager` in the `Makefile`.
+1. Atleast, one of the two controllers' container images must be set in the `Makefile` variables `MCM_IMAGE` and `MC_IMAGE` for the controllers to run in the Control Cluster. 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 unset the variables `MCM_IMAGE` and `MC_IMAGE` and set variable `MACHINE_CONTROLLER_MANAGER_DEPLOYMENT_NAME := machine-controller-manager` in the `Makefile`.
 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
  ```
 ## Scenario based additional configurations
 ### Gardener Shoot as the Control Cluster 
 
-If the Control Cluster  is a Gardener Shoot cluster then,
+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. 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 update the `Makefile` variable `MACHINECLASS_V2` to point to `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,
+If the Control Cluster is a Gardener SEED cluster, then the suite ideally employs the already existing `MachineClass` and Secrets. However,
 
 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>`.

pkg/test/integration/common/framework.go

@@ -1043,7 +1043,7 @@ func (c *IntegrationTestFramework) ControllerTests() {
  },
  ).Stream(ctx)
  gomega.Expect(err).NotTo(gomega.HaveOccurred())
- gomega.Expect(io.Copy(mcOutputFile, readCloser)).NotTo(gomega.HaveOccurred())
+ _, err = io.Copy(mcOutputFile, readCloser)
  gomega.Expect(err).NotTo(gomega.HaveOccurred())
  } else {
  readCloser, err := c.ControlCluster.Clientset.CoreV1().
@@ -1052,7 +1052,7 @@ func (c *IntegrationTestFramework) ControllerTests() {
  Container: containers[i].Name,
  }).Stream(ctx)
  gomega.Expect(err).NotTo(gomega.HaveOccurred())
- gomega.Expect(io.Copy(mcmOutputFile, readCloser)).NotTo(gomega.HaveOccurred())
+ _, err = io.Copy(mcmOutputFile, readCloser)
  gomega.Expect(err).NotTo(gomega.HaveOccurred())
  }
  }