On Wed, Apr 3, 2019 at 11:15 AM Thomas Goirand <[email protected]> wrote: > > On 4/2/19 11:23 PM, Alfredo Deza wrote: > > On Tue, Apr 2, 2019 at 4:48 PM Thomas Goirand <[email protected]> wrote: > >> > >> Hi, > >> > >> Using ceph-volume is absolutely *NOT* mandatory, this is only a way to > >> setup your ceph cluster, but that's really not the only one. > >> > >> I've been using ceph-osd without it, and the [email protected] is really > >> enough, provided that you know how to set it up properly. > >> > >> Therefore, this bug is *NOT* of severity grave, because the definition is: > >> > >> "makes the package in question unusable by most or all users, > >> or causes data loss, or introduces a security hole allowing > >> access to the accounts of users who use the package." > >> > >> There's no security hole or data loss, it is just maybe a little harder > >> to use ceph-osd. > > > > I would argue that an unusable ceph-volume would make Ceph unusable > > for most users. > > My understanding is that ceph-volume is a conveniency tool only, just > like ceph-deploy (which I gave up on, btw...). It isn't at all > mandatory. BTW, I don't really understand why one would need a > [email protected] at all, since we already have [email protected]. > Can you explain? isn't this redundant?
The ceph-volume unit will map to each OSD that has been created. Upon system startup, each unit will try to discover the devices associated with an OSD, mount them (if needed, for example in Filestore), and decrypt them if required. The associated ceph-osd unit will then be started at the end of the process. This is part of the activation process that is documented in detail here: http://docs.ceph.com/docs/master/ceph-volume/lvm/activate/#ceph-volume-lvm-activate > > > Running [email protected] is not enough, since one of the > > responsibilities of ceph-volume is to ensure that > > everything is in place for the OSD to start when the system boots, > > with all the complexity that may involve: encrypted, > > bluestore or filestore, block/block.db/block.wal, journals, etc... > > I've done all of this using my own script, and it isn't hard. FYI, this > is included in openstack-cluster-installer, also in Debian Sid/Buster. > It's a "push button" install of Ceph (and OpenStack if you need that > too), if you're searching for something simple. > > If you want to set things up by hand, you may reuse this script too (and > adapt it to your needs, of course, as this tightly integrates with OCI): > > https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer/blob/debian/stein/bin/oci-make-osd > > Comments on it, or even better, improvements, would be welcome. > > > You may be able to run an OSD manually, but that doesn't mean it is > > the way we would recommend for a stable system. > > I don't see how setting-up things with another tool, or even by hand, > makes Ceph OSD unstable. I'm re-using the description for "grave": "...makes the package in question unusable by most or all users" In this case, most users will not be able to deploy a Ceph cluster with an unusable ceph-volume. All the Ceph automation is done interacting with ceph-volume, and the most used deployment tooling uses ceph-volume (vs. a script): SeaSalt, ceph-deploy, ceph-ansible, and most recently Rook. > > >> It would still be desirable to get this fixed ASAP though, and probably > >> deserving a fix before Buster is out. > > As I wrote above, it is useless to discuss, just send a patch, and we'll > go from there. > > Cheers, > > Thomas Goirand (zigo)
