canonical / canonical/landscape-server-operator

terraform: landscape-scalable cannot place landscape_server, haproxy or postgresql on existing machines

Open
#186 1 comment 1 reaction 1 assignee Claimed by @jansdhillon View on GitHub
synced-to-jira
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.