docker-ce dictating pool quota enabled disabled status

[phillxnet]

After moving to docer-ce in stable 3.9.2-3 (pr #1865) it was found that docker-ce, upon starting (ie on boot or when it's service was switched on) would disable quotas. This at the time was very disruptive to many basic Rockstor functions so a work around was found in:
"rock-ons-root host pool quota disabled by docker-ce" #1872
and implemented in:
"rock-ons-root host pool quota disabled by docker-ce. Fixes #1872" #1873
essentially adding " '--storage-opt', 'btrfs.min_space=1G' " to dockerd's initialization.
This 'work around' effected a re-enabling of quotas by dockerd almost directly after it had initially disabled them, which it still did. This quota cycling of the affected pool on every boot was alleviated some what by improving Rockstor's quota disabled/cycling capabilities under issue:
"improve quotas not enabled behaviour" #1869
and pr:
"improve quotas not enabled behaviour. Fixes #1869" #1874
Given the above recent improvement in quota disabled behaviour a Web-UI selector for quotas / pool was introduced via issues:
"[New feature] Add option to disable BTRFS quota/qgroups" #1592 and "Feature: Quota rebuild script?" #1785
and implemented in pr:
"Add option to disable BTRFS quota-qgroups. Fixes #1592" #1903
So we now entertain the user selectable option of Quotas Disabled. But given that a pool's quota state is remembered by the pool itself and all our existing mechanism observe and are informed by the behaviour we have again surfaced an issue with docker-ce dictating pool quota status.

This, to the issue author, looks to be the same upstream issue as was observed in the first referenced issue above (re-referenced here for ease: docker/for-linux#78).

It is not clear how we are to proceed as currently docker-ce is now dictating the final quota state for the pool that hosts it's rock-ons-root share (subvol). This is inappropriate and not in keeping with btrfs defaults of adopting the last quota stats set, which the rest of Rockstor observes.

A workaround for those wishing to adopt a quota disabled state for a pool currently hosting the rock-ons-root is to re-create their rock-ons-root on another pool (where enabled quotas are acceptable) or potentially to revert the changes in #1873; but the latter would simply have docker-ce dictate that quotas were disabled rather than enabled shortly after boot and again circumvent the user setting (added in #1903) and the btrfs default behaviour of maintaining the last setting requested.

Suggestions welcome: however, in the issue authors opinion, docker-ce should not dictate/hard wire quota status, irrespective of it's initialisation parameters. And as such this is viewed as an upstream bug that can only be addressed upstream.

[FroggyFlox]

Although this remains to be tested (on my end, at least), a possible fix has been merged and released by Docker...
moby/moby#42273

... and included in the latest docker-ce-20.10.6 package in the openSUSE Leap 15.2 repo:
https://build.opensuse.org/package/view_file/openSUSE:Leap:15.2:Update/docker/docker.changes?expand=1

-------------------------------------------------------------------
Thu Apr 15 05:23:20 UTC 2021 - Aleksa Sarai <asarai@suse.com>

- Update to Docker 20.10.6-ce. See upstream changelog in the packaged
  /usr/share/doc/packages/docker/CHANGELOG.md. bsc#1184768
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-PRIVATE-REGISTRY-add-private-registry-mirror-support.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
- Backport upstream fix <https://github.com/moby/moby/pull/42273> for btrfs
  quotas being removed by Docker regularly. bsc#1183855 bsc#1175081
  + 0005-bsc1183855-btrfs-Do-not-disable-quota-on-cleanup.patch

[phillxnet]

@FroggyFlox Thanks for updating this long standing issue with fresh info. Looks promising.

[Hooverdan96]

@FroggyFlox is this still an issue that we need to address?