Uploaded image for project: 'Cloud Infrastructure Security & Compliance'
  1. Cloud Infrastructure Security & Compliance
  2. CMP-1158

Define PriorityClass in ComplianceSuite to have pods run with a specific PriorityClass

    XMLWordPrintable

Details

    • Define PriorityClass in ComplianceSuite to have pods run with a specific PriorityClass
    • False
    • False
    • Green
    • To Do
    • Impediment
    • 100
    • 100% 100%

    Description

      Epic Goal

      • The goal of this epic is add ability to set PriorityClass on pod for Compliance Operator.

      Why is this important?

      • When heavily using Pod Priority and Preemption for automated scaling and the default PriorityClass is too low to guarantee pods to run then scans are not executed and reports are missing. Since the Compliance Operator is important for ensuring compliance, we should give administrators the ability to associate a PriorityClass to the operator. This will ensure the compliance operator is prioritized and minimizes the chance that the cluster will fall out of compliance because the compliance-operator wasn’t running.

      Scenarios

      • As an OpenShift administrator, I'm trying to use the compliance operator to get my cluster compliant, when my cluster is opt to use Pod Priority I want to set Pod Priority with a high priority in ScanSetting for Compliance Operator so that required compliance won't be disrupted.
      • As an OpenShift administrator, I want to be able to associate a PriorityClass to the compliance-operator that applies to pods performing scans

      Acceptance Criteria

      • Updated ScanSetting CRD to have the option to which PriorityClass scan pod will use
      • All Compliance Operator scanning pod must be launched with PriorityClass set in ScanSetting
      • Add documentation regarding CRD changes as well the usage of this feature
      • Include end-to-end testing that ensures the compliance-operator is configured to use a higher priority PriorityClass and that the resulting pods have the associated PriorityClass
      • Include end-to-end testing that ensures the compliance-operator is configured to use a lower priority PriorityClass and that the resulting pods have the associated PriorityClass

      Documentation needs

      Under Compliance Operator scans, add the following to:[ https://docs.openshift.com/container-platform/4.10/security/compliance_operator/compliance-scans.html#running-compliance-scans_compliance-operator-scans|https://docs.openshift.com/container-platform/4.10/security/compliance_operator/compliance-scans.html#running-compliance-scans_compliance-operator-scans]

      How to use PriorityClass in ScanSetting.

      More documentation can be supplied once the implementation plan has been decided.

      Documentation should include, but isn’t limited to the following:

      • The use cases for when an administrator would want to use PriorityClass for scan pods (the scan must always run, or the scan can be skipped if resources are constrained and priority must be given to the workload pods)
      • Configuration settings and usage
      • Default behavior for users who don’t create PriorityClasses or associate them to the compliance-operator

      QE needs

      We want to verify Compliance Operator is able to launch scanning pod based on Pod Priority set in ScanSetting

      A proposed test is as follows:

      • In a clean cluster, install the compliance-operator
      • Set PriorityClass reference in default ScanSetting
      • Run a scan for the moderate profile without applying remediations. This will be a Node scan and a Platform scan.
      • Verify that all the pods related to scan have correct PriorityClass that was set in ScanSetting.

      Dependencies (internal and external)

      • NA

      Previous Work (Optional):

      • NA

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

      Attachments

        Issue Links

          Activity

            People

              wenshen@redhat.com Vincent Shen
              rhn-support-sreber Simon Reber
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: