You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An automated OS update was triggered from a version 1.3 classified as supported to a 2.1 version classified as deprecated with a very short expiration time.
What you expected to happen:
OS image versions shall never be updated from a version classified as "supported" to a version classified as "deprecated".
How to reproduce it (as minimally and precisely as possible):
Assume you have the following setup:
2.1 preview
2.0 preview
1.3 supported
Now add a 2.2 version and deprecate the 2.0 and 2.1 versions.
2.2 preview
2.1 deprecated (with expiration date in 2 weeks time)
2.0 deprecated (with expiration date in 2 weeks time)
1.3 supported
As a result, 1.3 (supported) will be updated to 2.1 (deprecated) when automatic OS updated are enabled for the shoot cluster.
Anything else we need to know?:
While this behaviour appears awkward there is room for interpretation. According to https://github.com/gardener/gardener/blob/master/docs/usage/shoot_versions.md this may well be the desired behaviour. In this case I would consider it a design issue. There is a reason why an image is set to deprecated and (automatic updates) shall never update to a deprecated version.
This said, there is one exception: if the current version is about to expire it would be ok to update it to a newer deprecated version according to the update strategy.
Environment:
Gardener version: any up-to-date version
Kubernetes version (use kubectl version): n/a
Cloud provider or hardware configuration: n/a
Others:
The text was updated successfully, but these errors were encountered:
How to categorize this issue?
/area os
/kind bug
What happened:
An automated OS update was triggered from a version 1.3 classified as supported to a 2.1 version classified as deprecated with a very short expiration time.
What you expected to happen:
OS image versions shall never be updated from a version classified as "supported" to a version classified as "deprecated".
How to reproduce it (as minimally and precisely as possible):
Assume you have the following setup:
Now add a 2.2 version and deprecate the 2.0 and 2.1 versions.
As a result, 1.3 (supported) will be updated to 2.1 (deprecated) when automatic OS updated are enabled for the shoot cluster.
Anything else we need to know?:
While this behaviour appears awkward there is room for interpretation. According to https://github.com/gardener/gardener/blob/master/docs/usage/shoot_versions.md this may well be the desired behaviour. In this case I would consider it a design issue. There is a reason why an image is set to deprecated and (automatic updates) shall never update to a deprecated version.
This said, there is one exception: if the current version is about to expire it would be ok to update it to a newer deprecated version according to the update strategy.
Environment:
kubectl version
): n/aThe text was updated successfully, but these errors were encountered: