the feature
drop Initializing and split it into Pending and Progressing.
today Initializing is one bucket for two different truths :

our own catalog shows the miss :
# core-pod-v1 : a pod stuck unschedulable is "Initializing"
initializing:
- byPhase: Pending
# leaderworkerset : a condition literally NAMED Progressing becomes "Initializing"
initializing:
- byConditions:
- type: Progressing
a user watching a workload "Initializing" for two hours cannot tell if it is stuck ( no quota , unschedulable - go act ) or starting normally ( pulling images , scaling - just wait ). the status exists to answer exactly that question , and it doesnt.
the proposal
Pending waiting , nothing runs yet ( unscheduled , quota , queue )
Progressing actively moving to running ( pods creating , pulling , scaling )
the ecosystem already made this split - we would align with all of it :
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase
- pod phase
Pending - scheduled nowhere yet , exactly the waiting truth
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#deployment-status
- deployment condition
Progressing - actively rolling out , exactly the moving truth
https://argo-cd.readthedocs.io/en/stable/operator-manual/health/
- argo health
Progressing - the word every gitops user already reads for "starting normally"
related : #228 ( lws reports Running while workers are still Pending ) - the coarse bucket is part of why that mapping went wrong.
what changes
ResourceStatus enum : Initializing out , Pending + Progressing in
statusMappings in definitions : initializing: becomes pending: and progressing: keys
- every catalog definition re-sorts its initializing matchers into the right bucket ( the lws one literally moves
type: Progressing under progressing: )
heads up , this is a breaking change to a public enum and to every existing definition - needs a deprecation window where initializing: still parses ( mapped to Progressing ) with a warning. wdyt ?
the feature
drop
Initializingand split it intoPendingandProgressing.today
Initializingis one bucket for two different truths :our own catalog shows the miss :
a user watching a workload "Initializing" for two hours cannot tell if it is stuck ( no quota , unschedulable - go act ) or starting normally ( pulling images , scaling - just wait ). the status exists to answer exactly that question , and it doesnt.
the proposal
the ecosystem already made this split - we would align with all of it :
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase
Pending- scheduled nowhere yet , exactly the waiting truthhttps://kubernetes.io/docs/concepts/workloads/controllers/deployment/#deployment-status
Progressing- actively rolling out , exactly the moving truthhttps://argo-cd.readthedocs.io/en/stable/operator-manual/health/
Progressing- the word every gitops user already reads for "starting normally"related : #228 ( lws reports Running while workers are still Pending ) - the coarse bucket is part of why that mapping went wrong.
what changes
ResourceStatusenum :Initializingout ,Pending+ProgressinginstatusMappingsin definitions :initializing:becomespending:andprogressing:keystype: Progressingunderprogressing:)heads up , this is a breaking change to a public enum and to every existing definition - needs a deprecation window where
initializing:still parses ( mapped toProgressing) with a warning. wdyt ?