[BUG] Minion side master (in multimaster) setting is not shown as set in the minion conf file

[amalaguti]

Description
The value for master setting in multimaster setup (list) differs depending on it being called using salt-call or salt <minion>

When using salt from the master to show the master setting on the minion, only the first master in the list is shown. Some other options are even hidden or not available like master_list and master_uri_list (this is less important due it's not something commonly used I guess and can be considered "internals").

But being able to see the actual value for master setting is important.

Here you go a simple state to show the values of the master and other mentioned settings gathered from grains, opts and config module, in which you can see the difference when running it using salt-call from the minion directly and when using salt <minion> from the master

{% set master_options = ['master', 'master_list','master_uri_list' ] %}
show:
  test.configurable_test_state:
    - changes: False
    - result: True
    - comment: |
        GRAIN MASTER:
        {{ grains['master'] }}

        CONFIG.GET
        {%- for master_option in master_options %}
        {{ master_option }}: {{ salt['config.get'](master_option) }}
        {%- endfor %}

        

        OPTS
        {%- for master_option in master_options %}
        {{ master_option }}: {{ opts.get(master_option, 'NOT AVAILABLE') }}
        {%- endfor %}


        CONFIG.ITEMS
        {%- for master_option in master_options %}
        {{ master_option }}: {{ salt['config.items']().get(master_option, 'NOT AVAILABLE') }}
        {%- endfor %}

PS C:\Users\adrian> salt-call state.sls minion.minion_config
local:
----------
          ID: show
    Function: test.configurable_test_state
      Result: True
     Comment: GRAIN MASTER:
              ['172.21.0.10', '172.21.0.11']

              CONFIG.GET
              master: 172.21.0.10
              master_list: ['172.21.0.10', '172.21.0.11']
              master_uri_list: ['tcp://172.21.0.10:4506', 'tcp://172.21.0.11:4506']



              OPTS
              master: 172.21.0.10
              master_list: ['172.21.0.10', '172.21.0.11']
              master_uri_list: ['tcp://172.21.0.10:4506', 'tcp://172.21.0.11:4506']


              CONFIG.ITEMS
              master: 172.21.0.10
              master_list: ['172.21.0.10', '172.21.0.11']
              master_uri_list: ['tcp://172.21.0.10:4506', 'tcp://172.21.0.11:4506']
     Started: 01:06:31.167354
    Duration: 0.0 ms
     Changes:

Summary for local
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time:   0.000 ms

$ salt minion-win-1 state.sls minion.minion_config
minion-win-1:
----------
          ID: show
    Function: test.configurable_test_state
      Result: True
     Comment: GRAIN MASTER:
              172.21.0.10

              CONFIG.GET
              master: 172.21.0.10
              master_list:
              master_uri_list:



              OPTS
              master: 172.21.0.10
              master_list: NOT AVAILABLE
              master_uri_list: NOT AVAILABLE


              CONFIG.ITEMS
              master: 172.21.0.10
              master_list: NOT AVAILABLE
              master_uri_list: NOT AVAILABLE
     Started: 01:06:47.796141
    Duration: 0.0 ms
     Changes:

Summary for minion-win-1
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time:   0.000 ms

I have a workaround using the slsutil module yaml deserializer

{% set file_content = salt['file.read']("C:\\ProgramData\\Salt Project\\Salt\\conf\\minion.d\\minion.conf") %}
{% set file_content_des = salt['slsutil.deserialize']("yaml",file_content) %}
{% set master_config = file_content_des.get('master') %}

Despite the workaround, I think the master setting should be respected and maintained the same from grains, opts, config no matter the call type.

Setup
3006.x
Sample files included in the description.

Steps to Reproduce the behavior
Run the provided state, or even try config.get master using salt-call and salt with the minion set in multimaster

Expected behavior
Master option should be shown as set on the minion conf

[amalaguti]

maybe related, grains.item vs config.get

PS C:\Users\adrian> salt-call grains.item master
local:
    ----------
    master:
        - 172.21.0.10
        - 172.21.0.11
PS C:\Users\adrian> salt-call config.get master
local:
    172.21.0.10

[twangboy]

https://github.com/saltstack/salt/blob/master/salt/minion.py#L593-L596

[max-arnold]

Reposting from Slack:

It looks like the master_list, master_uri_list (and also local_masters, master_uri) aren't proper (and documented) minion settings. These seem to be more like private minion variables that get calculated from the master setting and pushed into __opts__ in the minion code.

It is not good. Ideally the settings should be immutable, but Salt abuses the opts dictionary as a global context

The logic is quite complex and uses some master selection code (that is probably why it is different for minion and salt-call). https://github.com/saltstack/salt/blob/master/salt/minion.py#L544

Core team seems to be aware of this problem (see We'd like to get to a place where opts is no longer mutable):

#64269 (comment)

The default options are already immutable for a while, which looks like a first step in that direction.

A possible workaround:

show:
  test.configurable_test_state:
    - changes: False
    - result: True
    - comment: |
        MASTER:
        {{ salt['slsutil.deserialize']('json', salt['cmd.run']('salt-call --local config.get master --out json'))['local'] }}