Skip to content
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 #368

Merged
merged 1 commit into from
Nov 29, 2023

Conversation

richm
Copy link
Collaborator

@richm richm commented Nov 24, 2023

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:

- 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.

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.
@richm
Copy link
Collaborator Author

richm commented Nov 24, 2023

[citest]

@richm richm merged commit 644e72c into linux-system-roles:main Nov 29, 2023
8 checks passed
@richm richm deleted the refactor-ostree branch November 29, 2023 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant