Bug 1427289

Summary: Multiple containers in single pod mix logs in web view
Product: OpenShift Container Platform Reporter: Will Gordon <wgordon>
Component: Management ConsoleAssignee: Samuel Padgett <spadgett>
Status: CLOSED ERRATA QA Contact: Yadan Pei <yapei>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.5.0CC: aos-bugs, bleanhar, jforrest, jokerman, mmccomas, pruan, spadgett, tdawson, xiaocwan, yanpzhan
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
When viewing logs for a pod with multiple containers in the web console, it was possible for log output from more than one container to mix together after switching the selected container a few times. The issue has been fixed. The logs now only contain content for the selected container.
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-12 19:13:55 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:

Description Will Gordon 2017-02-27 19:29:29 UTC
Description of problem:
Launching the following pod:
apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-1
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-2
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}


When viewing the logs from the web console, and selecting "count-log-1" or "count-log-2", and then selecting another container causes the logs to "bleed" into the other views (I'm guessing the original websocket just never closes, so now both websockets just write into the same window)

Version-Release number of selected component (if applicable):
OpenShift Master: v3.3.1.3
Kubernetes Master: v1.3.0+52492b4

How reproducible:
always

Steps to Reproduce:
1. oc create -f https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master/docs/user-guide/logging/examples/two-files-counter-pod-streaming-sidecar.yaml
2. View logs tab for pod in web console
3. Toggle between "count-log-1" and then back to "count".

Actual results:
The logs from "count-log-1" continue to show in "count"

Expected results:
"count" should remain empty

Additional info:

Comment 2 openshift-github-bot 2017-03-01 00:24:20 UTC
Commit pushed to master at https://github.com/openshift/origin-web-console

https://github.com/openshift/origin-web-console/commit/12803823e767b0302dea97babbeca3f874207a76
Bug 1427289 - Fix log updates when switching containers

The `onClose` callback for log streamers happens asynchronously. Make
sure the `onClose` cleanup happens before we begin streaming the next
container log.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1427289

Comment 3 Troy Dawson 2017-03-01 22:54:45 UTC
This has been merged into ocp and is in OCP v3.5.0.37 or newer.

Comment 4 Yanping Zhang 2017-03-02 10:10:57 UTC
Reproduced the bug on OCP v3.5.0.34.
Checked on OCP v3.5.0.37, logs for different containers of a pod can be shown correctly now.

Comment 6 XiaochuanWang 2017-03-03 01:37:35 UTC
Verified on OCP v3.5.0.37
The logs from "count-log-1" and "count" show different content respectively.

Comment 9 errata-xmlrpc 2017-04-12 19:13:55 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, 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-2017:0884