podiumd 4.8.4 - PABC seed job en basis dingen (IN-2004)

[githubjimmeicatt]

wat er al was

commit 94b07fc (van 4.8.0, zat niet in 4.8.4): pabc-dataset-configmap.yaml +
files/pabc-dataset.json. alleen het e2e-zaaktype, overal
isAllEntityTypes: false, en geen job die de configmap inlas.

wat ik heb toegevoegd

• templates/pabc-seed-job.yaml: de ontbrekende job, draait pabc-migrations
  eenmalig met JSON_DATASET_PATH
• 21 mappings met isAllEntityTypes: true in de dataset, per keycloak-groep
  gelijk aan de zac-clientrollen uit het realm-config
• pabc.seedJob in values, default uit
• docs/apps/pabc/pabc-iam-migration.md en enabling-pabc.md bijgewerkt

zonder dit blijft pabc leeg en blokkeert zac elke pagina met "u heeft geen
toestemming". getest op ontw-mayk: rev 189 deployed, 41 mappings, zac-login werkt.

[infojohn]

Looks good

[infojohn]

One correctness concern on pabc-seed-job.yaml's idempotency design:

The Job's name (and therefore the boundary of what Kubernetes treats as immutable) is derived only from a hash of files/pabc-dataset.json:

{{- $jobSuffix := .Files.Get "files/pabc-dataset.json" | sha256sum | trunc 10 }}

But the Job's actual pod spec also depends on pabc.migrations.image (repository/tag/pullPolicy), pabc.seedJob.resources, and any nodeSelector — none of which factor into that name.

Concretely: if pabc.migrations.image.tag gets bumped in a later release (a routine image update) while the dataset itself stays byte-identical, the Job keeps the same name, but its pod template now differs from what's already deployed. spec.template on a batch/v1 Job is immutable, so the next helm upgrade will fail trying to patch it in place (field is immutable) — not a no-op, an actual failed release.

Might be worth hashing the fully-rendered pod spec (or at least including the image tag) into $jobSuffix, so an image bump forces a genuinely new Job name instead of colliding with the old one.