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

[Ola Lundqvist]

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. :-)

See further below.

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. 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.

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

> 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. If not the change will be overwritten. That is solved by the
solution from Ghe.

> If let's say, the user decides to use MySQL when configuring the package
> using debconf, then later on upgrade his nova-common package, then we
> really don't want dpkg to prompt the user about new stuff in the config
> file. Especially considering that the user may decide to overwrite the
> file, which may potentially break his configuration.

For this I fully agree!

> Also, the policy tells that we *must* read the configuration from the
> configuration file in the debian/nova-common.config. That is: if the
> user edits /etc/nova/nova.conf and decides, for some reason, let's say
> to switch from sqlite to mysql, we should be able to detect that, and
> have dbconfig-common catch up with it. Currently, it's quite hard to do,
> because dbconfig-common cannot be preseed easily. So again, currently,
> that has to be done, because our package isn't policy compliant.

Fully agree to this part.

> 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. :-)

> 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? 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.

> Please note that the release team agrees with me, and that I had such
> issues in the past, so I believe I'm right.

:-)

// Ola

> Thomas
> 
> 
> 
> _______________________________________________
> Openstack-devel mailing list
> Openstack-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/openstack-devel
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal at debian.org                     Annebergsslingan 37      \
|  ola at inguza.com                      654 65 KARLSTAD          |
|  http://inguza.com/                  +46 (0)70-332 1551       |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------