冲突键的支柱合并策略

如何解决冲突键的支柱合并策略

当我在两个不同的支柱存储库中定义了相同的密钥时，哪个优先？ Salt 的文档并不清楚会发生什么，而且我从测试中看到的行为不是我所期望的。

pillar namespace flattening documentation 详细说明了当您在同一个 repo 中遇到密钥冲突时会发生什么情况——应用 top.sls 中最后定义的文件：

支柱文件按照它们在顶部文件中列出的顺序应用。 因此，冲突的密钥将在“最后一个获胜”中被覆盖 方式！

好的，这是完全有道理的，但是当我有两个顶级文件时呢？考虑在文件系统上定义的两个支柱存储库，一个在 /srv/pillar/A 中，一个在 /srv/pillar/B 中。他们每个人都将一个状态文件应用到所有 Minion：

/srv/pillar/A

# top.sls
pillarA:
  '*':
    - instance

# instance/init.sls
my_key: 'ABC'

/srv/pillar/B

# top.sls
pillarB:
  '*':
    - instance

# instance/init.sls
my_key: 'XYZ'

现在，我们在 pillar_roots 的 /etc/salt/master 键中定义支柱：

pillar_roots:
  pillarA:
    - /srv/pillar/A
  pillarB:
    - /srv/pillar/B

将更改推送到单个 Minion，并检索 my_key：

[root@salt01]# salt -L 'myminion01.foo.bar' saltutil.pillar_refresh
myminion01.foo.bar:
    True
[root@salt01]# salt -L 'myminion01.foo.bar' pillar.get 'my_key'
myminion01.foo.bar:
    ABC

我希望返回 XYZ，因为 pillarB 在 pillar_roots 中最后定义，但同样，我找不到任何文档来支持这一点。如果我在 pillarA 中交换 pillarB 和 pillar_roots 的顺序，结果是一样的——我总是得到 ABC。

那么有谁知道这里的预期行为是什么？我的用例是我正在尝试设置一个公共/共享支柱，该支柱定义将适用于我们 90% 的随从的变量，但仍允许在其他支柱数据中逐个覆盖这些值覆盖边缘情况。话虽如此，我的假设是，pillar_roots 和 ext_pillar 中的支柱存储库的顺序会影响发生键冲突时哪些值优先。

我最接近确定答案的是TOP_FILE_MERGING_STRATEGY option。我认为这也适用于支柱顶级文件，但文档没有明确说明这一点，所有示例都用于合并状态顶级文件。无论如何，默认选项是 merge，它指出：

设置为合并时，首先评估基础环境的顶层文件， 其次是其他环境的顶级文件......环境将 没有特定的顺序进行评估（除了基数在前）

假设此选项适用于支柱顶级文件，这听起来像是在 base 环境之外，我无法控制其他支柱环境的加载顺序。

编辑：

我确实找到了 this StackOverflow answer，它指出：

所有外部支柱都按照列表中列出的顺序执行 配置文件。

没有来源支持此声明，但我确实通过 ext_pillar 键使用外部支柱对此进行了测试，并且确实有效——如果发生密钥冲突，最后定义的支柱环境优先.这是我所期望的行为，但令人沮丧的是，同样的情况不适用于 pillar_roots -- 我使用这种方法进行了测试，因为它更简单、更快捷。