[Openstack-devel] Bug#677400: Bug#677400: Bug#677400: Bug#677400: This is not a bug, it is a feature!

[Thomas Goirand]

On 06/26/2012 04:46 AM, Ola Lundqvist wrote:
> Hi Thomas
> 
> I still do not fully agree with you. But as I understand you have solved
> the issue with another git commit so I will not argue to death. :-)

Well, if you don't agree with me, then you do not agree with the Debian
policy, and this list / bug report isn't the place for such discussion
(I believe that debian-devel@ or debian-mentors@ would be a better place
for such a discussion).

> On Tue, Jun 19, 2012 at 01:48:45AM +0800, Thomas Goirand wrote:
> ...
>> The issue isn't only with the default. That's not the way to fix. The
>> file shouldn't be marked as conffile, and that's it.
> 
> All admin changes in files in /etc/somewhere must be prerved. This is
> what the policy says.

Yes, that's truth.

> So either we store this information in some other
> place and read that from the file in /etc/nova/nova.conf. That means
> that nova must have that kind of support so that other files can be
> included from nova.conf.

I'm not sure what you intend to do here.

> Another way is to keep it being a conffile, but then read the data
> in nova-common.config.

Reading values of nova.conf from our nova-common.config is mandatory,
and has very little to do with having nova.conf set as conffile. What we
are discussing here isn't that (which we agree upon), but how can we
*write* in nova.conf.

If we set nova.conf as conffiles, then our postinst changes it even with
the default values (eg: when using debconf frontend in a non-interactive
mode), then this will trigger automatically the kind of bug report that
we just had. So if our postinst script changes anything in
/etc/nova/nova.conf, and that this file is marked as conffile, then we
violating the policy. End of the story. Nothing more to discuss, I'm
afraid! :)

But the case of default values (eg: non-interactive mode of debconf)
isn't the only case where the policy is violated. If let's say, using
debconf, you choose MySQL, and input a login / pass, then when
upgrading, dpkg prompts for nova.conf changes, we are also in a policy
violation case.

>> We should allow everyone to upgrade from one version to another, without
>> prompting anything to the user if the user didn't edit anything in the
>> config file. That's basically what the policy tells.
> 
> If someone actually enter something different from the default in
> debconf question then it should really ask if it tries to install a new
> version.

It should *not*. If it does, then this is a policy violation. Learning
this has also been painful for me, and I had to fix some other packages
because of this problem. I don't think I could explain better (I'm not
very good at explaining, IMO). So if you don't trust me, please open a
thread in debian-devel@ or debian-mentors at .

> If not the change will be overwritten. That is solved by the
> solution from Ghe.

The solution from Ghe doesn't solve the problem. Or rather, it only
partly solves the problem if using the defaults in debconf, but we need
this to be fixed in all cases, even when using something else than the
default values.

>> I'm really not sure how to fix this issue. I don't think parsing
>> /etc/nova/nova.conf to find out what values are in would be hard, but
>> I'm really not sure how to preseed stuff in dbconfig-common. Ghe, could
>> you explain to me how to do dbconfig-common preseed, and what's the
>> format of the files in /etc/dbconfig-common/? It's currently a bit
>> cryptic to me.
> 
> It is a bit cryptic to me too. :-)

See what Ghe did for debstack, this shows how to preseed dbconfig-common
(but it's unfortunately lacking explanations, and I'd like to understand
better). Also please note #476946 is an RC bug, but nobody came with a
solution...

>> So, anywa, what we should do (and what I did) is: we don't ship a
>> /etc/nova/nova.conf in the nova-common package, and create it when the
>> postinst script is ran. For this, I've put it in
>> /usr/share/doc/nova-common/nova.conf.dist. This in our Git repository
>> right now.
> 
> Is this really a good solution?

Well, I'm not sure it's a good solution, but that's the only one we have
available. An ideal solution would be tools in Debian that would help us
to do it better. There has been some people working on it, with a
description of each configuration files, but I don't know how much
progress has been made. I don't think something like ucf would be of a
good help here.

> What happens when we upgrade the
> configuration file in the package? Normally a question is asked by
> dpkg whether it should be replaced or not (the one that triggered this
> bug) and that is a good thing, because then the admin can decide if the
> new one is better than the old, even considering the changes done to it.

Yes, that's problematic. Unfortunately, we have no choice but to
maintain the file in our postinst script. Instead of having dpkg handle
the file as conffiles, we are now taking over the responsibility of it.
One way to handle it if it happens that we have deprecated config values
in the file, is writing about it in README.news or README.Debian, or
using debconf to prompt for the maintenance of the file. But I don't
think we should worry too much for the moment, this is the kind of
problems we will have when working on the Wheezy+1 release of openstack.

Thomas