New resource - azurerm_integration_service_environment

[jbinko]

Support for Integration Service Environments
See spec in the issue above.

It contains:

• Documentation
• Resource: azurerm_integration_service_environment
• Unit Tests
• Acc Tests
• Hack for delete operation - see comments in source code.
• Helper code

make test TEST='github.com/terraform-providers/terraform-provider-azurerm/azurerm/internal/services/logic/parse' TESTARGS='-run=TestIntegrationServiceEnvironmentId'
make test TEST='github.com/terraform-providers/terraform-provider-azurerm/azurerm/internal/services/logic/validate' TESTARGS='-run=TestIntegrationServiceEnvironmentName'

make acctests SERVICE='logic' TESTARGS='-run=TestAccAzureRMIntegrationServiceEnvironment_basic' TESTTIMEOUT='600m'
make acctests SERVICE='logic' TESTARGS='-run=TestAccAzureRMIntegrationServiceEnvironment_requiresImport' TESTTIMEOUT='600m'
make acctests SERVICE='logic' TESTARGS='-run=TestAccAzureRMIntegrationServiceEnvironment_update' TESTTIMEOUT='600m'

Please provide feedback.

(fixes #7394)

[WodansSon]

@jbinko, thanks so much for this! This mostly looks good but I added a few comments, which are mostly fairly minor, but it is looking really good and I appreciate all the effort you put in to creating the PR! This is looking awesome! Once the changes are push we can get this merged into main! Thanks again! 🚀

[tombuildsstuff]

spotted a couple of things whilst passing through

[jbinko]

I agree with all the comments above. Thank you for review.
I’m not just sure about proposal merging capacity and SKU together for Developer sku.
We need sku_name and capacity properties for Premium use case anyway. Correct?
For Developer use case you need specify sku_name as well and you either skip capacity property (Default is 0)
Or you need to make sure capacity is 0 and if not - TF will report it before provisioning.

In my opinion, introducing additional artificial sku name Developer_0 will
Increase confusion and increase code complexity because of more options/special cases.
Not sure also what would be the advantage of such sku. What are we trying to address?
Don’t get me wrong, I just think I might be missing something.
@WodansSon: Can you please describe in more details the idea? Thank you.

[WodansSon]

I agree with all the comments above. Thank you for review.
I’m not just sure about proposal merging capacity and SKU together for Developer sku.
We need sku_name and capacity properties for Premium use case anyway. Correct?
For Developer use case you need specify sku_name as well and you either skip capacity property (Default is 0)
Or you need to make sure capacity is 0 and if not - TF will report it before provisioning.

In my opinion, introducing additional artificial sku name Developer_0 will
Increase confusion and increase code complexity because of more options/special cases.
Not sure also what would be the advantage of such sku. What are we trying to address?
Don’t get me wrong, I just think I might be missing something.
@WodansSon: Can you please describe in more details the idea? Thank you.

@jbinko, sorry for the late reply... the reason we flatten the sku block into a underscore delimited string is because we had many customers complaining that it was difficult to automate the sku block in their automation scripts and that a structured string was a much easier way for them to manipulate and update while running their scripts against the resource via Terraform. For an implementation example you can take a look at the postgresql_server_resource.go resource. As such, the sku_name delimited string is the new standard moving forward for all resources to help our customers automate Terraform in their environments. Feel free to ask more questions if I didn't explain it clearly enough or if you still have questions around why the two attributes need to be combined into a single sku_name attribute.

Oh one other thing I forgot to mention, in the docs, be sure to mention the order they need to be in, like the below example from the PostgreSQL Server documentation:

sku_name - (Required) Specifies the SKU Name for this PostgreSQL Server. The name of the SKU, follows the tier + family + cores pattern (e.g. B_Gen4_1, GP_Gen5_8). For more information see the product documentation.

[katbyte]

@jbinko - you can also validate the sku_name with regex/a custom validation function that splits it apart. We spent some effort earlier this year to move resources to sku_name when reasonable/made sense and this seems like one of those times.

[jbinko]

@WodansSon, @katbyte: Got it. Now I understand. I changed sku_name as you proposed. Code should be ready for another review. Let me know what do you think.

[WodansSon]

@jbinko, thanks for that... I will take a look at this tomorrow morning my time (PST), I've been out for the last few days for eye surgery...

[WodansSon]

@jbinko, thanks so much for pushing those changes this LGTM now! 🚀

[WodansSon]

@jbinko, one thing really quick... super minor, but I've left 5 suggestions to rename the resource group in the test cases. If you can merge those I will merge this PR into master and we can get it into this release! 🚀

[jbinko]

Thanks @WodansSon ! Sure, I merged your suggestions. Done.

[ghost]

This has been released in version 2.23.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.23.0"
}
# ... other configuration ...

[ghost]

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!