new resource for azurerm_synapse_role_assignment
#8863
Conversation
| // apply firewall rule first | ||
| { | ||
| Config: testAccAzureRMSynapseRoleAssignment_template(data), | ||
| }, | ||
| // create synapse role assignment | ||
| { | ||
| Config: testAccAzureRMSynapseRoleAssignment_basic(data), | ||
| Check: resource.ComposeTestCheckFunc( | ||
| testCheckAzureRMSynapseRoleAssignmentExists(data.ResourceName), | ||
| ), | ||
| }, |
There was a problem hiding this comment.
how come this is a two step process? this means users won't be able to chain these togeather?
There was a problem hiding this comment.
user must have network access permission first and then they could assign synapse role. users could use depends_on to chain these togeather
There was a problem hiding this comment.
Could we use depends on in the tf configs instead of 2 tests steps?
azurerm/internal/services/synapse/tests/synapse_role_assignment_resource_test.go
Outdated
Show resolved
Hide resolved
azurerm/internal/services/synapse/tests/synapse_role_assignment_resource_test.go
Show resolved
Hide resolved
azurerm/internal/services/synapse/tests/synapse_role_assignment_resource_test.go
Show resolved
Hide resolved
|
@katbyte Thanks for your time to review this PR, could you please have a look again? |
azurerm/internal/services/synapse/synapse_role_assignment_resource.go
Outdated
Show resolved
Hide resolved
| // apply firewall rule first | ||
| { | ||
| Config: testAccAzureRMSynapseRoleAssignment_template(data), | ||
| }, | ||
| // create synapse role assignment | ||
| { | ||
| Config: testAccAzureRMSynapseRoleAssignment_basic(data), | ||
| Check: resource.ComposeTestCheckFunc( | ||
| testCheckAzureRMSynapseRoleAssignmentExists(data.ResourceName), | ||
| ), | ||
| }, |
There was a problem hiding this comment.
Could we use depends on in the tf configs instead of 2 tests steps?
|
Hi @katbyte, I have updated this PR, could you have a look again when free? |
|
This has been released in version 2.34.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example: provider "azurerm" {
version = "~> 2.34.0"
}
# ... other configuration ... |
|
This regresses the provider for any Azure environment which does not have Synapse available - which is basically China, USGov, and German clouds. The provider is no longer usable in those environments because the call to create a synapse token fails. See #9099 https://github.com/Azure/go-autorest/blob/master/autorest/azure/environments.go You shouldn't add Synapse credentials into the main provider here: https://github.com/terraform-providers/terraform-provider-azurerm/blob/2c7ae3cfcc59aad45239d021aa64198dd1701d51/azurerm/internal/clients/builder.go#L100 I imagine you would want to use the Client model using Autorest to create a new client - similar to how DataLake provisions their client. Do we not run automated tests against environments than public cloud (like say German cloud) to prevent regression? |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
ghost
locked as resolved and limited conversation to collaborators
synapse data plane resource
points that needs to pay attention:
currently the id format is
{synapseWorkspaceId}|{synapseRoleAssignmentId}, please confirm it's ok.or this id format
{synapseWorkspaceId}/roleAssignments/{synapseRoleAssignmentId}is better