-
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
PoC / WiP for #48067 and related #51636
Conversation
You haven't made any changes to the I think what we'd want is something similar to what you've done (though maybe someone else in @saltstack/team-core who's more familiar with salt-ssh can weigh in on this), since this appears to actually be asking the master for the file. What I think we'd want is to have the file client injected into the fileclients on the client. If that's not too many clients If you need me to hunt it down, I can find the place I think it's in the cmd module, where it's checking fileclients - that's where we'd want this one, I believe. |
Well I figured out the wrapper is actually only executed master-side upon direct invocation. |
Ahh. That makes some sense, regarding what we've seen. It sounds like we just need to see if it's possible for the salt-ssh master to receive file requests, rather than the existing method of bundling up the file when we start the call. |
Some sort of wrapper or utility function like this would still be very handy for the modules which do include I was looking at getting saltcheck to support salt-ssh, and it looks like it will need to override the Relatedly, when testing out this PR, I noticed that
So rather than populating
|
@The-Loeki This needs to be re-opened against the |
Dude this was a test-case in last February while you guys were really busy upgrading your pipelines. So please don't 'just' close this |
What does this PR do?
Salt-SSH 'wraps' around the
cp
module to enable transport over SSH. This wrap is however incomplete and is done by manually rewriting parts of the original function in the wrapper.As a number of functions are missing, the direct invocation of salt-ssh will b0rk on them, subtly or less so for range of modules & functions.
See discussion in #48067.
This is a working PoC to take a slightly different tack on that problem, by injecting a modified
fileclient
.The end result is that the function calls to the cp module can be left untouched & be called directly, increasing stability, reducing code dupliation and erroneous and unexpected behaviour from
salt-ssh
when calling modules directly.I would really like some input on this solution before proceeding, as I'm not sure I fully understand the consequences of what I'm doing here code/namespace/injection/cleanliness wise.
What issues does this PR fix or reference?
#48067
#50525
#50196
#50351
Previous Behavior
Salt-SSH Wrapping functions in the
cp
module is cumbersome and difficultNew Behavior
Salt-SSH Wrapping functions in the
cp
module is a matter of pointing at the actualcp
module and very maybe add/overload a function.Tests written?
No
Commits signed with GPG?
Yes/No
Please review Salt's Contributing Guide for best practices.
See GitHub's page on GPG signing for more information about signing commits with GPG.