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

new grains not refreshed for matches #5737

Closed
knightsamar opened this issue Jun 26, 2013 · 11 comments
Closed

new grains not refreshed for matches #5737

knightsamar opened this issue Jun 26, 2013 · 11 comments
Assignees
Labels
Bug broken, incorrect, or confusing behavior severity-low 4th level, cosemtic problems, work around exists

Comments

@knightsamar
Copy link

When a new grain is distributed to the minions by using saltutil.sync_grains, it's data is listed when doing a grains.items but the data cannot be used while matching based on the grains using -G option.

For example, writing a grain like the below

def something():
     return {'spell':'alohomora'}

And running
salt '*' saltutil.sync_grains
will distribute the grain.

And it will even show in the output of
sudo salt '*' grains.items

But matching minions, based on the newly written grain data does not work.
salt -G 'spell:alohomora' test.ping

Unless, the minion is restarted OR saltutils.sync_modules is run from the master, matches based on this new grain do not seem to work.

Shouldn't there be some command to get the minion to send/store the newly gained grain ? And shouldn't it be triggered automatically when we do sync_grains ?

@basepi
Copy link
Contributor

basepi commented Jun 26, 2013

What version are you running? We fixed a bug with regard to this issue recently, and I'm thinking you might not be running the latest.

@knightsamar
Copy link
Author

@basepi I am using 0.15.3 on both minion and master.
What version is this issue fixed in ?

@basepi
Copy link
Contributor

basepi commented Jun 27, 2013

I'm not sure off the top of my head. Any chance you could test with the 0.16.0 RC (0.15.90) on PyPI, or from the develop branch in git?

@knightsamar
Copy link
Author

@basepi, I just tested with 0.15.90 from PyPi on both master and minion and I still have to run saltutils.sync_modules so that the grain can be matched against.

I will test on the develop branch soon and get back.

@basepi
Copy link
Contributor

basepi commented Jun 28, 2013

I appreciate it. If it wasn't fixed in 0.15.90, then it probably is not fixed in develop, but I haven't been paying super close attention so I can't be sure. =)

@knightsamar
Copy link
Author

@basepi, I am trying to setup master and minion using develop branch, using the instructions at https://salt.readthedocs.org/en/latest/topics/hacking.html#posting-patches-to-the-mailing-list but I still get 0.15.90 as the version when I run salt --version. Is this the right behavior and would I be testing on the right version?

@basepi
Copy link
Contributor

basepi commented Jul 8, 2013

I thought we added a 0.16 tag to make it properly parse as a 0.16 version, but I can't remember. Did you do a git pull before you installed?

In any case, it sounds like the issue is still there in develop, so we'll look into it.

@ghost
Copy link

ghost commented Sep 19, 2013

ref: #7334

@ghost ghost assigned cachedout Oct 17, 2013
@thatch45
Copy link
Contributor

@cachedout also make it so that grains get auto refreshed every n minutes, say 5 by default and make it configurabel

cachedout pushed a commit to cachedout/salt that referenced this issue Oct 17, 2013
…ars so that it can fire an event back to the master to inform it of its new state. Refs saltstack#5737.
@cachedout
Copy link
Contributor

The above PR should address the original issue. Before closing this, I still need to add functionality so that the minion will auto-update its grains every 5 minutes (configurable) and only send a pillar refresh if the grains have changed. (Per @thatch45)

s0undt3ch added a commit that referenced this issue Oct 18, 2013
Fix for #5737 and some minor doc changes.
@cachedout
Copy link
Contributor

Pull req pending for auto-refresh.

cachedout pushed a commit that referenced this issue Oct 30, 2013
…ars so that it can fire an event back to the master to inform it of its new state. Refs #5737.
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