Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jaeger Operator manifest points to unreleased versions #580

Open
iblancasa opened this issue Jun 7, 2022 · 5 comments
Open

Jaeger Operator manifest points to unreleased versions #580

iblancasa opened this issue Jun 7, 2022 · 5 comments
Labels

Comments

@iblancasa
Copy link

Describe the bug
The Jaeger Operator documentation points to the manifest file to install it in a Kubernetes cluster. When a new Jaeger release is done, the documentation points to the manifest associated with the Jaeger version. This is a problem because that Jaeger Operator file will not exists until a new release of the Jaeger Operator is done.

For instance, latest Jaeger release is 1.35 and latest Jaeger Operator is version is 1.34.1. The Jaeger documentation points to https://github.com/jaegertracing/jaeger-operator/releases/download/v1.35.0/jaeger-operator.yaml but that file doesn't exist yet.

@frzifus
Copy link
Member

frzifus commented Jun 7, 2022

What would you suggest as a solution @iblancasa? Maybe an info that if the file does not exist, probably no version has been released yet and a link to the github release page?

@iblancasa
Copy link
Author

Well, something like that could be a good idea.

@yurishkuro
Copy link
Member

I think we have options:

  1. Make the operator release the official step in the Jaeger release, so that documentation release is the last step that guarantees all versioned links are valid. I haven't been involved in the operator releases, so not sure how complex the release workflow.
  2. Change the operator to not depend on the exact Jaeger version. I don't really understand why the deployment infra need to change every time we release a new Jaeger version, although I realized that sometimes it needs to be validated. Perhaps there is a process we can create here (or maybe it will be the same as option 1).
  3. Make the docs more dynamic. Our current mechanism are all build-time, i.e. if docs version is released without the corresponding operator version, and then operator version is published, the docs need to be manually rebuilt.

@pavolloffay
Copy link
Member

The answer depends on how quality Jaeger ecosystem offers to the users.

Coordinating the release across the components probably provides the best user experience, however in this case (release 1.35.0) the Jaeger release would have to wait until the operator adds support for the OTLP (this is why the operator 1.35.0 hasn't been released yet).

I would vote on decoupling the operator and jaeger releases given It is a community project. I see it as a good thing and it allows to maintain the velocity of individual components.

@SaarthakMaini
Copy link
Contributor

I think the Operator should be changed to not depend on the exact Jaeger version. Is this issue still open?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants