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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
