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

fix nested executions using non-standard ports #1389

Merged
merged 3 commits into from Apr 7, 2016

Conversation

Projects
None yet
3 participants
@HarryWeppner

HarryWeppner commented Oct 14, 2015

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

@HarryWeppner

This comment has been minimized.

HarryWeppner commented Oct 19, 2015

Hi there,

do you have an eta when you'll be able to review and merge this pull request?

Thanks & cheerio, Harry.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Oct 26, 2015

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!

@HarryWeppner

This comment has been minimized.

HarryWeppner commented Nov 3, 2015

Hi,

that's a bummer because I

  • tried to keep code changes to an absolute minimum
  • avoided larger refactoring to stay within the existing style
  • made sure it passes all existing tests
  • added a new test to avoid future regressions

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.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Nov 3, 2015

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 (network.connect is as critical as it gets), the more of those pitfalls come into play.

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 connect() handles port numbers, that's scary" reaction.


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.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Nov 10, 2015

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 :))

@bitprophet bitprophet reopened this Nov 10, 2015

@bitprophet bitprophet added this to the 1.11 milestone Nov 10, 2015

@HarryWeppner

This comment has been minimized.

HarryWeppner commented Nov 12, 2015

great - thanks for reconsidering! In the (unlikely) event it breaks something I'll be around to help...

Harald Weppner added some commits Nov 13, 2015

Harald Weppner
fix escape sequences in open_shell
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 #196
Harald Weppner
Revert "fix escape sequences in open_shell"
sorry, wrong branch

This reverts commit 8efbff1.
@HarryWeppner

This comment has been minimized.

HarryWeppner commented Nov 13, 2015

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)

This comment has been minimized.

@kaaveland

kaaveland Jan 22, 2016

This sort of thing seems to me as something that should be documented somewhere. Maybe something like this should go into the docstring here?

nested executions should work with defined ports
"""
def sub_task_one():

This comment has been minimized.

@kaaveland

kaaveland Jan 22, 2016

Matter of personal taste I guess, but I think the main task would read more clearly if this was named something like assert_port_is_2201

@bitprophet bitprophet merged commit ac4762f into fabric:master Apr 7, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

bitprophet added a commit that referenced this pull request Apr 7, 2016

@bitprophet

This comment has been minimized.

Member

bitprophet commented Apr 7, 2016

Merged, including addressing Robin's concerns. Thanks both!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment