lstoll/fog-octocloud — pull request #12 by rubiojr (2013-08-02 22:09:29+00:00)
Title: Minor fix to be able import local OVA files

OVA -> cube conversion is not working for me for some reason.

The patch changes the convert_cube.rb request so that when converting
the OVA to a Cube, all the cube files remain in the same directory
(named after the cube name).

Right now (without the patch), the conversion process produces:

```sh
$ find ~/.octocloud/boxes/
/Users/rubiojr/.octocloud/boxes/
/Users/rubiojr/.octocloud/boxes//test-cube
/Users/rubiojr/.octocloud/boxes//test-cube/.md5
/Users/rubiojr/.octocloud/boxes//test-cube.vmwarevm
/Users/rubiojr/.octocloud/boxes//test-cube.vmwarevm/vmwarebox-disk1.vmdk
/Users/rubiojr/.octocloud/boxes//test-cube.vmwarevm/vmwarebox.vmx
```

So the .md5 is created in a different directory (test-cube). This
apparently breaks cube listings at least.

The code I'm using to test:

```ruby
require 'pp'
require 'fog'
require 'fog-octocloud'

octoc = Fog::Compute.new( :provider => 'octocloud' )
cube = octoc.cubes.create :name => 'test-cube',
:source => File.expand_path('~/tmp/tinycore-477.ova')

pp octoc.cubes
```

This raises an exception when listing the cubes after
importing/converting the OVA to a Cube:

```sh
/Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:12:in `initialize': No such file or directory - /Users/rubiojr/.octocloud/boxes/test-cube.vmwarevm/.md5 (Errno::ENOENT)
from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:12:in `open'
from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:12:in `block in local_list_boxes'
from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:9:in `map'
from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:9:in `local_list_boxes'
from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/models/compute/cubes.rb:14:in `all'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/fog-1.14.0/lib/fog/core/collection.rb:141:in `lazy_load'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/fog-1.14.0/lib/fog/core/collection.rb:22:in `pretty_print'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:154:in `block in pp'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:217:in `block (2 levels) in group'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:243:in `nest'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:216:in `block in group'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:228:in `group_sub'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:215:in `group'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:154:in `pp'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:77:in `block in pp'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:121:in `guard_inspect_key'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:77:in `pp'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:60:in `block in pp'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:59:in `each'
from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:59:in `pp'
from test2.rb:18:in `

'
```

With the patch applied, the .vmwarevm directory is renamed to
and the .md5 is created inside of it.

I'm not really sure if this is the behaviour we should expect so any input on
this is greatly appreciated.