-
Notifications
You must be signed in to change notification settings - Fork 349
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
Added upgrade mechanism for managed Jaeger instances #476
Conversation
Codecov Report
@@ Coverage Diff @@
## master #476 +/- ##
==========================================
- Coverage 91.7% 91.53% -0.17%
==========================================
Files 64 65 +1
Lines 3181 3189 +8
==========================================
+ Hits 2917 2919 +2
- Misses 184 188 +4
- Partials 80 82 +2
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #476 +/- ##
==========================================
- Coverage 91.98% 91.56% -0.43%
==========================================
Files 69 73 +4
Lines 3557 3615 +58
==========================================
+ Hits 3272 3310 +38
- Misses 199 213 +14
- Partials 86 92 +6
Continue to review full report at Codecov.
|
@jpkrohling Wanted to check one thing - currently it appears as if the jaeger version can be updated while the operator is running, as the controller checks for upgrading the version when a change is applied? Thought this would only be done when the operator is first started? How would the version be updated for a running instance? |
The usual case will be that the operator will get all the existing Jaeger instances and upgrade them, but there might be some concurrency-related situations (or permission-related cases) where the operator couldn't see an existing Jaeger instance when it first started. The reconcile logic will catch these cases and upgrade the individual instances on demand.
Pretty much all Jaeger instances will be running when the upgrade process starts. Each upgrade can define how the upgrade will work. In some cases, we might need to stop the storage, apply a new schema or data migration, and start the collector again. In other cases, we can just change the deployment to use a newer image and Kubernetes will take care of the rolling update. |
@objectiser : have you had a chance to look into this PR? Do you think this would be appropriate for our planned use cases? |
@jpkrohling Yes I've added a number of comments that you have responded to :) Yes looks a long the right lines for what we need. Not sure should be added for 1.13.x yet though - possibly plan for 1.14? |
7e77335
to
4d5bb41
Compare
The coverage is lacking because it's not easy to simulate client problems with the fake client. |
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
5db6bde
to
f851e08
Compare
This PR is still in draft mode. The purpose for now is to agree on the main assumptions, like versioning and how to apply the upgrades.
Closes #42
Signed-off-by: Juraci Paixão Kröhling [email protected]