Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-8555

Do not strip kube-* binaries on the hyperkube image

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • None
    • API, Node, workload
    • None
    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      1. Proposed title of this feature request

      Do not strip kube-* binaries on the hyperkube image.

      2. What is the nature and description of the request?

      Both the kubelet binary deployed on RHCOS and the kube-apiserver, kube-controller-manager and kube-scheduler included in the hyperkube image (and deployed in OCP clusters) are stripped, so they don't include debug symbols.

      We would like to either have the binaries built with debug symbols (like the rest of OpenShift binaries) or debug symbols to be provided separately for core dump analysis.

      3. Why does the customer need this? (List the business requirements here)

      Core dump analysis is sometimes a crucial tool to understand what is causing a bug. Being able to request one to the customer right at the moment when they have an issue is very valuable.

      For this reason, some time ago, it was decided to not stripe debug symbols from openshift built binaries. However, as hyperkube binaries seem to use some different build machinery, it was left out from this improvement.

      4. List any affected packages or components.

      kubelet, kube-apiserver, kube-scheduler, kube-controller-manager

              racedoro@redhat.com Ramon Acedo
              rhn-support-palonsor Pablo Alonso Rodriguez
              None
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                None
                None