Feature #13021
openceph: run daemons via init system
Added by Sage Weil over 8 years ago. Updated over 4 years ago.
0%
Description
the daemon-wrapper is non-standard, and doesn't test the init system. it also doesn't run as the ceph user
Updated by Andrew Schoen over 8 years ago
Is what you're looking to get rid of, or modify?
https://github.com/ceph/teuthology/blob/master/teuthology/task/daemon-helper
Or,this? https://github.com/ceph/teuthology/blob/master/teuthology/task/adjust-ulimits
Updated by Zack Cerza over 8 years ago
- Status changed from New to Need More Info
- Assignee set to Sage Weil
Sage, since daemon-helper predates me, would you mind explaining why we've needed it? And would you also be able to share your thoughts on how we might replace its functionality with something invoked via the init system?
Finally, by "the init system" - I am guessing you mean "each of the init systems we support". Is that true?
Updated by Boris Ranto over 8 years ago
@zack: If you use ceph-deploy to deploy the cluster, it should handle the choice of init system transparently. That would probably mean fixing this together with issue 13023, though.
btw: I have recently created something similar (automated cluster installation with ceph-deploy, far less complex than what teuthology does, though). Maybe, it could be of some use for you:
Updated by Sage Weil over 8 years ago
- Status changed from Need More Info to 12
- Assignee deleted (
Sage Weil)
Zack Cerza wrote:
Sage, since
daemon-helperpredates me, would you mind explaining why we've needed it? And would you also be able to share your thoughts on how we might replace its functionality with something invoked via the init system?
We used to run everything out of make install tarball extracted into /tmp/cephtest... ceph wasn't actually "installed" and using the init system wasn't an option.
daemon-helper also made it easy to notice when a daemon crashed. (e.g., stderr shows up in teuthology.log).
But.. we can accomplish that using the normal init system now. Well, maybe not stderr, but we can poll 'systemctl status ...'.
I think this means we need to change the DaemonHelper (?) class that has start(), stop(), send_signal(), etc. methods to invoke systemctl ... or upstart as needed.
I suspect the main thing we need to fix/change is to make upstart not restart the daemon, so that we can check the status and know whther the daemon crashed unexpectedly.
Finally, by "the init system" - I am guessing you mean "each of the init systems we support". Is that true?
We could possibly get away with not supporting sysvinit, although it is probably easy to do so. systemd and upstart are the two that matter. I think/hope it's mainly a matter of implementing those methods. The hard part will be switching all of the other code around to use the daemon framework in the first place (there are lots of explicit callers of daemon-helper, iirc.)
Side note: there is a daemon-helper argument that says what signal to send to shutdown... I think this was there in order to support gcov, which we don't use. I would rip out that complexity (iirc it does some weird inference based on the build flavor.
Oh.. supporting valgrind might be tricky. Hrm. Perhaps if everything is funneled through a single class we can keep a daemon-helper based one that we still use in the valgrind case... we still get good coverage on the real init system the rest of the time.
Updated by Vasu Kulkarni over 8 years ago
I think it would be better to use ceph-deploy to create cluster and it will handle the various init systems automatically, The script needs some optimization and it can be done easily, I am planning to run the smoke suite using ceph-deploy task instead of ceph task to see how it works, valgrind is the other thing it wont handle.