)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":23,"context_line":"convert a host.  On nftables hosts those rendered files are then"},{"line_number":24,"context_line":"transpiled and loaded with nft, and the iptables-persistent /"},{"line_number":25,"context_line":"iptables-services era units are retired so they cannot also load a"},{"line_number":26,"context_line":"ruleset at boot."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Only the two tables this role owns are replaced.  A blanket \"flush"},{"line_number":29,"context_line":"ruleset\" would also drop \"table ip nat\", which on Docker hosts"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"312e5a4a_d7116d78","line":26,"updated":"2026-08-10 17:34:33.000000000","message":"Do we know what happens when we try to load overlapping iptables and nftables rulesets? Is it effectively a noop since the rules don\u0027t conflict with one another or will the kernel complain about a conflict due to the overlap?","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"8414cc0c2be6eb1d59684b2c398a2d5aba52ce66","unresolved":false,"context_lines":[{"line_number":23,"context_line":"convert a host.  On nftables hosts those rendered files are then"},{"line_number":24,"context_line":"transpiled and loaded with nft, and the iptables-persistent /"},{"line_number":25,"context_line":"iptables-services era units are retired so they cannot also load a"},{"line_number":26,"context_line":"ruleset at boot."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Only the two tables this role owns are replaced.  A blanket \"flush"},{"line_number":29,"context_line":"ruleset\" would also drop \"table ip nat\", which on Docker hosts"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"80ac90d9_91258d56","line":26,"in_reply_to":"2642a1ff_9d725880","updated":"2026-09-16 22:19:24.000000000","message":"Acknowledged","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":true,"context_lines":[{"line_number":23,"context_line":"convert a host.  On nftables hosts those rendered files are then"},{"line_number":24,"context_line":"transpiled and loaded with nft, and the iptables-persistent /"},{"line_number":25,"context_line":"iptables-services era units are retired so they cannot also load a"},{"line_number":26,"context_line":"ruleset at boot."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Only the two tables this role owns are replaced.  A blanket \"flush"},{"line_number":29,"context_line":"ruleset\" would also drop \"table ip nat\", which on Docker hosts"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"2642a1ff_9d725880","line":26,"in_reply_to":"312e5a4a_d7116d78","updated":"2026-08-17 03:56:11.000000000","message":"No complaint from the kernel - the two stores are independent, so there is nothing for it to conflict over. Both are traversed on the same hook though, and a drop or reject in either is terminal, so the effective result is most-restrictive-wins: the old closing REJECT still drops traffic the new ruleset accepts.\n\nSo it\u0027s not a noop, and that\u0027s exactly why the legacy cleanup handler exists. Now written up in the commit message.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":28,"context_line":"Only the two tables this role owns are replaced.  A blanket \"flush"},{"line_number":29,"context_line":"ruleset\" would also drop \"table ip nat\", which on Docker hosts"},{"line_number":30,"context_line":"carries the container masquerade and port forward rules;"},{"line_number":31,"context_line":"iptables-restore of a *filter-only file never touched those."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The translator\u0027s banner comments are stripped, as their embedded"},{"line_number":34,"context_line":"timestamp would otherwise make the ruleset differ on every run and"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"ca969b9b_86e52568","line":31,"updated":"2026-08-10 17:34:33.000000000","message":"Note we typically use host networking as it simplifies a lot of this firewall stuff. I can\u0027t think of any containers that are not host networking, but they may exist. Not sure if that changes our assessment here.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"8414cc0c2be6eb1d59684b2c398a2d5aba52ce66","unresolved":false,"context_lines":[{"line_number":28,"context_line":"Only the two tables this role owns are replaced.  A blanket \"flush"},{"line_number":29,"context_line":"ruleset\" would also drop \"table ip nat\", which on Docker hosts"},{"line_number":30,"context_line":"carries the container masquerade and port forward rules;"},{"line_number":31,"context_line":"iptables-restore of a *filter-only file never touched those."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The translator\u0027s banner comments are stripped, as their embedded"},{"line_number":34,"context_line":"timestamp would otherwise make the ruleset differ on every run and"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"3263543e_7410d7ce","line":31,"in_reply_to":"070e40ca_8888b0da","updated":"2026-09-16 22:19:24.000000000","message":"Acknowledged","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":true,"context_lines":[{"line_number":28,"context_line":"Only the two tables this role owns are replaced.  A blanket \"flush"},{"line_number":29,"context_line":"ruleset\" would also drop \"table ip nat\", which on Docker hosts"},{"line_number":30,"context_line":"carries the container masquerade and port forward rules;"},{"line_number":31,"context_line":"iptables-restore of a *filter-only file never touched those."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The translator\u0027s banner comments are stripped, as their embedded"},{"line_number":34,"context_line":"timestamp would otherwise make the ruleset differ on every run and"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"070e40ca_8888b0da","line":31,"in_reply_to":"ca969b9b_86e52568","updated":"2026-08-17 03:56:11.000000000","message":"Agreed, and it does simplify most of this - host-networked containers don\u0027t need docker\u0027s forward rules at all.\n\nIt matters in one place: on iptables-nft hosts docker\u0027s chains live in `table ip filter`, which is the table we delete and recreate. I\u0027ve checked that on noble against the current role:\n\n  our transpiled load       docker chains in ip filter 4 -\u003e 0\n  today\u0027s iptables-restore  docker chains in ip filter 4 -\u003e 0\n\niptables-restore flushes the tables named in the file, so the current role already does this on every firewall change. Same behaviour, not a new regression. `table ip nat` survives in both, which is the one that carries docker\u0027s masquerade rules.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":38,"context_line":"emitting a rule matching ip6 saddr, which nft rejects.  Correct the"},{"line_number":39,"context_line":"set type on the ip6 stream only.  A \"nft -c\" check runs before the"},{"line_number":40,"context_line":"ruleset is installed so a bad translation fails the run rather than"},{"line_number":41,"context_line":"the firewall."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"For testing, system-config-run-base now converts its nodes to"},{"line_number":44,"context_line":"nftables, and a new system-config-run-base-iptables job keeps"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"82dad496_8c0f9db7","line":41,"updated":"2026-08-10 17:34:33.000000000","message":"Will this leave the host running without a firewall ruleset? We may need to consider what the fallback behavior we want is (maybe a bad ruleset that prevents any access is better than a bad ruleset that allows all access).","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":true,"context_lines":[{"line_number":38,"context_line":"emitting a rule matching ip6 saddr, which nft rejects.  Correct the"},{"line_number":39,"context_line":"set type on the ip6 stream only.  A \"nft -c\" check runs before the"},{"line_number":40,"context_line":"ruleset is installed so a bad translation fails the run rather than"},{"line_number":41,"context_line":"the firewall."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"For testing, system-config-run-base now converts its nodes to"},{"line_number":44,"context_line":"nftables, and a new system-config-run-base-iptables job keeps"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"8d9ed67f_ecab00c6","line":41,"in_reply_to":"82dad496_8c0f9db7","updated":"2026-08-17 03:56:11.000000000","message":"It won\u0027t - this path is already fail-safe. We render a candidate file and run `nft -c` on it; if that fails the task fails and nothing is installed, so the host keeps the ruleset it is already running. Never partial, never empty.\n\nSo the fallback isn\u0027t \"deny all\" or \"allow all\", it\u0027s \"no change\" - which I think is the better of the three, since the host stays exactly as reachable as it was before the run. The original wording was ambiguous about this; reworded in the commit message.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"8414cc0c2be6eb1d59684b2c398a2d5aba52ce66","unresolved":false,"context_lines":[{"line_number":38,"context_line":"emitting a rule matching ip6 saddr, which nft rejects.  Correct the"},{"line_number":39,"context_line":"set type on the ip6 stream only.  A \"nft -c\" check runs before the"},{"line_number":40,"context_line":"ruleset is installed so a bad translation fails the run rather than"},{"line_number":41,"context_line":"the firewall."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"For testing, system-config-run-base now converts its nodes to"},{"line_number":44,"context_line":"nftables, and a new system-config-run-base-iptables job keeps"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"c5d69585_d3ed5a8b","line":41,"in_reply_to":"8d9ed67f_ecab00c6","updated":"2026-09-16 22:19:24.000000000","message":"Done","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"cf02c3c5545e61ec12766a044e7b7f2f97b662e5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"975746ac_50b78eda","updated":"2026-08-06 02:34:06.000000000","message":"Thanks Clark - agreed, I\u0027d rather restructure now than after it lands.\nNeed some guidance going with your third option, a new group:\n\n- empty `nftables: []` group in groups.yaml\n- group_vars sets `iptables_use_nftables`, default false in the role\n- backend vars behind one conditional include_vars\n\nLanding that is a no-op in prod, then each tier is a one-line change\nadding a glob to the group. Picked the group over a parallel role since\nthe role is called from 20+ playbooks, and futureparser/puppet4 already\ndid exactly this here (including retiring the flag at the end).\n\nHelpfully, the new `nft list ruleset` assertions pass unchanged on\ncurrent iptables hosts - it\u0027s already the iptables-nft compat layer, I\nchecked on trixie. So one assertion set covers both backends and CI can\ntest converted and unconverted hosts side by side. And since the\nsystem-config-run nodesets use production hostnames, each tier change\nconverts the CI node and the prod host together - so it\u0027s proven in the\ngate before it merges. Roughly 15 independent changes, low risk first,\ngitea-lb/review late, bridge last.\n\nTwo questions before I respin: cacti, storyboard(-dev), translate(-dev)\nand the afs servers have no system-config-run job, so converting them\nis blind - hold them for a manual check, or just leave them until\nthey\u0027re retired? And are host globs fine, or would you rather I opt in\nexisting service groups?","commit_id":"c94c496a5e7c835447935f994072a0a4995f6ae2"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"2080db31f0d1b8045ea599f29a7b7c70390ff19b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a84f08fe_de8bcb44","in_reply_to":"6150b077_7c213590","updated":"2026-08-07 08:00:48.000000000","message":"Thanks, that all makes sense. Respun along those lines. This is now\ntwo changes:\n\n1. testinfra: teach verify_iptables() to handle both backends\n2. this change: the opt-in mechanism, with the group empty\n\nOne correction to what I said earlier - I claimed the nft assertions pass unchanged on unconverted hosts. That\u0027s true on jammy and noble, but not on focal, which still defaults iptables to iptables-legacy (alternatives priority 20 vs 10 for the nft variant), so \"nft list ruleset\" there is empty. The reverse is also true: once a host is on a natively loaded ruleset, \"iptables -S\" refuses to render it at all (\"table `filter\u0027 is incompatible, use \u0027nft\u0027 tool\"). So the two readbacks really aren\u0027t interchangeable and I had that wrong.\n\nThe testinfra change probes \"iptables -S\" first and only falls back to nft when it fails. That means unconverted hosts keep asserting exactly what they assert today, byte for byte, on both the legacy and the iptables-nft backends, and only converted hosts take the new path.\n\nAdded system-config-run-base-iptables as you suggested, parented to system-config-run-base. The base job now sets gate_nftables, which puts its nodes in the nftables group via the gate-groups template, and the new job leaves it off. So both backends are covered by the base job pair regardless of which services have been converted.\n\nAlso worth noting the legacy path is untouched here - vars/Debian.yaml, vars/RedHat.yaml, vars/Ubuntu.trusty.yaml, tasks/RedHat.yaml and both rules templates are identical to master, and the legacy handlers just gained a \"when\". The nftables bits are additive, so unconverted hosts should be a genuine no-op.","commit_id":"c94c496a5e7c835447935f994072a0a4995f6ae2"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"7491c0db61ab384ef28e74f53c636887fe80afe5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"6150b077_7c213590","in_reply_to":"975746ac_50b78eda","updated":"2026-08-06 20:21:54.000000000","message":"\u003e Thanks Clark - agreed, I\u0027d rather restructure now than after it lands.\n\u003e Need some guidance going with your third option, a new group:\n\u003e \n\u003e - empty `nftables: []` group in groups.yaml\n\u003e - group_vars sets `iptables_use_nftables`, default false in the role\n\u003e - backend vars behind one conditional include_vars\n\u003e \n\u003e Landing that is a no-op in prod, then each tier is a one-line change\n\u003e adding a glob to the group. Picked the group over a parallel role since\n\u003e the role is called from 20+ playbooks, and futureparser/puppet4 already\n\u003e did exactly this here (including retiring the flag at the end).\n\nThis seems like good justification for this approach.\n\n\u003e \n\u003e Helpfully, the new `nft list ruleset` assertions pass unchanged on\n\u003e current iptables hosts - it\u0027s already the iptables-nft compat layer, I\n\u003e checked on trixie. So one assertion set covers both backends and CI can\n\u003e test converted and unconverted hosts side by side. And since the\n\u003e system-config-run nodesets use production hostnames, each tier change\n\u003e converts the CI node and the prod host together - so it\u0027s proven in the\n\u003e gate before it merges. Roughly 15 independent changes, low risk first,\n\u003e gitea-lb/review late, bridge last.\n\nYup I think this should work well. We should also probably add a new job that has parent system-config-run-base https://opendev.org/opendev/system-config/src/branch/master/zuul.d/system-config-run.yaml#L56-L91 to test the basic deployment with iptables specifically. Then we can make the existing base job test with nftables. That way it will be harder for us to regress if we\u0027re only making changes to this particular role as both the old and new method will be covered and tested before we try and convert a specific service.\n\n\u003e \n\u003e Two questions before I respin: cacti, storyboard(-dev), translate(-dev)\n\u003e and the afs servers have no system-config-run job, so converting them\n\u003e is blind - hold them for a manual check, or just leave them until\n\u003e they\u0027re retired? And are host globs fine, or would you rather I opt in\n\u003e existing service groups?\n\nYes, those servers are so old that I think we should avoid converting them. It is difficult to test them and the idea is that we\u0027re letting cacti and translate die on the vine. Storyboard is in a bit more limbo. All that to say I think we should continue to support iptables (rather than nftables) and let those hosts remain iptables only.\n\nI think host globs are fine. That gives us the ability to say convert a single host type first before committing all of the others. ze01.opendev.org first (exact match glob) before converting the rule to ze*.opendev.org as an example.","commit_id":"c94c496a5e7c835447935f994072a0a4995f6ae2"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b547a6f61685b8dc13b63335093554c10f756e65","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"863d66f7_130b1a30","in_reply_to":"a84f08fe_de8bcb44","updated":"2026-08-07 08:01:24.000000000","message":"Agreed on cacti, translate, storyboard and the afs servers - I\u0027ll leave those on iptables and won\u0027t plan a change that removes the iptables path. It stays supported indefinitely.\n\nHost globs it is, and good point on going finer than I\u0027d planned: ze01.opendev.org first, then ze*.opendev.org once it\u0027s had some soak.\n\nI verified the transpile end to end in a container: a pre-existing \"table ip nat\" survives the reload (docker\u0027s masquerade rules were the thing I was worried about), the generated file is byte-identical across runs so it doesn\u0027t reload every play, and the ip6 connlimit set type workaround holds.","commit_id":"c94c496a5e7c835447935f994072a0a4995f6ae2"},{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"647fa28d05bee89df8ac7103a6146fd65379ca22","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":6,"id":"b8c31824_569dfcef","updated":"2026-08-12 06:22:41.000000000","message":"I think the approach in https://review.opendev.org/c/opendev/system-config/+/1000664 might be a bit easier to comprehend instead of having a lot of when: nftables in the iptables role","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"8792fc0e_3051afc1","updated":"2026-08-10 17:34:33.000000000","message":"The general shape here makes sense to me. I\u0027ve left a bunch of inlines comments asking for clarification of behaviors in some places and improvements in others.\n\nOne thing that occurs to me is that we\u0027re not really testing a conversion from iptables to nftables in our tests as the test nodes deploy and get updated from \"scratch\" (there is actually a test specific iptables ruleset similar to our production iptables ruleset but they aren\u0027t identical so we\u0027re testing the conversion from that to nftables).\n\nThis is probably fine to start as we\u0027re likely to only start new nodes on nftables before converting old nodes and we can figure out testing for that later. But I wanted to call it out in case we want to start poking at that sort of testing sooner than later.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"710c0f19_11b8e4ad","in_reply_to":"8792fc0e_3051afc1","updated":"2026-08-17 03:56:11.000000000","message":"Thanks - all five addressed, respun.\n\nOverlapping rulesets: not an error, kernel doesn\u0027t complain. The two stores are independent but a packet traverses both, so it\u0027s most-restrictive-wins. That\u0027s the hazard the legacy cleanup handler exists for; now in the commit message.\n\nHost networking: agreed, which is why \"table ip nat\" has to survive the reload - it carries docker\u0027s masquerade rules.\n\nBad ruleset fallback: already fail-safe. \"nft -c\" fails the task before anything is installed, so the host stays on its existing ruleset - never partial, never none. Reworded, it was ambiguous.\n\nReal conversion testing: agreed. Rather than stretch this change, a follow-up job could deploy with iptables, flip the group and re-run. Worth doing before the first conversion?","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":6,"id":"7fab261b_b3920d17","in_reply_to":"b8c31824_569dfcef","updated":"2026-08-17 03:56:11.000000000","message":"Thanks for the pointer - agreed 1000664\u0027s written template is easier to read than translator output, and its own \"inet openstack\" table is a nice property.\n\nTwo things this change is doing that I\u0027d want to keep either way:\n\n- Conversion safety. Loading a native ruleset doesn\u0027t remove the\n  host\u0027s existing one; both are still traversed, so the old closing\n  REJECT wins. Our CI hit exactly this. 1000664 has no cleanup tasks,\n  and its noble node is built from scratch so the gate can\u0027t see it.\n- Validation. We render a candidate, \"nft -c\" it, and only install on\n  success, so a bad render leaves the host on its current ruleset.\n\nAlso, transpiling rules.v4/v6 keeps one source of truth. A hand-written template needs raw pass-through rules authored twice in both syntaxes - only review.yaml today, but permanently.\n\nOn shape: the opt-in group and the split into small changes came out of Clark\u0027s review on earlier patchsets - the point being that a backend switch should roll out host-by-host rather than fleet-wide, so Phase A is a no-op in production and Phase B is one-line group additions we can stop or revert at any host.\n\nNot either/or: the template could later replace the transpile step inside this opt-in mechanism, keeping the group rollout, the validation gate and the legacy cleanup. Happy to go that way if that\u0027s the preference.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"0d06607832f763bca8e3909cf21b26f02d5e234b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"b6bd8da4_70e77355","updated":"2026-09-16 22:24:10.000000000","message":"I like the approach to testing that has been taken in this change and its parent. In particular we are going to need to run iptables on some systems and nftables on other systems while we transition gradually over time. That means it is important to ensure that we continue to test both approaches to avoid regressing legacy iptables setups while we are still using them.\n\nThat said I like the approach Eric took in https://review.opendev.org/c/opendev/system-config/+/1000664 where we commit to using nftables with a native rather than converted ruleset. We don\u0027t often change these base rulesets and instead simply update open port numbers (usually anyway). What that means is it should be pretty safe to have two distinct rulesets for each system then we can pretty easily ensure they are equivalent by ensuring the ports lists are identical. The upside to Eric\u0027s approach is that we get something we can move forward with from day one and don\u0027t need to eventually migrate further away from. In this example we would need to eventually stop using iptables rulesets as the source of truth.\n\nThe other thing this change does is present a very clear migration path. System is running iptables, gets its rules converted, then starts relying on nftables. I think that path is less clear when we\u0027re just jumping straight to nftables rules, so I think we may need to incorporate some of that planning aspect into Eric\u0027s approach.\n\nAll that to say I think we should use a hybrid between these two setups. Use the fairly complete and robust testing from this change alongside the approach in 1000644 with a proper nftables ruleset from the start.","commit_id":"db15193a17d5b208220032a71c543b0d564c484e"}],"playbooks/roles/iptables/handlers/main.yaml":[{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":5,"context_line":"- name: Reload iptables (Debian)"},{"line_number":6,"context_line":"  command: \u0027{{ reload_command }}\u0027"},{"line_number":7,"context_line":"  when:"},{"line_number":8,"context_line":"    - not iptables_use_nftables"},{"line_number":9,"context_line":"    - not ansible_facts.is_chroot"},{"line_number":10,"context_line":"    - ansible_facts.os_family \u003d\u003d \u0027Debian\u0027"},{"line_number":11,"context_line":"  listen: \"Reload iptables\""}],"source_content_type":"text/x-yaml","patch_set":6,"id":"78394a6f_b177096e","line":8,"updated":"2026-08-10 17:34:33.000000000","message":"We need these conditions here on the handlers because the generic rule file installation tasks in main.yaml notify `Reload iptables`.\n\nRather than split the conditional logic between the main tasks file and the handlers file here can we try to keep all of that in main.yaml as much as possible? This may end up making main.yaml a bit more verbose (duplicate rule management tasks), but I think that will be easier to understand and debug in if the control is more centralized.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":false,"context_lines":[{"line_number":5,"context_line":"- name: Reload iptables (Debian)"},{"line_number":6,"context_line":"  command: \u0027{{ reload_command }}\u0027"},{"line_number":7,"context_line":"  when:"},{"line_number":8,"context_line":"    - not iptables_use_nftables"},{"line_number":9,"context_line":"    - not ansible_facts.is_chroot"},{"line_number":10,"context_line":"    - ansible_facts.os_family \u003d\u003d \u0027Debian\u0027"},{"line_number":11,"context_line":"  listen: \"Reload iptables\""}],"source_content_type":"text/x-yaml","patch_set":6,"id":"0dc20cc3_392abd55","line":8,"in_reply_to":"78394a6f_b177096e","updated":"2026-08-17 03:56:11.000000000","message":"Done - no backend conditionals left in handlers. main.yaml has one\nblock per backend, each notifying its own topic. Rule templates\nduplicated as you expected; nft copies named \"... for transpiling\".\nBonus: job logs now show which backend ran.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":27,"context_line":"  listen: \"Reload iptables\""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"- name: Reload nftables"},{"line_number":30,"context_line":"  command: \u0027nft -f {{ nft_ruleset }}\u0027"},{"line_number":31,"context_line":"  when:"},{"line_number":32,"context_line":"    - not ansible_facts.is_chroot"},{"line_number":33,"context_line":"  listen: \"Reload nftables\""}],"source_content_type":"text/x-yaml","patch_set":6,"id":"bea6db4a_640e83ce","line":30,"updated":"2026-08-10 17:34:33.000000000","message":"This reloads the rules into the running system on the fly. It looks like we\u0027re relying on the nftables service to automatically load the files in /etc/nftables.conf which is why we can uninstall netfilter-persistent. We don\u0027t ensure that service is running/enabled as part of this change. Should we do that?\n\nIt might be a good idea to add a reboot to the base test job before we check rules? That way we can ensure that the rules survive a reboot.\n\nAt that point we\u0027re really starting to optimize that more generic job for iptables/nftables testing at this point. But maybe that is ok since the firewall is a big part of what we want to check on a base installation.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":true,"context_lines":[{"line_number":27,"context_line":"  listen: \"Reload iptables\""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"- name: Reload nftables"},{"line_number":30,"context_line":"  command: \u0027nft -f {{ nft_ruleset }}\u0027"},{"line_number":31,"context_line":"  when:"},{"line_number":32,"context_line":"    - not ansible_facts.is_chroot"},{"line_number":33,"context_line":"  listen: \"Reload nftables\""}],"source_content_type":"text/x-yaml","patch_set":6,"id":"4247e51d_b40dd584","line":30,"in_reply_to":"bea6db4a_640e83ce","updated":"2026-08-17 03:56:11.000000000","message":"Fixed, we only enabled it. Now started too, since with\nnetfilter-persistent gone nothing else loads /etc/nftables.conf at\nboot. RemainAfterExit oneshot, so no per-run reload.\n\nReboot test: agreed it\u0027s the only real proof of persistence, and\nagreed it over-specialises the shared base job - so I\u0027d put it in the\nnftables sibling job instead. Left out here; say the word.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":37,"context_line":"# it: the alternatives priority is 20, against 10 for the nft variant)"},{"line_number":38,"context_line":"# the rules this role installed before the conversion stay in force"},{"line_number":39,"context_line":"# alongside the new ruleset until the host reboots.  That includes"},{"line_number":40,"context_line":"# their closing REJECT, which would drop traffic the new ruleset"},{"line_number":41,"context_line":"# accepts."},{"line_number":42,"context_line":"#"},{"line_number":43,"context_line":"# Remove only the chains this role owns; anything else in that store,"},{"line_number":44,"context_line":"# notably Docker\u0027s, is left alone.  This is ordered after the reload"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"e418c868_b89130c7","line":41,"range":{"start_line":40,"start_character":24,"end_line":41,"end_character":10},"updated":"2026-08-10 17:34:33.000000000","message":"This is only if we change the rulesets to be in conflict with one another before a reboot? Or is there a different situation where we\u0027d drop packets the new ruleset allows?","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"8414cc0c2be6eb1d59684b2c398a2d5aba52ce66","unresolved":false,"context_lines":[{"line_number":37,"context_line":"# it: the alternatives priority is 20, against 10 for the nft variant)"},{"line_number":38,"context_line":"# the rules this role installed before the conversion stay in force"},{"line_number":39,"context_line":"# alongside the new ruleset until the host reboots.  That includes"},{"line_number":40,"context_line":"# their closing REJECT, which would drop traffic the new ruleset"},{"line_number":41,"context_line":"# accepts."},{"line_number":42,"context_line":"#"},{"line_number":43,"context_line":"# Remove only the chains this role owns; anything else in that store,"},{"line_number":44,"context_line":"# notably Docker\u0027s, is left alone.  This is ordered after the reload"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"cb0bc246_3146e80c","line":41,"range":{"start_line":40,"start_character":24,"end_line":41,"end_character":10},"in_reply_to":"7aa7367b_0fe995c4","updated":"2026-09-16 22:19:24.000000000","message":"Acknowledged","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":true,"context_lines":[{"line_number":37,"context_line":"# it: the alternatives priority is 20, against 10 for the nft variant)"},{"line_number":38,"context_line":"# the rules this role installed before the conversion stay in force"},{"line_number":39,"context_line":"# alongside the new ruleset until the host reboots.  That includes"},{"line_number":40,"context_line":"# their closing REJECT, which would drop traffic the new ruleset"},{"line_number":41,"context_line":"# accepts."},{"line_number":42,"context_line":"#"},{"line_number":43,"context_line":"# Remove only the chains this role owns; anything else in that store,"},{"line_number":44,"context_line":"# notably Docker\u0027s, is left alone.  This is ordered after the reload"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"7aa7367b_0fe995c4","line":41,"range":{"start_line":40,"start_character":24,"end_line":41,"end_character":10},"in_reply_to":"e418c868_b89130c7","updated":"2026-08-17 03:56:11.000000000","message":"No conflict needed - that\u0027s what surprised me. Both stores are\ntraversed, so the old closing REJECT drops what the new ruleset\naccepts. It\u0027s how the earlier CI failure surfaced: assertions were\nreading the stale legacy store while the nft ruleset was live.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":47,"context_line":"- name: Remove superseded legacy xtables rules"},{"line_number":48,"context_line":"  shell: |"},{"line_number":49,"context_line":"    set -uo pipefail"},{"line_number":50,"context_line":"    for cmd in iptables-legacy ip6tables-legacy; do"},{"line_number":51,"context_line":"      command -v \"$cmd\" \u003e/dev/null 2\u003e\u00261 || continue"},{"line_number":52,"context_line":"      \"$cmd\" -S 2\u003e/dev/null | grep -q -- \u0027-j openstack-\u0027 || continue"},{"line_number":53,"context_line":"      \"$cmd\" -D INPUT -j openstack-INPUT 2\u003e/dev/null || true"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"8d1f6995_234e3ee7","line":50,"updated":"2026-08-10 17:34:33.000000000","message":"See comment in main.yaml but this is where we run the iptables-legacy commands after uninstalling iptables packages.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":true,"context_lines":[{"line_number":47,"context_line":"- name: Remove superseded legacy xtables rules"},{"line_number":48,"context_line":"  shell: |"},{"line_number":49,"context_line":"    set -uo pipefail"},{"line_number":50,"context_line":"    for cmd in iptables-legacy ip6tables-legacy; do"},{"line_number":51,"context_line":"      command -v \"$cmd\" \u003e/dev/null 2\u003e\u00261 || continue"},{"line_number":52,"context_line":"      \"$cmd\" -S 2\u003e/dev/null | grep -q -- \u0027-j openstack-\u0027 || continue"},{"line_number":53,"context_line":"      \"$cmd\" -D INPUT -j openstack-INPUT 2\u003e/dev/null || true"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"b2725b7d_dcfe5874","line":50,"in_reply_to":"8d1f6995_234e3ee7","updated":"2026-08-17 03:56:11.000000000","message":"Your guess was right - not a problem, but it needed a comment, which it now has in all three places.\n\nWe remove only the boot integration (iptables-persistent, netfilter-persistent, iptables-services). The \"iptables\" package stays - that\u0027s what shpis iptables-restore-translate and the iptables-legacy binaries, so they\u0027re present when handlers run.\n\nChecked on 20.04/24.04: iptables-legacy survives via xtables-legacy-multi. On stream9 it\u0027s absent entirely (RHEL9 dropped legacy), and there\u0027s no legacy store to clean - the \"command -v\" guard covers that.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"}],"playbooks/roles/iptables/tasks/main.yaml":[{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":87,"context_line":"          {"},{"line_number":88,"context_line":"            iptables-restore-translate -f {{ ipv4_rules }}"},{"line_number":89,"context_line":"            ip6tables-restore-translate -f {{ ipv6_rules }} \\"},{"line_number":90,"context_line":"              | sed \u0027s/^\\(add set ip6 .*\\)type ipv4_addr/\\1type ipv6_addr/\u0027"},{"line_number":91,"context_line":"          } | sed \u0027/^#/d\u0027"},{"line_number":92,"context_line":"        } \u003e {{ nft_ruleset }}.new"},{"line_number":93,"context_line":"      args:"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"c303f273_4dd4f242","line":90,"range":{"start_line":90,"start_character":16,"end_line":90,"end_character":75},"updated":"2026-08-10 17:34:33.000000000","message":"I think this sed and the one below probably each deserve a comment here.\n\nThey are explaining in the commit message, but for ease of debugging and understanding having a comment here explaining the purpose (translate the conn limit and remove comments that include timestamps) would be good.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":false,"context_lines":[{"line_number":87,"context_line":"          {"},{"line_number":88,"context_line":"            iptables-restore-translate -f {{ ipv4_rules }}"},{"line_number":89,"context_line":"            ip6tables-restore-translate -f {{ ipv6_rules }} \\"},{"line_number":90,"context_line":"              | sed \u0027s/^\\(add set ip6 .*\\)type ipv4_addr/\\1type ipv6_addr/\u0027"},{"line_number":91,"context_line":"          } | sed \u0027/^#/d\u0027"},{"line_number":92,"context_line":"        } \u003e {{ nft_ruleset }}.new"},{"line_number":93,"context_line":"      args:"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"b004a1c5_d95e0173","line":90,"range":{"start_line":90,"start_character":16,"end_line":90,"end_character":75},"in_reply_to":"c303f273_4dd4f242","updated":"2026-08-17 03:56:11.000000000","message":"Done, both commented at the line.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":111,"context_line":"        mode: 0640"},{"line_number":112,"context_line":"        setype: \u0027{{ setype | default(omit) }}\u0027"},{"line_number":113,"context_line":"      notify:"},{"line_number":114,"context_line":"        - Reload nftables"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"    - name: Remove native ruleset candidate"},{"line_number":117,"context_line":"      file:"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"cb0b3e3a_ccbfbd13","line":114,"updated":"2026-08-10 17:34:33.000000000","message":"This copy should only notify if the file content is changed (I think it checks hashes/checksums). That means we won\u0027t reload the nftables rules on every ansible run (good we want that).\n\nWe will however run the iptables-restore-translate script and validation every single ansible run as well as the rulseet check and the file deletion below. Maybe we can set it up so that we don\u0027t delete the intermediate rules file that we check and then we can run the ruleset check only if the file has updated? That may speed things up slightly and avoid unnecessary work in Ansible.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":false,"context_lines":[{"line_number":111,"context_line":"        mode: 0640"},{"line_number":112,"context_line":"        setype: \u0027{{ setype | default(omit) }}\u0027"},{"line_number":113,"context_line":"      notify:"},{"line_number":114,"context_line":"        - Reload nftables"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"    - name: Remove native ruleset candidate"},{"line_number":117,"context_line":"      file:"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"674401da_8cbafdf5","line":114,"in_reply_to":"cb0b3e3a_ccbfbd13","updated":"2026-08-17 03:56:11.000000000","message":"Done. Candidate is kept, and a cmp gates the validation so \"nft -c\" only runs when the rules changed. Verified all three cases: first run validates and installs, unchanged run skips and doesn\u0027t notify, changed run validates again. Added a umask since the candidate now persists - it was landing 0644.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":136,"context_line":"      paths:"},{"line_number":137,"context_line":"        - \u0027tasks/nftables\u0027"},{"line_number":138,"context_line":"  loop: \"{{ query(\u0027first_found\u0027, params, errors\u003d\u0027ignore\u0027) }}\""},{"line_number":139,"context_line":"  when: iptables_use_nftables"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"- name: Enable firewall service"},{"line_number":142,"context_line":"  service:"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"67c70916_068374e9","line":139,"updated":"2026-08-10 17:34:33.000000000","message":"This comment really spans content in ~3 locations, but I\u0027m going to do my best to capture the main thought here then leave breadcrumbs in the other locations.\n\nIs this an order of operations problem? We are using these distro specific nftables tasks to uninstall iptables packages. Then in the handlers file we\u0027re using iptables-legacy and ip6tables-legacy to clean up rules in the old iptables ruleset. Ansible handlers always run after all tasks are complete so will those commands be present anymore?","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":false,"context_lines":[{"line_number":136,"context_line":"      paths:"},{"line_number":137,"context_line":"        - \u0027tasks/nftables\u0027"},{"line_number":138,"context_line":"  loop: \"{{ query(\u0027first_found\u0027, params, errors\u003d\u0027ignore\u0027) }}\""},{"line_number":139,"context_line":"  when: iptables_use_nftables"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"- name: Enable firewall service"},{"line_number":142,"context_line":"  service:"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"628e8add_2fa8a8e7","line":139,"in_reply_to":"67c70916_068374e9","updated":"2026-08-17 03:56:11.000000000","message":"Good question, and I had to check rather than guess. It isn\u0027t an ordering problem, because we never uninstall the thing that provides those commands.\n\nThe distro tasks remove only the boot integration - iptables-persistent, netfilter-persistent, iptables-services. The `iptables` package itself is deliberately retained, and that is what ships the iptables-legacy / ip6tables-legacy binaries (via xtables-legacy-multi) as well as iptables-restore-translate. So when the handlers run at the end of the play, the commands are still there.\n\nVerified on 20.04 and 24.04: after removing the persistent packages, both legacy binaries are still present. On stream9 they are absent entirely - RHEL9 dropped legacy xtables - but there is also no legacy store to clean, and the `command -v ... || continue` guard makes the handler a no-op there. There are no RedHat-family hosts in the inventory today in any case.\n\nCommented in all three locations you flagged.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"}],"playbooks/roles/iptables/tasks/nftables/Debian.yaml":[{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":8,"context_line":"- name: Remove legacy iptables-persistent packages"},{"line_number":9,"context_line":"  package:"},{"line_number":10,"context_line":"    name:"},{"line_number":11,"context_line":"      - iptables-persistent"},{"line_number":12,"context_line":"      - netfilter-persistent"},{"line_number":13,"context_line":"    state: absent"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"ffdbf8cd_142ad827","line":11,"updated":"2026-08-10 17:34:33.000000000","message":"See comment in main.yaml, but this is where we\u0027re removing iptables packaging. Does that create a problem when running `iptables-legacy` commands?","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":false,"context_lines":[{"line_number":8,"context_line":"- name: Remove legacy iptables-persistent packages"},{"line_number":9,"context_line":"  package:"},{"line_number":10,"context_line":"    name:"},{"line_number":11,"context_line":"      - iptables-persistent"},{"line_number":12,"context_line":"      - netfilter-persistent"},{"line_number":13,"context_line":"    state: absent"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"bffed5ca_572602d7","line":11,"in_reply_to":"ffdbf8cd_142ad827","updated":"2026-08-17 03:56:11.000000000","message":"No - we only remove the boot integration here, not the `iptables` package, so the legacy binaries stay. Full answer on main.yaml L139; comment added here too.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"}],"playbooks/roles/iptables/vars/nftables/Debian.yaml":[{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"345651d197054ff1a8c37a6abcd5b142a909ec84","unresolved":true,"context_lines":[{"line_number":3,"context_line":"  # The iptables userspace package ships"},{"line_number":4,"context_line":"  # iptables-restore-translate, used only to transpile the rendered"},{"line_number":5,"context_line":"  # rules.  It is not the runtime firewall backend here."},{"line_number":6,"context_line":"  - iptables"},{"line_number":7,"context_line":"service_name: nftables"},{"line_number":8,"context_line":"rules_dir: /etc/nftables"},{"line_number":9,"context_line":"ipv4_rules: /etc/nftables/rules.v4"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"3b4b13c1_5953c16e","line":6,"updated":"2026-08-10 17:34:33.000000000","message":"See comment in main.yaml but maybe the iptables package is all we need to have `iptables-legacy` installed?","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"},{"author":{"_account_id":10089,"name":"Anil Shashikumar Belur","email":"abelur@linuxfoundation.org","username":"askb"},"change_message_id":"b9fd97ee1b19a6ae50e24f47d0e09acf1fde5112","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  # The iptables userspace package ships"},{"line_number":4,"context_line":"  # iptables-restore-translate, used only to transpile the rendered"},{"line_number":5,"context_line":"  # rules.  It is not the runtime firewall backend here."},{"line_number":6,"context_line":"  - iptables"},{"line_number":7,"context_line":"service_name: nftables"},{"line_number":8,"context_line":"rules_dir: /etc/nftables"},{"line_number":9,"context_line":"ipv4_rules: /etc/nftables/rules.v4"}],"source_content_type":"text/x-yaml","patch_set":6,"id":"cba42a13_9341bcf0","line":6,"in_reply_to":"3b4b13c1_5953c16e","updated":"2026-08-17 03:56:11.000000000","message":"Yes, exactly - the `iptables` package is all that\u0027s needed, which is why it is kept out of the removal list. That wasn\u0027t obvious from reading it, so it now says so in a comment. Details on main.yaml L139.","commit_id":"84f219f7f3eab7516d68f53a6cab2dec7a62b8c3"}]}