Bug 2230422

Summary:	The leapp data files should not be marked configuration.
Product:	Red Hat Enterprise Linux 8	Reporter:	jcastran
Component:	leapp-repository	Assignee:	Leapp Notifications Bot <leapp-notifications-bot>
Status:	CLOSED NOTABUG	QA Contact:	upgrades-and-conversions
Severity:	medium	Docs Contact:	Miriam Portman <mportman>
Priority:	medium
Version:	8.8	CC:	pstodulk, upgrades-and-conversions
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-14 08:42:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description jcastran 2023-08-09 12:18:02 UTC

These files should not be marked configuration. Customers should not be configuring them, they should be exactly what the package thinks they are.

.........  c /etc/leapp/files/device_driver_deprecation_data.json
.........  c /etc/leapp/files/pes-events.json
.........  c /etc/leapp/files/repomap.json

When files such as these are corrupted, the general approach is to reinstall a package. Because these are configuration files, they are silently not replaced.

They have to be manually removed, then the package can be reinstalled.

Request:
We should not mark these as configuration files. No one should be touching them and a reinstall should replace them.

Comment 2 Petr Stodulka 2023-08-14 08:42:25 UTC

Hi John. It's quite opposite, we really want them to be marked as configuration files. Some customers must update them manually if they have own very specific setups, e.g.
 * when they change official repository IDs on the satellite site and require their own repoids instead of official ones
 * if they want to fix something without waiting for an official update of data
 * if they want to automatize use of some repositories during the upgrade that are currently not officially covered
...

Files are automatically updated when newer package is installed, if we have changed the data files in the new package (typical scenario..). If original files have been modified before new package is installed, they are stored in such a case with .rpmsave suffix. So customer can easily check new changes or they can apply just their previous changes back if they want. If we make them data files, it will mean that any customisation is dropped without a backup during update of the package.

We had some discussions about that in the past, where we wanted to make them datafiles strictly and we agreed to make them configuration files. (no, we do no want to make them data files under the /etc/leapp/files/ directory - if we had done such a step, we would have also changed the path where they are stored.)

Current behaviour is the expected one and we do not want to change it. From our POV it's standard and in case customer change them by their mistake, they can still remove them and reinstall the package to recover them.