feature: complete modular starter module

[jaredfholgate]

Overview/Summary

The PR adds an end to end example of using the new avm modules for ALZ.

This PR fixes/adds/changes/removes

1. Feature Request: Add end to end example starter module for AVM ALZ modules #29

Breaking Changes

None

Testing Evidence

The starter module has been run and generated a hierarchy with no errors:

As part of this Pull Request I have

• Checked for duplicate Pull Requests
• Associated it with relevant issues, for tracking and closure.
• Ensured my code/branch is up-to-date with the latest changes in the main branch
• Performed testing and provided evidence.
• Updated relevant and associated documentation.

[luke-taylor]

Nice work here Jared.

I'd be tempted to remove the template file variables though, it layers in more complexity. I think being more opinionated would be better, the idea behind the complete was to somewhat replicate the scalability of caf-enterprise-scale.

Do you think we could just hard code certain variables directly in the modules in main.tf, like log_analytics_workspace_id etc. I don't think they necessarily need exposing in the config.yaml as 9 times out of 10 it will be the same, i.e. the output of the alz-management module.

[jaredfholgate]

Nice work here Jared.

I'd be tempted to remove the template file variables though, it layers in more complexity. I think being more opinionated would be better, the idea behind the complete was to somewhat replicate the scalability of caf-enterprise-scale.

Do you think we could just hard code certain variables directly in the modules in main.tf, like log_analytics_workspace_id etc. I don't think they necessarily need exposing in the config.yaml as 9 times out of 10 it will be the same, i.e. the output of the alz-management module.

It is quite possible I am over-engineering it. I was just thinking ahead to VBD usage and keeping it DRY. But yes, the templating could be confusing if not well documented. I will have a think about how to simplify it. I think the log_analytics_workspace_id can be removed for sure. The subscription ids might be problematic, but sure there is a way to handle that.

[luke-taylor]

Nice work here Jared.
I'd be tempted to remove the template file variables though, it layers in more complexity. I think being more opinionated would be better, the idea behind the complete was to somewhat replicate the scalability of caf-enterprise-scale.
Do you think we could just hard code certain variables directly in the modules in main.tf, like log_analytics_workspace_id etc. I don't think they necessarily need exposing in the config.yaml as 9 times out of 10 it will be the same, i.e. the output of the alz-management module.

It is quite possible I am over-engineering it. I was just thinking ahead to VBD usage and keeping it DRY. But yes, the templating could be confusing if not well documented. I will have a think about how to simplify it. I think the log_analytics_workspace_id can be removed for sure. The subscription ids might be problematic, but sure there is a way to handle that.

Yeah for sure, and the folks delivering the VBDs may not necessarily be fully clued up on advanced features of terraform. Why may the subscription Ids be problematic?

[jaredfholgate]

Please note that this is blocked while we figure out some stuff with the vNext module.

[matt-FFFFFF]

@jaredfholgate see this branch for some progress:

https://github.com/Azure/terraform-azurerm-avm-ptn-alz/tree/experiment/yamlinput/examples/dynamic-input

[jaredfholgate]

@matt-FFFFFF and @luke-taylor I appreciate that I have not added documentation for this starter module, but we have another issue open to add docs for the complete starter module, so plan to piggy back off that as the docs will be very similar. #43

[matt-FFFFFF]

lgtm