kudobuilder
Cleanup Internal Structures
What would you like to be added:
Between framework -> operator and bundle -> packages refactoring we have structures which are challenging for anyone new to the project to reasonable about. For instances we have 2 Operator structs.
https://github.com/kudobuilder/kudo/blob/master/pkg/kudoctl/packages/package.go#L48
https://github.com/kudobuilder/kudo/blob/master/pkg/apis/kudo/v1alpha1/operator_types.go#L51
one is used to create CRD.. the other is used to read in operator configuration from package files.
Why is this needed: provided in description
recommendation: lets name the CRD objects by it's proper name "Operator" for example and the thing in the operator tarball an OperatorConfig, or OperatorDef(inition)
hmm I am not that concerned about those being same, do they actually clash somewhere? I mean as long as they are in a different namespaces then you should never have two operator structs imported as Operator, right? it will always be packages.Operator and Operator or v1alpha1.Operator and Operator
But I don't know that code that work with both from the top of my head so would have to see examples :)
I see differing opinions on this in the Go wilds between naming of domain model name and raw API name (if they're separate packages, which is often true in k8s land). I think expanding the comments of both of these is a great start and we could determine if the packages.Operator is actually what we mean by that, wdyt @kensipe? On the flipside, I think changing v1alpha1.Operator is probably not the right decision since it breaks Kubernetes Go package naming convention, but I'm all for making it a lot more clear.
Since this ticket was created we refactored the packages types to be:
packages.OperatorFile
packages.ParamsFile
while the server-side API types are:
v1beta1.Operator
v1beta1.Instance
...
@kensipe do you think this is sufficient for the purposes of this issue?
