Discussion:
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
(too old to reply)
Mikaël Cluseau
2014-11-30 07:40:01 UTC
Permalink
Hi all,

I tried to minimize the changes to get close to a unit file in the
systemd spirit, while still using on the init-script to keep same
features as before. The patch below reflect the following actions:

1. don't auto-create the /var/*/${PROJECT_NAME} folder if not root, as
it will fail anyway.
2. add a do_systemd_start function to implement the systemd-start
argument that will exec' the daemon with the previously computed args.
3. since then systemd will manage the daemon, the systemd-stop argument
can be removed.
4. since the script doesn't create the necessary folders anymore, create
what's required using the systemd unit file.

The point 4 is where I did the most invasive choices; I assumed that
1. /var/run/${PROJECT_NAME} is not needed since PID file is not created
anymore (process managed by systemd);
2. /var/lib/${PROJECT_NAME} doesn't have to be created as it is created
when the package is installed;
3. /var/lock/${PROJECT_NAME}, AFAIK, is not needed when using systemd;
4. /var/log/${PROJECT_NAME} is the only one that is both required and
can be considered volatile.

If any of these choices is wrong, it's easy to add the folder in the
ExecStartPre lines of the systemd unit file.

If the systemd-stop argument should still be supported, I think it
should be noop or print a depreciation warning.

As a consequence of these changes, the unit file doesn't need its
RuntimeDirectory and PIDFile directives. Since the daemon is exec'd, the
Type falls back to the default (simple) so it is removed too.

I don't how to do less than that, so here is my minimal patch proposal:

diff --git a/init-template/init-script-template
b/init-template/init-script-template
index 0326b5d..fd20957 100644
--- a/init-template/init-script-template
+++ b/init-template/init-script-template
@@ -36,11 +36,13 @@ fi
# Exit if the package is not installed
[ -x $DAEMON ] || exit 0

-# Create /var/lock/X, /var/run/X, /var/lib/X and /var/log/X
-for i in lock run log lib ; do
- mkdir -p /var/$i/${PROJECT_NAME}
- chown ${SYSTEM_USER} /var/$i/${PROJECT_NAME}
-done
+# If ran as root, create /var/lock/X, /var/run/X, /var/lib/X and
/var/log/X as needed
+if [ "x$USER" = "xroot" ] ; then
+ for i in lock run log lib ; do
+ mkdir -p /var/$i/${PROJECT_NAME}
+ chown ${SYSTEM_USER} /var/$i/${PROJECT_NAME}
+ done
+fi

# This defines init_is_upstart which we use later on (+ more...)
. /lib/lsb/init-functions
@@ -65,6 +67,10 @@ do_stop() {
return "$RETVAL"
}

+do_systemd_start() {
+ exec $DAEMON $DAEMON_ARGS
+}
+
case "$1" in
start)
init_is_upstart > /dev/null 2>&1 && exit 1
@@ -88,11 +94,8 @@ status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
systemd-start)
- do_start
+ do_systemd_start
;;
-systemd-stop)
- do_stop
-;;
restart|force-reload)
init_is_upstart > /dev/null 2>&1 && exit 1
log_daemon_msg "Restarting $DESC" "$NAME"
@@ -110,7 +113,7 @@ restart|force-reload)
esac
;;
*)
- echo "Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload|systemd-start|systemd-stop}" >&2
+ echo "Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload|systemd-start}" >&2
exit 3
;;
esac
diff --git a/init-template/pkgos-gen-systemd-unit
b/init-template/pkgos-gen-systemd-unit
index b97e2a9..09cf3e5 100755
--- a/init-template/pkgos-gen-systemd-unit
+++ b/init-template/pkgos-gen-systemd-unit
@@ -33,12 +33,11 @@ $AFTER
[Service]
User=${SYSTEM_USER}
Group=${SYSTEM_GROUP}
+PermissionsStartOnly=true
+ExecStartPre=/bin/mkdir -p /var/log/${PROJECT_NAME}
+ExecStartPre=/bin/chown ${SYSTEM_USER}:${SYSTEM_GROUP}
/var/log/${PROJECT_NAME}
ExecStart=${SCRIPTNAME} systemd-start
-ExecStop=${SCRIPTNAME} systemd-stop
-RuntimeDirectory=${PROJECT_NAME}
-PIDFile=/var/run/${PROJECT_NAME}/${NAME}.pid
Restart=on-failure
-Type=forking

[Install]
WantedBy=multi-user.target
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Mikaël Cluseau
2014-11-30 07:50:01 UTC
Permalink
Sorry, I forgot to change the WorkingDirectory to fully comply with the
start-stop-daemon line. The patch for the unit file should be:

diff --git a/init-template/pkgos-gen-systemd-unit
b/init-template/pkgos-gen-systemd-unit
index b97e2a9..8700b6c 100755
--- a/init-template/pkgos-gen-systemd-unit
+++ b/init-template/pkgos-gen-systemd-unit
@@ -33,12 +33,12 @@ $AFTER
[Service]
User=${SYSTEM_USER}
Group=${SYSTEM_GROUP}
+WorkingDirectory=/var/lib/${PROJECT_NAME}
+PermissionsStartOnly=true
+ExecStartPre=/bin/mkdir -p /var/log/${PROJECT_NAME}
+ExecStartPre=/bin/chown ${SYSTEM_USER}:${SYSTEM_GROUP}
/var/log/${PROJECT_NAME}
ExecStart=${SCRIPTNAME} systemd-start
-ExecStop=${SCRIPTNAME} systemd-stop
-RuntimeDirectory=${PROJECT_NAME}
-PIDFile=/var/run/${PROJECT_NAME}/${NAME}.pid
Restart=on-failure
-Type=forking

[Install]
WantedBy=multi-user.target
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gaudenz Steinlin
2014-11-30 15:00:02 UTC
Permalink
Hi

Thanks for working on this. This looks like a step in the right
direction. I however still have some problems with the proposed
approach.
Post by Mikaël Cluseau
Hi all,
I tried to minimize the changes to get close to a unit file in the
systemd spirit, while still using on the init-script to keep same
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 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.
Post by Mikaël Cluseau
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.
Post by Mikaël Cluseau
2. add a do_systemd_start function to implement the systemd-start
argument that will exec' the daemon with the previously computed args.
That's an improvement over the current state. But how do you ensure that
the daemon is started in the foreground?
Post by Mikaël Cluseau
3. since then systemd will manage the daemon, the systemd-stop argument
can be removed.
4. since the script doesn't create the necessary folders anymore, create
what's required using the systemd unit file.
The point 4 is where I did the most invasive choices; I assumed that
1. /var/run/${PROJECT_NAME} is not needed since PID file is not created
anymore (process managed by systemd);
2. /var/lib/${PROJECT_NAME} doesn't have to be created as it is created
when the package is installed;
The please remove it from the init script alltogether. It's also not
needed when under sysv then.
Post by Mikaël Cluseau
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.
Post by Mikaël Cluseau
4. /var/log/${PROJECT_NAME} is the only one that is both required and
can be considered volatile.
No this should definitely not be considered volatile. It's ok to delete
the logfiles inside, but no one can expect the daemon to still work if
he just removes this directory completely. For all other packages I know
if this is part of the package and not created on the fly.

I would really prefer to have a full systemd unit file that does not
depend on the sysv script at all. It's fine and probably a good idea to
use the files in /etc/default/.

Gaudenz
Post by Mikaël Cluseau
If any of these choices is wrong, it's easy to add the folder in the
ExecStartPre lines of the systemd unit file.
If the systemd-stop argument should still be supported, I think it
should be noop or print a depreciation warning.
As a consequence of these changes, the unit file doesn't need its
RuntimeDirectory and PIDFile directives. Since the daemon is exec'd, the
Type falls back to the default (simple) so it is removed too.
diff --git a/init-template/init-script-template
b/init-template/init-script-template
index 0326b5d..fd20957 100644
--- a/init-template/init-script-template
+++ b/init-template/init-script-template
@@ -36,11 +36,13 @@ fi
# Exit if the package is not installed
[ -x $DAEMON ] || exit 0
-# Create /var/lock/X, /var/run/X, /var/lib/X and /var/log/X
-for i in lock run log lib ; do
- mkdir -p /var/$i/${PROJECT_NAME}
- chown ${SYSTEM_USER} /var/$i/${PROJECT_NAME}
-done
+# If ran as root, create /var/lock/X, /var/run/X, /var/lib/X and
/var/log/X as needed
+if [ "x$USER" = "xroot" ] ; then
+ for i in lock run log lib ; do
+ mkdir -p /var/$i/${PROJECT_NAME}
+ chown ${SYSTEM_USER} /var/$i/${PROJECT_NAME}
+ done
+fi
# This defines init_is_upstart which we use later on (+ more...)
. /lib/lsb/init-functions
@@ -65,6 +67,10 @@ do_stop() {
return "$RETVAL"
}
+do_systemd_start() {
+ exec $DAEMON $DAEMON_ARGS
+}
+
case "$1" in
start)
init_is_upstart > /dev/null 2>&1 && exit 1
@@ -88,11 +94,8 @@ status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
systemd-start)
- do_start
+ do_systemd_start
;;
-systemd-stop)
- do_stop
-;;
restart|force-reload)
init_is_upstart > /dev/null 2>&1 && exit 1
log_daemon_msg "Restarting $DESC" "$NAME"
@@ -110,7 +113,7 @@ restart|force-reload)
esac
;;
*)
- echo "Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload|systemd-start|systemd-stop}" >&2
+ echo "Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload|systemd-start}" >&2
exit 3
;;
esac
diff --git a/init-template/pkgos-gen-systemd-unit
b/init-template/pkgos-gen-systemd-unit
index b97e2a9..09cf3e5 100755
--- a/init-template/pkgos-gen-systemd-unit
+++ b/init-template/pkgos-gen-systemd-unit
@@ -33,12 +33,11 @@ $AFTER
[Service]
User=${SYSTEM_USER}
Group=${SYSTEM_GROUP}
+PermissionsStartOnly=true
+ExecStartPre=/bin/mkdir -p /var/log/${PROJECT_NAME}
+ExecStartPre=/bin/chown ${SYSTEM_USER}:${SYSTEM_GROUP}
/var/log/${PROJECT_NAME}
ExecStart=${SCRIPTNAME} systemd-start
-ExecStop=${SCRIPTNAME} systemd-stop
-RuntimeDirectory=${PROJECT_NAME}
-PIDFile=/var/run/${PROJECT_NAME}/${NAME}.pid
Restart=on-failure
-Type=forking
[Install]
WantedBy=multi-user.target
_______________________________________________
Openstack-devel mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Mikaël Cluseau
2014-11-30 21:20:01 UTC
Permalink
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).
Post by Gaudenz Steinlin
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 think a next step will be to get rid of this as it duplicates the
configuration files anyway.
Post by Gaudenz Steinlin
EnvironmentFile=/etc/default/openstack /etc/default/${PROJECT_NAME}
And then use the proper variables in the ExecStart setting.
In the same way, we should get rid of these environment files. See the
note here
https://wiki.debian.org/systemd/Packaging#overriding_options_and_.2Fetc.2Fdefault_handling:
"Note that it is preferable to configure options using native systemd
mechanisms for new packages". I definitely agree with this statement but
even if I wouldn't, it the Debian project's recommendation.
Post by Gaudenz Steinlin
Post by Mikaël Cluseau
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. Since OpenStack has a microservice
approach, the log would be naturally filtered: I'm not aware of any
requirement for, for instance, an access vs error log like with Apache
HTTPd or the same kind log multiplexing (I can think of ISC bind too).
Post by Gaudenz Steinlin
That's an improvement over the current state. But how do you ensure that
the daemon is started in the foreground?
I tried to get as close as possible to a unit file consisting of this:

[Service]
User=${SYSTEM_USER}
Group=${SYSTEM_GROUP}
WorkingDirectory=/var/lib/${PROJECT_NAME}
ExecStart=${DAEMON} --config-file=/etc/${PROJECT_NAME}/${PROJECT_NAME}.conf
Restart=on-failure

while retaining still running the daemon with the options users may
expect from the sysv init script. Since start-stop-daemon is used with
the "--background" option and uses a PID file, I know the program runs
in foreground as otherwise stopping would fail, kill a non-existant PID.
So, the do_systemd_start simply does this:

do_systemd_start() {
exec $DAEMON $DAEMON_ARGS
}

which replaces the shell process with the daemon one. In the context of
systemd with a service type of "simple", it is strictly equivalent to

start-stop-daemon [...] --background [...] --startas $DAEMON $DAEMON_ARGS

There's another improvement to do: at least keystone supports systemd's
notification system. Which means we could use a Type=notify if we did
adapt the default configuration file to include an "onready"
configuration:
http://docs.openstack.org/icehouse/config-reference/content/section_keystone.conf.html

|# onready allows you to send a notification when the process|
|# is ready to serve For example, to have it notify using|
|# systemd, one could set shell command: "onready = systemd-|
|# notify --ready" or a module with notify() method: "onready =|
|# keystone.common.systemd".|

There are also the security improvements you suggested (very interesting
link by the way).
Post by Gaudenz Steinlin
The please remove it from the init script alltogether. It's also not
needed when under sysv then.
/var/run is required for the classic sysv system. /var/lib could be
removed from here but it wouldn't be strictly addressing the current
bug, as it is only an issue linked to running the sysv init script with
the service user instead of root.
Post by Gaudenz Steinlin
Post by Mikaël Cluseau
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.
Post by Gaudenz Steinlin
Post by Mikaël Cluseau
4. /var/log/${PROJECT_NAME} is the only one that is both required and
can be considered volatile.
No this should definitely not be considered volatile. It's ok to delete
the logfiles inside, but no one can expect the daemon to still work if
he just removes this directory completely. For all other packages I know
if this is part of the package and not created on the fly.
While I tend to agree, I think that since it was automatically
recreated, some people now use this as a feature.
Post by Gaudenz Steinlin
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 :-)
Post by Gaudenz Steinlin
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.
Thomas Goirand
2014-12-01 11:30:04 UTC
Permalink
Post by Mikaël Cluseau
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).
Post by Gaudenz Steinlin
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
[ "x$USE_SYSLOG" = "xyes" ] && DAEMON_ARGS="$DAEMON_ARGS --use-syslog"
[ "x$USE_LOGFILE" != "xno" ] && DAEMON_ARGS="$DAEMON_ARGS
--log-file=$LOGFILE"
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.
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
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!!!
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
Post by Mikaël Cluseau
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.
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
Post by Mikaël Cluseau
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.
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
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.
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
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.

Cheers,

Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gaudenz Steinlin
2014-12-01 15:00:02 UTC
Permalink
Hi
Post by Thomas Goirand
Post by Mikaël Cluseau
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.
Post by Thomas Goirand
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
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
[ "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.
Post by Thomas Goirand
Post by Mikaël Cluseau
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.
Post by Thomas Goirand
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
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?
Post by Thomas Goirand
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
Post by Mikaël Cluseau
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.
Post by Thomas Goirand
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
Post by Mikaël Cluseau
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.
Post by Thomas Goirand
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
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.
Post by Thomas Goirand
Post by Mikaël Cluseau
Post by Gaudenz Steinlin
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Mikaël Cluseau
2014-12-02 07:30:02 UTC
Permalink
Hi,
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.
Post by Thomas Goirand
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).
Post by Thomas Goirand
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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gaudenz Steinlin
2014-12-02 18:10:03 UTC
Permalink
Hi Mikael

Thanks for still working on this. I think we are getting closer to a
workable solution.
Post by Mikaël Cluseau
Hi,
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.
Did you test the patches with the "minimal set of changes". I think we
need strong arguments that they are working if we want to propose them
to the Release Team for jessie. I currently don't have a good setup to
test such patches.
Post by Mikaël Cluseau
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.
After thinking about this a bit more, it's only usefull in case the
variable content starts with a "-" to avoid it being interpreted as a
test flag. Eg. USE_SYSLOG="-f" would cause an error without this
construct. The empty variable case is already dealt with the quoting.
So it's probably usefull to keep it.
Post by Mikaël Cluseau
Post by Thomas Goirand
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.
Yes supporting the yes/no variables is probably not possible directly in
systemd. If we really want to keep them, then we need a small script to
compile the needed command line arguments from them.
Post by Mikaël Cluseau
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 !=
EnvironmentFile=-/etc/default/openstack
EnvironmentFile=-/etc/default/${PROJECT_NAME}
EnvironmentFile=-/etc/default/${NAME}
I like this proposal. It would also simplify the sysv init script and
it's more flexible than the current approach at the same time. I prefer
this to the current set of yes/no variables. I'm not sure if an
automatic migration is necessary or if a NEWS.Debian entry is enough. I
would probably go for the latter as an automatic migration might be hard
to get right.

This change is certainly post jessie IMO. I don't think we should change
/etc/default settings for jessie at this stage. I don't think anyone
disputes that, just to be clear.

Thomas what do you think about it?
Post by Mikaël Cluseau
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.
[...]
DESC="OpenStack Identity service"
PROJECT_NAME=keystone
NAME=keystone
DAEMON=/usr/bin/keystone-all
OK, so PROJECT_NAME, NAME and DAEMON are all set on a per service basis
in the individual packages.
Post by Mikaël Cluseau
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).
Post by Thomas Goirand
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?)
What do you mean by dangerous choices? If we really need them they have
to be created by systemd and sysv init scripts as /var/lock is a symlink
into /run which is typically a tmpfs.
Post by Mikaël Cluseau
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.
Do you have a complete patch (including the recent discussion) which can
be applied to openstack-pkg-tools and used to rebuild test packages? I
think this needs thorough testing if it's to be proposed for jessie.

Gaudenz
Mikaël Cluseau
2014-12-02 20:40:02 UTC
Permalink
Hi Gaudenz,

I will focus on the so called "minimal set" for now. If you don't mind,
we will open another bug to improve systemd's integration after this one
is fixed.
Post by Gaudenz Steinlin
Did you test the patches with the "minimal set of changes". I think we
need strong arguments that they are working if we want to propose them
to the Release Team for jessie. I currently don't have a good setup to
test such patches.
I did with keystone but developper tests are never to be trusted ;-) Its
quite easy to test BTW, as root:

apt-get build-dep openstack-pkg-tools
git clone -b debian/unstable
https://github.com/MikaelCluseau/debian-openstack-pkg-tools.git
cd debian-openstack-pkg-tools
debuild -us -uc -b
dpkg -i ../openstack-pkg-tools_19_all.deb

Then you can build any other OpenStack package from source. For
instance, keystone:

apt-get source keystone
cd keystone-*/
debuild -us -uc -b
dpkg -i ../keystone_*.deb

There's a long test phase during the build, maybe Thomas can suggest a
trick to avoid it :-)
Post by Gaudenz Steinlin
What do you mean by dangerous choices?
Thomas considered the choice of not creating /var/lock/* dangerous.
Post by Gaudenz Steinlin
If we really need them they have
to be created by systemd and sysv init scripts as /var/lock is a symlink
into /run which is typically a tmpfs.
This is included in my last patch proposal.
Post by Gaudenz Steinlin
Do you have a complete patch (including the recent discussion) which
can be applied to openstack-pkg-tools and used to rebuild test
packages? I think this needs thorough testing if it's to be proposed
for jessie.
As I said at the beginning, yes. Here the complete patch for the
immediate review:

± git log -1 --stat -p
commit 8b3217905de88f2037f0bbc6eac46dca776c8f48
Author: Mikaël Cluseau <***@isi.nc>
Date: Sun Nov 30 18:45:25 2014 +1100

Fix for bug #770706
---
init-template/init-script-template | 23 +++++++++++++----------
init-template/pkgos-gen-systemd-unit | 10 +++++-----
2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/init-template/init-script-template
b/init-template/init-script-template
index 0326b5d..fd20957 100644
--- a/init-template/init-script-template
+++ b/init-template/init-script-template
@@ -36,11 +36,13 @@ fi
# Exit if the package is not installed
[ -x $DAEMON ] || exit 0

-# Create /var/lock/X, /var/run/X, /var/lib/X and /var/log/X
-for i in lock run log lib ; do
- mkdir -p /var/$i/${PROJECT_NAME}
- chown ${SYSTEM_USER} /var/$i/${PROJECT_NAME}
-done
+# If ran as root, create /var/lock/X, /var/run/X, /var/lib/X and
/var/log/X as needed
+if [ "x$USER" = "xroot" ] ; then
+ for i in lock run log lib ; do
+ mkdir -p /var/$i/${PROJECT_NAME}
+ chown ${SYSTEM_USER} /var/$i/${PROJECT_NAME}
+ done
+fi

# This defines init_is_upstart which we use later on (+ more...)
. /lib/lsb/init-functions
@@ -65,6 +67,10 @@ do_stop() {
return "$RETVAL"
}

+do_systemd_start() {
+ exec $DAEMON $DAEMON_ARGS
+}
+
case "$1" in
start)
init_is_upstart > /dev/null 2>&1 && exit 1
@@ -88,11 +94,8 @@ status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
systemd-start)
- do_start
+ do_systemd_start
;;
-systemd-stop)
- do_stop
-;;
restart|force-reload)
init_is_upstart > /dev/null 2>&1 && exit 1
log_daemon_msg "Restarting $DESC" "$NAME"
@@ -110,7 +113,7 @@ restart|force-reload)
esac
;;
*)
- echo "Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload|systemd-start|systemd-stop}" >&2
+ echo "Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload|systemd-start}" >&2
exit 3
;;
esac
diff --git a/init-template/pkgos-gen-systemd-unit
b/init-template/pkgos-gen-systemd-unit
index b97e2a9..4c41ef0 100755
--- a/init-template/pkgos-gen-systemd-unit
+++ b/init-template/pkgos-gen-systemd-unit
@@ -12,7 +12,7 @@ fi
if [ -z "${SYSTEM_USER}" ] ; then
SYSTEM_USER=${PROJECT_NAME}
fi
-if [ -z "${SYSTEM_USER}" ] ; then
+if [ -z "${SYSTEM_GROUP}" ] ; then
SYSTEM_GROUP=${PROJECT_NAME}
fi

@@ -33,12 +33,12 @@ $AFTER
[Service]
User=${SYSTEM_USER}
Group=${SYSTEM_GROUP}
+WorkingDirectory=/var/lib/${PROJECT_NAME}
+PermissionsStartOnly=true
+ExecStartPre=/bin/mkdir -p /var/lock/${PROJECT_NAME}
/var/log/${PROJECT_NAME} /var/lib/${PROJECT_NAME}
+ExecStartPre=/bin/chown ${SYSTEM_USER}:${SYSTEM_GROUP}
/var/lock/${PROJECT_NAME} /var/log/${PROJECT_NAME} /var/lib/${PROJECT_NAME}
ExecStart=${SCRIPTNAME} systemd-start
-ExecStop=${SCRIPTNAME} systemd-stop
-RuntimeDirectory=${PROJECT_NAME}
-PIDFile=/var/run/${PROJECT_NAME}/${NAME}.pid
Restart=on-failure
-Type=forking

[Install]
WantedBy=multi-user.target
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Mikaël Cluseau
2014-12-03 21:40:01 UTC
Permalink
Let's see what the release team says.
Thanks Thomas.

Aside from this, I took a look at how they did in Fedora.

Here is their unit file:

[Unit]
Description=OpenStack Identity Service (code-named Keystone)
After=syslog.target network.target

[Service]
Type=notify
Restart=always
User=keystone
ExecStart=/usr/bin/keystone-all --config-file
/usr/share/keystone/keystone-dist.conf --config-file
/etc/keystone/keystone.conf

[Install]
WantedBy=multi-user.target

So, we can use multiple config files, this allows the same granularity
as the /etc/default/* way. They also use the Type=notify clause. Their
keystone-dist.conf has the following DEFAULT section:

[DEFAULT]
log_file = /var/log/keystone/keystone.log
onready = keystone.common.systemd

To mimic the current genericity of our init-script, we could use
something like

ExecStart=... --config-file /usr/share/keystone/keystone-systemd.conf
--config-file /etc/openstack.conf --config-file /etc/keystone/keystone.conf

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.

Obviously, this is for post-jessie anyway.

Cheers,
Mikaël.
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gaudenz Steinlin
2014-12-04 09:50:02 UTC
Permalink
Post by Mikaël Cluseau
Let's see what the release team says.
Thanks Thomas.
Aside from this, I took a look at how they did in Fedora.
[Unit]
Description=OpenStack Identity Service (code-named Keystone)
After=syslog.target network.target
[Service]
Type=notify
Restart=always
User=keystone
ExecStart=/usr/bin/keystone-all --config-file
/usr/share/keystone/keystone-dist.conf --config-file
/etc/keystone/keystone.conf
[Install]
WantedBy=multi-user.target
So, we can use multiple config files, this allows the same granularity
as the /etc/default/* way. They also use the Type=notify clause. Their
[DEFAULT]
log_file = /var/log/keystone/keystone.log
onready = keystone.common.systemd
Cool, didn't know that keystone supports the systemd notification
protocol. We should definitely use that post jessie then. Do you know if
all the openstack daemons support this and configure it in the same way?
Post by Mikaël Cluseau
To mimic the current genericity of our init-script, we could use
something like
ExecStart=... --config-file /usr/share/keystone/keystone-systemd.conf
--config-file /etc/openstack.conf --config-file /etc/keystone/keystone.conf
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
Thomas Goirand
2014-12-04 12:30:02 UTC
Permalink
Post by Gaudenz Steinlin
Post by Mikaël Cluseau
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 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.

Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Thomas Goirand
2014-12-04 14:10:01 UTC
Permalink
FYI, I have pushed the patch from Mikael Cluseau to the
debian/experimental branch of openstack-pkg-tools (and therefore, all
the Juno packages are currently rebuilding automatically in my Jenkins).
Then later we can test that... though the build is for Wheezy, so I'm
not sure if that's so relevant. Is systemd working well in Wheezy?

Cheers,

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Mikaël Cluseau
2014-12-04 20:50:02 UTC
Permalink
Post by Thomas Goirand
Then later we can test that... though the build is for Wheezy, so I'm
not sure if that's so relevant. Is systemd working well in Wheezy?
I've been using systemd in wheezy for over a year now. It's working
well, especially if you use wheezy-backports to get systemd >200 instead
of 44 that ships with plain wheezy. So, I think a test with this version
is very close to the state we will have in jessie.
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gaudenz Steinlin
2014-12-05 16:20:02 UTC
Permalink
Post by Thomas Goirand
Post by Gaudenz Steinlin
Post by Mikaël Cluseau
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.)
Post by Thomas Goirand
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
Mikaël Cluseau
2014-12-06 02:00:03 UTC
Permalink
Hi,
Post by Gaudenz Steinlin
I'm not sure if I understand your concerns.
I think it is the difference between

* having one distribution-managed configuration file per daemon (like
in /usr/share/<project>/<daemon>.conf) containing the default log
file, meaning 58 configuration files (see the list at the end)
* versus having it computed in the init-script instead
(LOGFILE=/var/log/${PROJECT_NAME}/${NAME}.log)

I'm more inclined to have it explicitly put anyway because 58 files is
not that much, but as a developper too I can understand the problem that
it is a defactorised form. Maybe the best thing to do would be to allow
some templating in OpenStack configurations themselves.

Also note that using a small shell wrapper could be an idea too, as
systemd doesn't go against using shell scripts to launch service: it
simply enables us to avoid running (maybe 1ms?). The shell wrapper could
be generic and take 2 arguments : the project name and the daemon name.
This would allow us to avoid init-script when sysv init is not in use,
and using only one script means the system doesn't have to load many
files (it will be cached when the first openstack daemon is started).

List of configuration files required to manage the "one logfile per
daemon" logic, exclude /usr/share prefix:

ceilometer/ceilometer-agent-central.conf
ceilometer/ceilometer-agent-compute.conf
ceilometer/ceilometer-agent-notification.conf
ceilometer/ceilometer-alarm-evaluator.conf
ceilometer/ceilometer-alarm-notifier.conf
ceilometer/ceilometer-api.conf
ceilometer/ceilometer-collector.conf
cinder/cinder-api.conf
cinder/cinder-backup.conf
cinder/cinder-scheduler.conf
cinder/cinder-volume.conf
designate/designate-agent.conf
designate/designate-api.conf
designate/designate-central.conf
designate/designate-sink.conf
fuel-astute/astute.conf
fuel-nailgun/nailgun-api.conf
fuel-nailgun/nailgun-assassin.conf
fuel-nailgun/nailgun-reciever.conf
glance/glance-api.conf
glance/glance-registry.conf
heat/heat-api-cfn.conf
heat/heat-api-cloudwatch.conf
heat/heat-api.conf
heat/heat-engine.conf
ironic/ironic-api.conf
ironic/ironic-conductor.conf
keystone/keystone.conf*
murano-agent/murano-agent.conf
murano/murano-api.conf
murano/murano-engine.conf
neutron/neutron-dhcp-agent.conf
neutron/neutron-l3-agent.conf
neutron/neutron-lbaas-agent.conf
neutron/neutron-metadata-agent.conf
neutron/neutron-metering-agent.conf
neutron/neutron-plugin-linuxbridge-agent.conf
neutron/neutron-plugin-openvswitch-agent.conf
neutron/neutron-server.conf
neutron/neutron-vpn-agent.conf
nova/nova-api.conf
nova/nova-baremetal.conf
nova/nova-cells.conf
nova/nova-cert.conf
nova/nova-compute.conf
nova/nova-conductor.conf
nova/nova-consoleauth.conf
nova/nova-console.conf
nova/nova-consoleproxy.nova-novncproxy.conf
nova/nova-consoleproxy.nova-serialproxy.conf
nova/nova-consoleproxy.nova-spicehtml5proxy.conf
nova/nova-consoleproxy.nova-xenvncproxy.conf
nova/nova-network.conf
nova/nova-scheduler.conf
sahara/sahara.conf
tuskar/tuskar-api.conf
tuskar/tuskar-manager.conf
zuul/zuul-server.conf
Mikaël Cluseau
2014-12-14 21:10:02 UTC
Permalink
Let's work on this after the freeze, indeed!
Great, I'll help then :-)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gaudenz Steinlin
2014-12-04 19:10:02 UTC
Permalink
Hi
Post by Mikaël Cluseau
Hi Gaudenz,
I will focus on the so called "minimal set" for now. If you don't mind,
we will open another bug to improve systemd's integration after this one
is fixed.
Post by Gaudenz Steinlin
Did you test the patches with the "minimal set of changes". I think we
need strong arguments that they are working if we want to propose them
to the Release Team for jessie. I currently don't have a good setup to
test such patches.
I did with keystone but developper tests are never to be trusted ;-) Its
apt-get build-dep openstack-pkg-tools
git clone -b debian/unstable
https://github.com/MikaelCluseau/debian-openstack-pkg-tools.git
cd debian-openstack-pkg-tools
debuild -us -uc -b
dpkg -i ../openstack-pkg-tools_19_all.deb
Then you can build any other OpenStack package from source. For
apt-get source keystone
cd keystone-*/
debuild -us -uc -b
dpkg -i ../keystone_*.deb
OK I tested keystone on unstable now and this works as it should. It's
definitely an improvement over the current unit file which does not work
at all. I did not go down the route to do a full openstack installation
but I also installed nova and the service units there work too. I did
not go all the way to have a working setup, but the problems I have seem
to be unrelated to the systemd unit files.

One thing I noticed is that all services are disabled by default even
though they were configured through debconf and should be ready to use.
Is this intentional as an off by default behavior or is this a bug. How
is this handled with sysvinit?

Gaudenz
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Mikaël Cluseau
2014-12-04 20:50:02 UTC
Permalink
Post by Gaudenz Steinlin
One thing I noticed is that all services are disabled by default even
though they were configured through debconf and should be ready to use.
Is this intentional as an off by default behavior or is this a bug. How
is this handled with sysvinit?
For what I understood, no, they shouldn't be disabled. I will definitely
have to test on a clean install. Hopefully, the week-end is close.
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Thomas Goirand
2014-12-05 15:40:01 UTC
Permalink
Post by Gaudenz Steinlin
OK I tested keystone on unstable now and this works as it should. It's
definitely an improvement over the current unit file which does not work
at all.
Cool, thanks for your time!
Post by Gaudenz Steinlin
One thing I noticed is that all services are disabled by default even
though they were configured through debconf and should be ready to use.
Is this intentional as an off by default behavior or is this a bug. How
is this handled with sysvinit?
Gaudenz
This is a bug. With sysinit, it starts by default. What did you have to
do under systemd to make it start?

Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gaudenz Steinlin
2014-12-05 16:10:03 UTC
Permalink
Post by Thomas Goirand
Post by Gaudenz Steinlin
OK I tested keystone on unstable now and this works as it should. It's
definitely an improvement over the current unit file which does not work
at all.
Cool, thanks for your time!
Post by Gaudenz Steinlin
One thing I noticed is that all services are disabled by default even
though they were configured through debconf and should be ready to use.
Is this intentional as an off by default behavior or is this a bug. How
is this handled with sysvinit?
Gaudenz
This is a bug. With sysinit, it starts by default. What did you have to
do under systemd to make it start?
To make the services start on boot you have to manually enable them with
systemctl enable *sercicename*. You can stil start them manually with
systemctl start *servicename* and they work fine, even if they are
disabled. I don't know why they are not enabled by default, but suspect
it's because that's because you don't run dh_systemd_enable during the
package build or something similar.

