Create the BYOHost API type

[fabriziopandini]

We should create the BYOHost API type providing a representation of a BYO Host that enters in the cluster-api-provider-byoh capacity pool, setup the generation of the corresponding CRD type, and configure the related validation web-hook endpoint.

A BYO Host is an host provisioned outside of Cluster API, with the entire stack up to the OS already configured; the Kubernetes host components (e.g. containers, kubelet, kubeadm etc.) might be pre-provisioned (like the OS) or managed by this infrastructure provider.

In the initial version of the Host kind

• BYOHost will be a global resource (not namespaced)
• We are going to use labels for documenting:
  • System architecture (e.g ARM)
  • Host operating system (e.g Windows)
  • Bespoke devices (e.g. GPU, FGPA)
  • Fault tolerance criterias (e.g. Location, Failure Domain)
  • In case of the Kubernetes binaries are user provided, the installed Kubernetes version
  • Any other concept that can be used for defining resource pools (e.g. tenant/team, project etc.)
• The BYOHost.Spec section will contain a bare minimal set of information required to connect to the host in an insecure way.
  • Note: In the following iterations this set must be extended for supporting secure communications; eventually we could also consider shifting to a different communication protocol, with the node polling/watching the API server/a service endpoint.
  • Note: we are keeping host connection info in the Spec in order to make it easier to test host creation manually; in the future we might consider to move those info in the status and use the node agent as the authoritative source.
• The BYOHost.Status section will contain a bare minimal set of information required to handle host reservation.
  • Note: In the following iterations most probably this set will be extended for:
    • including host health check information/other information generated by the node agent
    • supporting host maintenance workflows
    • etc.

[fabriziopandini]

/assign

[fabriziopandini]

According to #12 (comment)

I don't think we should depend on the agent listening. Better for the agent to always be a network client.

Point taken, so I'm changing the Host type accordingly. I have considered two options:

• Make the controller expose an endpoint the node agent can talk to, but this has some implications, like e.g. assume it is possible to use some sort of ingress controller vs other solutions to let the traffic to come into the management cluster, which adds some complications in the initial phase of testing while I will be using mostly Kind/CAPD.
• Make the node agent to communicate to the infrastructure provider operator via the API server/by upgrading the status on the HostType object (which should be already possible as described in Implement host registration #10).

For the first iteration I'm going for 2, because it doesn't introduces further dependencies and it also reduces the scope of he first iteration given that it removes the need of implementing a grpc server/client.