Describe the solution you'd like
One of the primary features proposed by clusteradm is the ability to generate opinionated templates using config. What we need to figure out is if we enforce template flavors or variants, and what are those?

cc @frapposelli
/kind feature

In order to let clusterctl to work with federated repositories, it should be defined the contract each repository has to respect in order to be federated

The repository:
TBD...

The provider assets should:

• have a unique yaml file for deploying ensure that all the provider resources are deployed into a unique namespace [1]
• ensure to have a single namespace object
• ensure that all the placeholders variable substitution should be defined with the syntax ${ VARIABLE_NAME }

The config samples should:
TBD...

[1] it will be supported also to have folders a kusomization.yaml file a more yaml (like the /config folder generated by kubebuilder), but the recommendation is to use this only for development/local testing

In order to handle upgrades and other operations, it is necessary to store somewhere the list of providers installed in a management cluster.

A first proposal is to create a new CRD:

 $kubectl get providers -A

NAMESPACE      NAME      TYPE                     VERSION
cabpk-system   kubeadm   BootstrapProvider        v0.1.0
capa-system    aws       InfrastructureProvider   v0.4.0
capi-system    capi      CoreProvider             v0.2.3

Provider object will be created by clusterctl when doing init / add providers.

By querying providers it will be possible

1. plan for upgrades (see what version we have and check for newer versions)

2. help the user to avoid to screw up the Management Cluster by warning in the user is going to:

• install two instances of the same provider in same namespaces
• install two instances of the same provider in different namespaces
• install two different providers in same namespaces

Nb. the underlying assumption behind all the above warning is that the simple / out of the box experience is 1 provider for each namespace/watching for all namespaces; any other combination is supported, but the user has to explicitly opt-in

/cc @frapposelli

Time permitting it would be interesting to combine the idea of a FUSE mounted shell/repl that allowed new users to interact with the tooling -

clusteradm
... Fuse mounts an FS and starts a repl (this is weird)
/> help
init version ls
/> init --providers=aws,vsphere
... if no KUBECONFIG assume --local=true
... deploy clusteradm operator
... clusteradm operator deploys aws and vsphere providers
/> ls
aws vsphere
/> cd aws
/aws/> ls
.
/aws/> help
config version apply ls
/aws/> config test
... default editor or have a conf?
/aws/> save
... applies the YAML
/aws/> ls
test .
/aws/> config test

TODO: Directory
cat spec
cat status

Questions:

1. Namespacing
2. Using standard fs options and scripting find . | grep foo

/cc @frapposelli

• plugin based (across providers)
• flavors
• bootstrap pivot to create mgmt cluster.

/cc @ncdc @rosskukulinski @frapposelli

Describe the solution you'd like
in order to get clusteradm in place there should be agreement on what are the "features" supported by the management cluster, and more specifically what should be "simple" and what should be "possible" to achieve (80/20 rule)

"assumption":
One provider for each namespace

"simple":

1. to have one instance/version for each cluster API component installed in default namespaces
2. to have cluster API components watching resources in all namespaces

"possible":

1. to have more than one instance/version for each cluster API component, each one installed in a dedicated namespace
2. to have instances/versions of cluster API components watching resources in one namespace only
3. to have more providers installed in the same namespace

glossary:
cluster API component: is a set of CRDs, K8s resources required for running one of CAPI, bootstrap providers, infrastructure providers

/assign @timothysc @frapposelli

/kind feature

Describe the solution you'd like
when doing clusteradm init clusteradm is expected to install on the management cluster a set of resources for CAPI and for the selected infrastructure and bootstrap providers.

However, embedding resources for all the providers is not maintainable, so the idea is to:

• Define in clusteradm a list of repositories where to fetch resources for CAPI/for each "community maintained" provider e.g. CAPI from https://github.com/kubernetes-sigs/cluster-api/releases/latest/cluster-api-components.yaml, CAPA from ....
• During init, fetch required resources and apply

Extensions:

• the user will be allowed to change the repository for each provider for testing purposes or for air-gapped environments. Supported alternatives to github/releases are github/tree, local file system or http/https server
• the user will be allowed to add locally defined provider/repository for allowing usage with closed source providers / not "community-maintained" providers

Change clusterctl to leverage the operator for bootstrap and should be cross provider capable.