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

feat: add dnf charm library #75

Merged
merged 23 commits into from
Mar 8, 2023
Merged

feat: add dnf charm library #75

merged 23 commits into from
Mar 8, 2023

Conversation

NucciTheBoss
Copy link
Contributor

Description

This pull request aims to add a dnf charm library offering to the operator_libs_linux collection of charm libraries. The dnf library will be used for charms that need to support both Ubuntu and RPM-based distributions (CentOS, Alma, etc.), as well as charms just intended to be deployed to just RPM-based Juju units. It comes with the standard bells and whistles needed to interact with dnf from a simple Python interface.

What still needs to be done

Documentation and registering the library on Charmhub. This pull request is mostly focused on just adding the initial code for a dnf charm library; do not want too many themes in the pull request review.

Notes

  • I updated the version of the setup-lxd GitHub Action to 0.1.0 instead of just using a commit hash. I also set the channel of LXD to 5.9/stable
  • I am using the cleantest library to provide the test instances for the dnf charm library. This way the library can be tested inside a RPM-based environment on GitHub Actions.
  • I added a separate tox env named integration-but-with-cleantest so that I did not mess with how the current integration tests are done. I added an extra step in the CI job for the new environment.

Copy link
Member

@jnsgruk jnsgruk left a comment

Choose a reason for hiding this comment

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

A lot of this is just nits on style, but I do think in places we're over-complicating things and we probably need to consider if the added complexity is bringing much value over a more simplistic approach.

Remember that in the life of the charm, these methods are likely to be used only during install and upgrade-charm, which represents a very small portion of the charm's life, and never concurrently.

lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
tests/integration/test_dnf.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@benhoyt benhoyt 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 a lot of this is overly complex, and I'm worried about the "available" cache and the side effects done at import time. I've submitted a lot of comments to this effect. I hope they're constructive!

I think we should look at some use cases to determine what we actually need. And ask whether the cache is needed, or can we use something like dnf info instead.

tox.ini Show resolved Hide resolved
tox.ini Outdated Show resolved Hide resolved
tox.ini Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
tests/integration/test_dnf.py Outdated Show resolved Hide resolved
tests/integration/test_dnf.py Outdated Show resolved Hide resolved
tests/integration/test_dnf.py Outdated Show resolved Hide resolved
tests/integration/test_dnf.py Outdated Show resolved Hide resolved
@benhoyt
Copy link
Collaborator

benhoyt commented Mar 2, 2023

Oh sorry, I spent a bunch of time reviewing this and just submitted my comments, but didn't see that @jnsgruk just had too. Looks like we have many of the same exact concerns. Sorry about the duplication!

@NucciTheBoss
Copy link
Contributor Author

Thanks for reviewing this @jnsgruk and @benhoyt! I finished responding to most of your review comments. I am going to take dnf "back to the shop" and make some changes based on what has been discussed here. I will re-comment once I am done implementing my changes and ready for the next round of reviews.

Notes:
* I removed the _Cache class for managing data about what packages are currently installed on the unit.
* I removed the _MetaDNF class that checked if `dnf` was installed and brought in the `dnf-plugins-core` package.
* I removed all the threading.
* I removed the __getitem__ interface for retrieving package data.
@NucciTheBoss
Copy link
Contributor Author

Okay @jnsgruk and @benhoyt, I have completed my initial passthrough for improving the dnf charm library. Big changes that I made to this new revision is that I removed _Cache and _MetaDNF completely. Let me know what you think of the updated version. In the meantime, I will be testing an EL9 base with Juju to see if I can get it working. If it works, I will issue some new commits bumping up to Python 3.8 (i.e. change PackageInfo to a dataclass rather than having a lot of boilerplate).

@NucciTheBoss NucciTheBoss requested review from jnsgruk and benhoyt and removed request for jnsgruk and benhoyt March 3, 2023 22:34
Copy link
Collaborator

@benhoyt benhoyt left a comment

Choose a reason for hiding this comment

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

This is so much simpler, with any complexity that's left commensurate with what we're doing. Thanks! Just a few minor comments.

lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
Notes:
* Removed hashbang from top of file.
* Renamed ExecutionError -> Error.
* Removed UNKNOWN state as I find it to not be helpful.
* Simplified `version()` and as such removed need for StringIO.
* Refactored `upgrade()` so that upgrade can be performed even if no packages are specified.
* Refactored how missing args are evaluated.
* Refactored `fetch()` to be more resilient. i.e. handle regex match failure.
* Removed `installed()` check from `_dnf()` in favor of just handling the thrown `FileNotFoundError` thrown by subprocess if desired executable is not found.
@jnsgruk
Copy link
Member

jnsgruk commented Mar 6, 2023

Looking much, much simpler @NucciTheBoss - thanks! If you could clean up the unresolved conversations when you're done hacking we can take another pass at this and hopefully get it across the line?

@NucciTheBoss
Copy link
Contributor Author

Looking much, much simpler @NucciTheBoss - thanks! If you could clean up the unresolved conversations when you're done hacking we can take another pass at this and hopefully get it across the line?

Sure can do @jnsgruk. Here is what I still need to do hacking wise:

  1. Update to Python >= 3.8. I have verified that CentOS 9 Stream works with Juju so I am going to update to newer Python standards (i.e. dataclass rather than boilerplate @property).
  2. Change the integration tests for dnf to how they are being done now.
  3. Write some unit tests.
  4. Need some of @benhoyt's feedback on my replies to his newest review comments. The update and purge methods are part of "my grand plan" for data-plane charms to work on both Ubuntu and RPM-based distributions.

Notes:
* Removed the `purge(...)` and `update(...)` methods.
* Add note to fetch about package name needing too exactly match installed package.
* Changed `universal_newlines=True` to `text=True` in `_dnf(...)`.
* Modified upgrade(...) so that there is not a condition check if no packages are passed. Change since Python is fine iterating over an empty args object.
Notes:
* cleantest was removed after concluding discussion on this thread here: canonical#75 (comment). Cleantest can be reconsidered in a later PR, but for now we should just keep the tests to how they are being done now.
@NucciTheBoss NucciTheBoss requested a review from benhoyt March 7, 2023 19:47
@NucciTheBoss
Copy link
Contributor Author

Greetings @jnsgruk and @benhoyt - should be ready for the next round of reviews now. Here are the major changes you should be aware of now that I have published the new commits:

  1. I removed the update() and purge(...) methods since they do not really exist in dnf.
  2. I made PackageInfo a dataclass because I got CentOS 9 Stream to work as a base.
  3. I removed cleantest from the integration tests and made some modifications to the current tox.ini file. TL;DR is that I also added an instance for CentOS 9 Stream to test dnf. See this thread on the Charmhub Mattermost for more information. I also removed the integration test for checking if dnf is installed since I can just mock with unittest.mock.
  4. I added unit tests. Coverage is at 100%, but I did have to add a # pragma: no cover to add_repo(...). No matter how I patched the method, coverage would not mark it as covered. I think it had to do with trying to patch both subprocess.run and dnf.fetch(...). Luckily the integration tests for the library validate that the add_repo(...) method works!

Let me know what you thoughts are. We are getting closer!

Copy link
Collaborator

@benhoyt benhoyt left a comment

Choose a reason for hiding this comment

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

Nice. Approving, but just one nit comment!

lib/charms/operator_libs_linux/v0/dnf.py Show resolved Hide resolved
lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
Copy link
Member

@jnsgruk jnsgruk left a comment

Choose a reason for hiding this comment

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

One final thing: we need to register the lib name and add LIBID / LIBAPI / LIBPATCH before this can be uploaded :)

lib/charms/operator_libs_linux/v0/dnf.py Outdated Show resolved Hide resolved
@NucciTheBoss
Copy link
Contributor Author

Working on adding module level documentation for how to use the dnf charm library for Charmhub now.

@jnsgruk jnsgruk changed the title Add dnf charm library feat: add dnf charm library Mar 8, 2023
@jnsgruk jnsgruk merged commit 4f8ed01 into canonical:main Mar 8, 2023
@jnsgruk
Copy link
Member

jnsgruk commented Mar 8, 2023

This is now published! https://charmhub.io/operator-libs-linux/libraries/dnf

Thanks @NucciTheBoss!

@jamesbeedy
Copy link

@NucciTheBoss - super! Nice work, and thank you!

@NucciTheBoss NucciTheBoss deleted the dnf branch November 19, 2024 20:08
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.

4 participants