Gaudenz
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Thomas Goirand
2014-12-14 07:50:02 UTC
Permalink
Post by Gaudenz Steinlin
OK I tested keystone on unstable now and this works as it should. It's
definitely an improvement over the current unit file which does not work
at all. I did not go down the route to do a full openstack installation
but I also installed nova and the service units there work too. I did
not go all the way to have a working setup, but the problems I have seem
to be unrelated to the systemd unit files.
One thing I noticed is that all services are disabled by default even
though they were configured through debconf and should be ready to use.
Is this intentional as an off by default behavior or is this a bug. How
is this handled with sysvinit?
Gaudenz
Hi,

I have found out what happened. Indeed, this issue is that we're not
calling dh_systemd_enable. Or rather, openstack-pkg-tools is generating
the *.service files in the override_dh_installinit target, which happens
after the dh_systemd_enable in the standard dh sequence. So I wrote this:

# Generate the systemd unit file
# Note: because dh_systemd_enable is called by the
# dh sequencer *before* dh_installinit, we have
# to process it manually.
for i in `ls debian/*.init.in` ; do \
pkgos-gen-systemd-unit $$i ; \
MYSERVICE=`echo $$i | sed 's/debian\///'` ; \
MYSERVICE=`echo $$MYSERVICE | sed 's/.init.in/.service/'` ; \
dh_systemd_enable $$MYSERVICE ; \
done

