Skip to content

Allow backup plans to be unset.#116

Open
TurboNHS wants to merge 1 commit intomainfrom
turbo-allow-backup-config-to-be-unused
Open

Allow backup plans to be unset.#116
TurboNHS wants to merge 1 commit intomainfrom
turbo-allow-backup-config-to-be-unused

Conversation

@TurboNHS
Copy link
Copy Markdown

@TurboNHS TurboNHS commented Apr 22, 2026

We (CDS-NDSP) for example don't use DynamoDB, EBS volumes or ParameterStore, so we have no need for those backup plans, and it seems silly to create them no matter what.

So to make sure they don't gets created, I want/need to set:

module "source" {
  [...]

  backup_plan_config                 = { "enable": false }
  backup_plan_config_dynamodb        = { "enable": false }
  backup_plan_config_ebsvol          = { "enable": false }
  backup_plan_config_parameter_store = { "enable": false }
}

All the other backup_plan_config_* resources had a count to create them or not, but not the "main" one, so add that. That lead to the resources being an array, so make sure they're moved automatically.

It also required all options in the variables to be optional(), which should (!?) be ok, since there's defaults.

HOWEVER, the default is only used if/when the variable is completely unset! NOT if/when some values are missing. As in, TF won't substitute empty/unset values with one from the default.

That unfortunately lead to those three values required (selection_tag, compliance_resource_types and rules in the case of the "main" config) can't be required anymore. Because they have defaults, there's no way to check (validation {}) if they're set or not. Because they always will, wether enable is true or false :(.

Description

Context

Type of changes

  • Refactoring (non-breaking change)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would change existing functionality)
  • Bug fix (non-breaking change which fixes an issue)

Checklist

  • I am familiar with the contributing guidelines
  • I have followed the code style of the project
  • I have added tests to cover my changes
  • I have updated the documentation accordingly
  • This PR is a result of pair or mob programming

Sensitive Information Declaration

To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

  • I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.

We (NDSPCDSP) for example don't use DynamoDB, EBS volumes or ParameterStore,
so we have no need for those backup plans, and it seems silly to create
them no matter what.

So to make sure they don't gets created, I want/need to set:
```
module "source" {
  [...]

  backup_plan_config                 = { "enable": false }
  backup_plan_config_dynamodb        = { "enable": false }
  backup_plan_config_ebsvol          = { "enable": false }
  backup_plan_config_parameter_store = { "enable": false }
}
```

All the other `backup_plan_config_*` resources had a `count` to
create them or not, but not the "main" one, so add that. That lead
to the resources being an array, so make sure they're `moved`
automatically.

It also required *all* options in the variables to be `optional()`,
which should (!?) be ok, since there's defaults.

HOWEVER, the `default` is only used if/when the variable is completely
unset! NOT if/when some values are missing. As in, TF won't substitute
empty/unset values with one from the `default`.

That unfortunately lead to those three values required (`selection_tag`,
`compliance_resource_types` and `rules` in the case of the "main" config)
can't be required anymore. Because they have defaults, there's no way
to check (`validation {}`) if they're set or not. Because they always will,
wether `enable` is `true` or `false` :(.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant