Skip to content
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

Plugin needs to cache good addreses #275

Open
jkugler opened this issue Dec 20, 2018 · 3 comments
Open

Plugin needs to cache good addreses #275

jkugler opened this issue Dec 20, 2018 · 3 comments

Comments

@jkugler
Copy link

jkugler commented Dec 20, 2018

I have a very odd case. I'm using vagrant with vCenter, and using rsync folders. Most of the time it works, but some times the VM will boot, properly report its IPv4 address, swap out the ssh keys, but when it goes to connect for the rsync, it tries to use the VM's link-local address, and fails. Like so (please forgive the Jenkins copy/paste)

-----> Starting Kitchen (v1.23.2)
-----> Cleaning up any prior instances of <source-rhel-6-bento>
-----> Destroying <source-rhel-6-bento>...
       Finished destroying <source-rhel-6-bento> (0m0.00s).
-----> Testing <source-rhel-6-bento>
-----> Creating <source-rhel-6-bento>...
       Bringing machine 'default' up with 'vsphere' provider...
       ==> default: Calling vSphere CloneVM with the following settings:
       ==> default:  -- Template VM: DC1/vm/CICD/bento-rhel-6.10-x86_64-LATEST
       ==> default:  -- Target VM: DC1/vm/CICD/source-rhel-6-bento-project-1545253719-50
       ==> default: New virtual machine successfully cloned
       ==> default: Waiting for the machine to report its IP address...
           default: Timeout: 240 seconds
           default: IP: 10.199.251.38
       ==> default: Waiting for machine to boot. This may take a few minutes...
           default: SSH address: 10.199.251.38:22
           default: SSH username: vagrant
           default: SSH auth method: private key
           default: 
           default: Vagrant insecure key detected. Vagrant will automatically replace
           default: this with a newly generated keypair for better security.
           default: 
           default: Inserting generated public key within guest...
           default: Removing insecure key from the guest if it's present...
           default: Key inserted! Disconnecting and reconnecting using new SSH key...
       ==> default: Machine booted and ready!
       ==> default: Setting hostname...
       ==> default: Installing rsync to the VM...
       ==> default: Rsyncing folder: /var/lib/jenkins/workspace/MergeRequests/project/Distribution/rhel-6/Image/bento/ => /test_local_files/juniper/project
       There was an error when attempting to rsync a synced folder.
       Please inspect the error message below for more info.
       
       Host path: /var/lib/jenkins/workspace/MergeRequests/project/Distribution/rhel-6/Image/bento/
       Guest path: /test_local_files/company/project
       Command: "rsync" "--verbose" "--archive" "--delete" "-z" "--copy-links" "--no-owner" "--no-group" "--rsync-path" "sudo rsync" "-e" "ssh -p 22 -o LogLevel=FATAL  -o ControlMaster=auto -o ControlPath=/tmp/ssh.413 -o ControlPersist=10m  -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i '/var/lib/jenkins/workspace/MergeRequests/project/Distribution/rhel-6/Image/bento/.kitchen/kitchen-vagrant/source-rhel-6-bento/.vagrant/machines/default/vsphere/private_key'" "--exclude" ".vagrant/" "/var/lib/jenkins/workspace/MergeRequests/project/Distribution/rhel-6/Image/bento/" "vagrant@[fe80::250:56ff:fe97:154c]:/test_local_files/company/project"
       Error: rsync: connection unexpectedly closed (0 bytes received so far) [sender]
       rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.2]</pre>

It had the "good" IPv4 address, and it worked. Then it got the IPv6 link-local address from somewhere, which did not work. Can we cache the first-reported address? Or ignore link-local addresses, and ask again? I guess some environments do use link local addresses, so discarding may not be the best course of action. But caching the address first acquired seems like a sane thing to do.

@jkugler
Copy link
Author

jkugler commented Dec 20, 2018

@jkugler
Copy link
Author

jkugler commented Feb 5, 2019

Another example where it found the good address, but when asked for it later, returned a bad address.

-----> Creating <source-rhel-6-bento>...
       Bringing machine 'default' up with 'vsphere' provider...
       ==> default: Calling vSphere CloneVM with the following settings:
       ==> default:  -- Template VM: B5 Lab - OpSun/vm/CICD/bento-rhel-6.10-x86_64-LATEST
       ==> default:  -- Target VM: B5 Lab - OpSun/vm/CICD/source-rhel-6-bento-testing-utils-1549399882-d7
       ==> default: New virtual machine successfully cloned
       ==> default: Waiting for the machine to report its IP address...
           default: Timeout: 240 seconds
           default: IP: 10.199.251.191
       ==> default: Waiting for machine to boot. This may take a few minutes...
           default: SSH address: 10.199.251.191:22
           default: SSH username: vagrant
           default: SSH auth method: private key
           default: 
           default: Vagrant insecure key detected. Vagrant will automatically replace
           default: this with a newly generated keypair for better security.
           default: 
           default: Inserting generated public key within guest...
           default: Removing insecure key from the guest if it's present...
           default: Key inserted! Disconnecting and reconnecting using new SSH key...
       ==> default: Machine booted and ready!
       ==> default: Setting hostname...
       ==> default: Machine not provisioned because `--no-provision` is specified.
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Failed to complete #create action: [Invalid argument - connect(2) for [fe80::250:56ff:fe97:52b4]:22] on source-rhel-6-bento
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

@jkugler
Copy link
Author

jkugler commented Feb 9, 2019

As a work-around for this issue, disabling IPv6 on the guest images (whether VMs or templates) seems to fix the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant