Manageiq: Remove "vmware_web_service" gem dependency from the core repo

Created on 4 Feb 2019  路  8Comments  路  Source: ManageIQ/manageiq

There is dependency in core Gemfile:
https://github.com/ManageIQ/manageiq/blob/5810a00d317dc3f0ac56d52fea8bc5094440e0f7/Gemfile#L148

which should not be here, because its relevant and declared in manageiq-providers-vmware gem:
https://github.com/ManageIQ/manageiq-providers-vmware/blob/ae3c8a1059f0c98b24a592cacfb83c67d457ede5/manageiq-providers-vmware.gemspec#L17

But it can't be removed directly, because part of it used in: https://github.com/ManageIQ/manageiq/blob/5810a00d317dc3f0ac56d52fea8bc5094440e0f7/app/models/snapshot.rb#L43-L54

We should refactor that code, and remove that dependency in a core.

cleanup pinned providerinfrastructure

Most helpful comment

Now that @chessbyte moved the VMware specifics out of core VmScan (https://github.com/ManageIQ/manageiq/pull/19607) and @Fryguy moved the check for vix_disk_lib out (https://github.com/ManageIQ/manageiq/pull/19660) I don't see any more references to VMwareWebService in core

All 8 comments

Core also depends on this because of the serialization of VimType objects. cc @jrafanie

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

Core also depends on this because of the serialization of VimType objects.

This got me thinking, currently we serialize VimStrings into ems_ref_obj (e.g. "--- !ruby/string:VimString\nstr: vm-121\nxsiType: :ManagedObjectReference\nvimType: :VirtualMachine\n"). We do this because just the model_class and ems_ref isn't enough to know what the exact underlying type is (e.g. EmsCluster could be a ComputeResource or a ClusterComputeResource)

What we really need is the ManagedObject VIM class name + the ManagedObjectReference to be able to build the MOR that is sent to the provider.

If instead of ems_ref = vm-121 and ems_ref_obj = VimString.new('vm-121', 'ManagedObjectReference', 'VirtualMachine') we just had ems_ref = vm-121 and ems_type = VirtualMachine? This could be relatively easily migrated to, just parse the string and pull out the vimType and set that to the ems_type attribute and eventually delete ems_ref_obj.

Alternatively we could create an STI model for each type so that the VIM type was obvious from the model name.

We could also just possibly fit it into the ems_ref column directly with some parsable format

Yeah it is pretty common for code interacting with VMware to use managed_object_class:managed_object_reference e.g. VirtualMachine:vm-123. It is extremely handy because then the ems_ref is standalone unique for all objects across the entire ext_management_system.

I think that would be difficult for us to update to, we'd have to find all of the places in the code where we use ems_ref to interact with VMware and split it versus finding the relatively few references to ems_ref_obj and build the VimString there but if it turns out that combining and splitting would be feasible I'd love to get there.

Serialized VMwareWebService/VimTypes have been removed from the database, I'll start looking at the other references in core

https://github.com/ManageIQ/manageiq/pull/19551 removes MiqVimVm from Snapshot

Now that @chessbyte moved the VMware specifics out of core VmScan (https://github.com/ManageIQ/manageiq/pull/19607) and @Fryguy moved the check for vix_disk_lib out (https://github.com/ManageIQ/manageiq/pull/19660) I don't see any more references to VMwareWebService in core

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ahrechushkin picture ahrechushkin  路  8Comments

durandom picture durandom  路  8Comments

zhitongLBN picture zhitongLBN  路  6Comments

zigaSRC picture zigaSRC  路  8Comments

Nadkine picture Nadkine  路  7Comments