Improve Eclipse Che deploying with chectl

[tolusha]

Is your enhancement related to a problem? Please describe.

• chectl should be able to deploy Eclipse Che of the same version or any previous one (if possible). To deploy newer versions of Che user have to update chectl first.
• to install previous versions of Eclipse Che, chectl may need to download templates from GitHub.
• to make the process smooth for users, chectl should check for updates automatically, but not update silently.
• If chectl finds out that a newer version is available, a warning message will be printed when a user executes ANY chectl command except deploy and update.
• for the deploy and update commands an interactive prompt will appear and ask users if they want to install a newer version (a flag for non-interactive scenario will be added too).

[skabashnyuk]

@tolusha do we need to maintain somewhere a matrix of compatible chectl and che versions?

[l0rd]

cc @sympatheticmoose

[benoitf]

I was wondering why we don't just pull/cache/execute the binary of chectl matching the one specified by the user ?
as for each tagged version of che we have a corresponding chectl binary.

[mmorhun]

@benoitf thank you for the question. We've considered this method, but decided not to use it because it has some downsides:

• chectl binary is relatively large (33.8 Mb for the latest one)
• the downloaded archive has a lot of small files which makes extracting process time consuming
• taking into account binaries size, we need to implement some cleanup for already downloaded versions
• we need to have superstructure for chectl which will download, unpack and run chectl of needed version

[nickboldt]

Concerns from downstream...

1. Telemetry

• right now the product version of crwctl does not support updating between chectl/crwctl versions; this is intentional because we want end users to download a new version from https://developers.redhat.com/products/codeready-workspaces/download so we can collect metrics around # of downloads per CRW version and OCP version.
• if we make it possible for crwctl 2.7 to install crw 2.9, we lose the ability to collect these numbers

2. Airgap

• For offline/airgapped installs, if chectl/crwctl is now expected to call into GH to fetch newer templates, it'll fail when airgapped.
• Will chectl/crwctl fall back to the embedded templates when no network found?

3. Product restriction / test scenarios

• For crwctl, can we disable this call-home feature and ONLY use what's embedded? It'll be harder to validate install scenarios if we need to worry about 3 or 4x more permutations:
• crwctl 2.7 + CRW 2.7
• crwctl 2.7 + CRW 2.8
• crwctl 2.7 + CRW 2.9
• crwctl 2.8 + CRW 2.8
• crwctl 2.8 + CRW 2.9
• crwctl 2.8 + CRW 2.10
  vs. just
• crwctl 2.7 + CRW 2.7
• crwctl 2.8 + CRW 2.8

[tsmaeder]

so we can collect metrics around # of downloads per CRW version and OCP version.

That is not a valid reason to make chectl more awkward to use, IMO. Chectl can collect metrics, let's use that capability.

[mmorhun]

@nickboldt

if we make it possible for crwctl 2.7 to install crw 2.9, we lose the ability to collect these numbers

My changes doesn't effect downstream behaviour.

For offline/airgapped installs, if chectl/crwctl is now expected to call into GH to fetch newer templates, it'll fail when airgapped.

Only chectl will query GH, crwctl will not.

Will chectl/crwctl fall back to the embedded templates when no network found?

I think we should be able to use embedded templates then (if offline flag is given). Otherwise it doesn't make sense because we need to download docker images, etc.

For crwctl, can we disable this call-home feature and ONLY use what's embedded?

That's how it is implemented: for chectl only. I'd foreseen these problems when was implementing the feature =)

[mmorhun]

After discussion on this issue we agreed that:

• chectl should be able to deploy Eclipse Che of the same version or any previous one (if possible). To deploy newer versions of Che user have to update chectl first.
• to install previous versions of Eclipse Che, chectl may need to download templates from GitHub.
• to make the process smooth for users, chectl should check for updates automatically, but not update silently.
• If chectl finds out that a newer version is available, a warning message will be printed when a user executes ANY chectl command except deploy and update.
• for the deploy and update commands an interactive prompt will appear and ask users if they want to install a newer version (a flag for non-interactive scenario will be added too).

[tsmaeder]

If chectl finds out that a newer version is available

A newer version of Che or chectl?

ANY chectl command except deploy and update

I understand the "update" part, but if you "deploy", shouldn't you be warned you install an old version of Che?

[mmorhun]

A newer version of Che or chectl?

When we do a release we release both: Che and chectl.

shouldn't you be warned you install an old version of Che?

For deploy and update commands it will be interactive prompt. Not just warning, but question which stops execution and waits for user answer. It will not let user install older version unless it is what the user really wants.

[tsmaeder]

A newer version of Che or chectl?

When we do a release we release both: Che and chectl.

Yes, but what are you checking? We might make the release cycles different in the future.

[l0rd]

On Fri, Jan 29, 2021 at 11:48 AM Thomas Mäder ***@***.***> wrote: A newer version of Che or chectl? When we do a release we release both: Che and chectl. Yes, but what are you checking? We might make the release cycles different in the future.

The idea is to force users to update chectl if they want a newer version of Che. We are not testing old versions of chectl against newer versions of che. It's safer to avoid such scenarios and we want to push users to get the latest version of chectl that may contain important bug fixes. That means that a new version of chectl should be released at every release of che.

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18022 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEUF324YMHLENUW624XXSDS4KG6NANCNFSM4SBK23LQ> .

[tsmaeder]

Yes, but what are you checking? We might make the release cycles different in the future.

Aside from the background resoning: technically, are we checking for a new release of Che or of Chectl? These are different artifacts.

[mmorhun]

After the discussion I've changed the strategy and now check only for newer chectl version