Code review feedback

config/default/manager_image_patch.yaml

@@ -7,5 +7,5 @@ spec:
   template:
     spec:
       containers:
-      - image: gcr.io/k8s-staging-cluster-api/cluster-api-controller:master
+      - image: gcr.io/cluster-api-242700/cluster-api-controller-amd64:dev
         name: manager

docs/book/src/providers/implementers-guide/building_running_and_testing.md

@@ -9,16 +9,17 @@ Right now there is a placeholder `IMAGE_URL`, which you will need to change to y
 It's likely that you will want one location and tag for release development, and another during development.
 
 The approach most Cluster API projects is using [a `Makefile` that uses `sed` to replace the image URL][sed] on demand during development.
+
 [sed]: https://github.com/kubernetes-sigs/cluster-api/blob/e0fb83a839b2755b14fbefbe6f93db9a58c76952/Makefile#L201-L204
 
 ## Deployment
 
-### CertManager
+### cert-manager
 
-Cluster API uses [certmanager] to manage the certificates it needs for its webhooks. 
+Cluster API uses [cert-manager] to manage the certificates it needs for its webhooks. 
 Before you apply Cluster API's yaml, you should [install `cert-manager`][cm-install]
 
-[certmanager]: https://github.com/jetstack/cert-manager
+[cert-manager]: https://github.com/jetstack/cert-manager
 [cm-install]: https://docs.cert-manager.io/en/latest/getting-started/install/kubernetes.html
 
 ```
@@ -78,11 +79,11 @@ You can visit [some example repositories][capidev], but you can get started by w
 [tiltfile]: https://docs.tilt.dev/tiltfile_concepts.html
 
 ```starlark
-allow_k8s_contexts('kubernetes-admin@luna')
+allow_k8s_contexts('kubernetes-admin@kind)
 
 k8s_yaml('capm.yaml')
 
-docker_build('<your docke username or repository url>/cluster-api-controller-mailgun-amd64', '.')
+docker_build('<your docker username or repository url>/cluster-api-controller-mailgun-amd64', '.')
 ```
 
 You can then use Tilt to watch the logs coming off your container

docs/book/src/providers/implementers-guide/generate_crds.md

@@ -37,6 +37,14 @@ kubebuilder create api --group infrastructure --version v1alpha3 --kind MailgunC
 kubebuilder create api --group infrastructure --version v1alpha3 --kind MailgunMachine
 ```
 
+```
+Create Resource under pkg/apis [y/n]?
+y
+Create Controller under pkg/controller [y/n]?
+y
+```
+
+
 ### Add Status subresource
 
 The [status subresource][status] lets Spec and Status requests for custom resources be addressed seperately so requests don't conflict with each other. 
@@ -70,12 +78,6 @@ make manifests
 [rbac]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#customresourcesubresources-v1beta1-apiextensions-k8s-io
 [kbstatus]: https://book.kubebuilder.io/reference/generating-crd.html?highlight=status#status
 
-```
-Create Resource under pkg/apis [y/n]?
-y
-Create Controller under pkg/controller [y/n]?
-y
-```
 
 ### Commit your changes
 

docs/book/src/providers/implementers-guide/naming.md

@@ -33,15 +33,15 @@ service named **mailgun**. Therefore the name of the repository will be
 Every Kubernetes resource has a *Group*, *Version* and *Kind* that uniquely
 identifies it.
 
-* The resource *Kind* is the name of the objects we'll be creating and modifying.
-  In this case it's `MailgunMachine` and `MailgunCluster`.
-* The resource *Version* defines the stability of the API and its backward compatibility guarantees.
-  Examples include v1alpha1, v1beta1, v1, etc. and are governed by the Kubernetes API Deprecation Policy [^1].
-  Your provider should expect to abide by the same policies.
 * The resource *Group* is similar to package in a language.
   It disambiguates different APIs that may happen to have identically named *Kind*s.
   Groups often contain a domain name, such as k8s.io.
-  The domain for Cluster API resources is `cluster.x-k8s.io`, and infrastructure providers generally use `infrastructure.x-k8s.io`.
+  The domain for Cluster API resources is `cluster.x-k8s.io`, and infrastructure providers generally use `infrastructure.cluster.x-k8s.io`.
+* The resource *Version* defines the stability of the API and its backward compatibility guarantees.
+  Examples include v1alpha1, v1beta1, v1, etc. and are governed by the Kubernetes API Deprecation Policy [^1].
+  Your provider should expect to abide by the same policies.
+* The resource *Kind* is the name of the objects we'll be creating and modifying.
+  In this case it's `MailgunMachine` and `MailgunCluster`.
 
 For example, our cluster object will be:
 ```yaml

docs/book/src/providers/implementers-guide/overview.md

@@ -5,8 +5,8 @@ In order to demonstrate how to develop a new Cluster API provider we will use
 and CRDs in general we highly recommend reading the [Kubebuilder Book][kubebuilder-book].
 Much of the information here was adapted directly from it. 
 
-This is an _infrastructure_ provider - tasked with producing machines or nodes to install Kubernetes on.
-There are also [bootstrapping providers][bootstrap], which turn those nodes into Kubernetes nodes
+This is an _infrastructure_ provider - tasked with managing provider-specific resources for clusters and machines.
+There are also [bootstrap providers][bootstrap], which turn machines into Kubernetes nodes.
 
 [bootstrap]: https://cluster-api.sigs.k8s.io/reference/providers.html?highlight=bootstrap#bootstrap
 
@@ -18,7 +18,7 @@ There are also [bootstrapping providers][bootstrap], which turn those nodes into
 
 ### tl;dr
 
-{{#tabs name:"kind-cluster" tabs:"MacOS,Linux"}}
+{{#tabs name:"kubectl and kustomize" tabs:"MacOS,Linux"}}
 {{#tab MacOS}}
 
 ```bash