Provide a mechanism to prevent updates in certain time window

[srgothi92]

Description

Customers could have workload that cannot be interrupted during some periods of the day. Therefore, a mechanism to prevent Bottlerocket nodes update by the bottlerocket-update-operator in some time window is useful.

Workarounds

1. Since, the Bottlerocket update operator expects Kubernetes label updater-interface-version on nodes for it to start agent DaemonSet. Customer can have an external mechanism to control nodes label updater-interface-version.
2. Lock the version of all Bottlerocket hosts to desired version by setting settings.updates.version-lock (details) and have a mechanism that changes the settings on nodes to latest whenever you would like to update your cluster.

Issue or Feature Request: Feature Request

[srgothi92]

Details about Workaround option 2:

Lock the version of all Bottlerocket hosts to desired version by setting settings.updates.version-lock (details) and have a mechanism that changes the settings on nodes to latest whenever you would like to update your cluster. Detailed steps below:

1. Set updates.version-lock=v0.0.0 ; v0.0.0 is a dummy version number that would never occur and prevent update operator from detecting updates. By setting dummy version we don’t have to worry about getting current OS version and locking on that. (An issue #1500 is open, which requests adding a new label “current”, so dummy version will not be required).

# Change --targets according to the cluster
aws ssm send-command \
    --document-name "AWS-RunShellScript" \
    --comment "Locking bottlerocket version to v0.0.0" \
    --targets Key=tag:<tag-name>,Values=<tag-value> \
    --parameters commands="apiclient set updates.version-lock=v0.0.0"

2. During the maintenance period and when you know new Bottlerocket version is released you can change updates.version-lock=latest

# Change --targets according to the cluster
aws ssm send-command \
    --document-name "AWS-RunShellScript" \
    --comment "Locking bottlerocket version to latest" \
    --targets Key=tag:<tag-name>,Values=<tag-value> \
    --parameters commands="apiclient set updates.version-lock=latest"

Note: There are multiple influencing factors contributing to the amount of time to update the cluster, so it may not finish in your targeted maintenance window.

• We base our update schedule on "waves" that you can read a bit more about here and here. Only nodes landing in particular wave will be updated. You can change settings.updates.seed if you want to fall in a certain wave in the rollout, or set settings.updates.ignore-waves if you always want immediate updates.
• Total time updater takes in updating a single instance and interval configuration here for checking nodes with available updates.

3. Once all the nodes are updated, set updates.version-lock=v0.0.0 back to avoid any future updates.