kubernetes/kops · error
building %s: %v
Error message
building %s: %v
What it means
The nodeup loader runs each NodeupModelBuilder's Build() to produce the task map. If any builder returns an error, Build wraps it with the builder's reflect.TypeOf name so you know which model builder failed. This is a generic aggregator — the root cause is inside the named builder's error text.
Source
Thrown at upup/pkg/fi/nodeup/loader.go:39
"reflect"
"k8s.io/kops/upup/pkg/fi"
)
type Loader struct {
Builders []fi.NodeupModelBuilder
}
// Build is responsible for running the build tasks for nodeup
func (l *Loader) Build() (map[string]fi.NodeupTask, error) {
tasks := make(map[string]fi.NodeupTask)
for _, builder := range l.Builders {
context := &fi.NodeupModelBuilderContext{
Tasks: tasks,
}
err := builder.Build(context)
if err != nil {
return nil, fmt.Errorf("building %s: %v", reflect.TypeOf(builder), err)
}
tasks = context.Tasks
}
return tasks, nil
}
View on GitHub (pinned to 4c8573c808)
Solutions
- Read the wrapped %v text after "building <type>" to find the failing builder and root cause
- Ensure nodeup binary version matches the kOps cluster version used to generate NodeupConfig
- Re-run `kops update cluster --yes` so the nodeup config on the node matches the current cluster spec
- Check for recent cluster spec changes (channel, kubernetes version) that the builder validates
Defensive patterns
Strategy: try-catch
Validate before calling
// validate NodeupConfig completeness before Build
if cfg.ClusterName == "" || len(cfg.ApiserverAdditionalIPs) < 0 { /* schema-check via proto */ }
// assert nodeup binary version matches cluster kops version
if nodeupVersion != kopsVersion { return errors.New("nodeup/kops version mismatch") } Try / catch
tasks, err := loader.Build(ctx, bootConfig)
if err != nil {
var berr *reflect.TypeName // the wrapped builder type appears in message
klog.Errorf("model build failed: %v — inspect builder name after 'building '", err)
return err
} Prevention
- Keep nodeup binary and kOps controller versions in lockstep
- Regenerate NodeupConfig via `kops update cluster` after any spec change
- Run `kops toolbox template`/dry-runs in CI to exercise builders
- Read the reflect.TypeOf(builder) in the message to jump straight to the failing builder
When it happens
Trigger: Any fi.NodeupModelBuilder.Build returning a non-nil error during nodeup model construction — e.g. missing cluster spec fields, invalid instance group config, failed asset resolution.
Common situations: Cluster spec/channel incompatibilities after kOps upgrade; missing required fields in the nodeup config (NodeupConfig proto mismatch); bad instance-group settings (e.g. invalid containerd/kubelet config).
Related errors
- unsupported cloud provider for authenticator %q
- parsing path for kops-channels manifest %s: %w
- unable to parse KubernetesVersion %q: %w
- error building kubelet config: %v
- error loading configuration %q: %v
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/92bf209cff9efaae.
Report an issue: GitHub.