On Sat, Mar 31, 2018 at 2:31 AM, Ning Yao <zay11022@xxxxxxxxx> wrote:
> Hi, Sage
>
> Although we have ceph-volume now, ceps-volume cannot work as expected
> in most of scenarios. For example:
>
> when we use:
>
> ceph-volume lvm prepare --filestore --data /dev/sda --journal /dev/sdl1 or
> ceph-volume lvm prepare --bluestore --data /dev/sda --block.db /dev/sdl1
>
> 1. we need to create a Physical Volume for /dev/sda before it can be
> used. and ceph-volume does not help us to do that
Not sure what you mean by this. In that scenario, ceph-volume will use
/dev/sda and convert it to a single logical volume for "data". This is
even
how our tests work. If you are hitting errors, please give us some
examples on how to replicate.
> 2. the params of --journal or --block.db must be a partitioned disk
> such as /dev/sdl1 or /dev/sdl1, and cannot be a raw device without
> partition -- /dev/sdl like ceps-disk does and automatically create the
> partition by using sgdisk.
This is partially true. It can be a partition *or* a logical volume.
ceph-volume will not create partitions for a user because
this has been one of the most problematic pain points in ceph-disk.
Creating a partition is simple, but programmatically understanding
how to do partitions in any scenario that users throw at us is asking
to go back to ceph-disk issues.
ceph-volume is currently tremendously robust and I am hesitant to add
this kind of helpfulness that has brought us issues before.
> 3. we must explicitly use --journal or --block.db, --block.wal to tell
> ceph-volume where to put the data. It cannot be automatically
> partition or create multiple logical volumes for different usage, such
> as
> lvcreate --size 100M VG -n odd-block-meta-{uuid}
> lvcreate --size {bluestore_block_db_size} VG -n osd-block-db-{uuid}
> lvcreate --size {bluestore_block_wal_size} VG -n osd-block-wal-{uuid}
> lvcreate -l 100%FREE VG -n osd-block-{uuid} (use the left space for data)
>
Again, this is oversimplifying. Creating an LV can be done in dozens
of ways, not just this one. The code to support this deployment
complexity
would not be a good return-over-investment.
You can just specify the data device and ceph-volume will create a
full bluestore OSD for you, and yes, it will want to know what is your
wal or db device
if you want to use one.
> it seems now hard to switch to ceph-volume from ceps-disk. And if
> though, we need to do much extra work in ceph-ansible and help to
> prepare all the thing above. so is there any plan to enhance the
> function, or design spec of ceph-volume? and we may help on this.
I would suggest investing in a configuration management system that
can help automate all the use cases you need. ceph-ansible can do a
bit of this already for you, and we are planning
on adding more support to help out creating LVs for a user.
*However*, even on ceph-ansible, I am going to push towards a
simplistic approach, and not support all the various different ways
you can create a logical volume. This will no doubt leave
a lot of use cases out of luck, but it is a good way to provide
robustness on the tooling on the things we know will work right.
If using ceph-ansible, it isn't hard to pre setup your machines with
the logical volume creation you have used as examples here.
>
>
> Regards
> Ning Yao
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
