get-pools doesn't reflect capacity change made by consume_from_volume

[TommyLike]

When creating volume, we will decrease pool's free_capacity_gb, but get-pools' API will not reflect this change, follow this reproduce procedure:
1. cinder get-pools -detail
2. cinder create {size}
3. wait for volume successfully scheduled and make sure the scheduler's backend states have not been updated by backend.
4. cinder-get-pools --detail
5. "free_capacity_gb" keep unchanged.

[TommyLike (hu-husheng)]

Havn't tested this in Manila environment, but it may also exist in Manila as Cinder and Manila share most of the same codes here.

[OpenStack Infra (hudson-openstack)]

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

[Tom Barron (tpb)]

From xyang:

<xyang> tbarron, bswartz: I took a look of the get pools bug. I don’t think we need to rush to get this in. It’s still been debated in Cinder. It does look like Manila has the same issue by inspecting the code. This is not related to oversubscription. It is a general capabilities reporting problem. The root case is capabilities reporting is periodic. So there is a period when the data is stale. In this
<xyang> case a volume is created in the period between two capabilities reporting from backends so the pools stats are not updated yet.
<xyang> This fix let the scheduler update the capacities after create volume process is done in scheduler, but before there is a response from the backend. So this update is not completely accurate. If volume create is successful, it is accurate. If volume create fails in the backend, this is not accurate. When capabilities reporting happens for the next time, pools stats will be corrected. So this fix
<xyang> temporarily updates the pools stats until the next capabilities reporting from the backend.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Sean McGinnis (<email address hidden>) on branch: master
Review: https://review.opendev.org/543205
Reason: I agree with Zhao that this is the role of the update_stats call. While we can try to be preemptive in updating the capacity on create calls, it isn't until the create call succeeds (or fails) that the actual capacity is impacted. Due to the async nature of this, we need to stick with the periodic stats updates.