Storage: Use zero for unbound volumes' total size on the API

[hamistao]

As per discussed on #14595 (comment), this implements the standard of showing the size of unbound volumes as 0.

To keep the API consistent, also updates getting custom volume state so that total is shown even when usage is not supported and shows 0 to represent unsupporte usage of both custom and instance volumes.

[hamistao]

@tomponline In addition, we did not address what value to use for unsupported usage in our last 1-1. But throughout our discussions we stablished that:
1- It would be nice for the value we use for Usage when not supported to match the value for an unset total.
2- Total should be 0.
3- -1 is a value typically used to communicate an error.

For these reasons, volume/disk usage is being set here to be reported as 0 if not supported and -1 if an error ocurred while trying to retrieve its value.

[tomponline]

For these reasons, volume/disk usage is being set here to be reported as 0 if not supported and -1 if an error ocurred while trying to retrieve its value.

Does this change any existing usage values compared to lxd 6.2?

[tomponline]

1- It would be nice for the value we use for Usage when not supported to match the value for an unset total. 2- Total should be 0. 3- -1 is a value typically used to communicate an error.

For these reasons, volume/disk usage is being set here to be reported as 0 if not supported and -1 if an error ocurred while trying to retrieve its value.

What situations are there when usage is not suppprted/unavailable. I suspect we may want to consider unavailable/unsupported as an error (-1) to allow differentiation from zero usage (a possibility as a genuine value).

[hamistao]

Does this change any existing usage values compared to lxd 6.2?

Yes. Similarly to what happened to "total", we went from a null struct to showing -1 for unsupported usage in #14511, that was recently merged and made it into 6.2. So this would be changing that -1 to a 0.

What situations are there when usage is not suppprted/unavailable. I suspect we may want to consider unavailable/unsupported as an error (-1) to allow differentiation from zero usage (a possibility as a genuine value).

dir: doesn't support usage if project quotas are not enabled.
lvm and powerflex: don't support usage for unmounted volumes.
btrfs: doesn't support usage if quotas are disabled on btrfs, not common I suppose.

Also trying to get the usage on a snapshot volume is not supported on dir, lvm and cephfs.

We use a uint64 omitempty for custom volume usage, so perhaps using something similar would be best to keep it consistent across volume types. Like always showing 0 usage in case of error/unsupported.

type StorageVolumeStateUsage struct {
	Used uint64 `json:"used,omitempty" yaml:"used,omitempty"`

	Total int64 `json:"total" yaml:"total"`
}

cc: @tomponline

[tomponline]

@hamistao does this PR effectively restore the behaviour that we had in LXD 6.1?

[hamistao]

@hamistao does this PR effectively restore the behaviour that we had in LXD 6.1?

Not exactly, it keeps the main purpose of the merged PR, which is to show total even when retrieving usage is unsupported, but changes the value that we want to show for unsupported usage and for unbound total from -1 to 0.

[tomponline]

Thanks. Did you check each storage driver's implementation for total size 0 if unbounded?

[tomponline]

@hamistao i think we'll land this one for LXD 6.3 to partially restore the previous behaviour.

[hamistao]

I agree.

Thinking practically, although this is just conjecture, I suppose our users will hardly be bothered by this reverting.
I say this because only the value for unsupported usage and the instance state's total are affected, and the latter is so broken and useless that I doubt anyone is currently relying on it.

[tomponline]

I agree.

Thinking practically, although this is just conjecture, I suppose our users will hardly be bothered by this reverting. I say this because only the value for unsupported usage and the instance state's total are affected, and the latter is so broken and useless that I doubt anyone is currently relying on it.

Yes it didnt make it into any LTS which is good.

[tomponline]

@hamistao so is this good to merge?

[hamistao]

@tomponline I am concerned about this failing test, please give me some time to check on it

[hamistao]

@tomponline Sorry, I should have pinged you after I fixed the broken tests. This is ready.

[tomponline]

Thanks!

[tomponline]

@edlerd is this OK for LXD UI's consumption ?

[edlerd]

@edlerd is this OK for LXD UI's consumption ?

Yes, that seems all right.

[tomponline]

@MusicDin @roosterfish are all volumes in Powerflex and Pure bounded in size? Please can you double check they use the convention specified in this PR? Thanks