Template:

Networking Definition of Planned

Epic Template descriptions and documentation 

Epic Goal

• OCP needs to detect when customer workloads are making use of iptables, and present this information to the customer (e.g. via alerts, metrics, insights, etc)
• The RHEL 9 kernel logs a warning if iptables is used at any point anywhere in the system, but this is not helpful because OCP itself still uses iptables, so the warning is always logged.
• We need to avoid false positives due to OCP's own use of iptables in pod namespaces (e.g. the rules to block access to the MCS). Porting those rules to nftables sooner rather than later is one solution.

Why is this important?

• iptables will not exist in RHEL 10, so if customers are depending on it, they need to be warned.
• Contrariwise, we are getting questions from customers who are not using iptables in their own workload containers, who are confused about the kernel warning. Clearer messaging should help reduce confusion here.

Planning Done Checklist

The following items must be completed on the Epic prior to moving the Epic from Planning to the ToDo status

• Priority+ is set by engineering
• Epic must be Linked to a +Parent Feature
• Target version+ must be set
• Assignee+ must be set
• (Enhancement Proposal is Implementable
• (No outstanding questions about major work breakdown
• (Are all Stakeholders known? Have they all been notified about this item?
• Does this epic affect SD? {}Have they been notified{+}? (View plan definition for current suggested assignee)

Additional information on each of the above items can be found here: Networking Definition of Planned

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement
  details and documents.

...

Dependencies (internal and external)

1.

...