Adding systemd unit files in OpenStack packages

[Thomas Goirand]

On 07/08/2014 01:02 AM, Michael Stapelberg wrote:
> Thomas Goirand <zigo at debian.org> writes:
>> Well, network should be up, so that the IP is configured, and the daemon
>> can bind on it. But probably this part is already handled by the fact
>> I'm writing WantedBy=multi-user.target?
> No. You should explicitly add “After=network.target”. This is roughly
> equivalent to what $network in sysvinit scripts meant. Do note that
> systemd in general expects programs to behave reasonably when being
> faced with changing network interfaces, i.e. network interfaces can go
> down or come up at any point in time, and the configured IP addresses
> can also change.
> 
> This is not behavior that was introduced by systemd, but rather an
> observation of the status quo in today’s world (think of mobile devices
> for example). Hence, systemd does not pretend to provide a point at
> which “the network is up”, which is a broken concept these days :).

I do agree in principle. However, practically, many daemon do need the
network to be up to be able to bind correctly. :(

Do you know what's the default behavior if you bind on 0.0.0.0? Will the
daemon just pick-up whatever new IP is configured after its started?

>>>> Then another example. With nova-compute, I have the following:
>>>>
>>>> [ -r /etc/default/openstack ] && . /etc/default/openstack
>>>> [ -r /etc/default/$NAME ] && . /etc/default/$NAME
>>>>
>>>> [ "x$USE_SYSLOG" = "xyes" ] && DAEMON_ARGS="$DAEMON_ARGS --use-syslog"
>>>> [ "x$USE_LOGFILE" != "xno" ] && DAEMON_ARGS="$DAEMON_ARGS \
>>>> 	--log-file /var/log/nova/$NAME.log"
>>>>
>>>> The idea is that, by default, nova-compute only logs to a file. That is,
>>>> unless someone configures /etc/default/nova-compute. It is also possible
>>>> configure it globally in /etc/default/openstack (with the same
>>>> directives). How do I do this in a systemd unit file?
>>>
>>> I think they probably should log to the journal by default.
>>
>> I don't think so. File logging is what everybody does by default in
>> OpenStack, so I don't want to change the default behavior, only provide
>> another (optional) facility, easily configured.
> See StandardOutput in systemd.exec(5) for the logging facilities that
> systemd provides. Note that logging to a file is absent from these
> facilities.

But this is available in all OpenStack daemons directly, using the
command line arguments, which is what I want to use.

> Instead, as ansgar suggested, you should log to the
> journal. In case logging to a file is expected by OpenStack people, how
> about shipping a syslog config fragment that will make rsyslog write the
> messages generated by OpenStack to a file? That way, you’ll have both.

Well... no! :) I have to insist. What I want is to be able to use
whatever the user configures in /etc/default, just like I'm doing right
now already. And this is configured through the command line of each
daemons. I know that there's scripting available in systemd units, but I
couldn't find out how to make it influence the ExecStart directive.

> I do expect the majority of users to look into the journal in a while,
> though, as it’s just so much more convenient to use/filter/search than
> regular files.

However, systemd journal have some issues, as much as I have read, and
unless things changed. First, it wouldn't do network logging, just like
syslog does (am I right here?). And then, it wouldn't handle extreme
loads in the order of terabytes per day. So I want to keep things
configurable.

>> Well, I do not want to change the current behavior, as I know some
>> OpenStack on Debian users already have it in production. Having stuff
>> configured in a systemd units isn't ideal also because there's no unique
>> single place to configure all daemons (eg: /etc/default/openstack), and
>> configuring each and every systemd unit by hand wouldn't be nice. So I
>> would like to keep current behavior with systemd as well.
> The canonical way in systemd to configure things is in the configuration
> file of the application itself. If the application does not support
> that, the administrator would write a config snippet,
> e.g. /etc/systemd/system/apache2.service.d/ulimit.conf that overwrites a
> specific part of the service file, e.g.:
> 
>   [Service]
>   LimitNOFile=4096
> 
> Anyway, if you really really insist, you can use
> EnvironmentFile=/etc/default/openstack in your service files and use
> variables defined therein. Mind you, that’s not an idiomatic service
> file then, though, and perhaps people will be surprised/disappointed to
> see that openstack is deviating.

Ok, so it will read stuff in /etc/default/openstack. But then how do I
make ExecStart have different startup command depending on the
EnvironmentFile? What if EnvironmentFile=/etc/default/openstack doesn't
exist (which would be the default case)? Would it still continue to work
and start the daemon?

Cheers,

Thomas Goirand (zigo)