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

fix: warm up package cache if Python is already installed #57

Merged
merged 9 commits into from
Dec 4, 2023
Merged

fix: warm up package cache if Python is already installed #57

merged 9 commits into from
Dec 4, 2023

Conversation

philippwaller
Copy link
Contributor

Description

This bugfix will preheat the package cache if python is already installed and the native Ansible functions are used to install the bootstrap packages. This pull request will fix the problems described in issue #56.

Testing
To reliably test these changes, new/additional containers with python installed are required. However, before implementation, we should consider whether it is possible to simplify this role.

Copy link
Owner

@robertdebock robertdebock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be even (a bit) simpler:

    - name: install bootstrap packages using package manager
       ansible.builtin.{{ ansible_pkg_mgr }}:
         name: "{{ item }}"
         update_cache: yes
       changed_when: no
       loop: "{{ bootstrap_facts_packages.split() }}"

It feels a bit hacky, but may work. It would save some 60 lines or so.

Can you give that a try?

And; most "package" modules can work with a list, so I think it can be simplified further:

    - name: install bootstrap packages using package manager
       ansible.builtin.{{ ansible_pkg_mgr }}:
         name: "{{ bootstrap_facts_packages }}"
         update_cache: yes
       changed_when: no # I'm not sure why this should no be changed, I think this line can be removed...

@philippwaller
Copy link
Contributor Author

Great idea! This solution is much smarter. We only need an exception for the Portage module as it uses a different API.

The "changed_when" attribute is required in some cases to pass the idempotency test. The apk module for example, always returns "changed" when a package update is performed. We can either keep the changed_when attribute or tag the task with molecule-idempotence-notest.

@philippwaller
Copy link
Contributor Author

@robertdebock: I came across two issues:

  1. Ansible complains about the syntax. I have tried several notations but always encountered this error. I think I've seen this notation before, but I haven't found a working example.

ERROR! couldn't resolve module/action 'ansible.builtin.{{ ansible_pkg_mgr }}'. This often indicates a misspelling, missing collection, or incorrect module path.

  1. Not all package manager modules are maintained in the same namespace:
Package Manager Namespace
apt,yum,dnf ansible.builtin
apk,zypper,pacman,portage community.general

If the first problem is solved, the second can be solved using variables. However, we only move the complexity to another file. What do you think about the idea of using only RAW commands in this role?

@robertdebock
Copy link
Owner

robertdebock commented Jan 10, 2022

Ah, you are right, did not think of that. In that case, the PR looks good.

About only raw; I think raw is required in this role, but prefer to use non-raw.

And one more question; sorry for the lengthiness;

  • Why are there all these different tasks, condition bases on the ansible_pkg_mgr, but all of them have the same parameters, like update_cache? Could that update_cache not be passed to then package module?

@philippwaller
Copy link
Contributor Author

  • Why are there all these different tasks, condition bases on the ansible_pkg_mgr, but all of them have the same parameters, like update_cache? Could that update_cache not be passed to then package module?

According to the documentation and some stack overflow users, there is unfortunately no generic way to update the package cache. That why I was pushing the "raw" solution. Instead of distinguishing whether or not Python is installed and then going different paths, I would just always run the existing step "install bootstrap packages (raw)". In 90% of the cases, the raw command is executed anyway and also cover the corner cases like mine where python is already installed.
I can absolutely understand why you prefer modules and share your opinion in general but in this particular case I see it as a chance to simplify the code. But I am also totally fine with the current solution, I just wanna be a good sparring partner :).

@philippwaller
Copy link
Contributor Author

I have made further optimizations and removed the loop instructions. Unfortunately, I have not found a way for a leaner implementation.

@philippwaller
Copy link
Contributor Author

Hey @robertdebock, please let me know if there are any tweaks you want me to make. Cheers!

@dgibbs64
Copy link

dgibbs64 commented Oct 6, 2022

Any decisions on this solution as I have come across the issue with debian 11 missing gnupg remoting on and running apt update solves the problem.

@philippwaller
Copy link
Contributor Author

@robertdebock: Two years have passed, and we now have a straightforward fix for this issue. Would you be open to merging this simple one-liner 😀?

@robertdebock
Copy link
Owner

Thanks, CI is running. When CI passes, I'm ready to merge.

@robertdebock robertdebock merged commit 9444930 into robertdebock:master Dec 4, 2023
15 checks passed
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.

3 participants