Pull requests

#4 Merged
Repository
heyvaerm heyvaerm
Branch
fix-disable-known-hosts
Repository
andrewmacgregor andrewmacgregor
Branch
develop

Respect the fabric -D option in rsync transfers (disable_known_hosts)

Author
  1. Michael Heyvaert
Reviewers
Description

Test + fix, I use this for working with vagrant vms that get rebuild regularly, so the host key entry changes each time.

Comments (6)

  1. Andrew Macgregor repo owner

    Michael, this test is not working for me on this branch:

    Traceback (most recent call last):
      File "/Users/andrew/Personal/hg-devel/other_parcels/parcel/vptest/lib/python2.7/site-packages/mock.py", line 1201, in patched
        return func(*args, **keywargs)
      File "/Users/andrew/Personal/hg-devel/other_parcels/parcel/tests/test_tools.py", line 137, in test_rsync
        rsync_local.calls_args[0][0])
    AssertionError: "rsync -av -e 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'" not found in <MagicMock name='rsync_local.calls_args.__getitem__().__getitem__()' id='4323003984'>
    

    It might just be my setup though. Would you might double checking for me?

  2. Michael Heyvaert author

    I encounter the same issue on ubuntu, the test worked on my other system. It is possible to fix the test by adding a unicode prefix to the test string:

    --- a/tests/test_tools.py   Tue Oct 08 13:02:34 2013 +0200
    +++ b/tests/test_tools.py   Wed Nov 13 11:47:06 2013 +0100
    @@ -132,9 +132,9 @@
                 rsync(test_file, 'test.tar.gz')
    
                 # rsync command should specify ssh command
    -            self.assertIn("rsync -av -e 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'",
    +            self.assertIn(u"rsync -av -e 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'",
    
             # combine keyfile and port
             with settings(key_filename="/some/path/to/a/keyfile.pub", port=3232):
    

    but I first want to understand why this issue is specific to this test. I will update the pull request afterwards

  3. Andrew Macgregor repo owner

    Strange - a problem with assertIn I reckon - I see it is relatively new. It also won't work under 2.6.x so we might be better going back to

    self.assert("x" in "xxxx")
    
  4. Michael Heyvaert author

    I just found the real cause, it was a simple type calls_args -> call_args, due to the MagickMock this call returned None instead of throwing an error. I must have corrected the attribute while debugging the issue, sorry for the confusion.

    The pull is updated with the fixed version.