-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow contextual creation of role assignments and related resources #315
base: main
Are you sure you want to change the base?
Allow contextual creation of role assignments and related resources #315
Conversation
🦋 Changeset detectedLatest commit: 92f1d93 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
infra/modules/azure_role_assignments/modules/key_vault/variables.tf
Outdated
Show resolved
Hide resolved
Does it make sense to keep name/resource group pairs in variables? |
It's pretty much the same idea as described here. PS: Actually, I should check if they are still needed when specifying the resource id. Maybe we can make them optional and check that at least one is populated |
I think we can remove name/rg pairs in both contexts (new/existing) as the id is always needed to the |
@Krusty93 currently, the code allows specifying either the target resource's name + resource group or its id. Since it's a breaking change, I think we can do it anyways with a major. Moreover, I saw that from version 3.114 it is possible to opt in for the provider functions feature (source) If you and the team agrees, I proceed removing the name and resource group name variables for simplicity. |
when exactly? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, let's see what others think @pagopa/engineering-team-devex
required_providers { | ||
azurerm = { | ||
source = "hashicorp/azurerm" | ||
version = ">= 3.114, < 5.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Is 3.114
ok with the provider::azurerm::parse_resource_id
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added these lines in the migration guide to explain how to make it work for >= 3.114 azurerm versions
apims = distinct([for assignment in var.apim : { name = assignment.name, resource_group_name = assignment.resource_group_name }]) | ||
|
||
norm_apims = [for apim in var.apim : { | ||
name = provider::azurerm::parse_resource_id(apim.id)["resource_name"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Why do you still need name
and resource_group_name
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly to not break old resource indices. Cosmos submodule, instead, will still need them
Do you think we can remove them? Projects already using the module and updating to the new major may need to move some resources state.
@@ -2,7 +2,7 @@ terraform { | |||
required_providers { | |||
azurerm = { | |||
source = "hashicorp/azurerm" | |||
version = ">= 3.110, < 5.0" | |||
version = ">= 3.114, < 5.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Isn't this constraint enough for all the sub modules?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Submodules can be instantiated on their own, so the providers definition shall be defined
Co-authored-by: Marco Comi <[email protected]>
.changeset/beige-buses-refuse.md
Outdated
Role assignments can now be created contextually with identities and target resources | ||
|
||
**Migration guide**: | ||
When using the azurerm provider version >= 3.114.0, the beta opt-in feature must be enabled by setting the following environment variable: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: what's the "the beta opt-in feature" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to explain it better in a next commit. The module makes use of features available from azurerm 4.0 version (provider defined functions). The beta opt-in feature allows to use them from 3.114.0 version as well.
It's a way to not break projects that don't support the 4.0 version of the provider yet.
Due to the presence of data sources, it is not possible to contextually create the target resource (storage account, redis cache, apim, ...) and the related role assignments in the same terraform plan or apply.
Resolves #CES-781