As long as the TELEMETRY setting is configured in settings.py it must be managed by the installer. The user could manually edit settings.py and restart pulp services (if they are careful to do so at a time when nothing is happening) but the next installer run would overwrite their changes.
The installer has an interactive mode (although I don’t think I have heard of anybody actually using it). I don’t think that pausing the installer to wait for user input in the default (non-interactive) mode is something that we’d want to do. Not only would this break user expectations and the difference between interactive and default installer modes, but there is also tons of tooling that wraps the installer and expects non-interactive execution, whether that’s in CI, foreman-maintain, forklift, foreman operations collection, end user scripts, and so on…
The installer has a mechanism for remembering the user’s choice, and that mechanism is the scenario answers / hiera data. Basically, to determine what value to use for a given parameter, the installer will try lookups from various sources according to priority rules defined here: foreman-installer/foreman-hiera.yaml at 8362b7259643bc2191595043b2f25a46a91ac73e · theforeman/foreman-installer · GitHub (if those data sources are exhausted and a value for the parameter is still not found, then the default value from the relevant puppet module will be used)
The current behavior is that the puppet-foreman_proxy_content module has a $pulpcore_telemetry
parameter with default value false
. The issues that I would have with changing this default to true
would be that telemetry data would be sent without the user’s consent until the user explicitly opts out by running foreman-installer --foreman-proxy-content-pulpcore-telemetry false
, and this issue is compounded by the fact that running the installer can take 20 minutes of downtime, or sometimes even longer, for all katello services, per katello server and per content-proxy.
So, it is easy to imagine the frustration of an user who is running 30 content-proxies, and does not consent to provide (or their organizational policy prohibits providing) telemetry data, and to rectify the situation they must take significant downtime of all instances to disable it.
I also understand the point of view that, for the same reason, users would be disincentivized to opt-in to providing telemetry data.
So as a compromise to try to best satisfy all of the competing constraints that have been laid out in the discussion so far, what if we take the following approach:
- Continue to have telemetry disabled by default
- Pulp provides an API to check whether telemetry is enabled
- Katello uses this API to check whether telemetry is enabled, and if it is not, it provides a nice notification explaining how helpful this data is and asking the admin to please consider enabling it
- The admin can decline, and check a box that says “do not prompt me about this again” (or decline for now and be reminded again later)
- The admin can opt-in to telemetry, in which case they get a REX job that creates a drop-in file with the hiera data
foreman_proxy_content::pulpcore_telemetry: true
- The configuration will take effect automatically whenever the installer next runs (whenever they next update or upgrade, or use the installer to modify any other infrastructure configuration)
- The REX job could in theory also immediately edit settings.py to match the value that the installer will eventually provide, so that the configuration takes effect at the next restart of pulp services, while also surviving future installer runs
Thoughts / feedback on this design, @iballou @bmbouter @ekohl and any other interested parties?