While working on the liquid-ceph implementation, we have found a potentially problematic (albeit unlikely) issue with how quota values are defined.
See the specification for ResourceQuotaRequest, where Quota is an unsigned 64-bit int.
Then, on ResourceUsageReport, the value for Quota becomes a signed 64-bit int.
(This is also applicable to per-Availability Zone quota)
As one might see, this loss of precision may lead to an integer overflow when reporting quota on usage request.
Again, albeit this is unlikely due to storage capacity in real-life scenarios, it still feels odd that we are subject to this mismatch, loss of precision, and opening ourselves to unforeseen issues, now or in the future.
Works as designed. OpenStack will report "no quota" as -1, so we have to allow negative values for backend quotas, while Limes uses unsigned values for frontend quotas.
While working on the
liquid-ceph
implementation, we have found a potentially problematic (albeit unlikely) issue with how quota values are defined.See the specification for
ResourceQuotaRequest
, whereQuota
is an unsigned 64-bit int. Then, onResourceUsageReport
, the value forQuota
becomes a signed 64-bit int.(This is also applicable to per-Availability Zone quota)
As one might see, this loss of precision may lead to an integer overflow when reporting quota on usage request.
Again, albeit this is unlikely due to storage capacity in real-life scenarios, it still feels odd that we are subject to this mismatch, loss of precision, and opening ourselves to unforeseen issues, now or in the future.