Skip to content

Conversation

JanaHoch
Copy link
Contributor

@JanaHoch JanaHoch commented Sep 7, 2025

SUMMARY
  • Create/update/delete firewall rules at cluster/group/vnet/vm level
  • create/delete firewall security group at cluster level
  • create alias at cluster/vm level
  • list all/ at pos firewall rules at cluster/group/vnet/vm level
  • list all firewall security groups
  • list all alias at cluster/vm level
ISSUE TYPE
  • New Module Pull Request
COMPONENT NAME

proxmox_firewall
proxmox_firewall_info

ADDITIONAL INFORMATION

This is part of #30

@JanaHoch JanaHoch marked this pull request as draft September 7, 2025 23:57
@JanaHoch JanaHoch marked this pull request as ready for review September 8, 2025 00:59
@IamLunchbox
Copy link
Contributor

IamLunchbox commented Sep 8, 2025

I am neither Collaborator nor Maintainer, but I think you will need to provide Unit Tests as well. Additionally, there is an integration test for several functions, which probably would be well suited for this module. :)

Copy link

codecov bot commented Sep 8, 2025

Codecov Report

❌ Patch coverage is 67.50630% with 129 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.86%. Comparing base (80dc876) to head (508e616).
⚠️ Report is 7 commits behind head on main.

Files with missing lines Patch % Lines
plugins/modules/proxmox_firewall.py 50.00% 69 Missing and 19 partials ⚠️
plugins/module_utils/proxmox.py 40.90% 10 Missing and 3 partials ⚠️
plugins/module_utils/proxmox_sdn.py 47.36% 8 Missing and 2 partials ⚠️
plugins/modules/proxmox_firewall_info.py 80.00% 7 Missing and 3 partials ⚠️
...ests/unit/plugins/modules/test_proxmox_firewall.py 94.11% 3 Missing and 1 partial ⚠️
...unit/plugins/modules/test_proxmox_firewall_info.py 93.54% 3 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #183      +/-   ##
==========================================
+ Coverage   63.57%   64.86%   +1.28%     
==========================================
  Files          60       69       +9     
  Lines        6315     6941     +626     
  Branches     1235     1326      +91     
==========================================
+ Hits         4015     4502     +487     
- Misses       2128     2223      +95     
- Partials      172      216      +44     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@JanaHoch
Copy link
Contributor Author

JanaHoch commented Sep 8, 2025

I am neither Collaborator nor Maintainer, but I think you will need to provide Unit Tests as well. Additionally, there is an integration test for several functions, which probably would be well suited for this module. :)

aah I hate writing unit tests.... But let me try......

- state=present:
    + check if fw rules already exists and if needed update them instead of creating
    + check if group exists and if so don't do anything
- state=update:
    + check if fw rules don't existsand if needed create them instead of updating
- make rules.pos as required this is to handle above conditions
- add method to get security groups and list them with firewall rules when state is not provided
- add proxmox_firewall in meta/runtime.yml
@JanaHoch
Copy link
Contributor Author

JanaHoch commented Sep 9, 2025

Hi I've added unit test for this module. can you trigger the checks again. I'm working on others but it'll take some time....

@JanaHoch
Copy link
Contributor Author

Hi @IamLunchbox , Hold off on reviewing this. I'm adding way to create aliases and update firewall level options.

@JanaHoch JanaHoch marked this pull request as draft September 13, 2025 05:30
- Earlier it was only checking if rule at pos already exists
- If it did it would update it given force was true.
- But it means if we ran same pipeline twice without force it would fail
- To fix it Checking the entier rule
- Move check_rules() to proxmox module_utils and rename to compare_list_of_dicts()
- Generalize the implemnetation as this is usefull in multiple places.
- e.g. filtering out which fw rules, aliases, etc needs to be created/updated
@JanaHoch JanaHoch marked this pull request as ready for review September 21, 2025 06:36
@JanaHoch
Copy link
Contributor Author

Hi @Thulium-Drake / @IamLunchbox please review this also.
I've added get methods in module_utils/proxmox_sdn.py but not sure if this is correct because we will be getting details for both sdn resources and non sdn resources. If it needs to be moved let me know.
And as discussed in previous PRs I've merged state present and update here as well.

@IamLunchbox
Copy link
Contributor

IamLunchbox commented Sep 21, 2025

I will check it out.

@JanaHoch
Copy link
Contributor Author

Sorry I just added 1 more small change with 0b01684 which i needed for another PR.

@Thulium-Drake
Copy link
Collaborator

Please ping me when you are happy with the results @IamLunchbox :-) I will merge it and re-start the CI on #182

Thanks for the work!

Also @JanaHoch, I think it's a good moment to do a new release after #181 is merged. Is that PR also ready for prime time?

Copy link
Contributor

@IamLunchbox IamLunchbox left a comment

Choose a reason for hiding this comment

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

Thank you for your extensive work! @JanaHoch A nice PR, I mostly annotated grammar errors and such.

The only think I would like to discuss is, if the level option is actually needed, when there are implicit arguments, which define the desired level already. E.g. vmid or node.

@Thulium-Drake, what do you think?

params_to_ignore=['digest', 'ipversion']
)

if len(rules_to_create) == 0 and len(rules_to_update) == 0:
Copy link
Contributor

Choose a reason for hiding this comment

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

Just a note :)

len(emtpy_list) == 0 is the same as not emtpy_list. Evaluating an empty list with bool() returns False, otherwise True.

@JanaHoch
Copy link
Contributor Author

Please ping me when you are happy with the results @IamLunchbox :-) I will merge it and re-start the CI on #182

Thanks for the work!

Also @JanaHoch, I think it's a good moment to do a new release after #181 is merged. Is that PR also ready for prime time?

#181 will need some time. I need to write unit tests and a way to compare subnets. But I think I can finish it over the weekend. Thanks.

@JanaHoch
Copy link
Contributor Author

Thank you for your extensive work! @JanaHoch A nice PR, I mostly annotated grammar errors and such.

The only think I would like to discuss is, if the level option is actually needed, when there are implicit arguments, which define the desired level already. E.g. vmid or node.

@Thulium-Drake, what do you think?

Yeah, I'm also not sure. I used it so that it'll be clear where this is getting applied. but i guess same can be done with clear docs. also @IamLunchbox Thanks for review. I'm just little packed for the week. I'll make changes over the weekend. Thanks.

@Thulium-Drake
Copy link
Collaborator

Thank you for your extensive work! @JanaHoch A nice PR, I mostly annotated grammar errors and such.

The only think I would like to discuss is, if the level option is actually needed, when there are implicit arguments, which define the desired level already. E.g. vmid or node.

@Thulium-Drake, what do you think?

I think it's good to make them explicit, so people using this know what they are doing. And who knows what the implications of Proxmox Datacenter Manager's "let's stretch your SDN over all your clusters" feature will bring to the table. (https://pve.proxmox.com/wiki/Proxmox_Datacenter_Manager_Roadmap)

That said, if there is a reason to assume that the option is either redundant or not actually needed, it could be left out.

Added suggestions from @IamLunchbox

Co-authored-by: IamLunchbox <[email protected]>
@JanaHoch
Copy link
Contributor Author

Thank you for your extensive work! @JanaHoch A nice PR, I mostly annotated grammar errors and such.
The only think I would like to discuss is, if the level option is actually needed, when there are implicit arguments, which define the desired level already. E.g. vmid or node.
@Thulium-Drake, what do you think?

I think it's good to make them explicit, so people using this know what they are doing. And who knows what the implications of Proxmox Datacenter Manager's "let's stretch your SDN over all your clusters" feature will bring to the table. (https://pve.proxmox.com/wiki/Proxmox_Datacenter_Manager_Roadmap)

That said, if there is a reason to assume that the option is either redundant or not actually needed, it could be left out.

I also vote for keeping it explicit so that there is no confusion. And yes the level is part of the API endpoint we are calling but also that it can be easily inferred based on other parameters.

- When state is absent and pos is 0 if condition with pos was failing.
  to fix it explicitly check if pos is not None.
@Thulium-Drake
Copy link
Collaborator

@JanaHoch thanks for updating the PR with the fixes proposed! 🚀

@IamLunchbox Are you happy with the end-result? ;-)

@IamLunchbox
Copy link
Contributor

Lgtm :)

@Thulium-Drake Thulium-Drake merged commit b190cb3 into ansible-collections:main Oct 3, 2025
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