[Discussion] - Contributors guide new resource vs inline

[aristosvo]

Goal

To put my thoughts in a doc and start a little discussion, align practices, avoid unnecessary (re)work.

Why

I've been struggling a bit with this the last few days and also before when contributing resources/properties like:

• Database work, AAD auth, auditing policies etc (azurerm_sql_active_directory_administrator - Support for azuread_authentication_only #14172, New Resource: azurerm_sql_managed_instance_active_directory_administrator #14104, azurerm_mssql_database: Fix extended_auditing_policy for Secondaries #13799, azurerm_mssql_server: Support for azuread_authentication_only #13754)
• Key Vault Key Rotation Policy (azurerm_key_vault_key_rotation_policy - New resource #18603, azurerm_key_vault_key - rotation_policy block added #19113)
• Probably more!

Other resources like VNet/Subnets/NSGs have their troubles as well, not only from a contributor perspective but also from a user perspective with security boundaries between Infra Teams, Networking Teams, Application Teams etc. Not gonna solve that with this one and only doc, but maybe as a 'best practices' spin-off.

I'm not aware if there is any previous work done or talks on this topic, maybe a nice one for HashiTalks: Build.

Status

First Draft

[katbyte]

thats for opening this @aristosvo - and provided such a great writeup for the contrib docs

A going to drop in my comments from the other PR and a few thoughts:

IMHO i think a 1:1 relation alone is reason enough to consider adding functionality to the existing resource. Even more so when it really is just "enabling/configuring feature X on resource Y".

i think its a better user experience to have resource.feature_x_enabled then

resource "azurerm_something_feature_enabled" {
    something_id = numbers
    enabled = true
}

there are times where it does not make sense/can't be: ie CMK where the resource has to be created, permissions updated, and then CMK applied

or users may want to configure it separately (adding network ules)

or users may want to configure it in both places: azuread_group.members vs azuread_group_member

seems like you've covered most of this already with what you've written 😄

[katbyte]

Thanks again for this @aristosvo! - leaving some minor comments inline for when @tombuildsstuff loops back for a final look

[katbyte]

LGTM 🍄

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.