Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 680822

Summary: Ansible provision post vagrant creation
Product: Gentoo Linux Reporter: gjy0724 <n8hth>
Component: Current packagesAssignee: Gentoo Linux bug wranglers <bug-wranglers>
Status: RESOLVED CANTFIX    
Severity: normal    
Priority: Normal    
Version: unspecified   
Hardware: AMD64   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description gjy0724 2019-03-18 02:38:56 UTC
I have discovered a possible bug, or hopefully just a missed USE tag.  I am attempting to create vagrant boxes using libvirt with provisioning of the box with vagrant after creation, a practice that works fine with CentOS/SL but I want to move back to Gentoo.

The first step works fine, however upon the initiating of the provisioning process with ansible the process fails with the following error.

/home/gjy0724/.vagrant.d/gems/2.4.5/gems/fog-libvirt-0.5.0/lib/fog/libvirt/requests/compute/list_domains.rb:9:in `lookup_domain_by_uuid': Call to virDomainLookupByUUID failed: internal error: client socket is closed (Libvirt::RetrieveError) 
   from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/fog-libvirt-0.5.0/lib/fog/libvirt/requests/compute/list_domains.rb:9:in `list_domains' 
   from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/fog-libvirt-0.5.0/lib/fog/libvirt/models/compute/servers.rb:15:in `get' 
   from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/driver.rb:65:in `get_domain' 
   from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/driver.rb:79:in `created?' 
   from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/provider.rb:101:in `state' 
   from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/action/wait_till_up.rb:105:in `terminate' 
   from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/action/wait_till_up.rb:101:in `recover' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:67:in `block in recover' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:64:in `each' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:64:in `recover' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/builtin/call.rb:61:in `recover' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:67:in `block in recover' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:64:in `each' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:64:in `recover' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:53:in `rescue in call' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:28:in `call' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/builder.rb:116:in `call' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/runner.rb:66:in `block in run' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/util/busy.rb:19:in `busy' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/runner.rb:66:in `run' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/machine.rb:239:in `action_raw' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/machine.rb:208:in `block in action' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/environment.rb:614:in `lock' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/machine.rb:194:in `call' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/machine.rb:194:in `action' 
   from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

The with trial and error I have worked out a work-around which is to remove the box image in the libvirt image folder (/var/lib/libvirt/images) and restart libvirtd, but I find it much less than ideal as it is required everytime I create a new box image that is intended to run ansible against.  More info can be found in the forums (https://forums.gentoo.org/viewtopic-t-1091024-highlight-libvirt.html?sid=365ff17f392faa42b239f24cbeb8c6ab) and as one of the issues in the vagrant-libvirt github repository here (https://github.com/vagrant-libvirt/vagrant-libvirt/issues/963)

Current versions are as follows:
libvirt: 4.9.0
vagrant: 2.2.2
ansible: 2.7.6

Thank you in advance
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2019-03-18 17:33:15 UTC
Please tell us what the bug is when you find it, not during the discovery phase, and only then if it is something that should be solved in the Gentoo distribution and not actually elsewhere.
Comment 2 gjy0724 2019-03-18 18:09:08 UTC
How exactly can I tell were the bug is?  While I admit that vagrant with libvirt seems to work fine, the fact that I have to remove the image file from the /var/lib/libvirt/images folder then restart the libvirtd daemon in order to get ansible to provision the newly created box/instance does at least suggest possible involvement.

I have created issues with vagrant, vagrant-libvirt, fog-libvirt, and now created this bug on the issue.  Hashicorp also closed the issue I created on this, as you may have seen the issue with vagrant-libvirt was at least helpful enough to figure out a work-around, and I haven't heard from fog-libvirt yet. I did update fog-libvirt to latest and the issue persists.

I just wanted to cover my bases with libvirt here to see if there is anything I am missing.  If you can think of anything that would help, please let me know.