cloudposse / cloudposse/atmos

Atmos `providers` field doesn't properly handle an empty `features` object (to make an empty features block) when defining the azurerm provider overrides for aliased providers

Open
#2,615 0 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
Go
Stars
1.4k
Forks
175
Avg merge
2d 25m
Merged PRs (30d)
143

Description

### Describe the Bug

This may also affect unaliased providers but I haven't dug into that as I didn't receive an error from tofu, while I did receive an error from tofu about aliased providers.

What's happening is that in my environment, we had versions.tf files with provider versions in some of our components, but not all, and we ran into an issue that our pipelines started taking longer and longer to run as we added more stacks and components into the workflow.

We can't (yet) parallelize the workflow but plan to, so in an effort to save some time I worked out a process to have all of the providers, required_version, and required_providers blocks defined in the atmos yaml, and a script parses that to pre-mirror the providers on each CI run and generate the lock files (we don't commit them to git for various reasons that I won't go into here, as I'm not familiar with them all.)

This works well, except for one small issue. For aliased providers in the yaml, when the yaml has a nested `features: {}` inside of the aliased azurerm provider definition, atmos is not creating the features block inside the provider block in the .tf file. This appears to be due to the features object in the yaml being empty; because when I add `prevent_deletion_if_contains_resources: true` (a provider default setting) to the yaml inside the features object, then it starts working properly.

### Expected Behavior

I should be able to define features as an empty object in atmos yaml and have an empty features nested block created inside the azurerm provider block. This is a requirement of the azurerm provider that even if you are not setting anything within the block, you must still have the block present.

### Steps to Reproduce

Define an azurerm provider in atmos `providers` yaml field, and a second aliased azurerm provider as well. Both can have an empty features object.

Then remove any providers that mention azurerm from the .tf manifests (you can leave required_providers and required_versions, as these are not involved in this bug.

Ensure that you have an empty aliased provider block defined in the .tf manifests to avoid a terraform error complaining about the code not containing base aliased provider block which is to be overridden.

Then run atmos terraform deploy for the component and stack and you should see terraform complain that the features block is missing from the provider block.

### Screenshots

_No response_

### Environment

_No response_

### Additional Context

_No response_

Contributor guide

Open the contributing guide

Research direction

Start with the provider-generation path exercised by `atmos terraform deploy`, using the YAML `providers` field and the aliased azurerm configuration described in the reproduction. Compare generated `.tf` manifests when `features` is `{}` versus when it contains a setting; done means the empty nested features block is preserved for aliased providers and the reported Terraform error no longer occurs.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, yaml
Domain
cli, devops, infrastructure
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.