v24.3.1
Improvements
Improvement Number | Improvement Description |
---|---|
PWX-39128 | If the AWS init gets stuck for a long time and prevents Stork from starting up, you can skip the AWS driver init from the Stork imports by adding the environment variable SKIP_AWS_DRIVER_INIT="true" to the stork pod. |
Fixes
Issue Number | Issue Description | Severity |
---|---|---|
PWX-38383 | In certain scenarios, Kubernetes etcd was overloaded, and stork pods went into CrashLoopBackOff state with the following error:Controller manager: failed to wait for snapshot-schedule-controller caches to sync: timed out waiting for cache to be synced .User Impact: Stork failed and restarted multiple times due to the overloading of Kubernetes etcd .Resolution: We've added a --controller-cache-sync-timeout flag, using which you can tweak the value of the cache sync timeout based on your requirements. The default value is 2 minutes.Example: --controller-cache-sync-timeout=10 - sets the controller cache sync timeout as 10 minutes instead of the default 2 minutes.Affected Versions: 24.3.0 and earlier |
Minor |
PWX-36167 | The Stork health monitor was incorrectly considering stale node entries with an offline status for pod eviction. User Impact: If a node was repaired and returned with a different IP address, pods were inadvertently evicted from this online node due to the presence of stale node entries. Resolution: If a node entry with an 'online' storage status shares the same scheduler ID as an 'offline' node entry, the system will disregard the offline node entry when considering pod evictions. This change ensures that pods are not inadvertently evicted from nodes that have been repaired and are now online. Affected Versions: 24.3.0 and earlier |
Minor |