Parameterized Argo app template in mmli2 #15

Activity

1. matthewberry

   added

   enhancementNew feature or requestNew feature or request

   on Oct 19, 2026
2. matthewberry commented on Oct 20, 2026

   

   matthewberry

   on Oct 20, 2026

   ContributorAuthor

   More actions

   Implementation is on mmli2 (GitLab) branch feat/alpha-frontends (03c8784), as two commits:

   1. feat: the generated Applications, the test staging canary, and the CORS check plus a render check in CI;
   2. fix: the crispr-copies/mutagenesis staging CORS origins (iBioFoundry/mutagenesis-frontend#10).

   The MR is being opened on GitLab. Design decisions (2026-10-20): CORS entries stay hand-edited, with a CI check rather than generated (generation deferred). Deploys use a scoped manual kubectl rollout restart until #24.
3. matthewberry commented on Oct 20, 2026

   

   matthewberry

   on Oct 20, 2026

   ContributorAuthor

   More actions

   Review of mmli2 feat/alpha-frontends at 03c8784. It's based on current main (c51a7a2). Nothing blocks the test canary.

   Findings

   1. Sign-in for alphasynbio apps on prod is broken, and passing the CORS check doesn't catch it. (Reproduced live.) This is outside the diff, but it affects the check's claim that a correct origin list means sign-in works. Every app's prod config signs in at auth.platform.moleculemaker.org (frontend-template AUTH.prod). That oauth2-proxy runs with --whitelist-domain=.platform.moleculemaker.org and --cookie-domain=.platform.moleculemaker.org.

      • GET https://auth.platform.moleculemaker.org/oauth2/start?rd=https://mutagenesis.platform.ibiofoundry.illinois.edu/configuration returns a state ending in :/. The redirect target was dropped, so after login the user lands on the proxy's own / instead of back on the app. With rd set to the ezspecificity origin, the full URL is kept.
      • The session cookie is set for Domain=platform.moleculemaker.org with no SameSite attribute. A userinfo request with credentials from *.platform.ibiofoundry.illinois.edu is cross-site, so the browser probably won't send it. I didn't test this in a browser.

      This applies to mutagenesis prod today, not only to template apps. It doesn't affect alphasynthesis apps, or any staging app (staging is all under .mmli2.ncsa.illinois.edu). Possible fixes: an iBioFoundry auth host under the family's own domain, or add the domain to whitelist-domain and set SameSite=None. Either way, the family can't simply be swapped for the other one until this is fixed.

   2. Moving an existing app into alphaFrontends while its hand-written template is still enabled renders two Applications with the same name, and apps_render passes. (Reproduced with alpine/helm:3.16.4.) Adding {id: ezspecificity, family: alphasynthesis, prod: main, staging: main} renders mmli2-ezspecificity-frontend and -staging twice each. helm template doesn't detect duplicates. I didn't check which copy Argo applies. The migrations you're planning (ezspecificity, mutagenesis) are exactly how this would happen. A step in apps_render that fails on a duplicate metadata.name would catch it, for example helm template … | grep '^ name:' | sort | uniq -d, then fail if anything prints.

   3. Low: a revision that isn't a string renders as something wrong, with no error. (Reproduced.)

      • prod: true renders targetRevision: "true".
      • An unquoted prod: 1.10 renders as "1.1", because YAML reads it as a float.

      false, a missing key and "" are all skipped correctly. Failing unless the revision is a string, or false, would rule out both.

   4. Note: automated sync can't be turned off. Every other app template here wraps automated: in {{ if .sync }}. Here it's always on, and with selfHeal: true any kubectl hotfix during an incident gets reverted. That may be intended ("so the cluster can't drift"). If so, it's worth one line in the values comment saying how to pause an app (for example, disable auto-sync in the Argo UI).

   Checked

   • Template errors. An unknown family and a missing url both fail with the template's own messages. A missing family or id also fails, though with a less clear error (wrong type for value, or a YAML parse error).
   • Your questions:
     • Prune scope. With prune: true, Argo only deletes resources this Application tracks. The frontend chart names everything after .Release.Name (<id>-frontend[-staging]), plus <id>-prod-domain-redirect on prod only. So two apps can't collide in the shared staging namespace. I didn't check the cluster for existing resources named test-frontend-staging, or Argo's tracking method.
     • values.ibiofoundry.prod.yaml doesn't need checking. frontend-template's AUTH has exactly two hosts: mmli2.ncsa.illinois.edu, served by values.staging.yaml, and auth.platform.moleculemaker.org, served by values.prod.yaml. Nothing generated from it calls auth.icloudbiofoundry.illinois.edu.
   • The staging backend is covered by this change. The backend's staging ingress uses staging-cors-header, which is the cors-header Middleware this chart's values.staging.yaml deploys in the staging namespace. A live preflight from https://test.frontend.staging… currently gets no Access-Control-Allow-Origin, while ezspecificity's origin does. That's expected until this merges.
   • The staging CORS fix. crispr-copies.frontend.staging… and mutagenesis.frontend.staging… both return 200 live. The old frontend.<tool>.staging… names don't.

   Didn't investigate: the parent apps Application's own prune setting. With no resources finalizer on these Applications, removing an entry would leave its workloads running rather than delete them. I didn't check that against the cluster.
4. matthewberry commented on Oct 20, 2026

   

   matthewberry

   on Oct 20, 2026

   ContributorAuthor

   More actions

   Re the review of feat/alpha-frontends (issuecomment-6281794974). Each item was reproduced first; fixes are in mmli2 35d64da.

   1. AlphaSynBio prod sign-in: reproduced. For rd=https://mutagenesis.platform.ibiofoundry.illinois.edu/... the OAuth state is ':/', while ezspecificity's keeps its full URL. Neither prod proxy's whitelist or cookie domain covers *.platform.ibiofoundry.illinois.edu. It's outside this diff and an infra decision, so it's filed as iBioFoundry/mutagenesis-frontend#12, including the app:sync change it implies. It doesn't block EZKinetics (alphasynthesis) or this canary.
   2. Duplicate Application names: apps_render now fails listing them. An ezspecificity entry beside its enabled hand-written template now fails with Duplicate Application names: mmli2-ezspecificity-frontend.
   3. Revisions: true and non-string values (the unquoted 1.10 → 1.1 case) now fail with a message. A quoted "1.10" renders as-is.
   4. Automated sync can't be turned off: that's intentional. The point of these Applications is that they can't drift from git. If one ever needs it off, the right move is a deliberate template change.

   Thanks also for confirming that prune is scoped to each Application's own resources, and that the staging CORS entry covers the backend's staging ingress too.