Mark provider name optional for Custom providers, and remove for predefined

[Danil-Grigorev]

The CAPIProvider since v0.8.0 no longer requires spec.name to be specified at all times. In case when it is not set, it uses metadata.name, so this field can be marked as optional.

It makes sense to specify spec.name only if the kind of provider is unknown. For existing set of providers like Docker, AWS, etc., the default one for the applied resource coming from UI code is enough.

Why

This will remove ambiguity. Users may supply a name for docker provider like aws and install aws provider under docker label.

[eva-vashkevich]

Hi @Danil-Grigorev, the "Name" field from your screenshot sets metadata.name field. We only allow user to provide spec.name when creating Custom provider ('Provider' field). Are you suggesting we should not be asking the user to provide metadata.name and supply the name ourselves instead?

[Danil-Grigorev]

I’m not aware of the internals that much to tell that metadata.name is set or the spec.name is. I’m suggesting that for known provider types, which are known in the UI tiles it should not be possible to supply a name at all. The UI always knows it in advance. Example: docker is always docker, aws is always aws. If you call aws as my-aws, it is still the same aws provider, and on top of that there shall not allow creation of duplicate providers in the cluster (read: creating duplicate CAPIProvider with the same spec.type)

[eva-vashkevich]

Hi @kwwii, what do you think?

[kwwii]

1. If you can only create one of each type of infrastructure provider, how does one enter different credentials for different accounts?
   a) Assuming that there CAN be multiple, how would a user select the correct infrastructure provider later in the UI?

[kwwii]

Currently, the backend allows the creation of multiple providers of a given type. Is this expected to change?

[kwwii]

Given that we currently allow for more than one provider of a given type, we cannot remove the name field as we need it to differentiate between providers of the same type in the provider list.

[Danil-Grigorev]

We’ve discussed the issue on the call. The conclusion is that we can’t have multiple providers of the same type due to cluster-api-operator limitation (thanks @alexander-demicev for pointing this out). The reason being that this may lead to clashing cluster-scoped objects, like CRDs whenever there more then one provider of this type is installed. More context on this: kubernetes-sigs/cluster-api#9875 (comment) Since the CAPI operator uses clusterctl libraries, this limitation extends on the project too.

@kwwii pointed out that this limitation may have larger impact on UI and credentials handling mechanism and it requires additional changes.