Myasnikov Daniil
ed0297eb87
Every package Makefile tagged images via `settag` which, on a non-release commit, collapsed to `:latest`. Concurrent PR builds therefore raced on every image's `:latest` manifest in the OCIR registry. Two outliers (metallb, redis-operator) used hardcoded version tags and collided across PRs even when `settag` would not have. Replace `settag` and the `TAG=latest` fallback with an `image-tags` macro driven by three env vars: - IMAGE_TAG — build-unique tag, always pushed - PUBLISH_VERSIONED — also push :<component-version> - PUBLISH_FLOATING — also push :latest PR CI sets IMAGE_TAG=pr-<N>-<sha> with both PUBLISH_* off, so every push is unique across runs. Release CI sets IMAGE_TAG=<git-tag> with both PUBLISH_* on, preserving the previous release output and adding a uniform :<git-tag> tag across every image. Local builds default to IMAGE_TAG=dev with PUSH=0 already off. Image consumers reference digests pinned into values.yaml by each Makefile, so the tag is decorative for cluster-side pulls; the build-unique tag is sufficient for E2E. Drops the redundant `:<component-version>-<git-tag>` form (cilium, linstor, matchbox, ubuntu-container-disk, kubevirt-*, cluster-autoscaler) — nothing in the repo or downstream values.yaml consumed it. The same information is preserved via the new uniform `:<git-tag>` plus the existing `:<component-version>` on release. ubuntu-container-disk builds a separate image per Kubernetes version in a loop. Switched its primary tag to `:<k8s-ver>-<IMAGE_TAG>` so loop iterations within a single build do not push to the same tag. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
lineage-controller-webhook
Cozystack system package for the lineage controller webhook — a mutating
admission webhook that stamps "lineage" labels onto tenant workloads, linking
each resource back to the Cozystack Application that ultimately owns it.
The webhook intercepts CREATE and UPDATE on pods, secrets, services,
persistentvolumeclaims, ingresses.networking.k8s.io, and
workloadmonitors.cozystack.io outside system namespaces. For each request it
walks the ownership graph upward (Kubernetes ownerReferences, then the
HelmRelease Flux installed the resource with, then the Cozystack
Application-derived CRD that produced the HelmRelease) and writes the
discovered application's group, kind and name as labels
(apps.cozystack.io/application.{group,kind,name}) on the incoming object.
Those labels let the aggregated API server, the Cozystack dashboard, and other
lineage-aware consumers reason about which application a resource belongs to.
The webhook serves TLS on port 9443 with a cert-manager issued certificate, and
runs with failurePolicy: Fail — every CREATE/UPDATE on the resources above
is gated on the webhook being reachable.
Topology
The chart ships a single shape, modelled on cozystack-api:
- Deployment with two replicas (override via
replicas). - Soft
nodeAffinitypreferringnode-role.kubernetes.io/control-plane(Exists, so it matches both Talos's empty value and k3s/kubeadm's"true"). Soft means: the pod lands on a control-plane node when one is reachable, and on any worker otherwise — no override needed for managed Kubernetes, Cozy-in-Cozy tenants, or any other cluster where control-plane nodes aren't visible. - Permissive
tolerations([{operator: Exists}]) so the pod can land on tainted control-plane nodes when the soft affinity is satisfiable. - Soft
podAntiAffinityonkubernetes.io/hostnameso replicas spread across nodes when possible (best-effort). PodDisruptionBudgetwithmaxUnavailable: 1, unconditional. Atreplicas: 1it's a useful no-op (allows full drain); atreplicas >= 2it caps disruption to one pod.Servicewithspec.trafficDistribution: PreferCloseso the apiserver prefers a webhook endpoint on its own node when one exists, and transparently falls over to a remote endpoint otherwise. Requires Kubernetes ≥ 1.31; on older clusters the field is silently ignored and traffic uses default cluster-wide distribution.
Parameters
All keys live under the top-level lineageControllerWebhook: map.
| Name | Description | Value |
|---|---|---|
image |
Container image (digest-pinned) | ghcr.io/cozystack/cozystack/lineage-controller-webhook:v1.3.0@sha256:e898…6fb0 |
debug |
Enable --zap-log-level=debug instead of info |
false |
replicas |
Deployment replica count | 2 |
localK8sAPIEndpoint.enabled |
Deprecated. See note below. | false |
localK8sAPIEndpoint.enabled (deprecated)
When enabled, this injects KUBERNETES_SERVICE_HOST=status.hostIP and
KUBERNETES_SERVICE_PORT=6443 so the webhook talks to the kube-apiserver on
its own node. It was originally added to avoid latency on the
webhook-to-apiserver path, but it is only valid when the pod is actually
scheduled on an apiserver-bearing node — which the chart's soft control-plane
affinity no longer guarantees. With this flag enabled and the pod scheduled
off a control-plane node, the controller will crash-loop dialing a non-
apiserver hostIP. Slated for removal once the latency motivation is addressed
in the webhook itself; leave disabled.