Resource Instance Name constraints

[ThomasNieto]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Summary

I would like to use periods . in my resource instance name but the schema says that is not allowed. Is there a technical reason for only allowing spaces, letters and numbers?

See below #845 (comment) for the issues it causes with dsc config/resource export because the auto created document uses resource type name which contains periods, forward slashes, hyphens, and underscore.

https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/v3/definitions/instanceName.json

The short, human-readable name for a DSC resource instance. Must be unique within a DSC Configuration document. Must be a non-empty string containing only letters, numbers, and spaces

Steps to reproduce

n/a

Expected behavior

n/a

Actual behavior

n/a

Error details

Environment data

n/a

Version

3.1-preview6

Visuals

No response

[ThomasNieto]

This also causes issues with dsc config/resource export as the name of the resource instance is resource type followed by a hyphen and counter.

[theJasonHelmick]

The DSC WG discussed this and agreed wit the proposal overall. We believe we can open this up further allowing additional characters and non-ascii characters to support other languages than English in the name. A Colon (:) cannot be allowed as it conflicts with the ID name - Forward slash (/) cannot be used as it conflicts with the Export implementation.

[michaeltlombardi]

Planned changes:

• Update the schema for instance name to use the pattern ^[^:\/]+$ (allowing any unicode characters except for : and /
• Update the default naming¹ for exported instances from <fully-qualified-type-name>-<zero-index> to <short-type-name>-<zero-index-plus-one>, so instead of TailspinToys.Example.CLI/SettingsFile-0, the name for the first exported resource instance would be SettingsFile-0.

This will allow users to define descriptive names for their resource instances in languages that need to use non-Latin characters or Latin characters with diacritics, both of which are considered invalid by the current validating pattern.

Footnotes

1. Ideally, resources that support Export will instead implement the _name canonical property, which when returned from the Export operation is hoisted from the properties to the instance definition. ↩

[SteveL-MSFT]

@michaeltlombardi I believe this is just a schema change right? In the docs, we should be clear that DSC's use of name differs from ARM where in ARM it's an identity but in DSC it's a friendly name. As such, we also allow arbitrary unicode since the name is intended for the config user and not the resource, but is still required to be unique across instances of the same type of resource.

[michaeltlombardi]

@SteveL-MSFT there's two components - the first is to update the schema to allow arbitrary text for resource names except : and / (which breaks our parsing/handling for the resourceId() lookup). The second is to generate default names for exported resources as <short resource type name>-<index> instead of <fully qualified resource type name>-<index> to remove the / in the exported resources.

This should be a backwards compatible change, as it:

1. Loosens the validation pattern for the name field. All previously valid name values are still valid.
2. Changes the exported name for resource instances to be valid (previous values couldn't be correctly resolved by lookup).

[SteveL-MSFT]

Ok, I'll work on a PR for the exported name then.