The lineage-controller-webhook now sets a
scheduler.cozystack.io/scheduling-class label on mutated pods (in
addition to the existing annotation of the same name).
This unlocks SchedulingClass authors writing podAffinity rules whose
labelSelector targets pods across different applications that share
the same class. A natural pattern becomes: define a class whose name
is the affinity-group identifier, attach it to several applications,
and have the scheduler co-locate them at the chosen topology key
(region, zone, hostname).
Behavior preserved when the SchedulingClass CR is missing: pods are
left untouched (no scheduler injection, no label) so they do not stay
Pending on a non-existent scheduler.
Tests cover label/annotation/schedulerName injection, existing label
preservation, non-Pod no-op, no-class no-op, and missing-CR no-op.
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
Every admission walks the owner chain (Pod, StatefulSet, HelmRelease,
application CR) with one uncached GET per level, and sibling Pods
repeat the same lookups. On a cluster with many tenants that put the
lineage webhook at 300-500ms p99, the largest share of apiserver
admission latency.
Owners are now reused for 60 seconds, successful lookups only. A failed
lookup, whether RESTMapping, NotFound or a timeout, leaves the walk
without an owner, so the object is admitted with no lineage labels and
stays unlabeled until its next UPDATE runs the walk again. Secrets,
Services and PVCs can go a long time between updates, so a cached
failure would leave every object admitted within the TTL unlabeled for
that long, and the aggregated cozystack-api makes such failures
routine: discovery of apps.cozystack.io fails while it rolls.
Non-Pod objects that already carry every lineage label, tenantresource
included, skip the walk, since the objectSelector still matches an
UPDATE whose old object lacks the label. Pods go through it regardless,
as each Pod admission also sets the scheduling class.
Assisted-by: LLM
Signed-off-by: Mattia Eleuteri <mattia@hidora.io>
With no decoder injected, the webhook decodes the admitted object with
encoding/json, which turns every number into float64, so an int64
above 2^53 comes back rounded. jsonpatch up to v2.4 compared both
sides as float64 and hid this; from v2.5 it compares json.Number, and
the webhook would emit a replace that silently rewrites such a field.
Decode with apimachinery's json, which keeps integers as int64, and
pin that the patch touches only the lineage labels and scheduling.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
mattia-eleuteri