Refactor oak::enable for per-component template variables

Jason Plumrequested to merge
jp/oak-enable-generic-refactor into master

What does this MR do?

Stack 1 of 6. Targets master.

The oak::enable recipe hardcoded OpenBao's nginx and Helm template variables inline, which the OAK component integration guide flags as a known gap: adding a second component meant growing two inline blocks rather than adding a branch.

This extracts the two variable sets into oak_nginx_variables and oak_helm_variables lambdas keyed on the component name. OpenBao remains the only component, so this is a pure refactor with no behaviour change.

Lambdas rather than methods, because a def inside a recipe pollutes the enclosing scope and the values are only needed by the resources below it.

Why this exists as its own MR

It is the first of six stacked MRs that add GitLab Artifact Registry as an OAK component. Separating "move the code" from "add the component" keeps the two MRs that follow it substantially smaller and reviewable on their own terms.

Note

This work is deliberately early. It runs well ahead of Artifact Registry's own deliverable timelines. It is raised primarily to exercise OAK enablement itself — to find out what a second advanced component actually costs in the OAK cookbook — with Artifact Registry as the consumer that provides a concrete target. It is not required by any current Artifact Registry milestone.

Related issues

Related to #10053

Checklist

See Definition of done.

Required

  • MR title and description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • Latest Merge Result pipeline is green.
  • When ready for review, MR is labeled workflowready for review per the Distribution MR workflow. Currently workflowin dev.
  • The UBT version and corresponding checksum hash have been updated and referenced in the merge request if applicable. — n/a, no component versions change.

Expected

  • Test plan indicating conditions for success has been posted and passes. — the pre-existing OAK specs pass unmodified, which is the intended evidence that behaviour is unchanged.
  • Documentation created/updated. — n/a, no user-facing change.
  • Tests added. — n/a; existing coverage is the assertion.
  • Integration tests added to GitLab QA. — n/a.
  • Equivalent MR/issue for the GitLab Chart opened. — n/a, no chart-visible change.
  • Validate potential values for new configuration settings. — n/a, no new settings.

Merge request reports