Azure / Azure/unbounded

ci: the deploy gate waits on 5 of 7 component workloads

Open
#625 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
28
Forks
11
Avg merge
1d 8h
Merged PRs (30d)
55

Description

Both deploy gates wait on:

```
deploy/unbounded-operator
deploy/unbounded-net-controller
ds/unbounded-net-node
deploy/machina-controller
ds/gantry
```

`metalman` and `unbounded-storage-supervisor` are not in the list, so nothing in the release pipeline fails when either does not roll out. `internal/operator/imagecoverage_test.go` already records this as known non-coverage:

> it compares component names, not the repository lists under them ... (only by `hack/release/wait-rollouts.sh`, which omits metalman and storage)

Image coverage catches a component image that was never *built*. It does not catch one that was built and then does not start, which is what the rollout gate is for.

Adding them is not just two more arguments. Both are optional per-Site components (`SiteComponentSpec.Enabled`, `api/machina/v1alpha3/site_types.go`), so the gate has to ask whether the component is enabled for the Site being deployed before it waits on the workload - otherwise it blocks forever on a DaemonSet the operator was never going to create. `wait_exists` currently treats a missing workload as "keep waiting until CREATE_TIMEOUT_SECONDS", which is the right behaviour for an enabled component and the wrong one for a disabled component.

Sketch:

- read the Site's component spec once at the start of the gate
- skip, loudly, any workload whose component is disabled
- add both workloads to the list in `nightly.yaml` and `release-upgrade.yaml`

Worth doing: a release currently ships storage and metalman with no deploy-time verification at all.

Contributor guide

Open the contributing guide

Research direction

Start with hack/release/wait-rollouts.sh, then inspect nightly.yaml and release-upgrade.yaml for the deploy gates. Read internal/operator/imagecoverage_test.go and api/machina/v1alpha3/site_types.go to understand the existing coverage note and optional Site components. Done means enabled metalman and unbounded-storage-supervisor workloads are checked, while disabled components are skipped loudly without blocking.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes, yaml
Domain
ci-cd, devops, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.