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.

Sign up for GitHub

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

Jump to bottom

Support diff mode when using vyos_firewall_rules #222

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Support diff mode when using vyos_firewall_rules #222

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6011a2b
Support diff mode when using `vyos_firewall_rules`
sdwilsh Dec 13, 2021
e86f042
use RST, not markdown, in the changelog fragment
sdwilsh Dec 14, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions changelogs/fragments/diff-mode-firewall_rules.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
---
major_changes:
- Support `diff mode <https://docs.ansible.com/ansible/latest/user_guide/playbooks_checkmode.html#using-diff-mode>` in ``vyos_firewall_rules``
11 changes: 11 additions & 0 deletions plugins/module_utils/network/vyos/config/firewall_rules/firewall_rules.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -114,6 +114,17 @@ def execute_module(self):
result["gathered"] = changed_firewall_rules_facts

result["warnings"] = warnings

if self.state in self.ACTION_STATES and self._module._diff:
result["diff"] = {
"after": "\n".join(
sorted(self.set_state(self._module.params["config"], {}))
),
"before": "\n".join(
sorted(self.set_state(existing_firewall_rules_facts, {}))
),
}
Comment on lines +119 to +126
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is only the right thing for overridden, so this PR needs more work. However, this got me thinking that there are two ways to accomplish this.

Commands [to be] Run

You don't get to see the commands this module (returned via results["commands"]) unless you run your play with -vvv as far as I can tell. That has a lot of other output, which makes it not useful in a lot of situations. However, we could just include those as the "after" lines in a diff, and this change would then be quite simple. It would amount to something like this:

         if self.state in self.ACTION_STATES and self._module._diff:
            result["diff"] = {
                "after": "\n".join(result["commands"]),
                "before": "",
            }

Resulting Config

This would basically generate what show configuration commands for the current state (easy) as well as the new state (hard). This would require new helper methods for deleted, merged, and replaced states that will compute what the config object would look like once all the changes we want to apply would look like. Ideally, we'd be able to share code between _state_deleted, _state_merged, and _state_replaced, but I don't actually see a reasonable way to do that.

Comparison

Option Pros Cons
Commands Run
  • Easy to implement
  • Easy to test
  • Always accurate as to what was run
  • Not really what the diff command is meant to convey
Resulting Config
  • Accurate representation of changed sate on the device
  • Hard to implement
  • Hard to test
  • Risk of being inaccurate due to divergent code paths

Despite the table outcome, I actually think the resulting config approach is the better one long-term. However, I don't want to do a bunch of work to implement that if it's not wanted. Therefore, I'm going to wait for some input from y'all before I push this further.

I'd also like to add some tests for this, but unfortunately ansible-test fails a bunch of tests for me, and there aren't really any docs that tell me how to run them locally for this module (at least that I've found). Uploading and waiting for zuul to find out if it works or not isn't a way I want to develop this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Code re-use is actually possible here, so that's not a con of the resulting config approach after all. If we go that route, I'll do a refractor in a seperate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ashwini-mhatre, any thoughts here? I don't want to do a bunch of work that the project doesn't ultimately want, but I think getting check mode added will be a valuable feature.

Copy link
Contributor

Choose a reason for hiding this comment

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

@sdwilsh This seems to be a good feature in my mind as of now. Let me take 2 days to process this and discuss the same with the team and get back to you. Thank you.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@GomathiselviS, any thoughts on direction to go here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@GomathiselviS, bump for any thoughts on direction to go here. I'm still interested in solving this because I think it'll help track down an issue where I see my firewall rules always being listed as changed when I am pretty sure they are not.


return result

def set_config(self, existing_firewall_rules_facts):
Expand Down