Uploaded image for project: 'OpenShift Workloads'
  1. OpenShift Workloads
  2. WRKLDS-1189

Drop DS openshift default project node selector patch

XMLWordPrintable

    • Drop DS openshift default project node selector patch
    • False
    • None
    • False
    • Not Selected
    • To Do
    • 100% To Do, 0% In Progress, 0% Done
    • XS

      Epic Goal*

      A carry patch was introduced long time ago (at times where DaemonSets were responsible for assigning their pods to nodes and knowingly bypassing the kube-scheduler) to protect the DS controller against a hot loop:
      1. DS creates a pod for every node including those forbidden by the openshift project selector
      2. openshift admission plugin rejects the newly created DS pod since the assigned nodename does not match the project selector
      3. the rejected pod fails
      4. the ds controller reconciles and creates a new ds pod for the same node that the admission plugin rejected

      The patch is part of https://github.com/openshift/origin/commit/f74ad818d0959db680dd660f1b4050ea748da9f4

      Why is this important? (mandatory)

      The DS controller no longer directly schedules pods. Instead, the controller sets a node affinity term targeting a specific node. Thus, the admission plugin no longer rejects the pod since the DS pods does not set its nodename. Thus, the patch can be dropped. Dropping the patch reduces the number of carried patches.

      > What are the benefits to the customer or Red Hat?   Does it improve security, performance, supportability, etc?  Why is work a priority?

      Low priority. Makes the kubernetes rebase a little bit easier.
       
      Scenarios (mandatory) 

      No new scenarios. The DS controller will newly create DS pods even for nodes that do not patch the project selector. However, these pods will stay in Pending state indefinitely. This is not a new behavior. The upstream node selector leads to the same scenario.
       
      Dependencies (internal and external) (mandatory)

      No dependencies.

      Contributing Teams(and contacts) (mandatory) 

      Our expectation is that teams would modify the list below to fit the epic. Some epics may not need all the default groups but what is included here should accurately reflect who will be involved in delivering the epic.

      • Development - workloads team
      • Documentation - no documentation, no release notes
      • QE - workloads qe team
      • PX - no PX
      • Others - no

      Acceptance Criteria (optional)

      The patch is gone.

      Drawbacks or Risk (optional)

      Potentially more pods in Pending state.

      Done - Checklist (mandatory)

      The following points apply to all epics and are what the OpenShift team believes are the minimum set of criteria that epics should meet for us to consider them potentially shippable. We request that epic owners modify this list to reflect the work to be completed in order to produce something that is potentially shippable.

      • CI Testing -  current e2e tests passing
      • Documentation - no changes
      • QE - Some test scenarios might get altered
      • Technical Enablement - No slides
      • Engineering Stories Merged
      • All associated work items with the Epic are closed
      • Epic status should be “Release Pending” 

              Unassigned Unassigned
              jchaloup@redhat.com Jan Chaloupka
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: