Skip to content
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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

christian-calabrese
Copy link
Contributor

@christian-calabrese christian-calabrese commented Feb 25, 2025

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

Copy link

changeset-bot bot commented Feb 25, 2025

🦋 Changeset detected

Latest commit: 92f1d93

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
azure_role_assignments Major

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

@Krusty93
Copy link
Contributor

Does it make sense to keep name/resource group pairs in variables?

@christian-calabrese
Copy link
Contributor Author

christian-calabrese commented Feb 26, 2025

Does it make sense to keep name/resource group pairs in variables?

It's pretty much the same idea as described here.
Do you think we can get rid of the possibility to just specify the name of the service when it's already created?

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

@Krusty93
Copy link
Contributor

Does it make sense to keep name/resource group pairs in variables?

It's pretty much the same idea as described here. Do you think we can get rid of the possibility to just specify the name of the service when it's already created?

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 scope property, while the name/rg pair is useful only for data. I suggest to have a look at it before doing changes by the way

@christian-calabrese christian-calabrese changed the title Allow contextual creation of role assignments and related resources [CES-871] Allow contextual creation of role assignments and related resources Feb 26, 2025
@christian-calabrese christian-calabrese changed the title [CES-871] Allow contextual creation of role assignments and related resources [CES-781] Allow contextual creation of role assignments and related resources Feb 26, 2025
@christian-calabrese
Copy link
Contributor Author

christian-calabrese commented Feb 27, 2025

Does it make sense to keep name/resource group pairs in variables?

It's pretty much the same idea as described here. Do you think we can get rid of the possibility to just specify the name of the service when it's already created?
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 scope property, while the name/rg pair is useful only for data. I suggest to have a look at it before doing changes by the way

@Krusty93 currently, the code allows specifying either the target resource's name + resource group or its id.
We can surely remove it, but it needs the azurerm provider function parse_resource_id, hence azurerm 4.x.y.

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.

@christian-calabrese christian-calabrese changed the title [CES-781] Allow contextual creation of role assignments and related resources Allow contextual creation of role assignments and related resources Feb 28, 2025
@christian-calabrese christian-calabrese marked this pull request as ready for review February 28, 2025 17:12
@christian-calabrese christian-calabrese requested a review from a team as a code owner February 28, 2025 17:12
@gunzip
Copy link
Contributor

gunzip commented Feb 28, 2025

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.

when exactly?

Copy link
Contributor

@gunzip gunzip left a 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"
Copy link
Contributor

@Krusty93 Krusty93 Mar 4, 2025

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?

Copy link
Contributor Author

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"]
Copy link
Contributor

@Krusty93 Krusty93 Mar 4, 2025

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?

Copy link
Contributor Author

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"
Copy link
Contributor

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?

Copy link
Contributor Author

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

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:
Copy link
Contributor

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" ?

Copy link
Contributor Author

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.

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.

4 participants