Managed multiple wireguard interfaces per machine

[MEschenbacher]

This role looks pretty sophisticated, cool!

I've read through the wg.conf.j2 and tasks/main.yml and noticed that there was currently no way of managing multiple wireguard interfaces per machine with a single run. Is this assessment correct?

Are you open to accepting a merge request for this kind functionality?

[githubixx]

Well not sure if your assessment is correct 😉 It depends on your use-case most probably. You can at least do something like described here: https://github.com/githubixx/ansible-role-wireguard#example-inventory-using-two-different-wireguard-interfaces-on-host-multi

If I accept a PR mostly depends on the PR itself. I assume that this kind of PR most probably won't be backwards compatible (that's at least something that cames into my mind first...). That's normally something I try to avoid. The question is always if the role really needs to cover all the "edge cases" that 99% of the users (including me 😉 ) don't need. But that's of course my very own subjective perception. If I don't understand the PR then I also don't merge it as I need to maintain it. The same is true if the coding style is totally different than what's currently available already. And meanwhile having a Molecule test scenario is something I really want to have to be able to test if changes will break something - at least a little bit.

But if you've a basic idea what you've in mind and what needs to be changed we can talk about it of course.

[MEschenbacher]

Well not sure if your assessment is correct wink It depends on your use-case most probably. You can at least do something like described here: https://github.com/githubixx/ansible-role-wireguard#example-inventory-using-two-different-wireguard-interfaces-on-host-multi

That would probably work, however I would still need multiple runs per machine because as a single run may configure at most one interface per host.

We're using netbox config contexts to configure each individual host and the technique of maintaining multiple inventory files with configuration options split horizontally throughout probably cannot be done with netbox.

If I accept a PR mostly depends on the PR itself. I assume that this kind of PR most probably won't be backwards compatible (that's at least something that cames into my mind first...). That's normally something I try to avoid. The question is always if the role really needs to cover all the "edge cases" that 99% of the users (including me wink ) don't need. But that's of course my very own subjective perception. If I don't understand the PR then I also don't merge it as I need to maintain it. The same is true if the coding style is totally different than what's currently available already. And meanwhile having a Molecule test scenario is something I really want to have to be able to test if changes will break something - at least a little bit.

Of course, that's all understood.

But if you've a basic idea what you've in mind and what needs to be changed we can talk about it of course.

If we plan a change to be backwards compatible, the only option I currently see is introducing a new top level variable e.g. wireguard_interfaces: [] which supports exactly the same arguments as currently available e.g.

wireguard_interfaces:
 - wireguard_interface: wg1
   wireguard_port: 1194

Maybe we can find a way to programmatically loop through top level as well as the newly introduced wireguard_interfaces list without having to duplicate code, keeping maintenance managable.

[githubixx]

I think that's definitely a possibility. I guess most people will never need a second interface. So keeping the current variables like wireguard_interface makes sense and people doesn't need to change anything.

I think the easiest way would be to have an internal variable like wireguard__interfaces and only work with that one e.g. Then the values of wireguard_interface and all other variables will be the first interface of wireguard__interfaces. And the interfaces defined in wireguard_interfaces will be copied into that data structure afterwards. So after that task all the information is only in wireguard__interfaces and will contain at least one interface. This way the role stays compatible with the old versions and internally only wireguard__interfaces needs to be considered.

[strarsis]

@githubixx: First, thanks for this great Ansible role!

+1 for multiple interfaces! Even as I just need one for now, it should not be the "default" or "primary" WireGuard interface.