Problem
The AVD and SOFS repos use different terminology for the same FSLogix share topologies, causing confusion for users following deployment guides across both repos.
| Concept |
AVD Repo (variables.example.yml) |
SOFS Repo (docs/architecture) |
| Single share for all FSLogix data |
single |
Option A |
| Three separate shares (Profiles/ODFC/AppData) |
split |
Option B |
| Cloud Cache replication |
cloud_cache |
Cloud Cache (DR overlay) |
Neither repo defines a mapping between these terms. A user reading both repos has to mentally figure out that split = Option B.
Discussion Points
- Which terminology should be canonical?
single/split/cloud_cache or Option A/Option B?
- Should we define both with a mapping table in each repo?
- Should the config
variables.example.yml use the same enum values?
- AVD can focus on more than just profiles on SOFS — should the topology terminology be extended for general-purpose SOFS use cases?
Acceptance Criteria
Affected Repos
azurelocal-avd — config/variables.example.yml, docs/guides/fslogix.md
azurelocal-sofs-fslogix — docs/architecture/overview.md, docs/getting-started.md, config/variables.example.yml
Problem
The AVD and SOFS repos use different terminology for the same FSLogix share topologies, causing confusion for users following deployment guides across both repos.
variables.example.yml)singlesplitcloud_cacheNeither repo defines a mapping between these terms. A user reading both repos has to mentally figure out that
split=Option B.Discussion Points
single/split/cloud_cacheorOption A/Option B?variables.example.ymluse the same enum values?Acceptance Criteria
variables.example.ymlFSLogix topology enum valuesAffected Repos
azurelocal-avd—config/variables.example.yml,docs/guides/fslogix.mdazurelocal-sofs-fslogix—docs/architecture/overview.md,docs/getting-started.md,config/variables.example.yml