Fog libvirt only supports volumes that have domain/devices/disk/source element with file attribute. This works fine for domains created with fog-libvirt, however when users manually create VMs with other types of storage domains (block/raw, iSCSI, LVM) it won't work. In that case, server.volumes returns [nil] array. That is not nice.
There was a change (https://github.com/fog/fog-libvirt/pull/75) to return empty collection if no matching volume was found, but this is then mapped in the server class to list of paths which is nil and it results to nil. This patch fixes it to prevent nil pointer exceptions.
This breaks the API, however we are in the "this have never worked" territory. Only users who previously had VMs with mulutiple volumes (one unsupported returning nil, other file-based) would see a regression. I think it is worth fixing this, what you think?
If not, then in Foreman we need to catch nil values and throw an error.
Fog libvirt only supports volumes that have domain/devices/disk/source element with file attribute. This works fine for domains created with fog-libvirt, however when users manually create VMs with other types of storage domains (block/raw, iSCSI, LVM) it won't work. In that case,
server.volumes
returns[nil]
array. That is not nice.There was a change (https://github.com/fog/fog-libvirt/pull/75) to return empty collection if no matching volume was found, but this is then mapped in the server class to list of paths which is
nil
and it results tonil
. This patch fixes it to prevent nil pointer exceptions.This breaks the API, however we are in the "this have never worked" territory. Only users who previously had VMs with mulutiple volumes (one unsupported returning nil, other file-based) would see a regression. I think it is worth fixing this, what you think?
If not, then in Foreman we need to catch nil values and throw an error.