Make tier 3 workload resource names consistent with other MLZ resource names

[vidyambala]

Benefit/Result/Outcome

So that resource names set by the tier 3 newWorkload template are consistent with the names set by the main MLZ bicep template.

Description

The tier 3 examples/newWorkload template has a naming convention that is inconsistent with the main mlz.bicep template. Update the naming logic to be consistent with mlz.bicep, including using a resourcePrefix and resourceSuffix parameter.

As part of this work analyze whether or not we should have a single common module that implements a consistent naming convention. Having this type of module is not part of the acceptance criteria, but it could simplify a customer's ability to have consistent naming across MLZ and all plugins/examples.

Acceptance Criteria

• A tier 3 instance can be deployed that uses the same naming convention as mlz.bicep.

[brooke-hamilton]

@vidyambala I made some updates to the title and description. Please correct me if I missed any intended scope. I didn't include moving the example to the add-ons folder. I think we should do that one separately.

[glennmusa]

I'm for this change. Following "1-2-Refactor", the next time we need to implement the same naming convention across resources in disparate modules, we should probably take a look at creating a naming convention module that calculates and outputs the names, but today let's just reuse what's working.

[brooke-hamilton]

I'm for this change. Following "1-2-Refactor", the next time we need to implement the same naming convention across resources in disparate modules, we should probably take a look at creating a naming convention module that calculates and outputs the names, but today let's just reuse what's working.

As part of this work let's analyze what this would look like as a reusable module. It would be helpful for all plug-ins/examples to have a consistent naming convention.

We just implemented consistent default tags in the Bicep examples and decided to not have a common module for calculating default tags, but I think we should reconsider. It didn't result in simpler code or many fewer lines of code, but it would have a benefit of being a single piece of code in one place.

[glennmusa]

We just implemented consistent default tags in the Bicep examples and decided to not have a common module for calculating default tags, but I think we should reconsider. It didn't result in simpler code or many fewer lines of code, but it would have a benefit of being a single piece of code in one place.

Sounds good. Here's an implementation idea: a defaultTags module that takes in a string dictionary of tags and union()s them with whatever we declare the defaults and can be used by output.

# defaultTags.bicep

param tags object = {}

var defaultTags = {
    'fizz': 'buzz'
}

output tags object = union(tags, defaultTags)

# myModule.bicep

param tags object = {}

module defaultTags './defaultTags.bicep' = {
  name: 'defaultTags'
  params: {
    tags: tags
  }
}

resource myResource '<type>@<version>' = {
  ...
  tags: defaultTags.outputs.tags
  ...
}

It feels like a layer of indirection, but I suppose it achieves the goal of single place to set a default.