> 3. What is the nature and description of the request? Having ansible_become under [all:vars] causes issues during installation/upgrade due to local tasks being executed using sudo, e.g temporary directories created using sudo will make the installer to fail when trying to store files with an unprivileged user. > 4. Why does the customer need this? (List the business requirements here) As a cluster operator, I'd like to avoid situations where the installer fails due to misplaced options. > 5. How would the customer like to achieve this? (List the functional requirements here) Currently the installer already does some sanity checks, adding this one to those check would be enough. > 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Example scenario: During an upgrade, by mistake, the ansible_become has been misplaced under [all:vars]. The installer should fail with a sensible message. > 10. List any affected packages or components. Installer
AFAICT, we can tell programmatically whether an Ansible variable is defined or not, but not where it was defined. If instead of asserting that ansible_become is not defined in [all:vars], would it be satisfying to assert that ansible_become is not defined for localhost?
This bug has been identified as a dated (created more than 3 months ago) bug. This bug has been triaged (has a trello card linked to it), or reviewed by Engineering/PM and has been put into the product backlog, however this bug has not been slated for a currently planned release (3.9, 3.10 or 3.11), which cover our releases for the rest of the calendar year. As a result of this bugs age, state on the current roadmap and PM Score (being below 70), this bug is being Closed - Differed, as it is currently not part of the products immediate priorities. Please see: https://docs.google.com/document/d/1zdqF4rB3ea8GmVIZ7qWCVYUaQ7-EexUrQEF0MTwdDkw/edit for more details.