-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
[BUG] Deltaproxy: Long/Non-linear setup time. #61805
Comments
@n-holmstedt Thanks for the report. Based on the logs above I'm not seeing the issue you're reporting, I do see Salt rendering the same file for each proxy device, which could be a source of some improvement. Can you point me at some logs where you're seeing the multiple pillar data for minions being rendered for each minion? |
@garethgreenaway No problem. I'm not entirely sure how to explain it, or if i'm using the right terms at all. I uploaded some logs from the rectifiers we're using. It's just the first 10 minutes since setting up about 30 of them can take upwards to 40ish minutes and it looks like each "new" minion causes the salt-master to redo all the inits from the first minion. |
@n-holmstedt Thanks I'll look through the logs. The startup being slow is a known issue and will be fixed in 3006, the other issue about the init happening from the first minion sounds like there might be some global variables involved. And this is a custom proxy minion? Would it be possible to see the source for it? Thanks! |
And This happens if I run the code via _proxy mounted with the docker-compose same issue if I copy Dummy.py and test to run it via _proxy and I renamed it too, proxyenabled = ["patrik_dummy"].
"""
If i build an image with my custom module and put it in /usr/local/lib/python3.8/dist-packages/salt/proxy/ and exclude - ./files/_proxy:/etc/salt/_proxy ## this is in ubuntu:20.04 I have the same issue with whatever image I use via the custom proxy module via _proxy. Tested : edit: i'm one of the code writers for this custom module |
Circling back to this one with some good news. I was able to reproduce it, the bug exists when using a custom proxy module. I suspect the available modules needs to be synced for the control proxy before attempting to load any sub proxies. |
Description
I'm trying to host 32 proxy-minions in a delta-proxy process. The setup time is more than 10minutes. It seems like the master is re-rendering pillar for all the minions currently connected to to the master from the deltaproxy.
deltaproxy-1 connects to the master, its pillar is rendered.
rectifier-1 connects to the master, its pillar is rendered plus the pillar of deltaproxy-1
rectifier-2 connects to the master, its pillar is rendered plus the pillar of deltaproxy-1, rectifier 1
rectifier-3 connects to the master, its pillar is rendered plus the pillar of deltaproxy-1, rectifier 1, rectifier 2
The time it takes between two renderings is about 1s. This would be: Σ i*1s = 561s with 32 minions plus deltaproxy. which is about the setuptime that i'm looking at.
Setup
(Please provide relevant configs and/or SLS files (be sure to remove sensitive info. There is no general set-up of Salt.)
Please be as specific as possible and give set-up details.
Using the official docker image, running on a Redhat 8.2 VM.
1x Master container
1x Deltaproxy container running 32x proxy-minions with connections to http-interfaces.
top.sls
deltaproxy.sls
eltek.sls
Steps to Reproduce the behavior
Trimmed debug logs:
Expected behavior
The master should render each device pillar once.
Screenshots
If applicable, add screenshots to help explain your problem.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)Additional context
This might also affect #61153
The text was updated successfully, but these errors were encountered: