Robert Wimmer

Well, to be honest I don't think it makes sense to compile `wireguard-go` in every OpenVZ guest. This is definitely something that should take place outside of this role. So...

TBH I'm not sure if this is really something this role needs or should handle. This can become quite complicated and everybody wants it differently. Personally I would implement a...

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 If I accept a...

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...

@lucasteinke Mainly time :wink:

I had something similar in mind but never had the time to implement it. I'll leave the issue open for now and mark it as `enhancement`.

Well... Being able to show someone a config file doesn't really justify PR to move the private key out of the WireGuard config TBH. :wink: That totally depends on your...

TBH I really think it makes sense for you to fork this project. That way you can really change it to your needs. Your way of thinking is totally the...

I'm thinking about it. But it'd be definitely optional as it'd change the current behavior of the role. So adding a variable like `wireguard_flush_handlers: true|false` might be an option.

Thanks for the PR! But I already came to the conclusion that this doesn't makes that much sense. Also see https://github.com/githubixx/ansible-role-wireguard/pull/133 . The whole logic basically is in this template....