Create initial operator from openshift/tektoncd-operator about operator HOT 13 CLOSED

@vincent-pli It is hard for me now to demonstrate which technology is preferable and prevail in future. One thing I think is good for an open source project is that it has lower barrier for existing and new developers.
For folks, who have been working in Tekton(even knative), they have known the existing structure, it will be easy for them to contribute here without hassle, looking at the code, understanding the code, etc. For new contributors in the community, they have to learn the packages and structures anyhow in pipeline. It really help them transition to work with operators without adopting a new model.

from operator.

FYI, I have started work on moving https://github.com/openshift/tektoncd-pipeline-operator to this repo

from operator.

@sthaha @vdemeester @vincent-pli
I am helping knative/serving-operator with refactoring the source code, so that we use the pkg/controller model as the backbone of the source code, instead of operator-sdk, in order to keep the architecture consistent with knative project.
I see tekton inherits the structure of knative. What is our plan regarding the structure of the operator source code?

FYI: knative/serving-operator#83.
Another thing I suggest is to port what we have under openshift here in the tekton repo, so that other people can join the force.

from operator.

@houshengbo
I saw that pr, great work.
So the reason to adopt pkg/controller is only keeping consistent with Knative, besides that is there any extra benefit?

from operator.

@houshengbo you raise a salient point about lowering the barrier to entry but some of the advantages that operator-sdk provides us is

• ability to locally standup the operator
• ability to run tests locally
• to easily upgrade between versions of operator-sdk (e.g: moving from dep to go.mod 0.7 -> 0.9 was easy)
• Ability to generate all olm releated artifacts (csv especially)

So by moving to pkg/controller what are the trade-off or is it a win-win?

from operator.

@sthaha As I said, I am unable to argue which technology is better than the other, but what you listed can also be covered by knative pkg/controller.

• Ability to standup the operator: like in knative/serving-operator, we are able to launch the operator locally already.
• Ability to run test locally: we need to conform the structure the same way as any other knative. After implementing release.sh under hack folder, we are able to run integration, unit, build, etc, locally, or in the prow jobs.
• Upgrade: I do not see pkg/controller cannot do upgrade.
• Ability to generate: we use k8s.io/code-generator to generate deepcopy,client,informer,lister under pkg/client, and use knative.dev/pkg to generate the injection code.

Again, it is not a beauty contest between pkg/controller and operator-sdk. It is about how to create the Tekton ecosystem with consistency and compatibility.

Trade-off: short-term there is a pain, because we need to dedicate some manpower working on that for sure, but for long-term, it will pay back, since a consistent code structure will easily attract more developers doing other tekton projects.

from operator.

Trade-off: short-term there is a pain, because we need to dedicate some manpower working on that for sure, but for long-term, it will pay back, since a consistent code structure will easily attract more developers doing other tekton projects.

I completely agree with that 👼 😅

from operator.

Trade-off: short-term there is a pain, because we need to dedicate some manpower working on that for sure, but for long-term, it will pay back, since a consistent code structure will easily attract more developers doing other tekton projects.

@sthaha As I said, I am unable to argue which technology is better than the other, but what you listed can also be covered by knative pkg/controller.

• Ability to standup the operator: like in knative/serving-operator, we are able to launch the operator locally already.
• Ability to run test locally: we need to conform the structure the same way as any other knative. After implementing release.sh under hack folder, we are able to run integration, unit, build, etc, locally, or in the prow jobs.
• Upgrade: I do not see pkg/controller cannot do upgrade.
• Ability to generate: we use k8s.io/code-generator to generate deepcopy,client,informer,lister under pkg/client, and use knative.dev/pkg to generate the injection code.

neat! and I guess we still can make use of operator-sdk to generate CSV and not have to fiddle around with yaml by hand

Again, it is not a beauty contest between pkg/controller and operator-sdk. It is about how to create the Tekton ecosystem with consistency and compatibility.

:) like I said, I am not attached at an api. I guess the point of my question was to ensure that we at the very least think about what we are gaining versus losing and not just adopt pkg/controller blindly
for the sake of consistency

Trade-off: short-term there is a pain, because we need to dedicate some manpower working on that for sure, but for long-term, it will pay back, since a consistent code structure will easily attract more developers doing other tekton projects.

And I hope it is a one time cost 🤞

from operator.

@houshengbo as a developer new to knative and tektoncd I have to say that not using the well documented kubebuilder in favour of the undocumented knative way of creating controllers makes the barrier significantly higher. I may have missed something but at this stage in my learn process I feel that the argument may be reverted.

from operator.

@fgiloux No matter what we choose for operator, operator-sdk, kubebuilder, knative/pkg, etc, it does not ease down any barrier for u to join the community.

"In favour of the undocumented knative way", as you said, other knative and tekton projects, have already become like that. If you join this community, we have to overcome that barrier ANYWAY. After that, there is no big "hurdle" ANY MORE, if you continue to work in the operator, as long as we apply knative/pkg(coz you have to get familiar with knative/pkg to join knative/tekton projects. No one can change this situation, unless we dump all the projects and restart them all with new packages).

Otherwise, you need to pick up new framework, e.g. operator-sdk, under a different env from other knative/tekton projects. Isn't it ANOTHER HURDLE(after you or other new developers have already conquered knative/pkg)? :-)

I am currently working in knative serving operator too. After crossing the barrier of knative/pkg, I can refer to other projects for writing any reconciling function, creating all the clients to access the kube or knative resources, adding e2e integration tests, building and releasing the image, etc.(These are what I have done or am doing now.) At least, this is what I can list as a benefit. If we use other framework, we probably need to start from scratch, or even think of how to start.

Again. This is not a beauty contest, but how to work within a community in a consistent way.

from operator.

@houshengbo please don't get agitated about this X vs Y argument, it doesn't help us with the cause.

In case you aren't aware, use of CAPS is akin to shouting and we all can be civil and don't have to intimidate to get our points across.

@fgiloux makes a point which is objectively true i.e. kubebuilder is better documented than knative/pkg but that can be addressed by improving the documentation of knative/pkg package, asking for feedback as to what can be improved ... after all what are we all arguing about ? The best way to make HTTP requests?

In case of operators (olm, market-place) the tooling provided by the operator-sdk (binary) is quite important: olm-catalog operator-sdk up local, so we can switch to using a different go (client`) pkg as long as the binary can be used to bring the operator up locally and to run tests.

from operator.

@houshengbo thanks for your input. I have started looking at knative code.
@sthaha thanks for reinforcing the point on documentation. I will leave it here as I don't want to divert this issue from its original intent.
Other things worth considering when choosing the tools to use:

• where is the K8 community moving to: kubebuilder is backed by the SIG API machinery and the Operator SDK has received positive feedbacks.
• where is the best place to have these tools being worked on (larger community) so that they can evolve without having the burden bared by a single (or a few) consumer project.

from operator.

I am closing this since initial version has been merged. Re: #2 (comment) lets track that in a new issue.

from operator.