serving-operator
serving-operator copied to clipboard
Move serving API
Before we add much more code we should nail down our API. Compiling thoughts on what it should look like here:
- Make our own api version domain (don't use serving.knative.dev). operators.knative.dev?
- Rename KnativeServing type to Serving.
- I think the internal spec is fine to build off, agree?
What about operator.serving.knative.dev? We will probably have operator.eventing.knative.dev in future. Shall we use the template operator.<knative-module-name>.knative.dev?
+1 for what @houshengbo suggested.
being able to differentiate between the different Knative components will be relevant once they are ready for operators.
We struggled with this internally: https://github.com/openshift-knative/knative-serving-operator/issues/17
And as the comments in there suggest, I think it's worth it to consider the effects the name will have on UI's.
Personally, because "operator" is already such an overloaded term, I think calling the custom resource that the operator watches "operator" will be confusing. To me, the word "operator" (like "controller") connotes a running process, rather than a CRD. It would be akin to naming a CRD "controller". :smiling_imp:
I didn't love what we first called it (install
) but that is what the CRD represents: an installation of Knative Serving. I don't particularly love KnativeServing
either, but it did make more sense in the OpenShift web console. Though it was weird because the CRD wants a plural name and dealing with "servings" of knative... kinda made me hungry. :smile:
I don't have a good suggestion -- naming is hard and I already mentioned we struggled -- but I don't think the custom resource itself should be called "operator".