feat(local): make StorageClass, MetalLB, and HTTPSPort configurable

[dcmcand]

Summary

• Add storage_class, https_port, and metallb (enabled + address_pool) as optional fields in the local provider config
• InfraSettings() reads these from config with current hardcoded values as defaults
• Fixes local provider only working for kind clusters - k3s users can now set storage_class: local-path and metallb.enabled: false

Closes

Closes #200

What changed

Config (pkg/provider/local/config.go)

• Added StorageClass, HTTPSPort fields to Config
• Added MetalLBConfig struct with Enabled (*bool to distinguish unset from false) and AddressPool

Implementation (pkg/provider/local/provider.go)

• InfraSettings() now parses the local config block and overrides defaults for any set fields
• Parse errors silently return defaults (same pattern as Hetzner provider)

Tests (pkg/provider/local/provider_test.go)

• 8 table-driven test cases: no config, empty config, each field individually, full override, unmarshal error

Examples (examples/local-config.yaml)

• Added commented examples showing k3s and custom MetalLB pool configurations

Example usage

k3s cluster:

local:
  storage_class: local-path
  https_port: 8443
  metallb:
    enabled: false

Custom MetalLB pool (kind on non-default Docker network):

local:
  metallb:
    address_pool: 172.18.255.100-172.18.255.110

Test plan

• go test ./pkg/provider/local/ -v passes (8/8 test cases)
• golangci-lint run ./pkg/provider/local/ passes
• Full project test suite passes

[marcelovilla]

@dcmcand I'll review this. Can you resolve the conflicts when you have a chance?

[viniciusdc]

Hey @dcmcand — could you rebase this against main and resolve the conflicts when you get a chance? Three refactors landed after this was opened (#190, #208, #211) that changed the Provider.InfraSettings signature to take *config.ClusterConfig and moved provider config under a nested cluster: block. The diff itself is small (mostly mirroring the pattern already in Summary()), so it should be a fairly mechanical rebase. Happy to review once it's green.

[dcmcand]

@viniciusdc it is rebased now

[viniciusdc]

Looked through the diff and nebari-dev/action-nebari-sandbox#15 — a few things worth discussing before merging.

Two questions:

pkg/provider/local/provider.go — the comment says "InfraSettings is called after Validate() has confirmed the config is parseable", but that ordering isn't enforced anywhere in the code. If someone calls InfraSettings without going through Validate (in a test, or a future codepath), they'll silently get defaults with no indication something went wrong. Is there a lifecycle guarantee that makes this safe? Or should we at least log the error instead of swallowing it?

Also on provider.go — why does UnmarshalProviderConfig take a context at all? For a pure config unmarshal context.Background() is fine, but if the function does any I/O the context matters and should be threaded through. If it's purely structural (the interface requires it), a quick comment there would save future readers the same question.

Two small things:

provider_test.go — the test covers metallb.enabled: false and the default (true implicitly), but not enabled: true explicitly. That's the case where the pointer is non-nil but *enabled == true — small gap in the pointer semantics coverage.

provider.go — cfg.ProviderConfig() is called without guarding against a nil cfg. Current callers never pass nil (and the "no local config block" test case passes a non-nil cfg with Providers: nil, which the rawCfg == nil guard handles correctly), but the function signature allows it. Worth a nil check at the top for robustness.

What looks good:

Enabled *bool for MetalLB is the right design — cleanly distinguishes "not set" (default true) from "explicitly false" without overloading the zero value. omitempty on a pointer works exactly as expected here.

The 8 table-driven test cases are solid: defaults, each field in isolation, full override, and the unmarshal error path. I also noticed the assertions verify the fields this PR doesn't touch (LoadBalancerAnnotations, KeycloakBasePath, SupportsLocalGitOps) haven't regressed — good discipline.

The integration evidence from nebari-dev/action-nebari-sandbox#15 is the best part: it removes the standard StorageClass workaround from create-cluster.sh — the one with the TODO pointing directly at this PR. That deletion is the cleanest possible proof this solves the underlying problem. The workaround only existed because this config field didn't. Full platform profile runs end-to-end against this branch in CI.

examples/local-config.yaml is clear and matches the actual struct. The k3s and custom MetalLB pool examples cover exactly the two cases that motivated this.

[viniciusdc]

Full platform profile runs end-to-end against this branch in CI nebari-dev/action-nebari-sandbox#15