As of today the system fs commands, depending on the order, allow the user to run multiple commands in a sequence, even if there isn't enough space left on the host cgts-vg. The following example shows a scenario where cgts-vg has 16GB available, but it allowed increasing docker host-fs in an AIO-SX deployment from 30 to 80GB (+50GB) in five chunks of 10GB: [sysadmin@controller-0 ~(keystone_admin)]$ s [sysadmin@controller-0 ~(keystone_admin)]$ SIZE=30 s [sysadmin@controller-0 ~(keystone_admin)]$ s host-lvg-list controller-0 +--------------------------------------+------------+-------------+--------+------------------+------------------+-------------+-------------+ | UUID | LVG Name | State | Access | Total Size (GiB) | Avail Size (GiB) | Current PVs | Current LVs | +--------------------------------------+------------+-------------+--------+------------------+------------------+-------------+-------------+ | 14665345-ea19-415a-a0d0-7efcab837ace | cgts-vg | provisioned | wz--n- | 178.968 | 16.156 | 1 | 12 | | 504332be-e8ef-4753-8937-575e3ef4f16e | nova-local | provisioned | wz--n- | 10.996 | 0.0 | 1 | 1 | +--------------------------------------+------------+-------------+--------+------------------+------------------+-------------+-------------+ [sysadmin@controller-0 ~(keystone_admin)]$ for I in $(seq 5); do date; s host-fs-modify controller-0 docker=$(( SIZE + (10 * I) )); sleep 3; done Qua Abr 6 20:13:11 UTC 2022 +--------------------------------------+---------+-------------+----------------+ | UUID | FS Name | Size in GiB | Logical Volume | +--------------------------------------+---------+-------------+----------------+ | 535e4841-e3d7-42d9-a441-2be9499aadb6 | backup | 25 | backup-lv | | 38d2bf0a-1489-4fb5-9119-cd588b3f0649 | docker | 40 | docker-lv | | 2ad5d50c-b4af-48de-bfbf-be856e1c27d7 | kubelet | 10 | kubelet-lv | | f536231f-2135-48ff-bf01-da941821121e | scratch | 16 | scratch-lv | +--------------------------------------+---------+-------------+----------------+ Qua Abr 6 20:13:19 UTC 2022 +--------------------------------------+---------+-------------+----------------+ | UUID | FS Name | Size in GiB | Logical Volume | +--------------------------------------+---------+-------------+----------------+ | 535e4841-e3d7-42d9-a441-2be9499aadb6 | backup | 25 | backup-lv | | 38d2bf0a-1489-4fb5-9119-cd588b3f0649 | docker | 50 | docker-lv | | 2ad5d50c-b4af-48de-bfbf-be856e1c27d7 | kubelet | 10 | kubelet-lv | | f536231f-2135-48ff-bf01-da941821121e | scratch | 16 | scratch-lv | +--------------------------------------+---------+-------------+----------------+ Qua Abr 6 20:13:26 UTC 2022 +--------------------------------------+---------+-------------+----------------+ | UUID | FS Name | Size in GiB | Logical Volume | +--------------------------------------+---------+-------------+----------------+ | 535e4841-e3d7-42d9-a441-2be9499aadb6 | backup | 25 | backup-lv | | 38d2bf0a-1489-4fb5-9119-cd588b3f0649 | docker | 60 | docker-lv | | 2ad5d50c-b4af-48de-bfbf-be856e1c27d7 | kubelet | 10 | kubelet-lv | | f536231f-2135-48ff-bf01-da941821121e | scratch | 16 | scratch-lv | +--------------------------------------+---------+-------------+----------------+ Qua Abr 6 20:13:34 UTC 2022 +--------------------------------------+---------+-------------+----------------+ | UUID | FS Name | Size in GiB | Logical Volume | +--------------------------------------+---------+-------------+----------------+ | 535e4841-e3d7-42d9-a441-2be9499aadb6 | backup | 25 | backup-lv | | 38d2bf0a-1489-4fb5-9119-cd588b3f0649 | docker | 70 | docker-lv | | 2ad5d50c-b4af-48de-bfbf-be856e1c27d7 | kubelet | 10 | kubelet-lv | | f536231f-2135-48ff-bf01-da941821121e | scratch | 16 | scratch-lv | +--------------------------------------+---------+-------------+----------------+ Qua Abr 6 20:13:42 UTC 2022 +--------------------------------------+---------+-------------+----------------+ | UUID | FS Name | Size in GiB | Logical Volume | +--------------------------------------+---------+-------------+----------------+ | 535e4841-e3d7-42d9-a441-2be9499aadb6 | backup | 25 | backup-lv | | 38d2bf0a-1489-4fb5-9119-cd588b3f0649 | docker | 80 | docker-lv | | 2ad5d50c-b4af-48de-bfbf-be856e1c27d7 | kubelet | 10 | kubelet-lv | | f536231f-2135-48ff-bf01-da941821121e | scratch | 16 | scratch-lv | +--------------------------------------+---------+-------------+----------------+ [sysadmin@controller-0 ~(keystone_admin)]$ s host-lvg-list controller-0 +--------------------------------------+------------+-------------+--------+------------+------------------+-------------+-------------+ | UUID | LVG Name | State | Access | Total Size | Avail Size (GiB) | Current PVs | Current LVs | | | | | | (GiB) | | | | +--------------------------------------+------------+-------------+--------+------------+------------------+-------------+-------------+ | 14665345-ea19-415a-a0d0-7efcab837ace | cgts-vg | provisioned | wz--n- | 178.968 | 6.156 | 1 | 12 | | 504332be-e8ef-4753-8937-575e3ef4f16e | nova-local | provisioned | wz--n- | 10.996 | 0.0 | 1 | 1 | +--------------------------------------+------------+-------------+--------+------------+------------------+-------------+-------------+ In the end, only the first docker fs increment happened in fact, but the database remained with an inconsistent value of 80GB, which would cause an upgrade failure later, as observed when the bug was reported. This fs increase is allowed because the cgts-vg is updated by the agent audit, which happens every 60s, so if another host-fs or controllerfs resize is executed before the agent reports back to conductor, it is allowed to run the resize command, the database is updated, but the resize may not be executed with success on the target host because of lacking vg space.