Controlled upgrade paths

[ghost]

Good morning team!!

Congratulations on a really cool and robust OS upgrade system!!

We would like to know if it is currently supported, in the roadmap or could be requested a more controlled upgrade path process while applying the same upgrade mechanism (orchestrated through the operator) but where the OS updates to a version previously configured instead of to the latest version published or available.

The reason for my request is to be able to honor the requirement of some companies (or teams within those companies) that state that no software component should be deployed in an environment unless confirmed working in the immediate previous lower environment.

Let's picture a company with 3 environments: TEST, STAGE, and PRODUCTION; all of them in sync running OS v1.12.0 with the following upgrade schedules configured:

• TEST should upgrade every 1st day of the month.
• STAGE should upgrade every 8th day of the month.
• PRODUCTION should upgrade every 20th day of the month.

The controlled upgrade path process for the company's ecosystem would look like this:

• Before the 1st of the month, OS v1.13.2 is released.
• On the 1st day of the month, the cluster that belongs to the TEST environment is upgraded to OS v1.13.2.
• Sometime between the 2nd of the month and the 20th of the month, OS v1.13.3 is released.
• Sometime between the 1st of the month and the 7th of the month, the company validates OS v1.13.2 as suitable to continue progressing across environments and sets STAGE to be upgraded to v1.13.2 on its next upgrade session.
• On the 8th day of the month, the cluster that belongs to the STAGE environment is upgraded to OS v1.13.2.
• Sometime between the 8th day of the month and the 19th day of the month, the company validates OS v1.13.2 as suitable to continue progressing across environments and sets PRODUCTION to be upgraded to v1.13.2 on its next upgrade session.
• From the 20th of the month to the 1st of the following month, all environments are in sync.

According to this process, OS v1.13.3 will not be considered during this chain of upgrades until the 1st day of the following month (unless a newer version has been released or published in the meantime).

This intended target version the operator should upgrade all the nodes of a cluster to could be configured as an additional environment variable for the controller

If you think that further clarifications or explanations are needed, we are happy to provide them.