> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt. # 0060 — Development seeds for Waldur and GitLab Status: Proposed. The commands, seed formats and safeguards are in [DD-0060](/reference/docs/dd/0060-development-seeds.md). Date: 22 October 2026. GitLab seed revisited on 4 November 2026, once Source Control made the Project groups (decision 5). ## Context A dev box installs Waldur and GitLab with their administrators and AAI clients ([0041](/reference/docs/decisions/0041-gitlab-waldur-services.md)), and the LLM access offering. It has no Projects, members, orders, groups or repositories, so a developer who works on a Project, an order, a site agent or Git access first builds that state by hand. The retained Themelio seeded it with Ansible roles (`seed-initial-admin-data`, `waldur-llm-access-local-seed`): - they ran Python inside `waldur shell` and created a staff user with a stored password; - they pre-created AAI users through the identity bridge; - they mirrored repositories from `gitlab.grnet.gr` with a developer's personal token, writing through the retained GitLab root actor. Code that uses a provider's internal models breaks on upgrades: the Icarus-hpc laboratory bootstrap needed changes for Waldur 8.1.3 ([DD-0055](/reference/docs/dd/0055-hpc-ssh-key-provisioning.md)). Project authority is moving to Beto's Project governance, and the Project provisioning epic's GitLab worker will create one group per Project at a path derived from the Waldur Project UUID. Neither has landed. Until then, Waldur is where development Projects live, and GitLab has nothing for a developer to clone. Since then Source Control, that worker, makes each Project's group at `pharos-projects/` with one subgroup per repository kind, from the Projects Beto takes from Waldur, and keeps their members. The retained Themelio reads repositories only there (#995). Source Control creates no repositories, and a group outside that root is not shown in Themelio. ## Decision 1. **Two commands, two declarative files.** - `make waldur-seed` applies `dx/common/waldur-seed.yaml`: Projects of the installation's customer, their members by role, and orders on existing offerings. - `make gitlab-seed` applies `dx/common/gitlab-seed.yaml`: repositories in the groups Source Control made for the seeded Projects, each with a small sample of ordinary Git files and Git LFS files. It runs after `make seed`. - `SEED=` applies another file. - Both create only what is missing and never change or remove anything, so they are safe to repeat. - They are development commands; a production installation gets this state from its own owners. 2. **Public APIs only.** - Waldur is seeded through its REST API at 8.1.3, the version dev boxes pin; a test checks every request body against that version's schema. - GitLab is seeded through its REST API and the Git LFS batch API, the interfaces a Git client uses. - Neither seed reads or writes a provider's internal models, so the upgrade risk is the public API's. 3. **A credential that lives for one run, inside the provider's container.** - Waldur: the seed's own staff user, `pharos-seed`, receives a fifteen-minute token that is minted, used and revoked inside one `kubectl exec` in the Waldur API container. - GitLab: one Rails runner in the toolbox creates a one-day `api` token for `root`, runs the seed with it and revokes it when the seed ends. GitLab issues no token for a password through its API; Rails is used for this step only. - The tokens never reach an argument, log, workstation or other pod. No stored administrator password or token is used. 4. **Members are local AAI test users who signed in.** Waldur creates an account at a user's first AAI sign-in. When a member has none, the Waldur seed changes nothing, signs that member in once through the local AAI and applies the seed again. It never creates or links provider accounts itself. The GitLab seed names no members: a Project's members reach its GitLab groups through Source Control. 5. **The GitLab seed only adds repositories to Project groups.** Groups and their membership belong to Source Control, which removes a member added by hand. The seed finds a Project's group by the name Source Control gives it, ` ()`, creates a repository in a kind subgroup as a member would through Themelio, and changes nothing while a Project's groups are missing. 6. **Out of scope:** - repository mirroring from `gitlab.grnet.gr`; - offerings, which are registered by their own charts; - anything for staging or production. ## Consequences - A dev box reaches a working Project state and a cloneable Git/LFS repository in one command each, and developers can share seed files. - A changed Waldur API fails the seed's schema test when the pin changes. A changed GitLab API fails the GitLab seed on a dev box. - Each GitLab run waits for one Rails start in the toolbox, about one to two minutes. - When Beto owns Project creation, the Waldur seed must create Projects through Beto or be retired. If Source Control gains a command that creates repositories, the GitLab seed should use it rather than GitLab's API. - The GitLab seed depends on the name Source Control gives a Project group; a change to that name must change the seed. - Only test users from `devops/aai/users.json` can be members.
Page source Source snapshot · Revision `f928834c8`.