[openstack-dev] Do all OpenStack daemons support sd_notify?

Clint Byrum clint at fewbar.com
Mon Dec 15 16:00:01 UTC 2014


Excerpts from Ihar Hrachyshka's message of 2014-12-15 07:21:04 -0800:
> Hash: SHA512
> 
> On 14/12/14 09:45, Thomas Goirand wrote:
> > Hi,
> > 
> > As I am slowing fixing all systemd issues for the daemons of
> > OpenStack in Debian (and hopefully, have this ready before the
> > freeze of Jessie), I was wondering what kind of Type= directive to
> > put on the systemd .service files. I have noticed that in Fedora,
> > there's Type=notify. So my question is:
> > 
> > Do all OpenStack daemons, as a rule, support the DBus sd_notify
> > thing? Should I always use Type=notify for systemd .service files?
> > Can this be called a general rule with no exception?
> 
> (I will talk about neutron only.)
> 
> I guess Type=notify is supposed to be used with daemons that use
> Service class from oslo-incubator that provides systemd notification
> mechanism, or call to systemd.notify_once() otherwise.
> 
> In terms of Neutron, neutron-server process is doing it, metadata
> agent also seems to do it, while OVS agent seems to not. So it really
> should depend on each service and the way it's implemented. You cannot
> just assume that every Neutron service reports back to systemd.
> 
> In terms of Fedora, we have Type=notify for neutron-server service only.
> 
> BTW now that more distributions are interested in shipping unit files
> for services, should we upstream them and ship the same thing in all
> interested distributions?
> 

Since we can expect the five currently implemented OS's in TripleO to all
have systemd by default soon (Debian, Fedora, openSUSE, RHEL, Ubuntu),
it would make a lot of sense for us to make the systemd unit files that
TripleO generates set Type=notify wherever possible. So hopefully we can
actually make such a guarantee upstream sometime in the not-so-distant
future, especially since our CI will run two of the more distinct forks,
Ubuntu and Fedora.



More information about the OpenStack-dev mailing list