abutcher

> I think the ccoctl output-dir in installation might be long gone when upgrade, so create-service-accounts makes more sense. WDYT? Yes, I hadn't considered the output-dir not being around which...

Looks good to me!

@jianping-shu Does the user need to know the ServiceAccount name / permissions required if processing the CR with ccoctl? I think having the operator install the CR for the user...

Hello @reitzig, I did some digging into the reasoning for the current design and found this comment. https://github.com/openshift/cloud-credential-operator/blob/2c3298b1bb3aca9d7ebcde541b49dcef039e108a/pkg/operator/credentialsrequest/credentialsrequest_controller.go#L140-L143 From the [k8s docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/): "A valid owner reference consists of the object...

One thing we could do is say that the Cloud Credential `ClusterOperator` owns all secrets managed by `CredentialsRequests`, credit to @wking for the idea. For example, the Cluster Version Operator...

I'm not yet sure why we've chosen to put all of the OpenShift component `CredentialsRequest` objects in the `openshift-cloud-credential-operator` namespace during installation. This might be something that we could change...