Am 22.02.2018 um 09:44 schrieb Dan van der Ster: > On Wed, Feb 21, 2018 at 11:56 PM, Oliver Freyermuth > <freyerm...@physik.uni-bonn.de> wrote: >> Am 21.02.2018 um 15:58 schrieb Alfredo Deza: >>> On Wed, Feb 21, 2018 at 9:40 AM, Dan van der Ster <d...@vanderster.com> >>> wrote: >>>> On Wed, Feb 21, 2018 at 2:24 PM, Alfredo Deza <ad...@redhat.com> wrote: >>>>> On Tue, Feb 20, 2018 at 9:05 PM, Oliver Freyermuth >>>>> <freyerm...@physik.uni-bonn.de> wrote: >>>>>> Many thanks for your replies! >>>>>> >>>>>> Are there plans to have something like >>>>>> "ceph-volume discover-and-activate" >>>>>> which would effectively do something like: >>>>>> ceph-volume list and activate all OSDs which are re-discovered from LVM >>>>>> metadata? >>>>> >>>>> This is a good idea, I think ceph-disk had an 'activate all', and it >>>>> would make it easier for the situation you explain with ceph-volume >>>>> >>>>> I've created http://tracker.ceph.com/issues/23067 to follow up on this >>>>> an implement it. >>>> >>>> +1 thanks a lot for this thread and clear answers! >>>> We were literally stuck today not knowing how to restart a ceph-volume >>>> lvm created OSD. >>>> >>>> (It seems that once you systemctl stop ceph-osd@* on a machine, the >>>> only way to get them back is ceph-volume lvm activate ... ) >>>> >>>> BTW, ceph-osd.target now has less obvious functionality. For example, >>>> this works: >>>> >>>> systemctl restart ceph-osd.target >>>> >>>> But if you stop ceph-osd.target, then you can no longer start >>>> ceph-osd.target. >>>> >>>> Is this a regression or something we'll have to live with? >>> >>> This sounds surprising. Stopping a ceph-osd target should not do >>> anything with the devices. All that 'activate' does when called in >>> ceph-volume is to ensure that >>> the devices are available and mounted in the right places so that the >>> OSD can start. >>> >>> If you are experiencing a problem stopping an OSD that can't be >>> started again, then something is going on. I would urge you to create >>> a ticket with as many details as you can >>> at http://tracker.ceph.com/projects/ceph-volume/issues/new >> >> I also see this - but it's not really that "the osd can not be started >> again". >> The problem is that once the osd is stopped, e.g. via >> systemctl stop ceph.target >> doing a >> systemctl start ceph.target >> will not bring it up again. >> >> Doing a manual >> systemctl start ceph-osd@36.service >> will work, though. > > In our case even that does not work reliably. > We're gathering info to create a tracker ticket. > > Cheers, Dan
Dear Dan,
did you manage to come around to report a ticket? If so, could you share the
ticket number?
Then I'd happily subscribe to it (with the flood of tickets it's hard to
find...).
On related news, I observe this:
# systemctl list-dependencies ceph-osd.target
ceph-osd.target
● ├─ceph-osd@2.service
● └─ceph-osd@3.service
on a host installed with ceph-deploy < 2.0 (i.e. using ceph-disk),
while I observe this:
# systemctl list-dependencies ceph-osd.target
ceph-osd.target
for a host installed with ceph-deploy 2.0, i.e. using ceph-volume.
I think this is caused by the ceph-volume systemd-files triggering the ceph-osd
services,
so they are not enabled at all, and hence not considered as dependencies of the
target.
Unsure how to solve this cleanly without refactoring the concept, but again,
I'm no systemd expert ;-).
Cheers,
Oliver
>
>>
>> The ceph-osd@36.service, in fact, is not enabled on my machine,
>> which is likely why ceph.target will not cause it to come up.
>>
>> I am not a systemd expert, but I think the issue is that the
>> ceph-volume@-services which
>> (I think) take care to activate the OSD services are not re-triggered.
>>
>> Cheers,
>> Oliver
>>
>>>
>>>>
>>>> Cheers, Dan
>>
>>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
