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
key_filename value from Collection.config and config file is not passed on connect to paramiko #1762
Comments
Looks like the problem is with |
Thanks for the report, just fixed the docs typo, and the rest I'll have to look at. Hoping it doesn't represent a design-level issue with the config system, but it might EDIT: to clarify the latter, the config system ought to be merging between levels without issue, and as you saw, This is absolutely a bug that needs fixing either way, since configuring one's default auth/cxn params is a top tier piece of functionality. |
Also this may need to move to Invoke if it's only at that level, but investigation is needed first. |
Looking at this now; yea, the debug log (which I hadn't looked at initially) definitely confirms the OP's suspicion that the overrides level is winning:
That comes after the per-project config file load line, which does show the user's desired value appearing there. So this has something to do with how we're populating the overrides layer, probably at the time when we take over from Invoke's default config stuff and add fabric-level specifics. What's weird is that we have a big ol' block of tests around all the various config layer interactions, specifically aimed at Those tests: Lines 651 to 749 in 3ab2d55
Output currently:
Notice how we're explicitly weaving in the 'Invoke config'. I'm guessing that this is too high-level and we're feeding in an explicit Going to try writing some more focused tests in the Config test suite to expose whatever's really going on. |
Also, looking at the code, I have a hunch this applies to all |
Seems the proximate cause is some too-strict value checking in Fabric's extension of
|
Hrm, so yea first fix easy, second fix tho...harder, because overrides are what they are. No good way to say "actually merge this one key instead of overriding with it". I'd bet most people giving Given that the actual behavior (due to this bug) resulted in "CLI wins" anyways and nobody could be relying on "CLI merges with config", I'm thinking I'll just tweak the docs and say we meant this all along. Yes...clearly. steeples fingers |
Will be out in next bugfix release. |
Python 3.6.5, Invoke 1.0.0, fabric 2.0.0, paramiko 2.4.1
First of all the argument is called
key_filenames
in documentation, but if used that way gives:TypeError: connect() got an unexpected keyword argument 'key_filenames'
But the real problem is that either using it in
Collection.confg
orfabric.yaml
or both,key_filename
value is not passed to paramiko.It looks like during the config merge phase it is detected, but overridden with an empty one
{'connect_kwargs': {'key_filename': []}}
, leading to exception:paramiko.ssh_exception.SSHException: No authentication methods available
Launching
fab -d -H c04801029 check-login > c:\tmp\fab.log 2>&1
.Debug log: fab.log
Here you see the
key_filename
initialized fromfabric.yaml
but initializing it from
Collection.config
or both together gives the very same result.The text was updated successfully, but these errors were encountered: