Problem
Variables across all Azure Local repos are not standardized. Each repo defines its own variables.example.yml with inconsistent naming, types, and defaults. When two repos need to reference the same concept (e.g., FSLogix share paths, Azure Local infrastructure IDs, subscription details), the variable names and structures diverge.
Examples of current mismatches:
- AVD repo uses
fslogix.share_path format; SOFS repo uses sofs.share_name — these refer to the same SMB share
- Both repos define
azure_local.custom_location_id, azure_local.logical_network_id but with slightly different structures
keyvault:// URI patterns are used in both but documented differently
Proposal: Master Variables Registry
Create a centralized master variables registry that serves as the single source of truth for all variable definitions across the Azure Local organization.
Requirements
- Registry format — A structured YAML/JSON schema file that defines every variable used across all repos
- Meta-tagging — Each variable should be tagged with:
repos: Which repos use this variable (e.g., [avd, sofs, toolkit])
scope: Whether it's global, solution-specific, or environment-specific
type: Data type and validation rules
canonical_name: The standardized name all repos must use
description: Human-readable purpose
default: Default value if applicable
- Validation tooling — CI check that validates each repo's
variables.example.yml against the master registry
- Code generation — Optionally auto-generate per-repo variable schemas from the master registry
- Breaking change detection — Flag when a repo introduces a variable that conflicts with the registry
Proposed Location
azurelocal-toolkit/config/registry/variables-registry.yml — hosted in the toolkit repo as a cross-cutting concern.
Example Registry Entry
variables:
azure_local.custom_location_id:
canonical_name: azure_local.custom_location_id
type: string
format: azure_resource_id
description: "ARM resource ID of the Azure Local custom location"
repos: [avd, sofs, toolkit, loadtools]
scope: global
required: true
fslogix.topology:
canonical_name: fslogix.topology
type: enum
values: [single, split, cloud_cache]
description: "FSLogix share topology strategy"
repos: [avd, sofs]
scope: solution
default: single
Acceptance Criteria
Affected Repos
All repos: azurelocal-avd, azurelocal-sofs-fslogix, azurelocal-toolkit, azurelocal-loadtools, azurelocal-vm-conversion-toolkit, azurelocal.github.io
Problem
Variables across all Azure Local repos are not standardized. Each repo defines its own
variables.example.ymlwith inconsistent naming, types, and defaults. When two repos need to reference the same concept (e.g., FSLogix share paths, Azure Local infrastructure IDs, subscription details), the variable names and structures diverge.Examples of current mismatches:
fslogix.share_pathformat; SOFS repo usessofs.share_name— these refer to the same SMB shareazure_local.custom_location_id,azure_local.logical_network_idbut with slightly different structureskeyvault://URI patterns are used in both but documented differentlyProposal: Master Variables Registry
Create a centralized master variables registry that serves as the single source of truth for all variable definitions across the Azure Local organization.
Requirements
repos: Which repos use this variable (e.g.,[avd, sofs, toolkit])scope: Whether it's global, solution-specific, or environment-specifictype: Data type and validation rulescanonical_name: The standardized name all repos must usedescription: Human-readable purposedefault: Default value if applicablevariables.example.ymlagainst the master registryProposed Location
azurelocal-toolkit/config/registry/variables-registry.yml— hosted in the toolkit repo as a cross-cutting concern.Example Registry Entry
Acceptance Criteria
variables.example.ymlfiles across all 6 reposAffected Repos
All repos:
azurelocal-avd,azurelocal-sofs-fslogix,azurelocal-toolkit,azurelocal-loadtools,azurelocal-vm-conversion-toolkit,azurelocal.github.io