Added RFD 0144 - Client Tools Updates #39805
Conversation
russjones
added
the
no-changelog
|
@sclevine @bernardjkim @r0mant @tigrato @hugoShaka I've pushed an update to reduce scope and focus on our primary use-case: Cloud. Instead of maintaining multiple versions of client tools per-cluster, a single version of client tools will be maintained. For Cloud customers this should have no impact as most have a single cluster and even those with multiple clusters will be on the same version. For self-hosted clusters, by default this feature will be turned off with I think this will be a much simpler implementation. We can come back around to supporting multiple versions (and self-hosted use case) in the future. |
|
|
||
| Inspiration drawn from https://go.dev/doc/toolchain. | ||
|
|
||
| ### Implementation |
There was a problem hiding this comment.
Could we build some kind of observability around this and use this as a success criteria?
- for the Teleport admins, so they know which tools versions their users have. For example recording the teleport client version on login, and when an update happens. (with prometheus metric)
- for cloud operations, so we know what's the tenant state and can send the apropriate communications/do the right maintenances (with prometheus metrics as well)
- for product decision so we can measure the tool update adoption for customers with dial-home (with the existing posthog analytics):
- report the versions of teleport tools
- report if automatic tool update is enabled
- report the OS distribution (mac/windows/linux, and which major version)
- report if the version is automatic, or pinned
There was a problem hiding this comment.
Yes, definitely planning on adding observability. I'll update the RFD a bit later in development on exact metrics, but all of the above sound reasonable.
We'll have to do something to avoid duplicates and preserve anonymity, we can follow a similar approach to what we do for product metrics.
* Add changes proposed for client autoupdate * Add proxy flag and CDN info
| All archive downloads are targeted to the `cdn.teleport.dev` endpoint and depend | ||
| on the operating system, platform, and edition. Where edition must be identified | ||
| by the original client tools binary, URL pattern: | ||
| `https://cdn.teleport.dev/teleport-{, ent-}v15.3.0-{linux, darwin, windows}-{amd64,arm64,arm,386}-{fips-}bin.tar.gz` |
There was a problem hiding this comment.
In the implementation PRs, did you take into account the fact that dev tag builds along with release candidates, alphas, and betas are served from a different domain? This has been a problem for Connect My Computer and other components:
There was a problem hiding this comment.
I'll create issue for this one, as far as I understand for first version we going to support stable versions only
| The original client tools binaries won't be overwritten. Instead, an additional | ||
| binary will be downloaded and stored in `~/.tsh/bin` with `0755` permissions. |
There was a problem hiding this comment.
Does that mean we don't have to worry about auto-update overriding the bundled version of tsh that has been symlinked by Teleport Connect?
Say I install Connect v16 on macOS and symlink the bundled tsh to PATH. I then upgrade my cluster to v17. When I log in with the symlinked tsh outside of Connect, it's going to download tsh v17, place it in ~/.tsh/bin and reexecute the command. But then when Connect calls tsh again with TELEPORT_TOOLS_VERSION=off, it's just going to use the v16 version, do I understand this correctly?
There was a problem hiding this comment.
@ravicious yes, TELEPORT_TOOLS_VERSION=off disables re-execution and update
|
I am going to merge the RFD if there are no objections |
No description provided.