kubernetes/kops · error

reading data: %v

Error message

reading data: %v

What it means

During terraform output rendering for Azure, MemFSPath.renderTerraformAzure reads the whole file content from the given io.Reader. Any read failure is wrapped as 'reading data: %v' and aborts rendering that blob.

Source

Thrown at util/pkg/vfs/memfs.go:249

	Bucket   string                   `json:"bucket" cty:"bucket"`
	Key      string                   `json:"key" cty:"key"`
	Content  *terraformWriter.Literal `json:"content,omitempty" cty:"content"`
	Acl      *string                  `json:"acl,omitempty" cty:"acl"`
	SSE      string                   `json:"server_side_encryption,omitempty" cty:"server_side_encryption"`
	Provider *terraformWriter.Literal `json:"provider,omitempty" cty:"provider"`
}

func (p *MemFSPath) RenderTerraform(w *terraformWriter.TerraformWriter, name string, data io.Reader, acl ACL) error {
	if w.Providers != nil && w.Providers["azurerm"] != nil {
		return p.renderTerraformAzure(w, name, data)
	}
	return p.renderTerraformS3(w, name, data, acl)
}

func (p *MemFSPath) renderTerraformAzure(w *terraformWriter.TerraformWriter, name string, data io.Reader) error {
	bytes, err := io.ReadAll(data)
	if err != nil {
		return fmt.Errorf("reading data: %v", err)
	}

	source, err := w.AddFilePath("azurerm_storage_blob", name, "source", bytes, false)
	if err != nil {
		return fmt.Errorf("rendering Azure Blob file: %w", err)
	}

	// memfs:// paths don't encode an Azure account or container, so this
	// fallback (only used in integration tests) hard-codes a test placeholder
	// container on the storage account from the cluster spec.
	tf := &terraformAzureBlobFile{
		Name:               p.location,
		StorageContainerID: w.AzureStorageAccountID + "/blobServices/default/containers/testcontainer",
		Type:               "Block",
		Source:             source,
		Provider:           terraformWriter.LiteralTokens("azurerm", "files"),
	}
	return w.RenderResource("azurerm_storage_blob", name, tf)

View on GitHub (pinned to 4c8573c808)

Solutions

1. Recreate the reader before rendering (Seek to 0 for ReadSeekers, or re-open the source)
2. Inspect the wrapped error to identify the underlying read failure and fix the reader lifecycle
3. Ensure each render pass gets fresh bytes (e.g. keep the raw []byte and pass bytes.NewReader each time)

Example fix

// before
r, _ := getReader(); render(r); render(r) // second call: reader consumed
// after
if s, ok := r.(io.Seeker); ok { s.Seek(0, io.SeekStart) }
render(ctx, w, r)

if rs, ok := data.(io.Seeker); ok { if _, err := rs.Seek(0, io.SeekStart); err != nil { return err } }

null

if err := p.RenderTerraform(w, name, data, nil); err != nil {
    if strings.HasPrefix(err.Error(), "reading data:") { /* recreate reader and re-render */ }
    return err
}

When it happens

Trigger: Calling RenderTerraform on a memfs path backed by Azure with an io.Reader (from the stored file/write path) that errors mid-read — typically a closed or already-consumed reader.

Common situations: Integration tests rendering terraform for Azure-targeted mock clusters where the source data reader was reused after a previous render consumed it.

Related errors

• rendering Azure Blob file: %w
• reading data: %w
• Azure storage account is not set on path %q
• Azure storage account ID is not set; it is required to rende
• rendering Azure Blob file: %w

AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/2f24a5c6ec12b357. Report an issue: GitHub.