in the override_dh_installinit. This works, then, except for keystone
where there's no #DEBHELPER# in the postinst (because I wanted to keep
the control of when invoke-rc.d is called, ie after the daemon starts,
the admin tenant is created, and the keystone endpoint is registered).
This means that for Keystone, we need to manually add what
dh_systemd_enable does. Then I've been asking myself what would happen
in Wheezy, and it's looking like the only thing that will happen is that
it's going to add a dependency on init-system-helpers, which IMO is
quite fine, because it's already available from the official
wheezy-backports.

Since the release team already expressed their opinion that fixing
systemd issues the way I proposed was fine, I hope to make it happen
before Jessie is released, with what's currently in the Git for
openstack-pkg-tools (version 20). I would welcome some reviews.

Thoughts anyone?

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gaudenz Steinlin
2014-12-15 09:00:03 UTC
Permalink
Post by Thomas Goirand
I have found out what happened. Indeed, this issue is that we're not
calling dh_systemd_enable. Or rather, openstack-pkg-tools is generating
the *.service files in the override_dh_installinit target, which happens
# Generate the systemd unit file
# Note: because dh_systemd_enable is called by the
# dh sequencer *before* dh_installinit, we have
# to process it manually.
for i in `ls debian/*.init.in` ; do \
pkgos-gen-systemd-unit $$i ; \
MYSERVICE=`echo $$i | sed 's/debian\///'` ; \
MYSERVICE=`echo $$MYSERVICE | sed 's/.init.in/.service/'` ; \
dh_systemd_enable $$MYSERVICE ; \
done
in the override_dh_installinit.
I don't see a reason why this should not work, but I wonder why you
don't just add an override_dh_systemd_enable target wich first uses
pkgos to generate the service files and then just calls
dh_systemd_enable. This seems like the more obvious solution to me.

Having this in a separate target would probably also make it possible to
build packages without systemd by just not build depending on
dh-systemd.
Post by Thomas Goirand
This works, then, except for keystone
where there's no #DEBHELPER# in the postinst (because I wanted to keep
the control of when invoke-rc.d is called, ie after the daemon starts,
the admin tenant is created, and the keystone endpoint is registered).
This means that for Keystone, we need to manually add what
dh_systemd_enable does. Then I've been asking myself what would happen
in Wheezy, and it's looking like the only thing that will happen is that
it's going to add a dependency on init-system-helpers, which IMO is
quite fine, because it's already available from the official
wheezy-backports.
I don't understand the problem you are trying to solve here. Why are you
not just adding the #DEBHELPER# at the end of the postinst where you
want it to be? I don't see how the debhelper inserted snippets don't
give you control over where they are called. But maybe I'm missing
something.

Gaudenz
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Thomas Goirand
2014-12-15 09:30:03 UTC
Permalink
Post by Gaudenz Steinlin
I don't see a reason why this should not work, but I wonder why you
don't just add an override_dh_systemd_enable target wich first uses
pkgos to generate the service files and then just calls
dh_systemd_enable. This seems like the more obvious solution to me.
True, I could just have used the override there instead of in the
installinit, however, I'm happy to have dh_systemd_enable to run
"normally" when there's a debian/<something>.service the normal way.
Post by Gaudenz Steinlin
Having this in a separate target would probably also make it possible to
build packages without systemd by just not build depending on
dh-systemd.
I don't see why you would like to do this. The dh-systemd utility is
available in Wheezy backports, and even if the OpenStack packages do
support systemd now, we don't have to use that as init system...
Post by Gaudenz Steinlin
Post by Thomas Goirand
This works, then, except for keystone
where there's no #DEBHELPER# in the postinst (because I wanted to keep
the control of when invoke-rc.d is called, ie after the daemon starts,
the admin tenant is created, and the keystone endpoint is registered).
This means that for Keystone, we need to manually add what
dh_systemd_enable does. Then I've been asking myself what would happen
in Wheezy, and it's looking like the only thing that will happen is that
it's going to add a dependency on init-system-helpers, which IMO is
quite fine, because it's already available from the official
wheezy-backports.
I don't understand the problem you are trying to solve here. Why are you
not just adding the #DEBHELPER# at the end of the postinst where you
want it to be? I don't see how the debhelper inserted snippets don't
give you control over where they are called. But maybe I'm missing
something.
I just wanted to do things by hand myself for keystone, but all the
other packages have it. Nothing to worry about IMO (the only thing I'm
worried about is the unblock requests ...).

Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loading...