-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: improve support for ostree systems #127
Conversation
also added vars/CentOS-9.yml which is copied from vars/RedHat-9.yml |
vars/CentOS_9.yml
Outdated
|
||
# This default lists the main configuration file defaults | ||
__ssh_defaults: | ||
Include: /etc/ssh/ssh_config.d/*.conf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, do not add copies of clones as long as they are same as the originals. Use symlinks as with the other vars files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
c4a4ac2
to
768d1f2
Compare
[citest] |
The dependency on `ansible.utils.update_fact` is causing issue with some users who now must install that collection in order to run the role, even if they do not care about ostree. The fix is to stop trying to set `ansible_facts.pkg_mgr`, and instead force the use of the ostree package manager with the `package:` module `use:` option. The strategy is - on ostree systems, set the flag `__$ROLENAME_is_ostree` if the system is an ostree system. The flag will either be undefined or `false` on non-ostree systems. Then, change every invocation of the `package:` module like this: ```yaml - name: Ensure required packages are present package: name: "{{ __$ROLENAME_packages }}" state: present use: "{{ (__$ROLENAME_is_ostree | d(false)) | ternary('ansible.posix.rhel_rpm_ostree', omit) }}" ``` This should ensure that the `use:` parameter is not used if the system is non-ostree. The goal is to make the ostree support as unobtrusive as possible for non-ostree systems. The user can also set `__$ROLENAME_is_ostree: true` in the inventory or play if the user knows that ostree is being used and wants to skip the check. Or, the user is concerned about the performance hit for ostree detection on non-ostree systems, and sets `__$ROLENAME_is_ostree: false` to skip the check. The flag `__$ROLENAME_is_ostree` can also be used in the role or tests to include or exclude tasks from being run on ostree systems. This fix also improves error reporting in the `get_ostree_data.sh` script when included roles cannot be found. Signed-off-by: Rich Megginson <[email protected]>
768d1f2
to
d4e1cf5
Compare
The dependency on
ansible.utils.update_fact
is causing issue withsome users who now must install that collection in order to run
the role, even if they do not care about ostree.
The fix is to stop trying to set
ansible_facts.pkg_mgr
, and insteadforce the use of the ostree package manager with the
package:
moduleuse:
option. The strategy is - on ostree systems, set the flag__$ROLENAME_is_ostree
if the system is an ostree system. The flagwill either be undefined or
false
on non-ostree systems.Then, change every invocation of the
package:
module like this:This should ensure that the
use:
parameter is not used if the systemis non-ostree. The goal is to make the ostree support as unobtrusive
as possible for non-ostree systems.
The user can also set
__$ROLENAME_is_ostree: true
in the inventory or playif the user knows that ostree is being used and wants to skip the check.
Or, the user is concerned about the performance hit for ostree detection
on non-ostree systems, and sets
__$ROLENAME_is_ostree: false
to skipthe check.
The flag
__$ROLENAME_is_ostree
can also be used in the role or tests toinclude or exclude tasks from being run on ostree systems.
This fix also improves error reporting in the
get_ostree_data.sh
scriptwhen included roles cannot be found.
Signed-off-by: Rich Megginson [email protected]