Uploaded image for project: 'OpenShift SDN'
  1. OpenShift SDN
  2. SDN-4114

Detect and warn about customer use of iptables

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Critical Critical
    • openshift-4.16
    • None
    • None
    • customer iptables deprecation
    • False
    • None
    • False
    • Yellow
    • To Do
    • OCPSTRAT-873 - Deprecation of iptables in OpenShift [Phase 1]
    • OCPSTRAT-873Deprecation of iptables in OpenShift [Phase 1]
    • 0% To Do, 0% In Progress, 100% Done
    • M
    • Hide

      [QE] May 28, 2024 - e2e testing automation done, all QE test tasks done for this epic

      [QE] Apr 25, 2024 - pre-merge testing done

      [QE] Apr 11, 2024 - pre-merge testing, basic functionality works

      [QE] Mar 27, 2024 - No QE stories planned in Sprint 251

      [QE] Mar 07, 2024 - No QE stories are planned in current Sprint 250.

      Show
      [QE] May 28, 2024 - e2e testing automation done, all QE test tasks done for this epic [QE] Apr 25, 2024 - pre-merge testing done [QE] Apr 11, 2024 - pre-merge testing, basic functionality works [QE] Mar 27, 2024 - No QE stories planned in Sprint 251 [QE] Mar 07, 2024 - No QE stories are planned in current Sprint 250.
    • ---
    • 0
    • 0

      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.

      ...

       

            dwinship@redhat.com Dan Winship
            dwinship@redhat.com Dan Winship
            Qiong Wang Qiong Wang
            Joe Aldinger Joe Aldinger
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: