Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
beacons.state does not save as list #41342
Description of Issue/Question
The following state file does not produce a working setup.
The beacon config that gets applied is wrong and the beacon itself fails because a list is expected.
It should have been a list.
Latest Saltstack 2016.11.5 on CentOS 7
Steps to Reproduce Issue
Right... So I'm having a dig through the beacons module and I see that it fires an event which triggers the manage_beacons function in salt/minion.py, which then triggers the add_beacon function in beacons...
and it looks like the beacon_data is a dict object (passed in from
It seems like this would be occurring for every type of beacon, can you confirm? I don't have a test machine up right now.
I think we would need to coerce the object received via the beacon_data param into a list of dictionaries.
Hi @cetanu , thanks for your response, you are correct all beacon data is set as a dict and not a list. If you coerce the object data to a list of dictionaries things will be correct.
(I have been unable to do this with my currect Python skillset ;)
I would need somebody to confirm but it looks like the beacon_data is passed here: https://github.com/saltstack/salt/blob/develop/salt/modules/beacons.py#L125
The schema of the data should be
If a dict IS being passed into this eventer/thing... it can be transformed with:
In terms of design, I think I'd like somebody from salt to weigh in on what should be done.
or in the source function
or some place else, but I wouldn't know where
I've fixed up a bunch of code for this.
What I am seeing though, is a fair bit of inconsistency when modifying beacons.
I have a lot of trouble modifying directly with beacons.modify, although changes from beacons.modify seem to apply when I apply a highstate afterwards (even if the highstate is applying something different).
Highstates also seem to mimic this, but differently; they seem to apply correctly on a consecutive highstate, but not the first.
At this point in time I am not sure what is causing this.
I might be hallucinating as it's 12:30AM and some of my log messages aren't coming through. I'll see tomorrow.
Yep I'm definitely having some issues with persisting new beacon configuration via beacon.modify and also via highstate.
If I set up a state file with beacon.present and apply it, I can then get into an infinite loop of applying highstate, followed by checking the beacons (as one might naturally do):
Step 3 will reset the beacons back to their previous config - I do not know why. I suspect it has something to do with a call to a function called config.merge, which might be getting whatever is saved in /etc/salt/minion.d/beacons.conf and applying it over the top of the current beacons!?
Edit: Oh yeah, that's exactly what's happening. I removed the file and all of a sudden, beacons.modify works just fine and dandy (Edit 2: until a beacon config is set, then the same thing appears to happen until the next salt-minion restart clears the beacon config). Gonna look further into this.
referenced this issue
Sep 19, 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.