Bug #3520
Prevent RPM upgrades to replace configuration files
| Status: | Closed | Start date: | 01/22/2015 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Javi Fontan | % Done: | 0% | |
| Category: | Packaging | |||
| Target version: | Release 4.12 | |||
| Resolution: | wontfix | Pull request: | ||
| Affected Versions: | OpenNebula 4.10 |
Description
During latest upgrade to 4.10.2, RPM upgrade process have replaced some configuration files in /etc/oned, removing all the changes we have made in them. Therefor, the opennebula service was unable to restart (default sqlite db file was not here anymore since we were using mysql db). Hopefully the RPM upgrade process back those files up to .rpmsave files.
To prevent such situation, the best practice in RPM packages, as shown in the Fedora Packaging Guidelines (http://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_files) also used for RedHat/CentOS packaging, is to not replace configuration files:
"As a rule of thumb, use %config(noreplace) instead of plain %config unless your best, educated guess is that doing so will break things."
This is possible by specifying in the RPM spec file, in the %files section:
%config(noreplace) /path/to/config/file
With the noreplace parameter, if the config file has been modified, the upgrade process won't replace this file and a new file .rpmnew is made. If the config file has not been modified, the file is silently overwritten by the new one. Nothing is broken.
Best regards.
History
#1
Updated by Ruben S. Montero over 6 years ago
- Status changed from Pending to New
- Target version set to Release 4.12
#2
Updated by Jaime Melis over 6 years ago
- Assignee set to Jaime Melis
#3
Updated by Javi Fontan over 6 years ago
- Assignee changed from Jaime Melis to Javi Fontan
#4
Updated by Jaime Melis over 6 years ago
- Status changed from New to Closed
- Resolution set to wontfix
We have discussed this internally, before and after this ticket, and we still think the current %config (without the 'noreplace' option) directive is where we want to be. In the upgrade to 4.10.2 the problem was that the year changed in the configuration file headers, and that's where all of the confusion came from. In future releases this will not be a problem, we will probably remove the current year from the copyright notice so we don't have to deal with this issue again.
In any case:
- OpenNebula configuration files are very complex
- they are not backwards compatible
- an automated configuration migrator would be very difficult to prepare, if not impossible
- so far, relying on the user to do the migration process [1] and having him to manually apply any changes to the configuration files to the new ones manually has worked for the users.
Admittedly porting the configuration changes to the new releases is a bit of a bother... Users have to read the compatibility docs, the upgrade guides, etc. But since OpenNebula is so customizable it's very difficult to solve this problem.
So, given that we cannot guarantee backwards compatibility for the time being, I'm closing this issue as wontfix, but keep in mind that we are well aware of this problem and we want to solve it. We just don't know how, yet :) If you have any further ideas on how to simplify the upgrade process, please re-open the ticket!
Thanks for the feedback Edouard!
[1] http://docs.opennebula.org/4.10/release_notes/release_notes/upgrade_410.html
#5
Updated by Edouard Bourguignon over 6 years ago
First of all, thanks for your time and response. However, with all my respect, I think you may have misunderstood my point, espescially because you spoke about migration process which is far from the subject. I'm not very confortable with english I'm very sorry.
Two situations:
1) Minor upgrade like 4.10.x to 4.10.x+1 where OpenNebula doesn't make any major changes in its configuration files, it's really (really) a bad idea to ignore user changes in the configuration files, and moreover, to generate useless operations (ie mv config.rpmsave to config without modifications). Do you agree? To prevent that bad situation, no big deal: %config(noreplace).
2) Major upgrade like 4.10 to 4.12 or any other major upgrade, of course, you have (if needed) to put %config(replace) to be sure the base configuration file from this major update will be in place. Then users will be aware that possible breaking changes are present in the configuration files, that documentation must be read etc. Users will have their *.rpmsave to help them to adapt. Do you agree?
I never pointed the fact that the RPM should make any kind of automatic migration for major upgrade, this indeed, would be a huge work I completly agree. And this huge work is not really needed since the documentation is good on this point. We agree here.
I was just pointing the fact that the actual spec file could mess again with user modifications in the configuration files.
%config(noreplace) in minor upgrade, %config(replace) in major. That's all, trivial, and best practice use of the %config(replace/noreplace) during minor/major update. Only you, packagers and developpers of the OpenNebula project know when it's good to replace or not the configuration, that's why you have the choice with %config. Maybe it's what you try to tell me in your last comment? I'm just pointing the fact that during the last "minor" upgrades, the rpms break our production configuration. I can't believe this is really the situation you want to be?
about those facts:
- configuration files are complex => not relevant here, what is relevant is when to force replace some files.
- not backwards compatible => in that case %config(replace)
- automatc migrator is difficult to prepare => true but not the subject
- I only speak of minor upgrade, where %config(noreplace) would be a better way
This is really the practice in all kind of quality packaging (being a packager and a redhat sysadmin myself) if possible I encourage you to rethink your position since it appears I was not clear and the actual behavior is not sane (only concerning minor upgrades). I can't recall, really, the last time I had this behavior from a RPM, do you?
If you're still sure the actual behavior is the good one no big deal too, we will repackage or just document the fact that minor opennebula updates could break production configurations, since it's a bit an unorthodox behavior (at least with RPM distros) we want our sysadmins to be aware of that. But we will survive ;) And may be I'm overworriing since you said you won't have to deal with this kind of issue again (copyright notice).
Sorry to bother you with such a little packaging details, I don't want to waste your time. We were and still are very pleased by OpenNebula (and its rpmsave touch).
Best Regards,
Edouard