Bug 2008949

Summary: Multiple storage pods are missing spec.priorityClassName
Product: Container Native Virtualization (CNV) Reporter: Debarati Basu-Nag <dbasunag>
Component: StorageAssignee: Alexander Wels <awels>
Status: CLOSED ERRATA QA Contact: dalia <dafrank>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.10.0CC: awels, cnv-qe-bugs, mrashish, ngavrilo, yadu
Target Milestone: ---   
Target Release: 4.10.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: CNV v4.10.0-201 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-03-16 15:56:11 UTC Type: Bug
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: 1992231    
Bug Blocks:    
Attachments:
Description Flags
hostpath provisioner pod output none

Description Debarati Basu-Nag 2021-09-29 14:36:49 UTC
Created attachment 1827370 [details]
hostpath provisioner pod output

Description of problem: Following storage pods are missing spec.priorityClassName:
1) cdi-operator, 2) hostpath-provisioner-operator,


Version-Release number of selected component (if applicable):
(cnv-tests) [cnv-qe-jenkins@iuo-tier2-410-l84zw-executor cnv-tests]$ oc version
Client Version: 4.10.0-202109212120.p0.git.538ee42.assembly.stream-538ee42
Server Version: 4.10.0-0.nightly-2021-09-26-233013
Kubernetes Version: v1.22.1+d156476
CNV version: v4.10.0-142

How reproducible:
Consistently

Steps to Reproduce:
1. run "kubectl get pod -n openshift-cnv <pod_name> -o yaml"
2. Check if spec.priorityClassName exists
3.

Actual results:
missing spec.priorityClassName

Expected results:
It should be present with a valid value

Additional info:
Will attach output of "kubectl get pod -n openshift-cnv <pod_name> -o yaml"

Comment 3 Debarati Basu-Nag 2021-10-20 23:21:51 UTC
Validated against 4.10.0-221

Except for hostpath-provisioner pod, I am able to see spec.priorityClass for all storage pod. Please let me know if that would be fixed against this bug or should I open a separate bug for the same:
================
dnsPolicy: ClusterFirst
  enableServiceLinks: true
  imagePullSecrets:
  - name: hostpath-provisioner-admin-dockercfg-st4tw
  nodeName: c01-dbn1-410-csjcg-worker-0-m4qwv
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: hostpath-provisioner-admin
  serviceAccountName: hostpath-provisioner-admin
  terminationGracePeriodSeconds: 30
  tolerations:
=================

Comment 4 dalia 2021-10-21 16:11:31 UTC
On: v4.10.0-221
verified cdi-operator + hostpath-provisioner-operator have priority class name

can't verify priorityClassName for hostpath-provisioner control plane pod -  blocked by this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1992231

Comment 5 Alexander Wels 2021-10-29 12:03:51 UTC
So I don't think we set a priority class on the actual hostpath-provisioner pod. We probably should. Yes the other bug is preventing the hpp from coming up in 4.10, so you cannot verify any fixes that would be made right now.

Comment 6 dalia 2021-11-29 15:17:22 UTC
$ oc get pod hostpath-provisioner-operator-*** -n openshift-cnv -oyaml| grep priority
  priority: 1000000000
  priorityClassName: kubevirt-cluster-critical

$ oc get pod -n openshift-cnv cdi-operator-*** -oyaml| grep priority
  priority: 1000000000
  priorityClassName: kubevirt-cluster-critical

verified on:
CDI v1.41.0
CNV 4.10


At the moment hpp workers won't have priority class set, this might be changed in the future.

Comment 11 errata-xmlrpc 2022-03-16 15:56:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Virtualization 4.10.0 Images security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:0947