It does not look like the PacketMachine needs a ProjectID. It is a value
that we get from the PacketCluster.

It is not even generated from the `make examples` file and when applied
via kubectl it fails because PachetMachine.ProjectID is a required field
in openapi.

…ctID

remove the projectID from PacketMachine crd

update the cluster template with required fields

v0.3.3

At the end of the story it took me an hour to understand the issue and 1
minutes to fix it. I suppose.

The kubebuilder installation process is already part of the Makefile,
but it was not used in CI.

now it should work.

fix ci installing kubebuilder

It is cool that we cache the go dependency as a separate layer so images
will take care of caching for us! But it does not come for free!!

fix ci image build test

Fix image build

The types.Machine or Cluster from v1alpha3 where not right registered to
the manager

fix manager adding custerv1 schema types

fix annotations so the CRDs are correct

set correct provider ID

proper cluster reconcile loop, remove finalizers on delete

If we attempt to remove a machine that is not running on Packet (for any
reason), we are in a loop where the reconciler returns 404 from Packet
API and the source never gets deleted.

This code should check for a 404, and it should pass forward the
finalizer trigger a garbage collection.

I presume we do not need to check for the number of `instances` anymore,
because if they are `0` we never get over the `not found error`.

From v1alpha2 to v1alpha3 the Bootstrap.Data field got deprecated in
favour of Bootstrap.DataSecretName as you can see:

https://cluster-api.sigs.k8s.io/developer/providers/v1alpha2-to-v1alpha3.html#data-generated-from-a-bootstrap-provider-is-now-stored-in-a-secret

…-present

trigger finalizer even if the machine is already deleted from packet

bootstrap data secret must be set

handle no ID on creation

fix packet go client wrong import

The tags generated by the machine controller where not merged with the
one passed from the MachineSpec. This PR fixes the issue. Now we can use
those labels to filter devices via packet api.

fix device tags

By default we mark a machine failed when it returns a status that we do
not know. I think it is very reasonable. But we were not handled a few
status: provisioning and queued.

get ip from control plan during cluster reconciliation

… bootstrap is not ready

add requeue timeouts for when machine cannot start because cluster or…

simplify manual install of a new cluster with make target

By default we mark a machine as failed when we receive an unrecognized
state. We were not handling the `provisioning` state.

because why not?

handle device in provisioning state

bump cluster api to 0.3.5

ensure controller-gen exists and is minimum right version

…ol-endpoint

move from APIEndpoint to control plane endpoint

with the userdata currently it place in this PR the master gets a
running kubelet.

As reported on Jira, the kubelet is not running because we do not
install a CNI yet, but this is not crucial at the moment.

The userdata has some fixed values that we have to remove, like the
ROLE. We will get there moving forward.

I would like to fix the certificate issue first

kubelet runs on master

This is the generated code required to support a PacketMachineTemplate

add support for packetmachinetemplate types

The right way to go here is via MachineSet, MachineDeployment.
Those are almost the equivalent of ReplicaSet and Deployment for pod.

* MachineSet represents an immutable group of Machine
* MachineDeployment manage the lifecycle of MachineSet

I updated our example to use those for pod rollout.
By consequence the example also uses KubeadmConfigTemplate and
PacketMachineTemplate

Control Plane management will come in another PR.

update example to use MachineDeployment