canonical / canonical/landscape-server-operator
terraform: landscape-scalable cannot place landscape_server, haproxy or postgresql on existing machines
- Dominant language
- Python
- Stars
- 5
- Forks
- 11
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 9
Description
## Summary
The `landscape-scalable` product module lets you set `machines` on `rabbitmq_server`,
`landscape_task_handler`, `landscape_debarchive` and `tls_certificates`, but there is no
way to place `landscape_server`, `haproxy` or `postgresql` onto pre-created machines. In a
deployment that colocates the stack on a fixed set of `juju_machine` resources, that means
three of the six applications still get their own provisioner-allocated machines.
## Details
`landscape_server` looks like the easy one: the charm module the product module wraps
already supports placement. In `terraform/charm/main.tf`:
```hcl
units = var.machines == null ? var.units : null
machines = var.machines
```
with `variable "machines"` documented as *"Set of machine IDs to deploy units to. When
specified, the 'units' variable is ignored."*
But `terraform/product/modules/landscape-scalable/variables.tf` does not declare `machines`
in the `landscape_server` object type, and `main.tf` passes only `units`:
```hcl
module "landscape_server" {
source = "../../../charm"
...
units = var.landscape_server.units
}
```
`haproxy` and `postgresql` carry explicit comments acknowledging the gap:
```hcl
# machines is not supported by the external haproxy module (haproxy-rev331)
# machines is not supported by the external postgresql module (v16/1.165.0)
```
(The postgresql comment is stale — the pinned ref is `v16/1.305.0`, which does have a
`machine` variable, though only a single one.)
## Footgun
Because `landscape_server` is an `object({...})` type constraint, Terraform **silently
discards** an unrecognised attribute rather than erroring. Setting:
```hcl
landscape_server = {
machines = toset(juju_machine.landscape[*].machine_id)
...
}
```
passes `terraform validate` with `Success!` and has no effect — the units are still
auto-placed. There is no signal to the operator that the placement was dropped. Verified
with terraform 1.x and juju provider v1.5.4 against `ref=main`.
## Request
1. Add `machines = optional(set(string))` to the `landscape_server` variable and forward it
to the charm module, mirroring what `rabbitmq_server` / `landscape_task_handler` /
`landscape_debarchive` already do.
2. Track `haproxy` and `postgresql` placement once the upstream modules grow the inputs
(filed separately against canonical/haproxy-operator and canonical/postgresql-operator).
Contributor guide
Assessment
This issue has not been assessed yet.