Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
mimic: ceph-volume: extend batch #29243
In the batch command use extents instead of size when creating lvs. This gives a more precise size and avoids rounding errors. Signed-off-by: Andrew Schoen <firstname.lastname@example.org> (cherry picked from commit add9f88) Conflicts: src/ceph-volume/ceph_volume/devices/lvm/strategies/bluestore.py remove json import; pick ours and add self.use_large_block_db = False (cherry picked from commit 83e71842d8cd77b7d45efdd344bd8fac31078745)
We should show the user what the size of the device will be after lvm creates a pv out of it. This way there isn't a discrepency between the sizes that are reported to the user and what is actually created. Signed-off-by: Andrew Schoen <email@example.com> (cherry picked from commit 071e7ce)
The self.use_large_block_db property was never getting set because the block in compute was never called as block_db_size was reset in validate if it was 0. We needed to set self.use_large_block_db in validate instead of compute. Signed-off-by: Andrew Schoen <firstname.lastname@example.org> (cherry picked from commit fdfb79b)
… size We know with a mixed type scenario the device used for data will be used at 100% capacity. This means we do not need to be explict when asking for the size of the data lvs, which avoids rounding errors with very small device sizes. Signed-off-by: Andrew Schoen <email@example.com> (cherry picked from commit 0023961)
This commit refactors lvm strategies to: a) change the constructor to receive usage specific device lists b) add classmethod with_auto_devices of automatic splitting by the rotational flag (keep backwards compatible behavior) c) rename ssds and hdds member variables to wal_devs and block_devs d) add db_devs member variable Signed-off-by: Jan Fajerski <firstname.lastname@example.org> (cherry picked from commit 60dec8b)
Keep filtered_devices as a member variable of the batch object and pass this to the report functionality instead of having the report functions retrieve filtered_devices. Also keep selected strategy as a batch member variable to avoid re-retrival in e.g. the report methods. Signed-off-by: Jan Fajerski <email@example.com> (cherry picked from commit dc2c4c5)
Signed-off-by: Jan Fajerski <firstname.lastname@example.org> (cherry picked from commit 5465712) Conflicts: src/ceph-volume/ceph_volume/tests/devices/lvm/strategies/test_bluestore.py src/ceph-volume/ceph_volume/tests/devices/lvm/strategies/test_filestore.py pick with_auto_devices and error.value changes
Signed-off-by: Jan Fajerski <email@example.com> Conflicts: src/ceph-volume/ceph_volume/tests/devices/lvm/strategies/test_bluestore.py Pick test addition and error.value change
Also add test case for a MixedStrategy with unusable data devices. Signed-off-by: Jan Fajerski <firstname.lastname@example.org> Conflicts: src/ceph-volume/ceph_volume/tests/devices/lvm/strategies/test_filestore.py Pick test addition and error-value change
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1666822 Signed-off-by: Andrew Schoen <email@example.com> (cherry picked from commit 8ebff47) (cherry picked from commit aa6da41)
@jan--f this doesn't have a link to a master PR because it is grouping a few commits that weren't together right?
It is OK if you want to pursue the backporting this way, but in the past we've seen that it was problematic to track what went where if backports weren't done in order. That is: every PR in master has a corresponding backport to other branches.
Again, it is OK if you want to do it this way, I am just pointing out that it might get painful to track commits back to their original PR if they are grouped.
@andrewschoen maybe you have some other thoughts on this? (my comments should not prevent this from moving forward)
this is odd, something may have changed for the NVMe setup. The way this works is by creating a sparse file and using the NVME fabric tooling to create a device recognized by the Kernel. If you look at the output, we do even list it to check if it came up alright:
What I think is happening here is that /dev/nvme0n1 exists but /dev/nvme1n1 does not. We create two IIRC, and I am not sure what is missing here (or if anything changed to add/remove /dev/nvme1n1)