Skip to content
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

Scheduler config in pillar is broken (works in minion config) #6201

Closed
tanyewei opened this issue Jul 17, 2013 · 17 comments
Closed

Scheduler config in pillar is broken (works in minion config) #6201

tanyewei opened this issue Jul 17, 2013 · 17 comments
Labels
Bug broken, incorrect, or confusing behavior severity-low 4th level, cosemtic problems, work around exists
Milestone

Comments

@tanyewei
Copy link

master config:

/etc/salt/master
pillar_roots:
  base:
    - /srv/pillar

/srv/pillar/
├── schedule.sls
└── top.sls

top.sls:
base:
  '*':
    - schedule

schedule.sls:
schedule:
  highstate:
    function: state.highstate
    minutes: 1


minion config:

/etc/salt/minion
pillar_roots:
  base:
    - /srv/pillar

master cli:
salt  "*" pillar.data

return:
    schedule:
        ----------
        highstate:
            ----------
            function:
                state.highstate
            minutes:
                1

But it did not work...

Manually execute the command:
salt "*" state.highstate
The changed files can be synchronized .but schedule does not work
What went wrong?
Thanks!

@basepi
Copy link
Contributor

basepi commented Jul 17, 2013

I haven't used the scheduler at all so I'm not sure what's going wrong. But we'll look into it, thanks.

@98
Copy link

98 commented Jul 23, 2013

schedule of 0.15.3 also cann't use, please look into it. tks.

@basepi
Copy link
Contributor

basepi commented Jul 23, 2013

Can you please try putting your schedule config in the minion config rather than in pillar? Just want to narrow down the issue if we can.

@tanyewei
Copy link
Author

i putting my schedule config in the minion config,It's work!
version:0.16.0

@basepi
Copy link
Contributor

basepi commented Jul 24, 2013

So it looks like it's just broken in pillar. Good to know, I'm updating the title to reflect this.

@tanyewei
Copy link
Author

0.16.1 still not work!

@hblanks
Copy link

hblanks commented Jul 31, 2013

@basepi Thanks for the quick update.

It's only a rough sketch, but if I wanted to assemble a pull request for fixing this, would this diff be headed in the right direction?

diff --git a/salt/minion.py b/salt/minion.py
index 44a3f47..4cd9424 100644
--- a/salt/minion.py
+++ b/salt/minion.py
@@ -462,8 +462,20 @@ class Minion(object):
         self.functions, self.returners = self.__load_modules()
         self.matcher = Matcher(self.opts, self.functions)
         self.proc_dir = get_proc_dir(opts['cachedir'])
+
+        # Merge the pillar's schedule dict with our minion's
+        # configuration before passing that configuration on
+        # to the schedule.
+        schedule_opts = {}
+        if 'schedule' in self.opts['pillar']:
+            schedule_opts.update(self.opts['pillar']['schedule'])
+        if 'schedule' in self.opts:
+            schedule_opts.update(self.opts['schedule'])
+        opts = dict(self.opts)
+        opts['schedule'] = schedule_opts
+
         self.schedule = salt.utils.schedule.Schedule(
-            self.opts,
+            opts,
             self.functions,
             self.returners)

@basepi
Copy link
Contributor

basepi commented Jul 31, 2013

@hblanks We actually found a fairly substantial pillar bug today that I think was the cause of this bug. I think the pillar's scheduling dict actually is being merged in somewhere else (though I haven't tested for sure).

Could you test on the latest develop branch and tell me if it's working in pillar now?

@hblanks
Copy link

hblanks commented Aug 2, 2013

@basepi Thanks! I will have time to test this later this weekend, and will let you know.

@basepi
Copy link
Contributor

basepi commented Aug 5, 2013

@hblanks Any luck? Did you get a chance to test?

@basepi
Copy link
Contributor

basepi commented Aug 5, 2013

@tanyewei Could you please test on the newly-released 0.16.2? We fixed a substantial pillar bug that I think was the culprit.

@tanyewei
Copy link
Author

tanyewei commented Aug 6, 2013

@basepi
Thanks for you share.
I do like this:
Master config:
/srv/pillar/
├── schedule.sls
└── top.sls

top.sls:

base:
  'MINION ID':
    - schedule

schedule.sls:

schedule:
  highstate:
    function: state.highstate
    minutes: 3

And then :
salt "MINION ID" state.highstate
salt "MINION ID" pillar.data

Return:

schedule:
    ----------
    highstate:
        ----------
        function:
            state.highstate
        minutes:
            3

I try to modify a file, and then wait three minutes, it does not have to be synchronized

Master and minion version : 0.16.2

@basepi
Copy link
Contributor

basepi commented Aug 6, 2013

So it's still not scheduling properly? Did you also try restarting your minion?

@tanyewei
Copy link
Author

tanyewei commented Aug 7, 2013

@hblanks
I didn't work for me, what about you?

@basepi
Copy link
Contributor

basepi commented Aug 8, 2013

So it's fixed in #6585.

Basically, previously we would not merge the config for pillar with the config in the minion config. If the scheduler were configured in the minion config, it would ignore any configuration in the pillar. This worked fine until we introduced the mine, which by default involves the scheduler at the minion config level. This meant that it would always ignore pillar.

I wrote a new function to merge these configuration values, giving the minion config priority. Scheduler config in the pillar is working again! =D

@basepi basepi closed this as completed in 8a482ad Aug 8, 2013
thatch45 added a commit that referenced this issue Aug 8, 2013
Fix scheduler configuration from Pillar, Fix #6201
@tanyewei
Copy link
Author

Thanks ! it already work in 0.16.3

@basepi
Copy link
Contributor

basepi commented Aug 12, 2013

Woot! Glad it's working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior severity-low 4th level, cosemtic problems, work around exists
Projects
None yet
Development

No branches or pull requests

4 participants