New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's the precedence if multiple master configurations are specified? #37512

Closed
ChristianBeer opened this Issue Nov 7, 2016 · 10 comments

Comments

Projects
None yet
4 participants
@ChristianBeer

ChristianBeer commented Nov 7, 2016

Description of Issue/Question

I have a use-case where I want to override a specific master configuration value (worker_thread) locally. I found a working solution but I want to make sure this is the intended behavior and maybe if this can be added to the documentation.

Working solution

Configurations included from /etc/salt/master via include take precedence over configurations included via default_include which take precedence over configurations directly specified in /etc/salt/master

/etc/salt/master:

default_include: /srv/salt/master/master.d/*.conf
include: /etc/salt/master.d/local.conf

/srv/salt/master/master.d/main.conf (this is git controlled):

...
worker_threads: 100
...

/etc/salt/master.d/local.conf (this is outside source control):

worker_threads: 3

Versions Report

Salt Version:
           Salt: 2016.3.3

Dependency Versions:
           cffi: 0.8.6
       cherrypy: Not Installed
       dateutil: 2.2
          gitdb: 0.5.4
      gitpython: 0.3.2 RC1
          ioflo: Not Installed
         Jinja2: 2.7.3
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.2
   mysql-python: 1.2.3
      pycparser: 2.10
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.9 (default, Jun 29 2016, 13:08:31)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.4.0
           RAET: Not Installed
          smmap: 0.8.2
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5

System Versions:
           dist: debian 8.6
        machine: x86_64
        release: 3.16.0-4-amd64
         system: Linux
        version: debian 8.6
@Ch3LL

This comment has been minimized.

Contributor

Ch3LL commented Nov 7, 2016

@ChristianBeer looks like you are right about this behavior. I confirmed this. Although I'm not certain if this is expected I would like to defer to @cachedout . Do you know if this is intended. If so we can def document it

@Ch3LL Ch3LL added this to the Blocked milestone Nov 7, 2016

@stale

This comment has been minimized.

stale bot commented Jul 20, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot added the stale label Jul 20, 2018

@ChristianBeer

This comment has been minimized.

ChristianBeer commented Jul 23, 2018

This looks like a simple documentation change once the behavior is confirmed to be intentional.

@stale

This comment has been minimized.

stale bot commented Jul 23, 2018

Thank you for updating this issue. It is no longer marked as stale.

@stale stale bot removed the stale label Jul 23, 2018

@Ch3LL

This comment has been minimized.

Contributor

Ch3LL commented Jul 24, 2018

thanks for bumping this @ChristianBeer
can anyone on @saltstack/team-core confirm this is expected?

@gtmanfred

This comment has been minimized.

Contributor

gtmanfred commented Jul 25, 2018

I believe they are looked at second, so I would think that overwrite anything read before them.

@Ch3LL

This comment has been minimized.

Contributor

Ch3LL commented Jul 27, 2018

when you say "i belivee they are looked at second" which one are you refering to? include, default_include?

@gtmanfred

This comment has been minimized.

Contributor

gtmanfred commented Jul 27, 2018

default_include gets loaded first, then include, so include would overwrite anything in the default_include.

I believe that the behavior that is being seen is correct, it would be good to just document it.

@terminalmage

This comment has been minimized.

Member

terminalmage commented Aug 2, 2018

@gtmanfred is correct. I've updated the docs in #48888 so that it describes this priority.

@ChristianBeer

This comment has been minimized.

ChristianBeer commented Aug 3, 2018

Thanks for resolving this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment