Suggestion: SLATE client update message

[adamhgriffith-uofu]

Background

We've had a few customers run an old SLATE client against their infrastructure and the API server that resulted in breakage.

• Some of the most recent issues revolved around the ingress manifests cooked into the client code.
• @sthapa modified the client code in a few cases (see Clusters get auto-deleted on update if error occurs #475) to help ameliorate specific issues but an underlying problem remains.

The suggestion

It is highly desired for a SLATE customer to always use the latest and greatest SLATE client when performing actions against the API server.

Many other software clients out there in the world include an update message like gcloud for example:

$ gcloud <some comand>
Updates are available for some Google Cloud CLI components.  To install them,
please run:
  $ gcloud components update

<command output>

Can we do something similar with the slate client? Maybe have it check for updates from https://github.com/slateci/slate-client-server/releases/latest.

and let the customer know they should update before performing any operations?

• If we wanted to get fancy we could allow a customer to hide this message in a new ~/.slate/client.conf file. Something like:

  clientAlertUpdateMessage=false
  

[cnweaver]

I considered this when originally designing the update mechanism, but rejected it, as it would require an extra network round-trip on every program startup/interactive command, and at the time it seemed like the extra delay would be a poor trade-off for the rare case of the client needing to be updated. It also seemed that it would be annoying to the user to see such a message repeatedly if they do not immediately want to drop what they are doing and install an update, but keeping track of the last time a check was performed would require extra config data, etc. (like the proposed client.conf).

In general, it seems to me that it would make more sense to detect actual errors (e.g. ingress manifest does not apply cleanly), and perhaps recommend upgrading if these occur, rather than constantly pester the user about updates which may have no relevance.

[adamhgriffith-uofu]

From today's team meeting, it was decided to leave this up for discussion later down the line, bringing Chris' good points into a future solution.