Description of problem: Bootstrap kube-apiserver audit log path does not set hostPath volume Version-Release number of selected component (if applicable): 4.4.0-0.nightly-2020-02-24-011137 How reproducible: Always Steps to Reproduce: 1. When env is being installed, go to the cloud console to get the bootstrap VM IP 2. ssh to the bootstrap VM, then check: [root@xxia24-b27l5-bootstrap ~]# cd /opt/openshift/ [root@xxia24-b27l5-bootstrap openshift]# cat kube-apiserver-bootstrap/config ... auditConfig: auditFilePath: /var/log/kube-apiserver/audit.log enabled: true ... [root@xxia24-b27l5-bootstrap openshift]# cat kube-apiserver-bootstrap/bootstrap-manifests/kube-apiserver-pod.yaml ... volumes: - hostPath: path: /etc/kubernetes/bootstrap-secrets name: secrets - hostPath: path: /etc/kubernetes/cloud name: etc-kubernetes-cloud - hostPath: path: /etc/kubernetes/bootstrap-configs name: config - hostPath: path: /etc/ssl/certs name: ssl-certs-host - hostPath: path: /var/log/bootstrap-control-plane name: logs ... Actual results: 2. Bootstrap kube-apiserver audit log path "/var/log/kube-apiserver/audit.log" does not set hostPath volume. This will make the bootstrap kube-apiserver audit log gone once the bootstrap kube-apiserver exits. May bring inconvenience for debugging bootstrap kube-apiserver related issue Expected results: 2. Bootstrap kube-apiserver audit log path sets hostPath volume
This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're marking this bug as "LifecycleStale" and decreasing severity from "medium" to "low". If you have further information on the current state of the bug, please update it, otherwise this bug will be automatically closed in 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Verified in 4.5.0-0.nightly-2020-06-05-021159: On the bootstrap host, checked: # cat kube-apiserver-bootstrap/bootstrap-manifests/kube-apiserver-pod.yaml ... volumeMounts: - mountPath: /etc/ssl/certs name: ssl-certs-host readOnly: true - mountPath: /etc/kubernetes/secrets name: secrets readOnly: true - mountPath: /etc/kubernetes/cloud name: etc-kubernetes-cloud readOnly: true - mountPath: /etc/kubernetes/config name: config readOnly: true - mountPath: /var/log/bootstrap-control-plane name: logs - mountPath: /var/log/kube-apiserver name: audit-dir ... volumes: - hostPath: path: /etc/kubernetes/bootstrap-secrets name: secrets - hostPath: path: /etc/kubernetes/cloud name: etc-kubernetes-cloud - hostPath: path: /etc/kubernetes/bootstrap-configs name: config - hostPath: path: /etc/ssl/certs name: ssl-certs-host - hostPath: path: /var/log/bootstrap-control-plane name: logs - hostPath: path: /var/log/kube-apiserver name: audit-dir The audit path /var/log/kube-apiserver is mounted using hostPath. And it can be accessed successfully: # vi /var/log/kube-apiserver/audit.log # can be opened
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 (OpenShift Container Platform 4.5 image release advisory), 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/RHBA-2020:2409