Minor fixes in devel docs (#2137)

* Fix some minor typos in devel docs

* Add note for developing kubeops with Kind

docs/developer/README.md

@@ -6,6 +6,12 @@ The dashboard is the main UI component of the Kubeapps project. Written in Javas
 
 Please refer to the [Kubeapps Dashboard Developer Guide](dashboard.md) for the developer setup.
 
+### kubeops
+
+The `kubeops` component is a micro-service that creates an API endpoint for accessing the Helm API and Kubernetes resources.
+
+Please refer to the [Kubeapps Kubeops Developer Guide](kubeops.md) for the developer setup.
+
 ### assetsvc
 
 The `assetsvc` component is a micro-service that creates an API endpoint for accessing the metadata for charts in Helm chart repositories that's populated in a Postgresql server.

docs/developer/apprepository-controller.md

@@ -43,7 +43,7 @@ This builds the `apprepository-controller` binary in the working directory.
 Before running the `apprepository-controller` binary on the development host we should stop the existing controller that is running in the development cluster. The best way to do this is to scale the number of replicas of the `apprepository-controller` deployment to `0`.
 
 ```bash
-kubectl -n kubeapps scale deployment apprepository-controller --replicas=0
+kubectl -n kubeapps scale deployment kubeapps-internal-apprepository-controller --replicas=0
 ```
 
 > **NOTE** Remember to scale the deployment back to `1` replica when you are done

docs/developer/basic-form-support.md

@@ -50,8 +50,8 @@ In order to render a slider, there are some requirements and additional tags tha
 
 - The supported types are `string`, `integer` and `numeric`.
 - It's necessary to specify the tag `render` and set it to `slider`.
-- The tag `sliderMin` identifies the minimum value the slider allows (this can be bypassed writting a smaller value in the input).
-- The tag `sliderMax` identifies the maximum value the slider allows (this can be bypassed writting a bigger value in the input).
+- The tag `sliderMin` identifies the minimum value the slider allows (this can be bypassed writing a smaller value in the input).
+- The tag `sliderMax` identifies the maximum value the slider allows (this can be bypassed writing a bigger value in the input).
 - The tag `sliderStep` identifies the step the slider will increment or decrement the value when moved.
 - The tag `sliderUnit` specifies the unit of the value to set. For example `Gi`.
 
@@ -88,7 +88,7 @@ In order to render a component as a textArea, it's necessary to specify the tag
 ```
 ### Drop-down lists
 
-When a property defines a `enum` tag as constraint, it will be rendered as a drop-down list. 
+When a property defines an `enum` tag as constraint, it will be rendered as a drop-down list. 
 
 This is an example:
 
@@ -114,7 +114,7 @@ When a property of type `object` is set with a `form` identifier, it will be ren
 
 All the parameters within an `object` will be rendered in the subsection.
 
-Note that in some cases, a parameter cause that the rest of parameters are no longer relevant. For example, setting `ingress.enabled` to `false` makes the `ingress.hostname` irrelevant. To avoid confussion, you can hide that parameter setting the special tag `hidden`. The tag `hidden` can be a `string` pointing to the parameter that needs to be `true` to hide the element, or an `object` to also set the value that the pointed value needs to match as shown below:
+Note that in some cases, a parameter cause that the rest of the parameters are no longer relevant. For example, setting `ingress.enabled` to `false` makes the `ingress.hostname` irrelevant. To avoid confusion, you can hide that parameter setting the special tag `hidden`. The tag `hidden` can be a `string` pointing to the parameter that needs to be `true` to hide the element, or an `object` to also set the value that the pointed value needs to match as shown below:
 
 ```json
 {

docs/developer/dashboard.md

@@ -79,7 +79,7 @@ Next you can launch the dashboard.
 yarn run start
 ```
 
-You can now access the local development server simply by accessing the dashboard as you usually would (e.g. doing a port-forward or accesing the Ingress URL).
+You can now access the local development server simply by accessing the dashboard as you usually would (e.g. doing a port-forward or accessing the Ingress URL).
 
 #### Troubleshooting
 

docs/developer/end-to-end-tests.md

@@ -1,6 +1,6 @@
 # End-to-end tests in the project
 
-In every CI build, a set of end-to-end tests are run to verify, as much as possible, that the changes don't include regressions from an user point of view. The current end-to-end tests are executed in two steps (or categories):
+In every CI build, a set of end-to-end tests are run to verify, as much as possible, that the changes don't include regressions from a user point of view. The current end-to-end tests are executed in two steps (or categories):
 
 - Chart tests
 - Browser tests
@@ -35,7 +35,7 @@ It's possible to run these tests either locally or in a container environment.
 
 You can setup a configured Kubeapps instance in your cluster with the `script/setup-kubeapps.sh` script.
 
-### Runing browser tests locally
+### Running browser tests locally
 
 To run the tests locally you just need to install the required dependencies and set the required environment variables:
 
@@ -49,7 +49,7 @@ If anything goes wrong, apart from the logs of the test, you can find the screen
 
 ### Running browser tests in a pod
 
-Since the CI environment don't have the required dependencies and to provide a reproducible environment, it's possible to run the browser tests in a Kubernetes pod. To do so, you can spin up an instance running the image `kubeapps/integration-tests`. This image contains all the required dependencies and it waits forever so you can execute commands within it. The goal of this setup is that you can copy the latest tests to the image, run the tests and extract the screenshots in case of failure:
+Since the CI environment doesn't have the required dependencies and to provide a reproducible environment, it's possible to run the browser tests in a Kubernetes pod. To do so, you can spin up an instance running the image `kubeapps/integration-tests`. This image contains all the required dependencies and it waits forever so you can execute commands within it. The goal of this setup is that you can copy the latest tests to the image, run the tests and extract the screenshots in case of failure:
 
 ```bash
 cd integration

docs/developer/kubeops.md

@@ -48,13 +48,17 @@ kubectl patch deployment kubeapps-internal-kubeops -n kubeapps --type=json -p='[
 ```
 
 The easiest way to create the `kubeops` image is to execute the Makefile task to do so:
+> Since Kubeops depends on certain information only available within the cluster, a deployment with Telepresence becomes much more difficult to set up. 
 
 ```bash
 IMAGE_TAG=dev make kubeapps/kubeops
 ```
 
 This will generate an image `kubeapps/kubeops:dev` that you can use in the current deployment:
 
+> If you are using Kind, remember to manually add the image to your cluster; otherwhise, your k8s cluster will not be able to pull the image. 
+To do so, execute: `kind load docker-image kubeapps/kubeops:dev`
+
 ```bash
 kubectl set image -n kubeapps deployment kubeapps-internal-kubeops kubeops=kubeapps/kubeops:dev
 ```