kubernetes/kubernetes

Distribute debugging symbols for every binary in a Kubernetes release

Open

#73,986 opened on Feb 13, 2019

View on GitHub
 (21 comments) (8 reactions) (0 assignees)Go (43,066 forks)batch import
help wantedkind/featurelifecycle/frozenneeds-triagesig/release

Repository metrics

Stars
 (122,268 stars)
PR merge metrics
 (Avg merge 28d 17h) (343 merged PRs in 30d)

Description

What would you like to be added: Distribute the debugging symbols generated when building every binary (e.g. kube-apiserver, kube-scheduler, kube-controller-manager, etc) in a Kubernetes release.

Why is this needed: To allow debugging of official Kubernetes binaries "in situ," i.e., in a cluster that is already deployed. Currently, end users who want to debug "in situ" have to build and distribute their own binaries. End users who choose to use (or are forced to use) official Kubernetes binaries are unable to debug "in situ."

Delve, the de facto go debugger, added support in November 2018 for reading debug symbols from external files. And GDB has had support for longer.

Contributor guide

Research direction
Investigate the Kubernetes release build process to understand how binaries are built and where debug symbols can be attached. Look into existing support for external debug symbols in Go (Delve and GDB) and plan the integration.
Tech stack
go
Domain
infrastructurebackend
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
Over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GoGit
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
45