Replace the Anaconda product configuration files with profiles
Summary
In Anaconda, we would like to introduce profile configuration files and remove the support for product configuration files.
Owner
- Name: Vendula Poncova
- Email: <vponcova@redhat.com>
Current status
- Targeted release: Fedora Linux 35
- Last updated: 2021-06-01
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Anaconda allows to change its configuration based on a detected product using the product configuration files. The configuration is chosen based on:
- the
inst.product
andinst.variant
boot options, - or the
Product
andVariant
options of the.buildstamp
file, - or the
NAME
option in theos-release
files.
This solution has several flaws:
- The detection based on the
os-release
files will no longer work because of a Fedora 35 change. - The
.buildstamp
file is generated bylorax
when it creates is a boot.iso. Therefore, we have to rely on other solutions during the live, dir and image installations. - The
inst.product
andinst.variant
boot options are misleading. Anaconda will run with a different configuration. That doesn't mean it will install a different product. - The configuration has to use a fake product name for its identification if it is not tied to a real product.
We would like to redesign the product configuration files to solve these issues. The idea is to replace them with more general profile configuration files:
- The profile will be identified by a unique id.
- The profile can specify additional options for the automated profile detection.
- The profile will be chosen based on the
inst.profile
boot option, or based on theID
andVARIANT_ID
options of theos-release
files.
For example, Fedora Server uses a configuration from /etc/anaconda/product.d/fedora-server.conf
.
The configuration can be enforced with the inst.product=Fedora inst.variant=Server
boot options.
The file contains the following sections:
[Product] product_name = Fedora variant_name = Server [Base Product] product_name = Fedora
After this change, Fedora Server will use a configuration from /etc/anaconda/profile.d/fedora-server.conf
.
The configuration can be enforced with the inst.profile=fedora-server
boot option.
The file will contain the following sections:
[Profile] profile_id = fedora-server base_profile = fedora [Profile Detection] product_id = fedora variant_id = server
The full draft of the profile configuration files is provided at: https://github.com/rhinstaller/anaconda/pull/3388
Feedback
Benefit to Fedora
- The installer will use ids instead of names. That will solve the problem with the Fedora 35 change and prevent similar issues in the future.
- All types of installation will use
os-release
values to identify the product. We can remove workarounds for boot.iso and Live ISO. - The
inst.profile
option makes more sense, because it allows to choose a different installation profile. - A configuration, that is not tied to a product, doesn't have to provide a fake product name or id.
Scope
- Proposal owners: Will submit a pull request for the
anaconda
package.
- Other developers: Should be no impact. Anaconda provides configuration files for all Fedora products and the products rely on the automated detection of configuration files.
- Release engineering: #Releng issue number
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives:
Upgrade/compatibility impact
How To Test
Test the automated profile detection:
- Download and boot the Fedora Server ISO.
- The installation is started with the Fedora Server configuration.
Test the inst.profile
boot option:
- Download and boot the Fedora Everything ISO.
- Add the
inst.profile=fedora-server
boot option. - The installation is started with the Fedora Server configuration.
User Experience
- Users will have to use the
inst.profile
boot option instead ofinst.product
andinst.variant
. - Maintainers of custom product configuration files will have to change their files.
- Otherwise, this change shouldn't impact the user experience.
Dependencies
None.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
Documentation
N/A (not a System Wide Change)