Further development

[ansibleguy]

Greetings.

Until now I haven't invested too much time in developing these modules as I was not sure if someone would have an use for them.

I would like to discuss the next steps in the development process.

What I have in mind:

• Adding integration tests like I did for the ansibleguy.opnsense collection

  This would boost the code-quality and allow us to find bugs earlier

• Implement the ansibleguy.nftables.rule module

  The module should allow users to piece together rules by using multiple fields.

  In a similar way the community.general.ufw or my ansibleguy.infra_nftables role can be used

• Modules for some different 'config objects' like counters, limits, sets, variables, maps, ...

[ansibleguy]

@thecandler @Dellerium I would appreciate if you would share your opinion.

[thecandler]

Hello @ansibleguy, I appreciate you opening this discussion and the work you've done on this collection thus far. You've been very helpful as I've come across bugs or needed to extend functionality.

---

I think integration tests are definitely needed.

Ideally, breaking changes should be immediately detectable, rather than requiring someone to download the most recent version of the collection and then rerun whatever playbook they have for their specific use case. Primarily since requiring someone to rerun their playbook means you'll only detect issues that their playbook happens to trigger, but also because it would allow us to prevent breaking changes from getting pushed to the latest branch at all.

---

I'm not sure the extent of what the ansibleguy.nftables.rule module would do based on your description. Is the idea that it would become the primary way of creating rules, with parameters for all the stuff you need to set (like port, allow/deny, protocol, etc), rather than needing to manually figure out the whole rule?

So, to allow only outoing traffic on port 80 (assuming the output chain is already attached to the output hook), rather than using raw_rule like:

  ansibleguy.nftables.rule_raw:
    id: '203'
    table_type: 'inet'
    table: 'filter'
    chain: 'output'
    rule: 'tcp dport http accept comment "Allow outgoing HTTP"'

instead you'd write something like

  ansibleguy.nftables.rule_raw:
    id: '203'
    table_type: 'inet'
    table: 'filter'
    chain: 'output'
    proto: 'tcp'
    port: 'http'
    rule: 'accept'
    comment: 'Allow outgoing HTTP'

If that's the goal, I guess that would be useful, I certainly like how that looks better than the current solution with needing to write the rule myself. My use case is pretty simple as well, so I think a module that works that way would be able to work for all the rule that I need, rather than using raw_rule.

---

As for being able to interact with config objects - I can't really speak on the importance of this since my current use-case doesn't call for these sorts of configuration objects.

---

I'm up for helping work on new features/bugs. I haven't done much work on ansible collections before, so I'm not very familiar with the inner workings of that side of things, but I am familiar with python so I should be able to write new code/fix bugs as long as they aren't too ansible-specific.

[ansibleguy]

Greetings @thecandler !

Thanks for the response and sorry for my delay - had a time-intensive project at work.

I'll try to find some time to create a testing-workflow first. I have some vacation days ahead - so that should be doable next month.

Regarding the ansibleguy.nftables.rule module: Yes you got it.
I've already got some well-working Python-code to handle the assembly of rules.

Thank you for offering up your help.
I like to develop these modules, but I have pretty limited time to do so. :(

[ansibleguy]

@thecandler I have implemented basic integration testing.
If you find the time - I would be glad to get feedback/your opinion.
Basically: An Ansible-Playbook that targets a VM/Container.

[ansibleguy]

The tests are now also executed daily.