From 54e2a3afe64778d3b74c7141c1684d0b0dfdaf86 Mon Sep 17 00:00:00 2001 From: Warren Fernandes Date: Fri, 8 Jan 2021 14:07:14 -0700 Subject: [PATCH] Updating Open Questions section --- .../20201020-capi-provider-operator.md | 38 +++++++++++++------ 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/docs/proposals/20201020-capi-provider-operator.md b/docs/proposals/20201020-capi-provider-operator.md index 04ae353ffdc7..f38316b2b681 100644 --- a/docs/proposals/20201020-capi-provider-operator.md +++ b/docs/proposals/20201020-capi-provider-operator.md @@ -452,21 +452,38 @@ type ProviderStatus struct { **Open Questions** 1. Should the CRDs be global objects or namespaced objects? - A provider lives in a namespace (e.g. capa-system), so it is nice to have - the object namespaced and use metadata.namespace. However, with the new - approach to multitenancy, we should enforce are like singleton (a - provider, identified by Kind & name, should be unique at cluster level) - It will be nice to provide a nice UX around kubectl get + A provider lives in a namespace (e.g. capa-system), so it is nice to have + the object namespaced and use metadata.namespace. However, with the new + approach to multitenancy, we should enforce are like singleton (a + provider, identified by Kind & name, should be unique at cluster level) + It will be nice to provide a nice UX around kubectl get + + _TBD_ + 1. What should the Group/Version for this API be? - Currently, we have it as `management.cluster.x-k8s.io/v1alpha1`. Should - the version be `v1alpha4` to match the CAPI version it is being introduced - in? This would be consistent with what we do for experiments. + Currently, we have it as `management.cluster.x-k8s.io/v1alpha1`. Should + the version be `v1alpha4` to match the CAPI version it is being introduced + in? This would be consistent with what we do for experiments. + + _We can determine this during implementation phase._ + 1. Should we have multiple types (i.e. CoreProvider, BootstrapProvider, ControlPlaneProvider and InfrastructureProvider) vs. a single Provider type? Even though we can use CRD categories to group them, the output may not be as readable as we’d want. + _We will keep the separate types to allow for distinction between the + various providers and follow Kuberentes API conventions._ + +1. Do we need to have the field `SecretName` since the providers are handling + multi-tenancy of workload clusters with multiple credentials? + + _As per discussion in the PR, we will keep the `SecretName` field to allow + the providers ample time to implement their own credential management for + multiple workload clusters. [See this thread for more + info][secret-name-discussion]._ + #### Example API Usage 1. As an admin, I want to install the aws infrastructure provider with @@ -756,10 +773,8 @@ will look like. command will consider image overrides defined in the local clusterctl config file. - If the admin does not want to use clusterctl to install the operator, it is - possible to kubectl apply the operator yaml that will be published in the + possible to `kubectl apply` the operator yaml that will be published in the cluster-api release artifacts. -- There can be only one operator installed per management cluster, across all - namespaces. ##### Operator Upgrade @@ -1071,3 +1086,4 @@ type LeaderElectionConfiguration struct { [issue 3042]: https://github.com/kubernetes-sigs/cluster-api/issues/3042 [issue 3354]: https://github.com/kubernetes-sigs/cluster-api/issues/3354 [issue 3822]: https://github.com/kubernetes-sigs/cluster-api/issues/3822) +[secret name discussion]: https://github.com/kubernetes-sigs/cluster-api/pull/3833#discussion_r540576353