[lbagic]

A partner can register its customer's cluster in that customer's own DevZero team: the module takes a team_id, such as a devzero_team's id. Left unset, everything plans as it does today.

Merge only once devzero-inc/devzero 0.3.0 is on the Terraform Registry: the provider floor moves to it, so terraform init on main fails until it is out. Also check the chart defaults going back to v0.1.6's. Risk: low, a revert undoes it all.

Why

A partner (OpenObserve first) installs DevZero into its customers' clusters, and each customer pays for its own DevZero team. The provider's next release adds devzero_team, which starts that team, and team_id on devzero_cluster, which registers a cluster in it. Today this module always registers the cluster in the provider's own team, so a partner's install lands in the partner's team.

Read first

1. main.tf, variables.tf: team_id (default null) goes straight to devzero_cluster.team_id. The provider refuses a change of it at plan, so the module never moves or re-creates a registered cluster.
2. providers.tf: devzero >= 0.3.0, the first release whose devzero_cluster has team_id.
3. variables.tf, chart versions: main holds one unreleased change, bump operator versions #10, which raised the defaults to zxporter 0.1.8 and dakr-operator 0.1.61. This sets them back to the v0.1.6 release's 0.0.59 and 0.1.49, so the next release carries only team_id and the floor.
4. README.md, examples/partner-customer-cluster.tf: a partner's example (a devzero_team and this module). Both declare required_providers, name a service account's token, and say that member_emails must name an Admin of the partner's team. The README's snippets use the registry address devzero-inc/cluster/devzero, pinned to ~> 0.2.

Evidence

• terraform fmt -check -recursive clean on 51e7172. On 1de948a (later commits change only comments and the README), terraform validate valid against the provider's main (0cceeb32c8) built locally through dev_overrides. 0.3.0 is not on the registry, so init ran with the floor relaxed in a throwaway copy.
• examples/partner-customer-cluster.tf run as a root: terraform providers binds devzero to devzero-inc/devzero >= 0.3.0, not hashicorp/devzero.
• terraform get accepts devzero-inc/cluster/devzero and downloads 0.1.6.

Left out

• Tagging this module's v0.2.0 once the merge is done.
• A partner needs the partner flag on its own team before devzero_team can start a team. DevZero staff set it.

Review and detail

• Upgrading: for a cluster in a state from before team_id, the first refresh stores the provider's team, so a refreshing plan shows no diff. A plan -refresh=false on such a state plans team_id as known after apply, and the update sends the same name and the provider's team. That behaviour is the provider's; the module cannot change it.
• Token: with a person's token, destroying a devzero_team is that person's leave. A team's last member leaving deletes it, unless DevZero refuses the leave, as it does once a cluster in the team has reported; then the destroy fails. That is why every example names a service account's token.
• Chart defaults: the registry's latest is 0.1.6, so no registry user ever had bump operator versions #10's values. A caller who wants newer charts sets zxporter_chart_version and operator_chart_version.
• The floor: even a null team_id is an argument the provider's schema must know, so 0.2.0 and older refuse the module.
• README tables: the Providers table is set by hand to >= 0.3.0: terraform-docs takes it from an init, which needs 0.3.0 on the registry.
• Rollback: revert the commit. Nothing is written outside Terraform state.

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[Copilot]

🔵 Needs a closer look

Merge depends on devzero-inc/devzero 0.3.0 being published, but Registry availability and released-provider compatibility remain unverified because validation used a local development build.

No open issues 🎉

What changed in this PR

Adds optional team selection to the cluster module so partners can register clusters in their customers’ DevZero teams. Leaving team_id unset preserves registration in the provider’s team.

Changes:

• Passes the new team_id input to devzero_cluster and raises the DevZero provider minimum to 0.3.0.
• Restores chart defaults to the module’s v0.1.6 values.
• Documents partner setup and adds a customer-team example using a service account token.

The PR remains gated on provider 0.3.0 being published to the Terraform Registry.

File	Description
variables.tf	Adds optional team_id and restores chart defaults.
README.md	Documents partner usage, provider requirements, and updated defaults.
providers.tf	Raises the DevZero provider minimum to 0.3.0.
main.tf	Passes team_id to cluster registration.
examples/​partner-customer-cluster.tf	Demonstrates creating a customer team and registering its cluster.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

DevZero provider 0.3.0 Registry availability and validation against the release remain unconfirmed; reported checks used a local build with a relaxed version floor.

No open issues 🎉

_{Review effort: Balanced}