fix nested executions using non-standard ports #1389
Conversation
|
Hi there, do you have an eta when you'll be able to review and merge this pull request? Thanks & cheerio, Harry. |
|
I'm not comfortable making this type of change at this point in 1.x's lifecycle (see http://www.fabfile.org/roadmap.html) - the chance for breaking existing-known-to-work functionality feels a bit too high :( thanks, and sorry! |
|
Hi, that's a bummer because I
The only aspect this commit disambiguates is the priority of port information, which is reflected in a comment. Working around this bug is painful and so is adding a custom patch for vanilla installations. I'd appreciate it if you could reconsider and review the changes once more. On my end, I'll promise to find time to contribute to the 2.0 roadmap. Thanks & cheerio, Harry. |
|
Thank you for taking the time for a reasoned & calm response, I appreciate it! To expand my initial reply, I'm not knocking the quality of your work or the caution you took (again, it's appreciated!). However, the history of code (or at least, all projects I've maintained) is rife with well-meaning, well-tested, small changes which nonetheless broke previously unseen/untested use cases. The more critical the code path ( So every bugfix is a risk assessment balancing act of "how many people are encountering this bug?" (I haven't seen many other reports that seem to map to this) vs "what's the chance of this bugfix causing other bugs?" (higher than I'd like). Compound that with the previously-noted conservative approach that I'm applying to Fabric 1 as 2 looms, and you get my original "ehh this changes how All that said, maintainership is a constant battle between "this could break shit!" and "people can always just roll back!" and I'm trying to cut more, smaller releases - meaning the cost of rollback should be lower than it might otherwise. So I will think about this some more and make another judgement call soon. Thanks again. |
|
Upon reflection, let's do it after all. Thanks @HarryWeppner. Adding to release milestone (feature release, because of potential impact/risk - this is a common practice :)) |
|
great - thanks for reconsidering! In the (unlikely) event it breaks something I'll be around to help... |
In the context of open_shell with sys.stdin connected to a channel, cursor movements appear "wonky", which can really mess up the user experience. An initial escape sequence is not captured correctly and only partially sent across the channel resulting in no effect. A repeated key press yields the correct sequence. I suspect this is caused by a mismatch between select (mapped to a syscall) and reading from the (buffered) sys.stdin. Dropping to the lower-level os.read resolves this issue entirely. NOTE: this may explain fabric#196
sorry, wrong branch This reverts commit 8efbff1.
|
Sorry, accidentally published a commit for a unrelated pull request here, which has been separated to pull request #1398 . |
| if env.use_ssh_config: | ||
| ssh_config_port = conf.get('port', None) | ||
|
|
||
| # port priorities (from highest to lowest) |
There was a problem hiding this comment.
This sort of thing seems to me as something that should be documented somewhere. Maybe something like this should go into the docstring here?
|
Merged, including addressing Robin's concerns. Thanks both! |
Nested executions using non-default ports did not work as env.port was prioritized over hostname and ssh config derived port numbers.
See test_tasks.py:TestExecute.test_nested_execution_with_explicit_ports