Re: scoping daemon-helper replacement effort

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 29, 2016 at 10:22 AM, Vasu Kulkarni <vakulkar@xxxxxxxxxx> wrote:
> On Fri, Jul 29, 2016 at 9:55 AM, Josh Durgin <jdurgin@xxxxxxxxxx> wrote:
>> On 07/29/2016 09:40 AM, Ken Dreyer wrote:
>>>
>>> daemon-helper predates a lot of things in Ceph, and the further we go
>>> into systemd-land with things like unprivilged daemons, SELinux, and
>>> cgroups, the further Teuthology diverges from what our users do. To
>>> remedy this, I want to retire daemon-helper and have Teuthology tests
>>> use the normal init system, particularly now that our main supported
>>> distros are unified around systemd.
> If we just have to worry about systemd it would be much simpler compared to
> supporting various previous initd systems(14.04/7.0 etc). changes can
> affect only jewel+ branches.
>
>>>
>>>  From what I understand, we use daemon-helper in Teuthology to:
>>>
>>>    1) start a daemon and eventually stop it with either SIGTERM or
>>> SIGKILL, depending on whether the Teuthology task has enabled the
>>> coverage or valgrind options,
> I still see some challenges here, some of the code in ceph_manager.py
> does pretty fast killing and revive of osd's, I think that would be possible
  Correction: will not be possible

> with systemd and also generally KILL of process wont work since systemd
> will end up restart the process based on its config, So those cases have
> to be rewritten.
>
>>>
>>>    2) send data via STDIN
>>>
>>>    3) print some messages when the child crashes
>>>
>>> I think we could run the services using the systemd unit files and
>>> still accomplish #1 and #3.
>>>
>>> For #2 (communicating to the daemons via STDIN), how could we
>>> accomplish this? What sort of things are we writing to the daemons'
>>> STDIN? I'm having trouble finding examples in ceph-qa-suite.git.
>>
>>
>> We're not using it to write data to the daemons, but as a way to kill them
>> automatically if our ssh connection dies.
>>
>> With fast reimaging in the works, this will be irrelevant. Even now,
>> it's not really useful for the usual scheduled jobs where the nodes are
>> rebooted on failure. So I wouldn't worry about (2).
>>
>> Josh
>>
>> --
>> 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



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux