Env vars in convert2rhel were originally meant to only enable unsupported behavior and they were not supposed to be used by customers under normal circumstances. As an example the env var CONVERT2RHEL_UNSUPPORTED_INCOMPLETE_ROLLBACK was to be used to continue even when it was certain that convert2rhel can't rollback all steps in case the conversion stops early.

Over time the use of env vars grew and started to be used for things that we expect the customers to use even under typical scenarios. However, using env vars is not a typical way of altering behavior of linux utilities. Convert2RHEL has two other avenues for altering its behavior by the user:

• command line options
• /etc/convert2rhel.ini config file

Using env vars for overriding pre-conversion checks causes problems when converting through Insights. Convert2RHEL cannot access the env vars they set on the host that they try to convert (HMS-3843) due to the product security measures taken when designing communication between Insights and hosts.

In Insights we are trying to find workarounds to allow customers to pass environment variables to the environment in which convert2rhel is executed when using Insights. But the workarounds won't be easy to document for customers because now the pre-conversion analysis report messages tell the customers to set env vars.

Acceptance criteria:

• All CONVERT2RHEL_* env vars are settable in the /etc/convert2rhel.ini config file
  • All possible vars are pre-filled in the convert2rhel file but commented out and with a bried description
• The pre-conversions analysis messages advise users to set the variables in the ini file
• 1. step: The old way using env vars still works for backwards compatibility reasons but when a customer uses them they are warned that it's deprecated and will be removed in a future version
• 2. step: Remove the possibility to use env vars
• Have all the variables settable also through CLI, similarly to how dnf has it with --setopt=key=value