feat(tenants): opt-in nachtelijke demo-reset per tenant

[rubenvdlinde]

Wat

Een openbare demo-tenant vult zich met wat bezoekers maken. Nieuwe opt-in
component tenant.components.demoReset zet zo'n tenant elke nacht terug naar
een gouden momentopname en laadt daarna de voorbeeldsets opnieuw. Aanleiding:
de demogemeente Zuiddrecht (zuiddrecht-prod).

Nieuwe lokale chart charts/tenant-demo-reset en een aparte ApplicationSet
nextcloud-tenant-demo-reset met een post-selector op
tenant.components.demoReset.enabled. Zelfde afweging als
nextcloud-tenant-routes: geen vierde source in nextcloud-tenants, dus de
bestaande tenant-Applications veranderen niet.

De chart levert een ServiceAccount met alleen pods get/list en pods/exec,
het script als ConfigMap, een nachtelijke CronJob en een CronJob
demo-reset-golden die een mens afvuurt. Alles loopt via kubectl exec in de
bestaande pods. De momentopname is een template-database in de eigen Postgres
plus een kopie van de datamap op dezelfde PVC.

Veiligheid: confirmWipe moet de tenantnaam herhalen (validator, chart en
script). De reset stopt voordat er iets gewist is bij een S3 primary
objectstore, een andere instanceid, of een database en map van verschillende
momenten. Faalt hij daarna, dan blijft de onderhoudsmodus aan. Redis wordt
alleen voor deze instantie geleegd (occ memcache:distributed:clear).

Validator: vijftien nieuwe cases. Nieuwe suite
nextcloud-platform/tests/run-demo-reset-tests.sh, gedraaid door
scripts/verify.sh. Docs: docs/DEMO-RESET.md.

Openstaand: de ApplicationSet komt pas na een handmatige sync van
nextcloud-platform-bootstrap. Het image alpine/k8s:1.29.2 is op tag
gepind, niet op digest. Nooit op een cluster gedraaid.

Gecontroleerd

Lokaal: scripts/verify.sh, nextcloud-platform/tests/run-tests.sh en pre-commit run --all-files --hook-stage pre-push geven exit 0. Alle 89 bestaande tenants renderen byte-identiek (values en manifests). Niet gedraaid: niets tegen een cluster.

Opt-in per tenant; platformwijziging, dus mergen ma tot do na 17:00 en daarna nextcloud-platform-bootstrap syncen. Eerste gebruiker: tenant zuiddrecht-prod (#145).

🤖 Generated with Claude Code

[rubenvdlinde]

Wat

Eén commit bovenop #147 (feat/tenant-demo-reset): de nachtelijke reset kan na de voorbeeldsets apps beperken tot medewerkers. Nieuw optioneel blok tenant.components.demoReset.limitApps:

tenant:
  components:
    demoReset:
      limitApps:
        apps: [dashboard, contacts, calendar, deck, mail, launchpad, dossiq, pipelinq, decidiq, shillinq, filinq, stackiq, buildiq, keepiq, hermiq, versioniq]
        exceptGroups: [inwoners]

Na occ openregister:example-set:install zet de reset elke app uit apps aan voor alle groepen behalve exceptGroups (occ app:enable --groups=<g> ... <app>), per app apart. Een app die Nextcloud niet tot groepen laat beperken, gaat aan voor iedereen met een WARN in de log. Een app die niet geïnstalleerd is, wordt overgeslagen.

Aanleiding: in de generale repetitie van Zuiddrecht zag een vers inwoners-account 17 apps in de navigatie en opende /apps/dossiq/ met 200. Het repetitiescript 15-staff-only-apps.sh loste dat met de hand op; dit is dezelfde stap, generiek en per tenant te configureren. Hij moet ná de sets draaien, want de voorbeeldset maakt de groepen van medewerkers aan, en hij moet elke nacht opnieuw, want de install-hook zet een app bij een pin-bump uit en weer aan, en dan vervalt een groepsbeperking.

Veiligheid

occ loopt in de Nextcloud-container als sh -c-string. Daarom:

• validator en script accepteren alleen app-ids (^[a-z][a-z0-9_]{0,63}$) en groeps-ids (^[A-Za-z0-9._@-]{1,64}$);
• een groep uit occ group:list met een andere naam stopt de stap met een fout, in plaats van hem door te geven;
• apps zonder exceptGroups weigert de validator, en het script stopt dan vóór de eerste kubectl-aanroep: zonder uitzondering beperkt de stap niets;
• blijft er geen groep over, dan faalt de Job zichtbaar. De tenant staat dan al op de momentopname en blijft in de lucht.

Ook in deze commit

De openregister-check van #147 in validate-values.sh (yq ... | grep -qx) gaf onder set -o pipefail af en toe een fout op een geldig bestand: grep -q stopt na de eerste match, yq krijgt SIGPIPE en de pipeline faalt. Eén van de nieuwe fixtures liep er bij de eerste run tegenaan; los gedraaid zes keer groen. Nu grep -x ... >/dev/null, dat de invoer helemaal leest.

Gedraaid

Commando	Exit
nextcloud-platform/scripts/validate-values.sh	0
nextcloud-platform/tests/run-tests.sh (6 nieuwe fixtures voor limitApps)	0 (41 geslaagd)
nextcloud-platform/tests/run-demo-reset-tests.sh (chart-env, appset-values en 5 nieuwe scriptcases)	0 (32 geslaagd)
scripts/verify.sh	0
pre-commit run --all-files --hook-stage pre-push	0
shellcheck op demo-reset.sh, validate-values.sh, run-demo-reset-tests.sh	0
mutatie: aanroep van limit_apps_to_groups uitgezet	3 scriptcases falen, zoals bedoeld

Niet gedraaid: niets tegen een cluster. Een tenant zonder limitApps krijgt geen nieuwe env vars in de CronJob; geen tenant op main gebruikt de demo-reset.

Te beslissen

• Basis. Deze branch is feat(tenants): opt-in nachtelijke demo-reset per tenant #147 plus één commit. Ofwel deze commit in feat(tenants): opt-in nachtelijke demo-reset per tenant #147 opnemen, ofwel een eigen PR na feat(tenants): opt-in nachtelijke demo-reset per tenant #147.
• Het tenantbestand. zuiddrecht-prod krijgt het blok components.demoReset (met limitApps) pas in een tenant-PR na de merge van feat(tenants): opt-in nachtelijke demo-reset per tenant #147; vóór die merge leest niets het blok.
• Welke apps. De lijst hierboven is die uit het repetitiescript. Dat script zegt zelf dat in de volgende repetitie nagekeken moet worden of de portaalstromen van een inwoner (Woo-verzoek, dossier, machtiging, raadspagina, taken) nog werken met deze apps beperkt.

Platformwijziging (nieuwe ApplicationSet en chart via #147), label change/platform, mergen ma tot do na 17:00 en daarna nextcloud-platform-bootstrap syncen.

🤖 Generated with Claude Code