d72355d297
Why I did it When sonic is managed by k8s, the sonic container is managed by k8s daemonset, daemonset identifies its members by labels. Currently when restarting a sonic service by systemctl, if the service's container is already managed by k8s, systemd script stops the container by removing the feature label to make it disjoin from k8s daemonset, and then starts it by adding the label to make it join k8s daemonset again. This behavior would cause problem during k8s container upgrade. Containers in daemonset are upgraded in a rolling fashion, that means the daemonset version is updated first, then rollout the new version to containers with precheck/postcheck one by one. However, if a sonic device joins a daemonset, k8s will directly deploy a pod with the current version of daemonset, it is expected when a device joins k8s cluster at first time. But for a device which has already joined k8s cluster, the re-joining daemonset will cause the container upgraded to new version without precheck, so if a systemd service is restarted during daemonset upgrade, the container may be upgraded without precheck and break rolling update policy. To fix it, we need to remove the logic about dropping k8s label in systemd service stop script for kube mode. Work item tracking Microsoft ADO (number only): 24304563 How I did it Don't drop label in systemd service stop script when feature's set_owner is kube. Only drop label when feature's set_owner is local. How to verify it The label feature_enabled should be always true if the feature's set owner is kube. |
||
|---|---|---|
| .. | ||
| ctrmgr | ||
| tests | ||
| .gitignore | ||
| pytest.ini | ||
| README.rst | ||
| setup.cfg | ||
| setup.py | ||
" This Package contains modules required for remote container management. "