Improvement on collecting/updating Secondary Storage total size/capacity

[andrijapanicsb]

Improvement request:

• the capacity of the Secondary Storage seem updated/obtained from time to time, by SSVMs and the value (capacity) is held in the memory of the mgmt server.

In certain cases, this becomes a very... useless... design, where the values can not be altered in case of edge cases where the Secondary Storage capacity needs to be expanded, but SSVMs are not running/existing, for whatever reason.

Proposal:

• store the capacity of the SS in the DB (perhaps op_host_capacity table, like for the Primary data, and other resource values)
• Enable a global setting that will control the interval of the capacity collection from the NFS Secondary Storage
• Consider offloading the work to the mgmt server, as per architecture design, all mgmt servers MUST be able to mount the secondary storage NFS shares (for various other tasks)
• Consider implementing an explicit API call that will trigger updating the SS NFS capacities (in cases where the backend capacity has been expanded)

[DaanHoogland]

​@anddrijapanicsb, so far I implemented a API/UI change to update the value in the DB, but the value returned is still coming from the StatsCollector. When a manual change has been done that disagrees with the actual/discovered size, which do we consider when/on what grounds?

[andrijapanicsb]

As discussed, consider the value from the DB during the boot of the mgmt server (instead of having null or zero value, whatever is the case currently), but when the stats collectors runs for the next time (when SSVM returns the size of the SS), then update in-memory capacity as well as the capacity inside the DB (that was set manually/via API/UI).

[rohityadavcloud]

Fixed by https://github.com/apache/cloudstack/pull/8941 tested by @kiranchavala @andrijapanicsb pl review and discuss if this is enough, re-open the issue if more work in needed.