search

linux-system-roles / podman

Management of podman, including systemd services that use podman
https://linux-system-roles.github.io/podman/
MIT License
54 stars 19 forks source link

fix: grab name of network to remove from quadlet file #155

Closed richm closed 5 months ago

richm commented 5 months ago

Cause: The code was using "systemd-" + name of quadlet for the network name when removing networks.

Consequence: If the quadlet had a different NetworkName, the removal would fail.

Fix: Grab the network quadlet file and grab the NetworkName from the file to use to remove the network.

Result: The removal of quadlet networks will work both with and without a custom NetworkName in the quadlet file.

Signed-off-by: Rich Megginson rmeggins@redhat.com

This also adds a fix for el10 and Fedora which installs the iptables-nft package to allow rootless podman to manage networks using nftables.

richm commented 5 months ago

[citest]

richm commented 5 months ago

Fixes https://github.com/linux-system-roles/podman/issues/150

richm commented 5 months ago

[citest]

Luap99 commented 5 months ago

Looks reasonable, I do wonder though doesn't this effect the other types as well such as image and volume units?

richm commented 5 months ago

Looks reasonable, I do wonder though doesn't this effect the other types as well such as image and volume units?

For deletion, no - it seems removing the quadlet file and then doing a systemctl daemon-reload is enough to remove those units/podman resources. It is only the podman network resources that require additional cleanup by using podman network rm $name - https://github.com/linux-system-roles/podman/blob/cbd28d55cbc28a5c64b39f1ec7eb88467972d45b/tasks/cleanup_quadlet_spec.yml at least, that is the behavior that I have observed. If this is not the expected behavior, please let me know. Also, as the podman system role is our primary automation interface to managing podman at scale, I would welcome a review of the code, as it was primarily developed by someone (me) without much knowledge of podman best practices.

Luap99 commented 5 months ago

Looks reasonable, I do wonder though doesn't this effect the other types as well such as image and volume units?

For deletion, no - it seems removing the quadlet file and then doing a systemctl daemon-reload is enough to remove those units/podman resources. It is only the podman network resources that require additional cleanup by using podman network rm $name - https://github.com/linux-system-roles/podman/blob/cbd28d55cbc28a5c64b39f1ec7eb88467972d45b/tasks/cleanup_quadlet_spec.yml at least, that is the behavior that I have observed. If this is not the expected behavior, please let me know. Also, as the podman system role is our primary automation interface to managing podman at scale, I would welcome a review of the code, as it was primarily developed by someone (me) without much knowledge of podman best practices.

Well volume units behave exactly like network units, they are a oneshot unit the creates the volume exactly once but never removes it. The same for image units AFAICT.

The reason is simple the resources can be bound to many containers so there is simply no way to delete these for quadlet as it cannot know the lifetime for them.

richm commented 5 months ago

Looks reasonable, I do wonder though doesn't this effect the other types as well such as image and volume units?

For deletion, no - it seems removing the quadlet file and then doing a systemctl daemon-reload is enough to remove those units/podman resources. It is only the podman network resources that require additional cleanup by using podman network rm $name - https://github.com/linux-system-roles/podman/blob/cbd28d55cbc28a5c64b39f1ec7eb88467972d45b/tasks/cleanup_quadlet_spec.yml at least, that is the behavior that I have observed. If this is not the expected behavior, please let me know. Also, as the podman system role is our primary automation interface to managing podman at scale, I would welcome a review of the code, as it was primarily developed by someone (me) without much knowledge of podman best practices.

Well volume units behave exactly like network units, they are a oneshot unit the creates the volume exactly once but never removes it. The same for image units AFAICT.

The reason is simple the resources can be bound to many containers so there is simply no way to delete these for quadlet as it cannot know the lifetime for them.

Which is why in the tests I do the cleanup in the reverse order of creation, and save the network deletion for last, after the other resources have been removed.

Luap99 commented 5 months ago

All I am trying to say is network files are not special and you will have to apply the same logic for volume and image files. Is this already the case? I cannot find such code here.

richm commented 5 months ago

All I am trying to say is network files are not special and you will have to apply the same logic for volume and image files. Is this already the case? I cannot find such code here.

For images - after removing the containers and container units, the code calls podman image prune -f https://github.com/linux-system-roles/podman/blob/main/tasks/cleanup_quadlet_spec.yml#L57 which should remove images not in use

For volumes - will have to test to see if there are any "dangling" volumes

richm commented 5 months ago

ok - there are definitely some cleanup issues with images, volumes, and secrets - will address that in additional PRs - @Luap99 thanks for the heads up!