Hey, just laying this out for everyone so there are no surprises. As part of a larger discussion, we have decided that the Firewall module is in need of a major restructuring, with more and more issues arising from it and compile times that seem to regularly take upwards of thirty minutes. In order to try and solve this issue the team is working to put together a plan on how the module should best be restructured to not only resolve the issues currently facing it but to help ensure that similar ones do not occur. As part of this however we would like to hear the communities feedback and what ideas that they might have on the best way to accomplish this, so that we can reach our goal and provide the best quality module that we can. As a start there are several questions that must be answered and choices to be made, these including:
* Should we keep to the current provider style module or convert it to run with templates? Converting the module may take more time to accomplish but could help keep the modules run time down and make the module more easily modified and maintained. * Should we refactor the current module or create a fresh one and leave the current one as is? Depending on the size of the refactor it may be easier to simply start fresh, especially if we convert to a template style, as we can leave the old module as is for people to use until we get the new one fully fleshed out. As a side note however, this could also be accomplished simply by cutting a major release and informing the community beforehand. * In the event that we create a new module, should we split it into two separate ones, one for iptables and one for ip6tables? Although there is overlap in how they are managed they are in fact separate and outright keeping them as such may be more convenient for people who simply use on or the other. * Finally, should the module/modules be expanded to include nftables? Although it has been around for some time now it is only recently that nftables seems to have gained traction, as such it may be best to add support for it to the firewall module/modules to ease people into converting over, as both it and iptables/ip6tables are both maintained by the same organisation, with the prior being actively developed as a successor and poised to take over. Finally, to anyone worried about the changes coming to the module, know that this is merely an initial investigation and that the actual changes are still some time away. We are well aware of how important this module is and are committed to getting this right. This issue has also been posted in a newly created Github issue and on the Puppet community slack, both of which are linked below. https://github.com/puppetlabs/puppetlabs-firewall/issues/1100 [https://opengraph.githubassets.com/7ea2e8ea7cf89c76883fc33d5b7c5e5e194b6451421aa21fe7f7e71d6302c161/puppetlabs/puppetlabs-firewall/issues/1100]<https://github.com/puppetlabs/puppetlabs-firewall/issues/1100> Re-Architect Firewall · Issue #1100 · puppetlabs/puppetlabs-firewall<https://github.com/puppetlabs/puppetlabs-firewall/issues/1100> Hey, just laying this out for everyone so there are no surprises. As part of a larger discussion, we have decided that the Firewall module is in need of a major restructuring, with more and more is... github.com https://puppetcommunity.slack.com/archives/C0W298S9G/p1670408721895409 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/DM5PR20MB1211BFB16A9A0545225A20F7F41A9%40DM5PR20MB1211.namprd20.prod.outlook.com.
