Open Stack

2014-12-15 17:00 GMT+01:00 Clint Byrum <clint at fewbar.com>:
> Excerpts from Ihar Hrachyshka's message of 2014-12-15 07:21:04 -0800:
>> 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.
...
>> 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.

There's one issue with Type=notify that Dan Prince discovered and
where Type=simple works better for his use-case:
if service startup takes more than DefaultTimeoutStartSec (90s by
default) and systemd does not get notification from the service, it
will consider it failed and try to restart it if Restart is defined in
the service unit file.
I tried to fix that by disabling timeout (example in Nova package
https://review.gerrithub.io/13054 ) but then systemctl start blocks
until notification is received.
Copying Dan's review comment: "This still isn't quite right. It is
better in that the systemctl doesn't think the service fails... rather
it just seems to hang indefinately on 'systemctl start
openstack-nova-compute', as in I never get my terminal back.
My test case is:
1) Stop Nova compute. 2) Stop RabbitMQ. 3) Try to start Nova compute
via systemctl.
Could the RabbitMQ retry loop be preventing the notification?
"

Current implementation in oslo service sends notification only just
before entering the wait loop, because at that point all
initialization should be done and service ready to serve. Does anyone
have a suggestion for the better place where to notify service
readiness?
Or should just Dan's test-case step 3) be modified as:
3) Start Nova compute via systemctl start ... &  (i.e. in the background) ?


Cheers,
Alan