feat(r2): deploy, federate and test OOP on k3s
flowchart LR
VM["plain Ubuntu VMs"] -- "install pinned k3s server/agents" --> K
EX["existing cluster"] -- "left intact" --> K["k3s per operator"]
K -- "helm upgrade when chart content changes" --> O["OOP chart per operator"]
O -- "partner credentials on stdin to FM internal API" --> R["partners registered"]
R -- "seed agreements: skip same, edit changed in place" --> A["agreements"]
A -- "create federation" --> F["federated"]
F -- "pytest e2e" --> T["22 passed, 1 xfailed, 84 s"]Tested topology:
flowchart LR
subgraph OP1["OP-1 Barcelona"]
S1["test-op1-1: k3s server"] --- A1["test-op1-2: k3s agent"]
end
subgraph OP2["OP-2 Paris"]
S2["test-op2: single node"]
end
subgraph OP3["OP-3 Athens"]
S3["test-op3: single node"]
end
OP1 <-- "EWBI federation" --> OP2
OP1 <-- "EWBI federation" --> OP3Provide a repeatable Release 2 workflow for existing clusters and plain Ubuntu VMs: install pinned k3s servers/agents when needed, deploy the Helm chart per operator, register partners and seed agreements, establish federation, then run the e2e suite.
Keep existing clusters intact, resolve remote kubeconfig paths on the remote host, trigger Helm upgrades when chart contents change, and retain encryption keys. The k3s uninstall path requires its explicit confirmation flag and distinguishes agent/server uninstall. Partner credentials travel through stdin to FM's internal API rather than public HTTP. Agreement seeding resolves local zone names, skips matching terms, and edits a changed agreement in place with PATCH, since FM keeps one agreement per partner; inventory-managed terms can overwrite portal edits on a later run.
Validation: tested across three operator clusters on four VMs (one server+agent cluster and two single-node clusters). Final Ansible e2e run: 22 passed, 1 xfailed in 84.36 seconds, with no failed hosts. Prior runs checked repeatability and agreement unchanged results. The separate browser run covered portal agreement handling and local/partner deploy, retrieval and deletion.
Depends on Helm !15's refactor/helm-2.0 chart and the component changes in the release plan. The VM inventory and combined image overlays are local test artifacts, not published release images. The remaining ownership xfail came from the older deployed OEG base; OEG !38 already merged that fix. Rebuild the final integrated images and retest it, removing the strict xfail when it passes.
All bootstrap and test changes remain in one MR because they implement one deploy-to-validation workflow.
What each playbook sets up, the inventory variables and the secrets: r2_existing_cluster/README.md.