Change tektonVersion to a command flag so that user can choose the tekton verision about operator HOT 12 CLOSED

@zhangtbj
You can use

args:
- --resource-dir=deploy/resources/v0.7.0

to achieve this, it's more flexible than just version, could handle the case that user want to use arbitrary version.

from operator.

Thanks @vincent-pli !

So is this arg resource-dir works for upgrade?

For example I installed the tekton version v0.7.0 by using operator with - --resource-dir=deploy/resources/v0.7.0. Then I would like to upgrade the version to v0.8.0.
What should I do next?

Restart the operator and reset the parameter to - --resource-dir=deploy/resources/v0.8.0 ?

from operator.

I'm afraid it's not work, you need do the uninstall and re-install :)

from operator.

em.... :(

I am still not clear about the upgrade path.

Hope you can have some doc to show how to do it in future.

Anyway, thanks a lot @vincent-pli :)

from operator.

Hi @vincent-pli ,

I re-opened this issue again.

Right now, the config cr only has one spec parameter TargetNamespace:
https://github.com/tektoncd/operator/blob/master/pkg/apis/operator/v1alpha1/config_types.go#L11

I am not sure why you want to use the operator execution parameter to set the release version.

But only set the release version in the CRD spec definition.

I think if you add a new config CRD spec definition parameter like TargetReleaseVersion, it is better for end user to modify or find it or maybe upgrade in future.

operator command parameter is not a good way I think ....

from operator.

hum, yes, it's make sense in upgrade scenario.
Seems we have not consider too much for the upgrade.
/cc @vdemeester @sthaha @nikhil-thomas @houshengbo

from operator.

We should discuss this in more detail in the WG meeting.

IMHO, --version or --resourcedir is useful only in dev environments and not in production where the expectation is that the operator is installed through OLM (operatorhub.io) (sidenote: we need to ship this operator to operatorhub.io 🙏)

So in the case where user installs pipeline through operator, the k8s way to install a different version would be to make use of cluster (CR) config.operator.tekton.dev and add field to it say: version: "0.7.0" but this presents its own challenges as often the controller code makes assumptions about the default version of the pipeline being installed and we might be able to solve this by delegating the "configuration" part to an object specific to the version of the pipeline installed but before we go that path, we should try the mechanism that OLM already provides

OLM (operatorhub.io) provides a way to upgrade (manual/auto) an operator and our experience writing the operator for OpenShift is that using the mechanism to upgrade the operator works without any hassles and imho we should rely on just that and not on config.tekton.dev or --version as a way to install different versions of pipeline. OLM support the upgrade path seamlessly, to provide an upgrade all we have to do is to provide the CSV to the community operators repo.

from operator.

Thanks all!

Please document somewhere that other people can know and review this requirement design.

Thanks a lot!

from operator.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

from operator.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

from operator.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

from operator.

@tekton-robot: Closing this issue.

from operator.