Updating Open Questions section

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 <providers>
+   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 <providers>
+
+    _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