feat(all): add base and constraints config options to charm tf modules

[NucciTheBoss]

This PR adds the base and constraints configuration options to the Slurm charm tf modules. This way we can specify different bases, and request specific instance types through OpenTofu/Terraform. This PR also adds READMEs for each of the modules to document both inputs and outputs.

[dsloanm]

Looking good - the variable descriptions in particular are much improved.

One thing is I'm seeing an error at the end of deployments (the application appears to deploy successfully anyway):

$ tofu apply -var="model_name=charmed-hpc" -auto-approve
[...]
juju_application.sackd: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to juju_application.sackd, provider "provider[\"registry.opentofu.org/juju/juju\"]" produced an
│ unexpected new value: .constraints: was cty.StringVal(""), but now cty.StringVal("arch=amd64").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

which I don't get with current main:

$ tofu apply -auto-approve
[...]
juju_application.sackd: Creating...
juju_application.sackd: Creation complete after 2s [id=charmed-hpc:login-node]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

app_name = "login-node"
provides = {
  "slurmctld" = "slurmctld"
}

Could just be my environment - have you seen the same?

It's consistent with tofu and terraform.

[NucciTheBoss]

Hmm... I'll need to check. Not sure if that's something we can control through our Terraform plan. IIRC the provider will supply its own defaults if certain resource fields are left blank.

[NucciTheBoss]

@dsloanm digging further into your issue, seems like we've accidentally stumbled upon this issue with the Terraform provider: juju/terraform-provider-juju#344.

TL;DR is that Juju automatically applies the constraint arch=amd64, but Terraform/Tofu throws an error because it doesn't know if the user actually intended for this to happen, and it doesn't fetch the user's data to determine if this is preferred or not.

Easiest fix here is to just change the default to arch=amd64 and then document once we support ARM64 that the user must pass arch=arm64 as a constraint to get the machine architecture they want.

[NucciTheBoss]

@dsloanm should be resolved now 😎

[dsloanm]

Yep, no issues with the apply now. LGTM!