Added RFD 0144 - Client Tools Updates

[russjones]

No description provided.

[r0mant]

lgtm with one question

[codingllama]

Drive-by review. Interesting RFD!

[russjones]

I think there is a issue with the current design.

This RFD essentially proposes forward (and backward compatibility). It outlines how to select the correct binary, but does not outline how to handle schema changes to ~/.tsh. For example, suppose we change the structure of ~/.tsh between Teleport 14 and 15. If you log into a Teleport 14 cluster, then a Teleport 15 cluster, you will no longer be able to log into the Teleport 14 cluster.

I'll update the design to handle this case.

@sclevine This is relevant for you as well, you are going to run into a similar problem with /var/lib/teleport.

[sclevine]

@sclevine This is relevant for you as well, you are going to run into a similar problem with /var/lib/teleport.

Less worried about this for agents, given that it's much less common to switch back and forth between versions. The solution I proposed here blocks the invalid downgrade until someone wipes /var/lib/teleport manually:
https://github.com/gravitational/teleport/pull/40190/files#r1553965583

[russjones]

@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 auto mode removed.

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.

[hugoShaka]

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

[russjones]

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.