Comment 2 for bug 1095633

Revision history for this message
Brano Zarnovican (zarnovican) wrote :

More info about the DFM refresh problem..

1) request to refresh lun list is ignored if it was executed "close" to the previous refresh has finished. Looks like the graceful period is around a minute or so. In this period DFM will return timestamp of the previous monitor execution. Currently, driver will run DfmObjectRefresh, but it does not check if the timestamp is in the past, only that it is non-zero.

https://github.com/openstack/nova/blob/stable/folsom/nova/volume/netapp.py#L870

Fix/workaround: Repeat DfmObjectRefresh requests until you get back timestamp higher than first execution of Refresh.

2) (Theory) Running 'lun' monitor will not refresh lun list if the new lun is 'inside' a qtree which was not discovered yet. Even if you run DfmObjectRefresh(.., ChildType='lun_path') multiple times and let it correctly finish, new lun still won't appear. It looks that qtree (and his lun) will appear only after 'file_system' monitor has been executed. This monitor is NOT triggered with ChildType='lun_path' parameter.

Fix/workaround: Explicitly trigger both 'file_system' and 'lun' monitors.