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
salt-api no longer forces the default timeout #38527
Conversation
Go Go Jenkins! |
Hi @rbjorklin - Can you explain a little more about why I ran across this change during a merge forward as there was a merge-conflict here between this change and the one made in #38560. The key overriding for After looking at these two conflicting changes, it seems to me that the For the time being, I am using the changes from 2016.3 to merge forward, and we can certainly discuss this further here and make whatever changes are needed. I want to make sure all of the moving pieces here are covered. Please see PR #38570 for the merge forward change. |
I think what he is attempting to say is the api default rest_timeout value of 300 is overwriting the users rest_timeout in their config is that correct? I'm assuming this because of the issue here: #38524 but the PR title here confuses me a bit as the intention. If the intention is to not overwrite the users
|
@rallytime The way I'm reading the existing code we get the master.conf opts and then overwrite them with the default here. My proposed change get's the defaults first and then overwrite them with the ones from master.conf. This should not break the @Ch3LL That's correct, sorry if I was being a bit unclear. That's basically what my change does but without the explicit step. By updating the entire config you don't have to maintain the explicit steps every time a new salt-api option is added. Did that make things any clearer? |
@Ch3LL and @rbjorklin Thanks for explaining what needed to be done for the My concern here with the way this change stands is that I am unsure of where the This change makes it so that It is OK with me if we keep the updates as they are here, as I agree with @rbjorklin that this is a better way to move forward so we don't have to update each default API value. However, we need to make sure we account for the change to the |
@rbjorklin and @Ch3LL - Can you guys take a look at the change I made in #38585 on the 2016.3 branch? I think that explains in code more what I mean. Hopefully that makes more sense! |
That looks great to me @rallytime ! That should grab all those configurations as you stated from what I can tell. 👍 |
@rallytime #38585 looks good! I initially missed that we stored the value from |
Ok awesome! Thanks everyone. I'll write some tests for the change in my PR. |
This will help prevent regressions in this area as discussed in PR saltstack#38527.
What does this PR do?
What issues does this PR fix or reference?
Fixes #38524
Previous Behavior
default rest_timeout was forced
New Behavior
rest_timeout is usable again
Tests written?
No