Skip to content
This repository has been archived by the owner on Jul 1, 2021. It is now read-only.

RbVmomi deserialization fails on managed object type ContentLibrary #205

Open
agrare opened this issue Dec 7, 2020 · 4 comments
Open

RbVmomi deserialization fails on managed object type ContentLibrary #205

agrare opened this issue Dec 7, 2020 · 4 comments
Labels

Comments

@agrare
Copy link
Contributor

agrare commented Dec 7, 2020

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. 💥
>> 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:

  • OS: Debian Bullseye
  • RbVmomi Version: 2.4.1 and 3.0.0
  • Ruby Version ruby 2.7.2p137 (2020-10-01 revision 5445e04352
@jrgarcia
Copy link
Contributor

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
Copy link
Contributor Author

agrare commented Feb 2, 2021

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.

@jrgarcia jrgarcia removed their assignment Apr 28, 2021
@agrare
Copy link
Contributor Author

agrare commented Apr 28, 2021

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
Copy link
Contributor

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants