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

[Gaudenz Steinlin]

Thomas Goirand <zigo at debian.org> writes:

> On 12/04/2014 05:42 PM, Gaudenz Steinlin wrote:
>>> with the same global section in 
>>> /usr/share/keystone/keystone-systemd.conf. One can then use 
>>> /etc/openstack.conf to switch back to syslog or stdout or stderr or 
>>> whatever she wants globally.
>> 
>> That looks like a good solution to me to get rid of the /etc/default
>> files without loosing any functionality. This would avoid duplicating
>> configuration settings in configuration files and /etc/default files.
>> Looks like the best solution to me, but ovviously post jessie.
>> 
>> Gaudenz
>
> I not sure this is a good solution. The only correct way is to configure
> it on the command line, with the init system, as we need a per-daemon
> configuration to keep previous functionality. I'm not even sure that
> with a non-existent /etc/default/openstack.conf, the daemons would all
> continue to run without complaining.

I'm not sure if I understand your concerns. As far as I understood what
Mikael found out it's possible to start the daemons with multiple
configuration files. With this it's possible to have a configuration
file with general OpenStack settings, one with project specific settings
and one with service specific settings.

To give you an example for nova-compute we would have these 3
configuration files (paths and names may change, this is only an
example):
- /etc/openstack/openstack.conf -> OpenStack generic settings
- /etc/nova/nova.conf           -> Settings for all nova services
- /etc/nova/nova-compute.conf   -> Settings only for nova-compute

The init system (every init system, not just systemd) would then start
the nova-compute service with this command:
nova-compute --config /etc/openstack/openstack.conf --config /etc/nova/nova.conf --config /etc/nova/nova-compute.conf

I currently don't see anything that can be done today with /etc/default
files that can't be done with this scheme. Am I missing something?

Sure this would need some changes to existing configuration and maybe
even a migration in the postinst script. But as this is all not targeted
at jessie we have plenty of time to get this right. (Which does not mean
I want to wait with the implementation until the next freeze.)

>
> I very much prefer the current state of things with (shell)
> configuration files in /etc/default, and I don't see any valid reason
> why we would stop using that.

The very compelling reason I see to get rid of the /etc/default files is
that we can have the same flexibility without them and that they
duplicate configuration settings from the config files (eg. logging). To
me having two ways to configure the same thing seems like a significant
disadvantage. That's why I'd prefer to get rid of /etc/default/xxx.

Gaudenz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20141205/5f14f6a6/attachment.sig>