{"record":{"id":"14f41d03ce33f894","repo":"istio/istio","slug":"failed-to-wait-for-resource-v","errorCode":null,"errorMessage":"failed to wait for resource: %v","messagePattern":"failed to wait for resource: (.+?)","errorType":"exception","errorClass":null,"httpStatus":null,"severity":"error","filePath":"operator/pkg/install/install.go","lineNumber":185,"sourceCode":"\tmanifests := manifestSet.Manifests\n\n\tplog := i.ProgressLogger.NewComponent(cname)\n\n\tfor _, obj := range manifests {\n\t\tobj, err := i.applyLabelsAndAnnotations(obj, cname)\n\t\tif err != nil {\n\t\t\treturn err\n\t\t}\n\t\tif err := i.serverSideApply(obj); err != nil {\n\t\t\tplog.ReportError(err.Error())\n\t\t\treturn err\n\t\t}\n\t\tplog.ReportProgress()\n\t}\n\n\tif !i.SkipWait {\n\t\tif err := WaitForResources(manifests, i.Kube, i.WaitTimeout, i.DryRun, plog); err != nil {\n\t\t\twerr := fmt.Errorf(\"failed to wait for resource: %v\", err)\n\t\t\tplog.ReportError(werr.Error())\n\t\t\treturn werr\n\t\t}\n\t}\n\tplog.ReportFinished()\n\treturn nil\n}\n\n// serverSideApply creates or updates an object in the API server depending on whether it already exists.\nfunc (i Installer) serverSideApply(obj manifest.Manifest) error {\n\tconst fieldOwnerOperator = \"istio-operator\"\n\tdc, err := i.Kube.DynamicClientFor(obj.GroupVersionKind(), obj.Unstructured, \"\")\n\tif err != nil {\n\t\treturn err\n\t}\n\tobjectStr := fmt.Sprintf(\"%s/%s/%s\", obj.GetKind(), obj.GetNamespace(), obj.GetName())\n\tvar dryRun []string\n\t// TODO: can we do this a server-side dry run? it doesn't work well if the namespace is not already created","sourceCodeStart":167,"sourceCodeEnd":203,"githubUrl":"https://github.com/istio/istio/blob/8dc789c5cf17517c64e3c36cb3288230f149dfae/operator/pkg/install/install.go#L167-L203","documentation":"After applying a component's manifests, WaitForResources (skipped only when SkipWait is set) failed within i.WaitTimeout and the installer wraps it as \"failed to wait for resource\" and reports it to the progress logger. The underlying wait error identifies resources that never reached ready, such as deployments whose pods stay pending.","triggerScenarios":"Pods unschedulable (insufficient CPU/memory, taints), image pull failures, crashlooping containers, or a WaitTimeout shorter than the cluster needs to roll everything out.","commonSituations":"Resource-constrained clusters; wrong image registry or credentials; slow CI clusters against default timeouts.","solutions":["Inspect the unready resources from the error and their pods' events with kubectl describe","Fix the root cause: quotas, image refs, tolerations, resource requests","Increase the wait timeout for slow clusters","Re-run the install after remediation"],"exampleFix":null,"handlingStrategy":"retry","validationCode":null,"typeGuard":null,"tryCatchPattern":"for attempt := 0; attempt < 2; attempt++ {\n\terr := installer.InstallManifests(manifestSets)\n\tif err == nil {\n\t\tbreak\n\t}\n\tif !strings.Contains(err.Error(), \"failed to wait for resource\") {\n\t\treturn err\n\t}\n\t// inspect pods, fix quota/image/scheduling, then retry with a longer timeout\n\tinstaller.WaitTimeout *= 2\n}","preventionTips":["Set generous wait timeouts on slow clusters","Pre-pull istiod and proxyv2 images on nodes","Check ResourceQuota and LimitRange before install","Watch the progress log to catch slow components early"],"tags":["wait","timeout","kubernetes","install","istio-operator"],"backgroundTag":null,"analyzedSha":"8dc789c5cf17517c64e3c36cb3288230f149dfae","analyzedAt":"2026-08-15T15:16:55.434Z","schemaVersion":2},"datasetVersion":"2026-08-15T22:17:37.221Z"}