Added RFD 0144 - Client Tools Updates#39805
Conversation
russjones
added
the
no-changelog
|
|
||
| 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 |
* Added RFD 0144 - Client Tools Updates * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Fix. * Client tools RFD update (gravitational#45515) * Add changes proposed for client autoupdate * Add proxy flag and CDN info * Naming adjustments * Naming adjustments * Update client tools autoupdate RFD (gravitational#47498) * Drop watch command for autoupdate * Add modified tctl commands and `find` endpoint response * Add words to spell checker --------- Co-authored-by: Vadym Popov <vadym.popov@goteleport.com>
10 participants
No description provided.