Machine creation fails silently when ProviderSpec.labels field is omitted

[craigvanaman]

Summary

Machine creation fails silently when MachineClass has no labels field in its ProviderSpec. The provider returns an empty ProviderID without executing the CreateMachine code path.

Expected Behavior

When a MachineClass is created without a labels field in its ProviderSpec, the provider should:

1. Execute the CreateMachine function in core.go
2. Handle the missing labels gracefully (treat as empty map)
3. Create the machine in STACKIT IAAS
4. Return a valid ProviderID in the format stackit://<project-id>/<server-id>

Actual Behavior

When labels are omitted from ProviderSpec:

• MCM logs show: Created new VM for machine: 'machine-wn58lb4r' with ProviderID: (empty ProviderID)
• Provider code in core.go:36 (CreateMachine entry point) is never executed - no klog messages
• No POST request reaches the IAAS API (confirmed via mock server logs)
• CreateMachine returns successfully but with an empty ProviderID

Root Cause

The issue occurs before the provider code runs, likely in:

• decodeProviderSpec() function, OR
• The validation layer

When ProviderSpec.Labels is nil, it may cause JSON unmarshalling issues or validation failures that prevent the request from reaching the provider's CreateMachine implementation.

Evidence

From e2e test debugging:

// MachineClass WITHOUT labels
providerSpec:
  machineType: "c2i.2"
  imageId: "550e8400-e29b-41d4-a716-446655440000"
  # NO labels field

Results in:

• ✅ MCM CreateMachine is called (MCM logs confirm)
• ❌ Provider CreateMachine is NOT called (no logs from core.go)
• ❌ IAAS API receives no requests
• ❌ ProviderID is empty

Steps to Reproduce

1. Create a MachineClass without labels in providerSpec:

apiVersion: machine.sapcloud.io/v1alpha1
kind: MachineClass
metadata:
  name: test-no-labels
  namespace: default
providerSpec:
  machineType: "c2i.2"
  imageId: "550e8400-e29b-41d4-a716-446655440000"
  # labels field intentionally omitted
secretRef:
  name: stackit-secret
  namespace: default
provider: STACKIT

2. Create a Machine using this MachineClass
3. Observe that Machine gets empty ProviderID and provider code is never executed

Affected Code

The issue predates the SDK migration (confirmed 2025-11-06), suggesting it's in the core provider/validation layer:

• pkg/provider/apis/provider_spec.go - ProviderSpec definition
• pkg/provider/apis/validation/validation.go - Validation logic
• pkg/provider/core.go - decodeProviderSpec() function

Test Case

See: test/e2e/e2e_labels_test.go - Test: "should create Machine without user-provided labels"

• Currently skipped with Skip() due to this bug

Suggested Investigation

1. Add debug logging to decodeProviderSpec() to see if unmarshalling fails
2. Check validation logic for required vs optional fields
3. Run with -v=4 verbose logging to see gRPC/driver layer logs
4. Verify if nil vs empty map for Labels field causes different behavior
5. Compare with working provider implementations (OpenStack) to see how they handle optional labels

Impact

• Severity: Medium-High
• Users cannot create machines without explicitly setting labels (even empty)
• Fails silently without clear error messages
• Blocks e2e test coverage for graceful degradation scenarios

Workaround

Always include a labels field in MachineClass ProviderSpec, even if empty:

providerSpec:
  machineType: "c2i.2"
  imageId: "550e8400-e29b-41d4-a716-446655440000"
  labels: {}  # Empty map as workaround

[nschad]

Just a thought. Maybe providerSpec can be nil when everything is empty?

var Decoder = serializer.NewCodecFactory(scheme, serializer.EnableStrict).UniversalDecoder())


func decodeProviderSpec(raw runtime.RawExtension) (*api.ProviderSpec, error) {
	json, err := raw.MarshalJSON()
	if err != nil {
		return nil, fmt.Errorf("failed to decode provider spec: %v", err)
	}

	var providerSpec *api.ProviderSpec{}
	_, _, err = Decoder.Decode(json, nil, providerSpec)
	if err != nil {
		return nil, fmt.Errorf("failed to decode provider spec: %v", err)
	}
	return providerSpec, nil
}

[craigvanaman]

Thanks for the suggestion @nschad but I don't think this helps with this issue. Go's standard JSON unmarshaling already handles missing fields correctly and we're already checking if the labels are nil before iterating over them. So the code here should handle missing labels just fine.

Based on the testing I did, it seems that the provider code doesn't run at all. The CreateMachine call returns successfully but with an empty ProviderID, and none of our log statements appear. This suggests the problem is happening somewhere earlier in the chain, probably in the gRPC layer between MCM and our provider, or possibly in how the request is being serialized before it reaches our code.