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

[Mikaël Cluseau]

Hi,

On 12/02/2014 01:52 AM, Gaudenz Steinlin wrote:
> So only new changes which fix (RC) bugs are allowed and the changes 
> should be as minimal as possible to fix the bug.

Since I already posted patches for a minimal set of code changes with a 
minimal set of feature changes, I can now move on more radical changes. 
My policy is now to follow your comments as long as Thomas doesn't 
disagree (including this policy itself ;-)). That's why I've gone 
farther in my last reply.

> I wanted to comment on this already in my first reply but forgot. 
> What's the advantage of comparing with "x" prepended here?

I didn't change what existed here. AFAIK, it's a pratice to help have 
portable shell scripts.

>> 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. [...] 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 [...]
>
> 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.

If we want to use these environment files, I can't see a way to keep the 
current logic without using a shell. As you say and as is suggested in 
https://wiki.debian.org/systemd/Packaging#overriding_options_and_.2Fetc.2Fdefault_handling, 
we could switch to an OPTIONS environment variable used in ExecStart. 
Supporting USE_SYSLOG and USE_LOGFILE seems hard to do while the OPTIONS 
solution improves the feature by allowing to specify globally any 
globally recognized daemon parameters. Thus, I think it's a reasonable 
choice that is easy to support in both init systems. As there's a 
consensus on keeping the same interface for the sysv-rc and systemd, we 
should change the init script accordingly.

My proposal is the following:

EnvironmentFile=-/etc/default/openstack
EnvironmentFile=-/etc/default/${NAME}
ExecStart=${DAEMON}--config-file=/etc/${PROJECT_NAME}/${PROJECT_NAME}.conf  \${OPTIONS}


We could even use the following environment files when $PROJECT_NAME != 
$NAME:

EnvironmentFile=-/etc/default/openstack
EnvironmentFile=-/etc/default/${PROJECT_NAME}
EnvironmentFile=-/etc/default/${NAME}


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

Every package has a debian/${DAEMON}.init.in with the variables defined. 
For instance for keystone:

[...]
DESC="OpenStack Identity service"
PROJECT_NAME=keystone
NAME=keystone
DAEMON=/usr/bin/keystone-all


> 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. 

I agree that someone switching where the log file are should create the 
log directories accordingly. As a consequence, if we default to 
/var/log/${PROJECT_NAME}, and if every other package is creating these 
at install time, we probably should do the same and create 
/var/log/${PROJECT_NAME} at install time (that whould even fix this bug 
without having to change a line in the unit and the sysv-rc script).

>> 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 prefer to avoid dangerous choices; its not expensive to have these 
created. But then, should they be created by systemd or at install time? 
(Thomas?)

> 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.

I think my previous work (keeping the init-script) can be accepted by 
the release team and is a significant step toward the systemd's way as 
it avoids start-stop-daemon. I will add the missing auto-created folders 
to keep closer to the original script.