skyhook-io/radar

Summary Radar's pod file browser can already browse, preview (size-limited text, #1581 / #1711) and download files from a container. This issue adds dedicated file-write actions: Upload a file from your machine into the directory you're browsing. Edit a small text file in place and save it back. Writing into a running workload needs more care than reading, so most of this issue is about the guarantees an implementation must keep to be safe and predictable. We'd welcome this as two PRs, upload first. Please comment before starting so we can agree on the approach. Where things live today Piece Location List / download / preview handlers internal/server/copy.go (handlePodFileList, handlePodFileDownload, handlePodFilePreview; preview cap podFilePreviewByteCap = 1 MiB) Routes internal/server/server.go. Download and the desktop files/save live outside the 60s timeout group; list and preview are inside it Exec plumbing startPodFileExec, executorFor in copy.go, and pkg/remotecomma

Moved from discussion #1765. Thanks @Svm1905 for the clear diagnosis there. Summary The Traffic view doesn't detect Istio when the istiod control plane uses a revisioned Deployment name such as istiod-1-30-1, the standard pattern for Istio canary / revision-based upgrades. The mesh is healthy and istio_requests_total is in Prometheus, but Radar reports Istio as not detected and recommends installing Caretta instead. Cause IstioSource.Detect() in internal/traffic/istio.go looks for istiod by an exact Deployment name across a fixed list of namespaces: const istiodName = "istiod" var istioNamespaces = []string{"istio-system", "istio", "default"} ... deploy, err := s.k8sClient.AppsV1().Deployments(ns).Get(ctx, istiodName, metav1.GetOptions{}) On a revisioned install that Get returns NotFound in every namespace, so the source ends up Available: false. Downstream, the Istio branch of generateRecommendation (internal/traffic/manager.go) only fires for a detected source, so the user falls thro

Summary Some users can use Kubernetes resources in a few namespaces but aren't allowed to list namespaces. This is common in multi-tenant clusters, where tenants deliberately can't see each other's namespaces. For these users Radar can't discover which namespaces exist, so the namespace picker shows a short list, often just one entry. Radar already supports the fix: pass the namespaces explicitly with --namespaces or in ~/.radar/config.json. But the picker never says so. Worse, the text it does show points users in the wrong direction. This issue is about making the picker explain what's happening and how to fix it. Background: #1707. The reporter hit exactly this and only found the workaround after asking. When this happens The backend reports the list of pickable namespaces as authoritative: false whenever the user can't list namespaces cluster-wide (see NamespaceScopeResponse in internal/server/namespace_scope.go). The picker then shows: only the kubeconfig context's namespace, plu

Describe the bug Pod logs panel opens always with dark mode, even if application with white theme. To reproduce Steps to reproduce the behavior: Run radar with white style Click on any pod, click logs See error: logs panel gonna be black style Expected behavior if radar runs with white theme, logs panel also should opens with white style. Screenshots Radar version: [1.14.0]

Problem statement Kubernetes 1.34 promoted Pod-level resource specification (PodLevelResources feature gate) to Beta, enabled by default. It lets a Pod define spec.resources.requests / spec.resources.limits as an aggregate budget for all its containers, instead of (or in addition to) per-container containers[].resources. A container without its own resources block doesn't run unbounded — it shares the Pod's aggregate budget. Radar currently appears to read/display resource requests and limits only from containers[].resources. Pods that rely on the pod-level field show up as if no requests/limits were configured at all (resource/topology views, any "missing limits" health check), even though the API server enforces real values for them. Feature request Read pod.spec.resources (requests/limits) in addition to containers[].resources wherever Radar surfaces resource requests/limits (resource browser, topology view, audits/health checks). When a container has no explicit resources but th