What:
-----
allocated_capacity_gb is currently expected from the drivers as part of capability reporting; If the driver does not provide it, it defaults to 0:
https://github.com/openstack/manila/blob/d8fc55728958429c95635b6418d0d9c0d592af73/manila/scheduler/host_manager.py#L361
Why does this matter:
---------------------
allocated_capacity_gb is a fallback for provisioned_capacity_gb; i.e, when a driver does not report provisioned_capacity_gb for a backend, we set provisioned_capacity_gb to allocated_capacity_gb.
https://github.com/openstack/manila/blob/d8fc55728958429c95635b6418d0d9c0d592af73/manila/scheduler/host_manager.py#L371
provisioned_capacity_gb is essential in calculation of the provisioned_ratio which comes into play while exercising the max_over_subscription_ratio in case of scheduling to backends that support thin_provisioning.
Why this is critical:
----------------------
Some backend have no good or efficient way to report allocated_capacity_gb or provisioned_capacity_gb for a given pool (or the backend itself in case of single pool backends). They would need to sum up the sizes of all the thin and thick shares created on them. With the deployment and operations documentation, we have always recommended that a backend configured for manila be only used by manila. i.e, no other tenants or services should be allowed to create shares on the backend. With this assumption, we can assume that, when the backend does not report allocated_capacity_gb or provisioned_capacity_gb; these values can be calculated by summing up sizes of all the shares of that host from the manila database.
working on this