Is there a recommended layout for multiple clusters sharing config?

[vooodoo10]

We manage several Talos clusters whose machine config is mostly identical, with
a small per-cluster delta (CNI, storage driver, networking). Coming from
talhelper, where a shared patches/ directory was merged with a per-cluster one.

The docs describe the merge order within one cluster (all/ → role → node/)
and patchesDir (default: the directory containing topf.yaml), and Production
Usage recommends versioning the config directory so a baseline can be shared —
but not the on-disk shape.

Is there a recommended layout for this? Specifically:

1. Is pointing several clusters' topf.yaml at one tree (patchesDir: ../shared)
   a supported pattern? Are relative patchesDir paths resolved against the
   directory containing topf.yaml, the way secretsPath explicitly is?

2. Is data: + templates the intended way to express per-cluster deltas, or is
   there something better suited?

3. Any plan for merging multiple patch directories (patchesDirs: [../shared, .]),
   so the delta could stay plain YAML instead of template conditionals?

topf 0.6.0 (Talos v1.14.0)

[clementnuss]

1.1 reusing the same 'config' folder for multiple clusters: yes, that's actually what we do.
1.2 yes, patchesDir is resolved relative to the config file directory:

	configFileDir := filepath.Dir(absPath)

	// Set default patchesDir if not specified
	if config.PatchesDir == "" {
		config.PatchesDir = configFileDir
	} else if !filepath.IsAbs(config.PatchesDir) {
		config.PatchesDir = filepath.Join(configFileDir, config.PatchesDir)
	}

2. for now this is the intended way. but there are discussions/ideas in Feature request: allow additional roles for a node #44 to have a classes: [] field on the node object, which would let topf gather class-specific patches in a folder of the same name. not sure we go that route yet though
3. this is actually a nice idea, which might (help) solve Feature request: allow additional roles for a node #44. we'll discuss it with @sebastian-stephan !

FYI: the way we organize our talos config is as follows:

• we have a talos/config repository, containing the shared config for all clusters
• we run topf in a GitLab pipeline. the 'init' script that runs topf starts by cloning out the config repository.
• currently we store the repo name and the revision in topf.yaml/data.repository..., and the init script consumes those values to clone the repo. there would also be an idea for a config provider, but that goes against topf's goal to stay minimal. configProvider? #94