Summary: | Network operator changes ovnkube-config too early causing ovnkube-master pods to crashloop during cluster upgrade | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | OpenShift BugZilla Robot <openshift-bugzilla-robot> |
Component: | Networking | Assignee: | Christoph Stäbler <cstabler> |
Networking sub component: | ovn-kubernetes | QA Contact: | Anurag saxena <anusaxen> |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | high | ||
Priority: | medium | CC: | anbhat, astoycos, bpickard, memodi, ngirard, surya, zzhao |
Version: | 4.6 | ||
Target Milestone: | --- | ||
Target Release: | 4.8.z | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Cause: ovnkube-node & -master pods fail to start, when the config file contains an unknown field or section.
Consequence: Can lead to failures on ovn-kubernetes updates, if a new config field or section was introduced. Imagine the following scenario:
1. ConfigMap is updated
2. ovnkube-node rollout starts
3. somehow an ovnkube-master pod needs to be (re-)started (be it through eviction from a node or something else)
4. the newly started ovnkube-master pod isn't aware of the new config structure (as it is still on the old version) and fails to parse the config, resulting in a crashloop of the newly ovnkube-master. This can result in a stucking rollout.
Fix: Make ovn-kube resilient for unknown field in config files and logs a warning instead of exiting if such a field was found.
Result: ovn-kube updates do not fail if config file contains an unknown field or section.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2022-01-05 16:11:42 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Bug Depends On: | 2027983 | ||
Bug Blocks: | 2034506 |
Comment 6
errata-xmlrpc
2022-01-05 16:11:42 UTC
|