Skip to content

[v16] Fix major version check for stateless environment#54640

Closed
vapopov wants to merge 1 commit intobranch/v16from
vapopov/major-version-check-v16
Closed

[v16] Fix major version check for stateless environment#54640
vapopov wants to merge 1 commit intobranch/v16from
vapopov/major-version-check-v16

Conversation

@vapopov
Copy link
Copy Markdown
Contributor

@vapopov vapopov commented May 8, 2025

Backport #52837 to branch/v16

Changelog: Fixed major version check for stateless environment

* Added auth information resource with persisting teleport version

* Check the set of the auth info to compare with min/max versions in cluster

* Store only one entity for the cluster version

* Add CRUD endpoints
Change to use conditional update and retry
Fix spelling

* Add validation for version, sub kind, kind, name

* Rename to authinfo.go

* Assigning error after creating new resource

* Move retry logic to version check helper

* Call create/update depends on if resource is created already
Read local database once without retry

* Restrict major version downgrade

* Make `--skip-version-check` available for major upgrade check

* Fix linter warnings

* Add logs and make skip more safe in case of broke item in backend

* Remove deleting version item from process database, stateBackend doesn't support deletion (requires implementation for kube secrets storage)

* Rename AuthInfo to BackendInfo
Add cleanup of the version item from process storage after successful migration

* Make skip-version-check to upsert the version in backend

* Update lib/auth/version.go

Co-authored-by: Edoardo Spadolini <edoardo.spadolini@goteleport.com>

---------

Co-authored-by: Edoardo Spadolini <edoardo.spadolini@goteleport.com>
@hugoShaka
Copy link
Copy Markdown
Contributor

How will this change interact when updating to versions that don't have it?

e.g. we run the latest v16, we update to v17.1.0, then to the latest v17

@vapopov
Copy link
Copy Markdown
Contributor Author

vapopov commented May 9, 2025

@hugoShaka good point

cluster with persisting local database:

  • latest v16 [including this change]: we migrate last known version from local sqlite -> backend, and delete it from local sqlite
  • earlier v17 [doesn't have this change]: can't find any version persisted in local sqlite, persists current version to local db v17.1.0
  • latest v17 [including this change]: ignores last known version from local sqlite, reads v16 from backend and updates to latest v17, but if this is v18 we should get an error message from major version check

@hugoShaka
Copy link
Copy Markdown
Contributor

hugoShaka commented May 10, 2025

On one hand that's one unlikely update path (latest v16 -> early v17 -> v18), on the other this would break our version compatibility guarantees. I would lean toward not backporting to v16 and v15 (this would not protect users properly anyway if they are updating to a version that doesn't have this change).

@vapopov vapopov closed this May 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants