-
-
Couldn't load subscription status.
- Fork 912
Feature: Auto-update client #4256
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
base: main
Are you sure you want to change the base?
Conversation
76b9397 to
9d44077
Compare
|
@lixmal All comments should be resolved, will need to conduct another round of testing however, so will keep the PR as Draft until testing is complete |
03eb50e to
d15b3e5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR introduces an auto-update client feature that allows the management server to control client version updates. The feature enables administrators to specify a target version for clients, which can be "latest", "disabled", or a specific semantic version.
- Added AutoUpdateVersion field to account settings with validation for "latest", "disabled", or semantic version format
- Implemented platform-specific update mechanisms for Windows, macOS, Linux, and FreeBSD
- Added update manager that monitors version changes and triggers updates when client version is older than target
Reviewed Changes
Copilot reviewed 19 out of 19 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| version/update.go | Made LatestAvailable field public for external access |
| management/server/types/settings.go | Added AutoUpdateVersion field to Settings struct |
| management/server/token_mgr.go | Added AutoUpdateVersion to TURN/relay token updates |
| management/server/peer.go | Added AutoUpdateVersion to peer deletion updates |
| management/server/http/handlers/accounts/ | Added API handlers and validation for AutoUpdateVersion |
| management/server/http/api/ | Added AutoUpdateVersion to API types and OpenAPI spec |
| management/server/grpcserver.go | Added AutoUpdateVersion to sync response |
| management/server/activity/codes.go | Added activity tracking for AutoUpdateVersion updates |
| management/server/account.go | Added handling for AutoUpdateVersion setting changes |
| management/proto/management.proto | Added autoUpdateVersion field to SyncResponse |
| client/internal/updatemanager/ | Implemented platform-specific update mechanisms |
| client/internal/engine.go | Integrated update manager with sync response handling |
d15b3e5 to
5ba5b40
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you put any thoughts into how we could do a rollback if the new version breaks connectivity?
Based on my discussions with @mlsmaycon , the upgrade mechanism is forward-moving only |
|
@lixmal If it's alright with you, I will mark the PR as no documentation needed for the time being as the dashboard changes are not yet done, as soon as dashboard can modify the auto upgrade version I will open a PR in docs |
Co-authored-by: Bethuel Mmbaga <[email protected]>
…rsion-networkmap Move autoUpdateVersion inside NetworkMap
|
Hey, Just wondering when is this expected to be released in production ? Best, |
|
Hi Team, Do we have an expected date for this release? Thanks |
|
Do we have an expected date for this release? |
|
Very much looking forward to this feature. Thanks for the good work. |
| u.cancel() | ||
| if u.update != nil { | ||
| u.update.StopWatch() | ||
| u.update = nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You set u.update = nil in Stop() while updateLoop or handleUpdate could still try to access it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only referenced inside handleUpdate once inside a mutex, so I used this to prevent a race and also added a check so that if u.update is nil it should return
| return false | ||
| } | ||
|
|
||
| if time.Since(u.lastTrigger) < 5*time.Minute { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure but we can miss a potential upgrade if we just ignore. What is the goal with this condition?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is so it doesn't spam retrying to upgrade with any trigger since each failure will show an error to the user, so this is just a way to backoff failures
Modify client-side behavior
- fix development version handling - add log lines
|



Describe your changes
Issue ticket number and link
Stack
Checklist