Repository navigation
Commit 366cc54
committed
Verify CP pod existence during startup orphan sweep
When a CP pod is force-deleted (crash, preemption, node drain), the
cp_instances row stays in 'active' state until the janitor expires the
heartbeat (~20s) and the orphan grace period passes (~30s). If the
deployment recreates the CP pod before that, the startup sweep sees the
dead CP as "live" in the DB and leaves its orphaned worker pods alone.
This caused TestK8sCPDeletionGarbageCollects to fail: the test force-
deletes a CP pod and expects its workers to be cleaned up within 90s,
but the startup sweep was deferring to the janitor path which is slower.
The fix: for each "live" CP returned by ListLiveControlPlaneInstanceIDs,
extract the pod name from the instance ID (format "pod-name:boot-id")
and verify the pod actually exists in K8s. If it's gone, treat the CP
as dead for the purpose of the sweep. This is ground truth — the DB
may lag behind K8s, but K8s is authoritative on pod existence.
Self is always skipped (the current CP is explicitly added to the live
set afterward), so this only checks peers.
Also fixes the existing peer-preservation tests to create CP pods for
peers that should be considered alive, now that the code verifies pod
existence.1 parent 8553958 commit 366cc54
2 files changed
Lines changed: 84 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
233 | 233 | | |
234 | 234 | | |
235 | 235 | | |
| 236 | + | |
| 237 | + | |
| 238 | + | |
| 239 | + | |
| 240 | + | |
| 241 | + | |
| 242 | + | |
| 243 | + | |
| 244 | + | |
| 245 | + | |
| 246 | + | |
| 247 | + | |
| 248 | + | |
236 | 249 | | |
237 | 250 | | |
238 | 251 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1958 | 1958 | | |
1959 | 1959 | | |
1960 | 1960 | | |
| 1961 | + | |
| 1962 | + | |
| 1963 | + | |
| 1964 | + | |
| 1965 | + | |
| 1966 | + | |
| 1967 | + | |
| 1968 | + | |
| 1969 | + | |
| 1970 | + | |
| 1971 | + | |
| 1972 | + | |
| 1973 | + | |
| 1974 | + | |
| 1975 | + | |
| 1976 | + | |
| 1977 | + | |
| 1978 | + | |
| 1979 | + | |
| 1980 | + | |
| 1981 | + | |
| 1982 | + | |
| 1983 | + | |
| 1984 | + | |
| 1985 | + | |
| 1986 | + | |
| 1987 | + | |
| 1988 | + | |
| 1989 | + | |
| 1990 | + | |
| 1991 | + | |
| 1992 | + | |
| 1993 | + | |
| 1994 | + | |
| 1995 | + | |
| 1996 | + | |
| 1997 | + | |
| 1998 | + | |
| 1999 | + | |
| 2000 | + | |
| 2001 | + | |
| 2002 | + | |
| 2003 | + | |
| 2004 | + | |
| 2005 | + | |
| 2006 | + | |
| 2007 | + | |
| 2008 | + | |
| 2009 | + | |
| 2010 | + | |
| 2011 | + | |
| 2012 | + | |
| 2013 | + | |
| 2014 | + | |
| 2015 | + | |
1961 | 2016 | | |
1962 | 2017 | | |
1963 | 2018 | | |
| |||
1969 | 2024 | | |
1970 | 2025 | | |
1971 | 2026 | | |
| 2027 | + | |
| 2028 | + | |
| 2029 | + | |
| 2030 | + | |
| 2031 | + | |
1972 | 2032 | | |
1973 | 2033 | | |
1974 | 2034 | | |
| |||
2093 | 2153 | | |
2094 | 2154 | | |
2095 | 2155 | | |
2096 | | - | |
| 2156 | + | |
2097 | 2157 | | |
2098 | 2158 | | |
2099 | 2159 | | |
| 2160 | + | |
| 2161 | + | |
| 2162 | + | |
| 2163 | + | |
| 2164 | + | |
2100 | 2165 | | |
2101 | 2166 | | |
2102 | 2167 | | |
| |||
2143 | 2208 | | |
2144 | 2209 | | |
2145 | 2210 | | |
| 2211 | + | |
| 2212 | + | |
| 2213 | + | |
| 2214 | + | |
| 2215 | + | |
2146 | 2216 | | |
2147 | 2217 | | |
2148 | 2218 | | |
| |||
0 commit comments