frapposelli / vagrant-vcloud

Vagrant provider for VMware vCloud Director®
MIT License
67 stars 38 forks source link

BuildVApp action breaks if fetching metadata for previously failed box upload #146

Closed mtkennerly closed 3 years ago

mtkennerly commented 6 years ago

This one needs a bit of background: I originally tried to upload a box with an incorrect filename into a catalog with other items, and the upload was initiated (could see it pending on the site), but failed right away on the client side since the file wasn't found. This left a pending upload on the vCloud site, and even when I hit cancel, it stayed in a "cancelling import..." state indefinitely.

After some other experiments, I tried uploading it into an empty catalog and hit the following error. The affected line is:

vm_name => cfg.catalog_item[:vms_hash].first.last[:id]

I added a print to double check it, and cfg.catalog_item[:vms_hash] is {} in this scenario.

Full error:

$ vagrant up
Bringing machine 'pos' up with 'vcloud' provider...
==> pos: Building vApp...
E:/.vagrant.d/gems/2.2.5/gems/vagrant-vcloud-0.4.7/lib/vagrant-vcloud/action/build_vapp.rb:262:in `call': undefined method `last' for nil:NilClass (NoMethodError)
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from E:/.vagrant.d/gems/2.2.5/gems/vagrant-vcloud-0.4.7/lib/vagrant-vcloud/action/inventory_check.rb:15:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from E:/.vagrant.d/gems/2.2.5/gems/vagrant-vcloud-0.4.7/lib/vagrant-vcloud/action/connect_vcloud.rb:50:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/builder.rb:116:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/action/runner.rb:66:in `run'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/machine.rb:225:in `action_raw'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/machine.rb:200:in `block in action'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/environment.rb:567:in `lock'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/machine.rb:186:in `call'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/machine.rb:186:in `action'
        from C:/Vagrant/1.9.3/embedded/gems/gems/vagrant-1.9.3/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

At first, I thought the problem was with the catalog being empty. However, I tried it again on the original catalog and got the same error. Then I tried doing it in another empty catalog by partially renaming the box but keeping the filename the same, which triggered an error from the server:

Invalid request [ 5874084a-cdb4-47df-80ae-a61c79d37974 ] The VCD entity rpos/pos-win7-vcloud already exists.

That error is fine since it just means the plugin is correctly handling the empty catalog and the server complained, but then I wasn't sure why the empty hash happened before. My best guess is that the plugin was retrieving metadata for the "cancelling import..." upload, and that metadata was empty. Not 100% positive, but that's what it seems like.