default scheduling doesn't seem to utilize multiple backends when using SolidFire driver

[John Griffith]

I set up two backends with the exact same characteristics and did not assign backend-names or types of any sort.

Created 10 volumes in succession and all volumes went to the first host, none of them went to the second host. This was observed using two SolidFire clusters as backend devices, so may have to do with capacity reporting. I'll try and duplicate on multiple LVM backings to verify it's not driver specific.

[Huang Zhiteng (zhiteng-huang)]

Hmm, do you see any strange log from scheduler?

[John Griffith (john-griffith)]

I didn't strangely enough here's the filter scheduler on the two calls. Only thing interesting is that the volume-size isn't enough to put a dent in the free capacity. Wondering if I should change the resolution there, or even if maybe the e notation is what throws things off?

2014-02-24 22:33:06.111 DEBUG cinder.scheduler.filter_scheduler [req-d28a8463-7d1b-48fa-9674-11926b844cd5 c0778e96ba8949d5bcd79f78d1a5ad16 92b0bfdbdbe647aabb00f985c8c950a2] Filtered [host 'bdr76@sf-2': free
_capacity_gb: 6.1846479872e+12, host 'bdr76@sf-1': free_capacity_gb: 6.1846479872e+12] from (pid=23946) _get_weighted_candidates /opt/stack/cinder/cinder/scheduler/filter_scheduler.py:259
2014-02-24 22:33:06.111 DEBUG cinder.scheduler.filter_scheduler [req-d28a8463-7d1b-48fa-9674-11926b844cd5 c0778e96ba8949d5bcd79f78d1a5ad16 92b0bfdbdbe647aabb00f985c8c950a2] Choosing bdr76@sf-2 from (pid=239
46) _choose_top_host /opt/stack/cinder/cinder/scheduler/filter_scheduler.py:276

2014-02-24 22:33:19.432 DEBUG cinder.scheduler.filter_scheduler [req-368e2ca1-983f-40d3-b055-876734dcefe8 c0778e96ba8949d5bcd79f78d1a5ad16 92b0bfdbdbe647aabb00f985c8c950a2] Filtered [host 'bdr76@sf-2': free_capacity_gb: 6.1846479872e+12, host 'bdr76@sf-1': free_capacity_gb: 6.1846479872e+12] from (pid=23946) _get_weighted_candidates /opt/stack/cinder/cinder/scheduler/filter_scheduler.py:259
2014-02-24 22:33:19.432 DEBUG cinder.scheduler.filter_scheduler [req-368e2ca1-983f-40d3-b055-876734dcefe8 c0778e96ba8949d5bcd79f78d1a5ad16 92b0bfdbdbe647aabb00f985c8c950a2] Choosing bdr76@sf-2 from (pid=23946) _choose_top_host /opt/stack/cinder/cinder/scheduler/filter_scheduler.py:276

[John Griffith (john-griffith)]

Well... I guess what should've struck me as strange was the ENORMOUS free capacity reported here ;)

So the issue is I'm feeding the "bytes" reported back and stuffing it in the free_GB variable. So this is a driver issue, I'll get it fixed ASAP.

Sorry about that.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/76233

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/76233
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=cfac9c7945f3cd5d39b7f6bd8950427a144b889d
Submitter: Jenkins
Branch: master

commit cfac9c7945f3cd5d39b7f6bd8950427a144b889d
Author: john-griffith <email address hidden>
Date: Mon Feb 24 23:02:11 2014 -0700

    Fix free_capacity reporting in SolidFire driver

    The SolidFire driver reports capacity info in bytes, the
    capabilities update reports available_GB. Sadly we neglected
    to convert the bytes to gigibytes here which made for a VERY
    large backend and caused things like capacity filtering to not
    work correctly.

    This patch just adds conversion to GiB when reporting capabilities.

    Change-Id: I62c6ad2edd8c2ced344df766c198504894f4902b
    Closes-Bug: 1284452

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/93415

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/93415
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=b75d26f9f3a15f00e2a9605e23752b30cab583e6
Submitter: Jenkins
Branch: master

commit b75d26f9f3a15f00e2a9605e23752b30cab583e6
Author: John Griffith <email address hidden>
Date: Tue May 13 01:01:55 2014 -0400

    Convert SolidFire Capacity response to GiB

    This patch fixes the reported free_capacity_gb response
    in the SolidFire update_cluster_status method.

    The initial patch fixed the free_capacity conversion,
    however omitted the same fix that was needed for the
    free_space calculation.

    Closes Bug: #1284452

    Change-Id: If034957764911ec92a6d7e603d0510325018db6d