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

Updated management group docs #574

Merged
merged 2 commits into from
Dec 15, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 0 additions & 2 deletions docs/management-groups.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,8 +35,6 @@ The Tier 3 (workload) subscriptions would probably have different management con

### Management group design

When setting up your management group hierarchy there are a number of critical design areas to consider. The areas are documented in [Management group and subscription organization](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/enterprise-scale/management-group-and-subscription-organization) in the Microsoft Cloud Adoption Framework documentation.

## Step-by-step

### Add a subscription to a management group
Expand Down
4 changes: 1 addition & 3 deletions src/bicep/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -335,8 +335,6 @@ Read more about JMESPath queries at: <https://jmespath.org/>

## Naming Conventions

The [naming convention is inspired by the Azure Cloud Adoption Framework](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming) and uses the [recommended resource abbreviations](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations).

By default, Mission LZ resources are named according to a naming convention that uses the mandatory `resourcePrefix` parameter and the optional `resourceSuffix` parameter (that is defaulted to `mlz`).

### Default Naming Convention Example
Expand Down Expand Up @@ -378,7 +376,7 @@ Let's look at an example using `--parameters resourcePrefix=FOO` and `--paramete

### Modifying The Naming Convention

You can modify this naming convention to suit your needs. We recommend following the [Cloud Adoption Framework guidance](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming).
You can modify this naming convention to suit your needs.

- In `mlz.bicep` you can modify the root naming convention. This is the default convention:

Expand Down
4 changes: 0 additions & 4 deletions src/bicep/mlz.bicep
Original file line number Diff line number Diff line change
Expand Up @@ -443,8 +443,6 @@ param emailSecurityContact string = ''

First, we take `resourcePrefix` and `resourceSuffix` by params.
Then, using string interpolation "${}", we insert those values into a naming convention.

We were inspired for this naming convention by: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming

*/

Expand All @@ -464,8 +462,6 @@ var namingConvention = '${toLower(resourcePrefix)}-${resourceToken}-${nameToken}
In an effort to reduce the likelihood of naming collisions,
we replace `unique_storage_token` with a uniqueString() calculated by resourcePrefix, resourceSuffix, and the subscription ID

We were inspired for these abbreviations by: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations

*/

// RESOURCE NAME CONVENTIONS WITH ABBREVIATIONS
Expand Down