Bug 2304176

Summary:	Netavark Nftables Default
Product:	[Fedora] Fedora	Reporter:	Aoife Moloney <amoloney>
Component:	Changes Tracking	Assignee:	Matthew Heon <mheon>
Status:	ON_QA ---	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	mheon
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2233686

Description Aoife Moloney 2024-08-12 17:42:41 UTC

This is a tracking bug for Change: Netavark Nftables Default
For more details, see: https://fedoraproject.org/wiki/Changes/NetavarkNftablesDefault

Netavark should use nftables by default to create/manage the firewall rules for the Podman containers.

If you encounter a bug related to this Change, please do not comment here. Instead create a new bug and set it to block this bug.

Comment 1 Aoife Moloney 2024-08-22 12:32:27 UTC

Hi Matthew, could you provide a status update on this change please? Changes need to be code complete before we enter beta freeze next Tuesday 27th August. Are you still on track to land this in F41, or do you need to defer to F42? 

Thanks,
Aoife

Comment 2 Matthew Heon 2024-08-22 13:33:24 UTC

The change is complete as of Netavark v1.12, released several weeks ago. Default firewall driver is now conditionally compiled based on Fedora version, with 41 and above receiving the new nftables default. We are starting to receive issues upstream (e.g. https://github.com/containers/netavark/issues/1054 - not our fault, custom kernel config from a hosted Gitlab runner that doesn't have nftables modules loaded by default) from folks using Rawhide, so we are confident the change was successful.

Not having handled a change request in previously, I am assuming that I should move this ticket to a new state, but am unsure what is appropriate given this. Is this considered closed?

Comment 3 Aoife Moloney 2024-08-22 14:22:49 UTC

I think the best state is ON_QA, and thank you for getting back to me so quick, its much appreciated. Ill move the state now and I'll note this info in the changes report I need to submit to FESCo on Tuesday when we enter Beta freeze that this is in good shape.

Thanks again!