Manageiq: scan_metadata / sync_metadata smartstate code expects to run on the system that's configured for this (libraries installed/volumes mounted/network reachable) by using queue server_guid - could be broken in pods

[jrafanie]

https://github.com/ManageIQ/manageiq/blob/bd464aa758bafb222b5ad3c6a61b526262d603e6/app/models/miq_server/server_smart_proxy.rb#L71

I assume we used server_guid for the queue calls because the appliance model miq_server would guarantee it's routed to a worker on the same filesystem/operating system that supports scanning/smartstate:

• vmware libraries are installed on vmware systems
• access to the filesystem of the vm/instance

The assumption was that the miq_server that passed this test early on could be used for scanning but that miq_server guid is used on many pods and not all of them have been checked for the appropriate libraries/network access/etc. It's unclear if any of this works in pods.

[jrafanie]

Related to #20343 #19957 #20290

[carbonin]

This feels like it would be okay. We have an issue open in manageiq-pods about how to rebuild the images to add the scanning libs we would need. In my mind that indicates that the libs should be available in all the workers.

The server/role/zone routing works in pods so that won't be an issue either (I assume this is how we would deal with your "access to the filesystem of the vm/instance" concern, right?)

[carbonin]

We should still definitely test and verify this before closing though. I'm not sure anyone has tried this.

[jrafanie]

Right, I was more concerned that has_vix_disk_lib column for a server is based on vix_disk_lib_installed? and this value is base on which pod checks if the library is there: https://github.com/ManageIQ/manageiq-providers-vmware/blob/a1f927fcf87264aedc79ecdae962cdb3ef39897e/lib/manageiq/providers/vmware.rb#L11-L16

It feels like that column and the checks based on it have a different meaning in pods. If we can guarantee that all pods will have the needed libraries for scanning so checking any one of them is good enough, 👍

[carbonin]

Yeah, checking this properly would be a pain, but with the way users specify images you can't actually deploy workers with different base images.

You could, for example, use one image for the base workers (anything not the ui, api, or remote consoles) and use another image not built off that base image for the service workers, but I don't think you could get into a situation where some generic workers have the lib and others don't for the same server. In this situation, only the service workers wouldn't have the lib which we don't care about I think.