vmware-archive / rbvmomi

Ruby interface to the VMware vSphere API.
MIT License
302 stars 175 forks source link

RbVmomi deserialization fails on managed object type `ContentLibrary` #205

Open agrare opened 3 years ago

agrare commented 3 years ago

Describe the bug Running a simple WaitForUpdates event catcher (watching latestPage from the eventManager) [ref] and observed an exception when a scheduled "Sync Library" task ran. When we caught this event an exception was raised by deserialization because it couldn't find the ContentLibrary type. Further investigation shows that there was a task with an entity of ManagedObjectReference:ContentLibrary clib-2895

To Reproduce Steps to reproduce the behavior:

  1. Synchronize a Content Library
  2. vim.serviceContent.taskManager.recentTask.first.info
  3. :boom:
>> vim.serviceContent.taskManager.recentTask.first.info
Traceback (most recent call last):
       16: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `traverse_data'
       15: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `each'
       14: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:119:in `block in traverse_data'
       13: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:90:in `deserialize'
       12: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `traverse_data'
       11: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `each'
       10: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:124:in `block in traverse_data'
        9: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:90:in `deserialize'
        8: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `traverse_data'
        7: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `each'
        6: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:124:in `block in traverse_data'
        5: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:87:in `deserialize'
        4: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/type_loader.rb:65:in `get'
        3: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/type_loader.rb:65:in `synchronize'
        2: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/type_loader.rb:67:in `block in get'
        1: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/type_loader.rb:105:in `make_type'
RuntimeError (unknown VMODL type ContentLibrary)

Expected behavior Given that ContentLibrary isn't a registered ManagedEntity in the Managed Object Types I expect this is one of those special types that has to be merged into the vmodl.db

Screenshots The task in the vSphere client: Screenshot from 2020-12-07 15-12-10

TaskInfo from the MOB: Screenshot from 2020-12-07 15-07-15

Platform:

jrgarcia commented 3 years ago

Sorry, I haven't gotten to this yet. The content library APIs are not available from SOAP. That's why it isn't registered as a ManagedEntity. I'll see what I can do to have it go around this.

agrare commented 3 years ago

No problem @jrgarcia If you know how you'd like to handle it I can take a crack at fixing it.

I could see adding a "stub" definition to the vmodl.wsdl or more generally changing the deserializer to create an object of the base class type for that property if it can't find the class in the vmodl.

Differentiating between an actual error and a case like this would be tricky though, but I don't know how many other cases like this there might be (where an internal definition "leaks" out over the public API).

This is mostly just annoying for us because it causes our WaitForUpdatesEx loops to raise out and we have to start from version="" again.

agrare commented 3 years ago

Hey @jrgarcia! I see you're no longer with VMware, congrats on the new job! Best of luck. Do you know if there is there a new maintainer of this gem?

jrgarcia commented 3 years ago

Thanks, @agrare! Unfortunately, I do not know who will be working on this going forward. I'll see if I can find an answer for you, but as I have no access to anything internal to VMware anymore, I'm not sure I'll be able to get an answer too quickly.