UX: consider renaming "cloud" param to something else
rsdcastro opened this issue · 9 comments
Users select a "cloud" to determine which provider/actuator to use, but some (like Loodse's) can target multiple providers under the covers (like Digital Ocean, AWS). And in their case (see #405), the parameter in the provider specific config is "cloud". This issue is to track renaming the top-level param to select the provider/actuator to something else more general.
Excellent point. Perhaps we could call it something more coughmundanecough familiar like "module".
I like module. Pasted this issue on Slack looking for other ideas as well.
What about just provider?
I think "provider" could be conflated with a single cloud provider. For example we could have a terraformModule (or s/Module/something) that deploys to multiple "providers".
Would there ever be a need to provide another type of module interface? If so module wouldn't module be too generic?
If we ever added support for additional infrastructure components other than individual machines, would they be separate modules or part of a larger module? If separate modules, then I would think we would want to be more specific with the naming like 'machine-provider'. Otherwise, I think 'provider' is good. The name/type/description of provider should clear up any confusion of it being a single/multiple cloud provider.
I'm imagining a multi-cloud module here. If someone were to implement a terraformModule (bear with me on module here), then terraform already has a concept of providers - which they mean a singular cloud provider.
But, it is easy enough to confuse terraformProvider (that belongs to cluster API), and terraform providers (that hook up into terraform).
If we ever added support for additional infrastructure components other than individual machines, would they be separate modules or part of a larger module?
Like what? We already have machine sets, but I doubt we want to expose anything else in the cluster API. Provider-specific infrastructure would be abstracted away in their own implementations (like say IP addresses).
If we ever added support for additional infrastructure components other than individual machines, would they be separate modules or part of a larger module?
Like what? We already have machine sets, but I doubt we want to expose anything else in the cluster API. Provider-specific infrastructure would be abstracted away in their own implementations (like say IP addresses).
I'm just thinking of other types of automated infrastructure, such as DNS, Virtual Networking, Load Balancers, etc
I'm just thinking of other types of automated infrastructure, such as DNS, Virtual Networking, Load Balancers, etc
Interesting. I'm not sure if the API would need to care about those resources.
I'll cc @kubernetes/sig-cluster-lifecycle-misc for further discussion / decision.
This issue was moved to kubernetes-sigs/cluster-api#48