Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Minions apparently doing *way* too much (crypto) work #2359
One of the machines I am currently using to evaluate salt doesn't have much
Starting the minion reveals some interesting stuff:
It seems like it's loading the minion key 7 times and decrypting the master
This is not only the case during startup, a simple highstate call to this
Here is the corresponding trace output
During this run, it loaded the minion key 31 times, decrypted the master key
So I think there is a whole lot of duplicate work being done, but foremost,
The minion maintains a connection with the master. The really expensive step
I'm still able to reproduce it with 2014.7.1 even when forcing an agressive 1 minute keep-alive probe. I have a mine function schedule at every minute and it generated 3 decryptions for a single job.
I'm not sure, I just read code from the github, but I think that the minion key isn't cached (salt.crypto::get_keys). In my case it's was loaded 4 times and decrypted at least 3 without counting all the master key operations.
salt-minion -l debug (minion is installed on the salt-master)
Yeah, as sad as it sounds, but in 2.5 years since I first looked at Salt and noted a few serious problems (e.g. also #2361 and #3436), I don't think the team has done anything in this direction. Salt is still NIH-ridden and especially its unreliable transport mechanism (incl. crypto) have made me look elsewhere… sadly, because I liked the community :/
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.