[PKG-Openstack-devel] debian openstack and puppet

[Gaudenz Steinlin]

Hi

Thomas Goirand <thomas at goirand.fr> writes:

> On Tue Jun 24 2014 04:56:31 AM HKT, Benedikt Trefzer <benedikt.trefzer at cirrax.com> wrote:
>
>> Hi list
>> 
>> I'm installing an openstack cluster, that is spanned over several nodes.
>> All config files (and also package installation) is handled with puppet.
>> The Debian packages do quite a lot of configuration work using
>> preseeding etc. But actually these configuration do not work together
>> well with the puppet manifests.
>
> This is not at all the experience that reported the
> company that sponsors my packaging work.

Just out of curiosity, do they use puppet or another configuration
management system and if they use puppet do they use the official
openstack modules or something home grown?

>
>> Problems occuring when package updates arriving. Either certain
>> configuration parameters are asked interactivly
>
> This can only be your fault. Either do:
> dpkg-reconfigure debconf
>
> and select the non-interactive mode, so that debconf
> is disabled forever (note: this can also be
> preseeded or edited somewhere in /etc) or use
> DEBIAN_FRONTEND=non-interactive each time you do the
> upgrades.

Reconfiguring debconf is not really an appropriate solution if you only
want to "opt out" of the debconf machinery for the openstack packages. It
sets the priority to low for ALL packages.

Using a lower priority does not opt out of debconf. It just disables the
prompting and uses the default values and does not mark the questions as
"seen" (thus the prompting on interactive upgrades).

Using the noninteractive frontend in an interactive session has many
disadvantages like the fact that you don't see any notes and errors or
that you don't get prompted for all the usefull questions like the one
if like to restart daemons on certain library upgrades (where the answer
might change from case to case depending on the circumstances (severity
of the bug fixed, deamons affected, ...).

>> or the default values
>> from installation are taken. Both results in overwriting the
>> configuration made by puppet.
>
> I very much doubt that. All config scripts are
> reading the configuration files and do the db_set
> calls accordingly, just like the Debian policy
> dictates. If you find such behavior in one of the
> packages, make sure you can reproduce it, and then
> please report it as a bug!
>

This sound like the correct approach.

Are you also respecting user modifications for debconf questions that
are not marked as "seen" but the corresponding value in the
configuration file has been changed by the user? Or is the user just
presented with the default value if he first sees the question and his
modifications are overwriten when he just accepts this value (knowing
that he want's to manage the configuration with his config management
system anyway)? I don't want to imply this is a bug. But as probably all
the machinery to read value from configuration files is already in
place, it would be nice to substitute the actual value into the debconf
prompt if it was changed before the question is first asked.

>> Even worse db synchronisation (something made by the postinst script) is
>> not executed correctly, since the database connection string is at its
>> default value at the time of execution....
>
> Same here. Directives are read from the config
> files. So this cannot happen. Well, unless you are
> producing obsolete directives which have moved to a
> new section / have been renamed in Icehouse, which
> is possible, but then packages can't be blamed:
> update your puppet scripts...

I very much doubt that you can just blame the puppet scripts if the
directives still work. IMO you should at least allow for a transition
period during which old deprecated but still working directives are
taken into account by package scripts. The Debian policy is quite clear
about the fact that user configuration has to be preserved in any
circumstances even if they use deprecated configuration syntax.

>
> All this is by the way described in both the Debian
> policy manual and OpenStack official (Debian)
> install guide. There's a chapter I wrote there
> especially conserning non-interactive mode.

This section contains several errors. The default priority in Debian is
not critical. It's the same you use during the installation with
debian-installer and the default in the installer is "high". This
section also contains the same recomendation to reconfigure the debconf
package to select non-interactive mode without telling the user that
this is in no way related to the openstack packages but for the whole
system. It also states that this opts out of using debconf. You can't
opt out of that, you can only suppress the prompts with the
non-interactive interface.

IMO the better way to do this is to use the DEBIAN_FRONTEND
environment variable (at least as a recommendation in an OpenStack
specific manual). Another possibility is to set
DEBCONF_NONINTERACTIVE_SEEN while installing packages with a
configuration management. This marks questions answered with the non
interactive frontend as seen and avoids this question on upgrades. Thus
only new questions are asked on (interactive) upgrades.

If you can point me to the source code repository of the manual I can
try to write a patch for the documentation.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~