[PKG-Openstack-devel] Bug#770706: keystone.service does not start, /var/run/keystone not created

[Gaudenz Steinlin]

Hi

Thomas Goirand <zigo at debian.org> writes:

> On 12/01/2014 05:12 AM, Mikaël Cluseau wrote:
>> Hi Gaudenz,
>> 
>> thank you for your comments. As I tried to explain first, I wanted to
>> make the smallest possible step that could possibly work because, from
>> what I understood, once we get in the freeze phase, users can take the
>> current state as a feature (ie, on the python-django-pyscss package,
>> Thomas had to selectively choose commits from the upstream's fix-only
>> branch).

I think you are mixing several things. The restrictions during the
freeze are not because of user expectations but because Debian has to
restrict the amount of changes if it wants to release at all. So only
new changes which fix (RC) bugs are allowed and the changes should be as
minimal as possible to fix the bug.

While I would have loved to have full systemd support already in jessie,
I'm sceptical this is still possible. So my advise for wheezy would be
to just remove the unit files alltogether and to rely on the sysv init
support in systemd.

So the comments below (and already in my last mail) are mostly targeted
at the state after jessie.

>> 
>> On 12/01/2014 01:48 AM, Gaudenz Steinlin wrote:
>>> I still don't like the idea of using the sysv init script here. I'd
>>> rather simplify the init script to the point where this is no longer
>>> needed
>> 
>> I agree, and I tried to get as close to this as possible. However, the
>> following feature really doesn't in the systemd's spirit IMHO:
>> 
>> [ "x$USE_SYSLOG" = "xyes" ] && DAEMON_ARGS="$DAEMON_ARGS --use-syslog"
>> [ "x$USE_LOGFILE" != "xno" ] && DAEMON_ARGS="$DAEMON_ARGS
>> --log-file=$LOGFILE"

I wanted to comment on this already in my first reply but forgot. What's
the advantage of comparing with "x" prepended here? I don't see why this
is needed at all if you use proper quoteing. But maybe I'm missing
something. I always found these prepended x very confusing and they make
the code harder to read.

>> 
>> I think a next step will be to get rid of this as it duplicates the
>> configuration files anyway.
>
> I don't agree at all here. It's *not* a duplicate. With a configuration
> file, you can choose, globally, for a given service, where to log. You
> cannot select which daemon. For example, if you use the configuration
> file for Glance, it will affect both the glance-registry and the
> glance-api daemon. With the /etc/default system, you can do it for only
> one of the daemons if you like. Also, the /etc/default/openstack can be
> global to *all* of OpenStack services, which you cannot do with all
> configuration files (well, you can, but then you have to edit each and
> every service configuration file, which is really annoying).
>
> So we really need this as a feature to make it easy to configure for
> each service, and the configuration files just wont do it.

I don't care very much about this. I can see Thomas point but as long as
it's also possible to configure this in the config file, I guess it's
more confusing to have two ways to configure the same thing than it
helps in the IMO very special case you want to split your files and not
use syslog. I would expect most openstack to use syslog and log to a
central log server.

The variables are designed in a way which is a bit hard to support with
systemd. It would be easier if the values in the /etc/default/ files
already contained the command line arguments.

>
>
>>> and we can just have the following in our unit file:
>>> EnvironmentFile=/etc/default/openstack /etc/default/${PROJECT_NAME}
>>> And then use the proper variables in the ExecStart setting. 
>
> No, it's not ${PROJECT_NAME}, but the daemon name!!!

This was not meant to be copied literaly. So no need for "!!!". Just
list the files that are read now to have the same variables. This was
the idea.

I don't yet fully understand how the templates in openstack-pkg-tools
work. How are service specific values filled in?

>
>>>> 1. don't auto-create the /var/*/${PROJECT_NAME} folder if not root, as 
>>>> it will fail anyway.
>>> Most of these should not be created by the init script anyway. Creating
>>> /var/lib/X and /var/log/X there seems like a bug to me. These should be
>>> part of the package. That's how it's done in all other packages I know.
>> 
>> I agree but I think we can't remove this feature in the freeze phase. In
>> fact, I think that a real systemd approach wouldn't use a specific log
>> dir anyway, and just let the software use stdout. You then have your log
>> managed by journald, with all the wonders like consistent timestamping
>> and filtering by many criterions.
>
> It's up to the operator to choose. Some would like to keep a per-daemon
> log, especially because otherwise, it can fill your syslog very fast.
> And also, consider the fact that journald is really bad performance
> wise, then you don't really want to fill-it-up with huge debug logs.

I agree that we should let the operator choose how he want's to do
logging. I don't think anyone want's to dispute that. But we need a
default configuration. Certainly we don't want debug logging by default
at all.

Anyway the discussion was about creating /var/log and /var/lib from the
sysv init script. This is wrong in all cases independently how logging
is done. This just belongs to the package.

>
>>>> 3. /var/lock/${PROJECT_NAME}, AFAIK, is not needed when using systemd;
>>> What was it used for? Seems strange that there is a difference between
>>> sysv and systemd here.
>> 
>> I think this is only needed by start-stop-daemon to avoid launching
>> multiple instances, but I may be wrong.
>
> I do believe that the /var/lock/${PROJECT_NAME} is needed in some cases
> for the internals of OpenStack. I would find it dangerous to remove
> it.

Then we have to find out which ones use it and create it for those
services. At least IMO.

>
>>> I would really prefer to have a full systemd unit file that does not
>>> depend on the sysv script at all.
>> 
>> We agree on this goal :-)
>
> Yup, me as well.

So we all agree on this. From here at least for me it follows that the
non working unit files should be removed as soon as possible. If we can
come up with a solution without relying on the sysv init script and that
is acceptable for the Release team, then good. Otherwise the second best
option IMO is to use the sysv support in systemd and not ship any unit
files.

>
>>> It's fine and probably a good idea to use the files in /etc/default/.
>> 
>> I not sure its a good idea, as I don't think it makes sense when you can
>> just throw 2 lines in a /etc/systemd/system unit file to override the
>> ExecStart line.
>
> I do think it's better to keep the same user interface for both systemd
> and sysv-rc.

I agree with Thomas here. As long as we support switching back to sysv
this is better than using a systemd only mechanism. At least if it's
very easy to support this.

I don't think the wiki page cited earlier about /etc/default represents
the project consensus about this but rather the systemd maintainers
preference. And it only talks about new packages. So it does not really
apply here.

Gaudenz