jaegertracing / jaeger-operator

Jaeger Operator for Kubernetes simplifies deploying and running Jaeger on Kubernetes.
https://www.jaegertracing.io/docs/latest/operator/
Apache License 2.0
1.01k stars 342 forks source link

Older versions of the operator and associated resources are inaccessible via links with version numbers #1010

Open mate-szalai opened 4 years ago

mate-szalai commented 4 years ago

The documentation suggests that links that include version numbers can be used to install a specific version of the operator and its associated resources.

For example, the documentation here uses links such as https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.17.0/deploy/crds/jaegertracing.io_jaegers_crd.yaml and https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.17.0/deploy/operator.yaml.

We were using https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.16.0/deploy/operator.yaml and https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.16.0/deploy/crds/jaegertracing.io_jaegers_crd.yaml to pin the operator version to 1.16.0 in our deployment but we received a stealth update to v1.17.0. This broke our deployment because we were reliant on the operator monitoring all namespaces for Jaeger-related events which is no longer the default behavior starting with the v1.17.0 release.

We fixed the issue by creating local copies of all the required manifests, however, it would be a welcomed enhancement if these versioned links behaved as expected.

The issue is not specific to the v1.16.0 links. As of 04/08/20, all of the following links point to v1.17.0 of the CRD and the operator deployment:

The ServiceAccount, Role, and RoleBinding links behave the same way as well.

For reference, we would expect v1.16.0 to point to version of these resources at this commit: https://github.com/jaegertracing/jaeger-operator/commit/90b4053280fb230f99da4a6be5b40091d754ae43

pavolloffay commented 4 years ago

It seems like a bug in our release procedure.

For instance PR https://github.com/jaegertracing/jaeger-operator/pull/928 was merged to master and the commit got also to 1.16.0 branch https://github.com/jaegertracing/jaeger-operator/commits/v1.16.0.

pavolloffay commented 4 years ago

This line looks suspicious https://github.com/jaegertracing/jaeger-operator/blob/master/.ci/release.sh#L72 maybe it is pushing to all branches

objectiser commented 4 years ago

Don't you mean https://github.com/jaegertracing/jaeger-operator/blob/master/.ci/release.sh#L73 - looks like it is mapping the version tag to master?

pavolloffay commented 4 years ago

One of those seems to be causing the problem.

objectiser commented 4 years ago

Looks like it has been in since the beginning: https://github.com/jaegertracing/jaeger-operator/commit/c5c97aea0b151b328816013b723610a90654ddc6#diff-0ade8a06d51b947d7705c1a9ae1bab59

The tags push has been in since the initial comment: https://github.com/jaegertracing/jaeger-operator/commit/dd0cd3b537268e0fe7a670eb6edd63493735cf29#diff-0ade8a06d51b947d7705c1a9ae1bab59

We should fix before next release - but need to decode whether to update the current tags? What the implications may be (if any).

jpkrohling commented 4 years ago

Line 72 is about pushing local tags to the remote repository. It should only be pushing the new tag. Line 73 is pushing the commits from the new local tag to master.

I see that 1.18.0 has been released recently, and it's not pushed to the 1.16 tag. Was this issue fixed, or was the release performed using a different script?