consider separating single CRD into respective 'types' as different 'kind's

[aegershman]

Currently quarks-secret is implemented as a single CRD kind: QuarksSecret, and to control the type of credential which gets generated you specify type in the spec, e.g. password, ssh, etc. : https://github.com/cloudfoundry-incubator/quarks-secret/blob/81bcfbc9ed04ec19c76738e34b63eec9bb1031af/docs/crds/quarks_v1alpha1_quarkssecret_crd.yaml#L44-L47

You may consider separating this CRD down from a single kind of QuarksSecret into respective credential types, e.g. kind: Password, kind: Certificate, etc.; this would offer some benefits:

• flexibility to individually version the respective types, so new features to one type don't require affecting the version of other credential types.
• if there was interest in introducing new credential types or a new CRD which describes functions on other CRDs (like kind: Password; kind: PasswordRotation; kind: PasswordCopy, etc.), even experimentally, it could be done with a bit more comfort separately as a different kind than having the different credential types in one CRD described as a type
• it could allow more flexibility in describing the view output of a crd, like if there was future interest in outputting the kubectl describe of a Certificate in a different way as a Password, etc., for example having flexibility to output a description of "expiry" for a Certificate vs. Password
• for operators to be able to query for the respective types when performing kubectl get and such; e.g., if an operator wanted to view all the Certificates types in a namespace vs. a Password, rather than kubectl get quarkssecret and having it describe all types
• flexibility in the future if there are other controllers/operators which would be interested in being notified on events happening on certain credential types, e.g. a Password is created/updated/etc. and receiving status updates from kubernetes about it, but not being interested in an Rsa being created; if the different types are under the same kind, I'm under the impression it makes it harder for other systems/controller/operators to specifically work with that type, because at the moment it'd need to work on the QuarksSecret kind and parse the spec.type. I know it's hypothetical, it's just something to consider that might affect whether other systems would use quarkssecret outside the context of cffork8s?

I don't mean to laundry-list or be negative or anything-- quarkssecret is being used in kubecf (https://github.com/cloudfoundry-incubator/kubecf/blob/20cd23b967eb04924fc16817ab4e50befe34ab52/deploy/helm/kubecf/templates/eirini.yaml#L9) and all; I'm just sharing some thoughts for consideration while the project is early in case there was concern or interest in evaluation on it. but again, not trying to yammer on, just putting it out there

thanks all for your time 👍

[manno]

Hey, thanks for the feedback.

I see the point about filtering, that might be usefule. However I'm afraid of the complexity more kinds will add, generating versionedclients for all of them, test setup, controller watches, different structs ...

We discussed that earlier in a meeting and the common sentiment was that Kubernetes is also using rather huge 'kinds'. Looking at the output of 'kubectl api-resources', I think that's true. There is one Volume kind, but many types of volumes. Or services, they don't even have a type, they just behave very different, depending on their spec.

I think 'filtering' can be fixed, if https://github.com/kubernetes/kubernetes/issues/53459 is implemented.

[aegershman]

right on, thanks again for your time - apologies for not responding back earlier 👍 closing for tidyness