🌱 Simplify CAPD quick start

[fabriziopandini]

What this PR does / why we need it:
This PR simplifies the quick start with the docker provider; this impacts also the clusterctl DX, and more specifically

• CAPD is now an embedded provider in clusterctl, so the UX is the same of all the other providers
• CAPD artifacts are now included in the CAPI release (infrastructure-components.yaml, cluster-template.yam)
• The quick start doc is updated according to ^^
• The local-override hack was deleted
• A new create-local-repository hack was introduced to allow the developer to create a local repository starting from sources files
• The clusterctl for developers dos is updated according to ^^

Which issue(s) this PR fixes:
Fixes #

[vincepri]

Thoughts about renaming the artifacts to CAPD where D stands for development? I want to make it super explicit that this provider should never be used in production, and I'm thinking to rename it altogether in v1alpha4, thoughts?

[fabriziopandini]

I want to make it super explicit that this provider should never be used in production, and I'm thinking to rename it altogether in v1alpha4, thoughts?

TBH I don't think this is necessary. The fact that CAPD is for development only is already well documented and the fact the current implementation is limited to a single machine is a hard stop-gap for any production use case.

In the end, no name/-dev prefix will prevent a user to do crazy things if he really wants, and, given that IMO we already did a good job in advising people about CAPD limitations, I'm OK with the current name.

[vincepri]

Is the cluster-template.yaml published as well?

[fabriziopandini]

Is the cluster-template.yaml published as well?

yes. all the CAPD templates are going to be part of the release; currently, there is only one

[vincepri]

Let's name it at least cluster-template-development?

[fabriziopandini]

Let's name it at least cluster-template-development?

Sure, but this requires --flavor when doing clusterctl config file (I'm going to document it)

[vincepri]

Could we add support in the metadata file / internal for the default template to look at?

Is the template file getting copied into the out/ folder when make release is executed?

[fabriziopandini]

@vincepri

Could we add support in the metadata file / internal for the default template to look at?

This is tricky, because the template name is generated by the yaml processor and currently this does not get in input any of metadata/provider config

Is the template file getting copied into the out/ folder when make release is executed?

yes!

[vincepri]

LGTM pending squash, thanks for doing this and applying the requested changes! The documentation looks even better now with --flavor development :)

[fabriziopandini]

/hold
this should be unblocker just before release because it touches the documentation

[elmiko]

this is awesome @fabriziopandini !

i have not tested this workflow, but as i have recently broken my test stand i will do so on monday. i left a couple comments inline.

[vincepri]

/milestone v0.3.9

[wfernandes]

/assign
Reviewing. Will try and follow instructions since it has been a while since I did anything with CAPD 🙂

[elmiko]

i tried to follow the developer instructions and ran into this error during the step for building artifacts. it looks like the dockerfile is referencing an image that is not pulling cleanly for me (gcr.io/distroless/static:latest). did i miss a step?

updated
i had some weird network outage, sorry.

[elmiko]

hey Fabrizio, i've tried to duplicate these instructions but i keep running into a few issues.

for reference, i am using Fedora 31, Docker 19.03, Go 1.13.14 and Kind 0.8.1.

i cleaned my environment (removed all old capi stuff), and rebuilt clusterctl and the capi images, these are some of the issues i see:

1. clusterctl is looking for a template file named cluster-template.yaml but the one provided is cluster-template-deployment.yaml. fix was to rename my local file, this might be intended but we should mention in the docs if so.
2. the kind management cluster is having issues pulling my local created images for the capi components. fix was to load all the images into the kind management cluster (with kind load docker-image) and then update the various infrastructure manifests to change the imagePullPolicy: Always to IfNotPresent.
3. the initial control plane machine deploys fine but it seems like additional control plane machines are never created and the workers are stuck in pending state.

not sure if i've messed something up locally, but i tried to follow the instructions from a clean environment.

[vincepri]

/milestone v0.3.10

[vincepri]

/milestone v0.3.9
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vincepri, wfernandes

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vincepri]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vincepri]

/hold cancel

[dlipovetsky]

I verified creating a cluster with this PR last Friday.

Thank you, @fabriziopandini!

/lgtm

[fabriziopandini]

/hold
This PR did not merge before v0.3.9 release due to test flakes 😭

[fabriziopandini]

/retest

[vincepri]

/milestone v0.3.10

[vincepri]

/hold cancel

[bboreham]

I see the instruction to set KIND_EXPERIMENTAL_DOCKER_NETWORK was removed in this PR; I am finding things work better with that setting. Was I supposed to do something different to replace it?

[bboreham]

Ignore previous question: the setting is still there on a different page.

[nistiwar]

I guess this code is not yet released, how do I use it to test. A trivial question maybe, but I am struggling at the exact steps, managed to get through the imagePull error by changing 'ALways' to 'ifNotPresent'. However am getting the following while creating workload cluster:

root@master-1:~# kubectl apply -f capi-quickstart.yaml
dockercluster.infrastructure.cluster.x-k8s.io/capi-quickstart created
dockermachinetemplate.infrastructure.cluster.x-k8s.io/capi-quickstart-control-plane created
dockermachinetemplate.infrastructure.cluster.x-k8s.io/capi-quickstart-md-0 created
Error from server (InternalError): error when creating "capi-quickstart.yaml": Internal error occurred: conversion webhook for cluster.x-k8s.io/v1alpha3, Kind=Cluster failed: the server could not find the requested resource
Error from server (InternalError): error when creating "capi-quickstart.yaml": Internal error occurred: conversion webhook for controlplane.cluster.x-k8s.io/v1alpha3, Kind=KubeadmControlPlane failed: the server could not find the requested resource
Error from server: error when creating "capi-quickstart.yaml": conversion webhook for bootstrap.cluster.x-k8s.io/v1alpha3, Kind=KubeadmConfigTemplate failed: the server could not find the requested resource
Error from server (InternalError): error when creating "capi-quickstart.yaml": Internal error occurred: conversion webhook for cluster.x-k8s.io/v1alpha3, Kind=MachineDeployment failed: the server could not find the requested resource

[wfernandes]

@nistiwar I was able to reproduce this myself. This happens because the current storage version of the CRDs being stored is v1alpha4. We may need to update the test/infrastructure/docker/templates/cluster-template-development.yaml file. If you'd like, feel free to open an issue, else I can do it on your behalf.

[wfernandes]

@nistiwar I ended up creating the issue referenced above and will submit a PR shortly. Thanks for surfacing this issue!