after update to 1.8.1: unknown VMODL type AnyType about rbvmomi HOT 30 CLOSED

Thanks for the report. Can you tell me what kind of object you are retrieving so I can more easily reproduce this?

from rbvmomi.

I get the from OSX Mavericks or Ubuntu 12.04 connecting to vCenter 5.5 just doing an 'ls' in a vCenter object:

0 /
1 the-vcenter01/

cd 1
/the-vcenter01> ls
RuntimeError: unknown VMODL type AnyType

If I downgrade to rbvmomi1.6.0 and rvc 1.7.0 everything works as expected.

from rbvmomi.

In this particular case I retrieve ClusterComputeResource objects, but faced same issue with virtual machine objects as well. Here is full code:

folder_traversal_spec = RbVmomi::VIM.TraversalSpec(
    :name => 'tsFolder',
    :type => 'Folder',
    :path => 'childEntity',
    :skip => false,
    :selectSet => [
      RbVmomi::VIM.SelectionSpec(:name => 'tsFolder'),
      RbVmomi::VIM.SelectionSpec(:name => 'tsDatacenterHostFolder'),
      RbVmomi::VIM.SelectionSpec(:name => 'tsClusterHost')
    ]
  )
  datacenter_cluster_traversal_spec = RbVmomi::VIM.TraversalSpec(
    :name => 'tsClusterHost',
    :type => 'ClusterComputeResource',
    :path => 'host',
    :skip => false,
    :selectSet => []
  )
  datacenter_folder_traversal_spec = RbVmomi::VIM.TraversalSpec(
    :name => 'tsDatacenterHostFolder',
    :type => 'Datacenter',
    :path => 'hostFolder',
    :skip => false,
    :selectSet => [
      RbVmomi::VIM.SelectionSpec(:name => 'tsFolder')
    ]
  )
  obj_spec = RbVmomi::VIM.ObjectSpec(
    :obj => connection.rootFolder,
    :skip => false,
    :selectSet =>
    [
      folder_traversal_spec,
      datacenter_folder_traversal_spec,
      datacenter_cluster_traversal_spec
    ]
  )

  property_specs = [
    { :type => 'Folder', :pathSet => ['name', 'parent'] },
    { :type => 'ClusterComputeResource', :pathSet => ['name', 'parent'] }
  ]

  filter_spec =  RbVmomi::VIM.PropertyFilterSpec(:propSet => property_specs, :objectSet => [obj_spec])

  result =  connection.propertyCollector.RetrieveProperties(:specSet => [filter_spec])

from rbvmomi.

I tried your code and can't reproduce this. With 1.8 I switched the deserializer over to a new one, which existed for a long time but for some reason was never the default in external rbvmomi releases.

Could you open deserialize.rb and in line 45 at the beginning of deserialize() add:
pp ["node", node]
pp ["type", type]

Btw, are you both using ruby 1.8? I notice this "/usr/lib/ruby/1.8/monitor.rb" in the backtrace.

from rbvmomi.

I tried out ruby 1.8.7 and still didn't hit this with your sample code.

from rbvmomi.

I'm also getting this same issue with 1.8.

/Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/type_loader.rb:103:in `make_type': unknown VMODL type AnyType (RuntimeError)
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/type_loader.rb:65:in `block in get'
    from /Users/epeterson/.rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/type_loader.rb:63:in `get'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:78:in `deserialize'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:116:in `block in traverse_data'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:98:in `each'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:98:in `traverse_data'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:81:in `deserialize'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:111:in `block in traverse_data'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:98:in `each'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:98:in `traverse_data'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/deserialization.rb:81:in `deserialize'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/connection.rb:68:in `block in parse_response'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/connection.rb:68:in `map'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/connection.rb:68:in `parse_response'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/connection.rb:90:in `call'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/basic_types.rb:205:in `_call'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/basic_types.rb:74:in `block (2 levels) in init'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/basic_types.rb:183:in `_get_property'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/rbvmomi-1.8.0/lib/rbvmomi/basic_types.rb:35:in `block (2 levels) in init'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:75:in `virtual_machines'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:130:in `virtual_machine'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:106:in `snapshots'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:99:in `revert_to_snapshot'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-cavalry-1.1/lib/cavalry/vmware_box.rb:93:in `destroy'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/lib/tasks.rb:45:in `destroy'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/lib/tasks.rb:31:in `smoketest'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/lib/tasks.rb:138:in `<top (required)>'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/bin/smokey:3:in `require_relative'
    from /Users/epeterson/.gem/ruby/1.9.3/gems/damballa-smokey-1.1.0/bin/smokey:3:in `<top (required)>'
    from /Users/epeterson/.gem/ruby/1.9.3/bin/smokey:23:in `load'
    from /Users/epeterson/.gem/ruby/1.9.3/bin/smokey:23:in `<main>'

The call that enters rbvmomi is vim.serviceInstance.content.rootFolder where vim is a RbVmomi::VIM object

from rbvmomi.

Could you open deserialize.rb and in line 45 at the beginning of deserialize() add:
pp ["node", node]
pp ["type", type]

I have spent multiple hours trying to reproduce this and can't. I don't know whats different about my environment.

from rbvmomi.

Can you paste the entire output, including the error? Maybe use pastebin :)

from rbvmomi.

I rescued the error in deserialization.rb and opened up a pry session: https://gist.github.com/subwindow/8100461

Let me know if you want to dig around in anything else.

from rbvmomi.

Thanks for digging into. Yes, I use ruby 1.8. Nokogiri is 1.5.11. Here is output with modified deserialize:
http://pastebin.com/8stStppL

from rbvmomi.

I looked at the output from subwindow:

Weird!

The method starts with:
type_attr = node['type']
type = type_attr if type_attr

So based on the output, I would have expected node['type'] to be set to "ServiceContent". But instead, it appears to be nil, so anyType is not overwritten with anything and hence the issue later down in the method. Can you confirm that?

from rbvmomi.

Yes, node['type'] is nil.

from rbvmomi.

Whats your nokogiri version? Mine is:
nokogiri (1.5.5, 1.5.2)

from rbvmomi.

1.6.1, which is the latest.

from rbvmomi.

We found it! Nokogiri 1.6.1 broke it! I just upgraded to it and now I am able to reproduce. Thanks for the help. Now I am sure I will be able to fix it.

from rbvmomi.

nokogiri 1.5.10 has the same issue

from rbvmomi.

Nokogori > 1.5.5 breaks rbvmomi 1.8.1
Thanks for all the help, guys!

from rbvmomi.

Is there going to be a code fix? At the very least a temporary change should be made to the gem specification mandate a compatible version of nokogiri.

from rbvmomi.

Is there a reason this is closed? This issue is still happening and is currently a major pain.

from rbvmomi.

You can work around it by specifying a compatible version of nokogiri in your Gemfile. There really needs to be a code fix in rbvmomi though.

from rbvmomi.

Could this issue be re-opened at least please?

from rbvmomi.

Nokogori 1.5.5 is not compatible with Ruby 2.0, so the workaround is not acceptable.
Can you suggest any other solutions?

from rbvmomi.

I'm having the same problem and cannot find a way around it. rbvmomi is used by a vagrant plugin vagrant-vsphere (https://github.com/nsidc/vagrant-vsphere) and this plugin requires nokogiri 1.5.10 (doco says it forces use of 1.5.10). Vagrant uses Ruby 2.0.

I'm surprised this is closed without a workable solution. Any suggestions of how to work around this would be welcome.
thanks

from rbvmomi.

I installed Nokogori 1.5.1 and removed all other versions. Then uninstalled and re-installed rbvmomi and the error goes away.

from rbvmomi.

@bwallis42 @jeremythehunt @mkuzmin
Can you guys try out #32

from rbvmomi.

That did the trick for me. I made the modification to deserialization.rb in my installed gem (in vagrant's gem directory) and now the vagrant-vsphere plugin is working.

Thanks very much for that!
regards.

from rbvmomi.

No worries mate, let me know if you run into any troubles, possibly over at https://github.com/dekz/rbvmomi

from rbvmomi.

Is there any chance that this will be fixed, rather than just pinning to an old version?

from rbvmomi.

@aramprice I think #32 resolves this issue, though there's no release yet.

from rbvmomi.

@domcleal - great news, thanks!

from rbvmomi.