Improve CRD validation and configuration initialization logic in the controller

[leecalcote]

Current Behavior
MeshSync needs to improve its custom resource validation logic in the controller's reconciliation loop.

Desired Behavior
Implement CRD validation and configuration initialization logic in the controller.

Contributor Resources

The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the master branch.

• See the Contributing to Meshery.io Website section of the readme.md and other contributing instructions, too.
• See Meshery site designs in Figma (open invite).
• Fill-in a Community Member Form and join the Community Slack for access.

[gentcod]

hello @leecalcote, can you please share more details on this?

[hamdikh]

Hello @leecalcote

Could you please provide me with more details regarding this issue, what kind of validations are you willing to add ?

[abohoss]

Hi @leecalcote ,
Can I work on this issue?

[anant-shipit]

Hi @leecalcote, I noticed this issue has been open for a while, but after working on the startup race conditions in #422, I believe it is still very relevant.

I'd like to pick this up as a follow-up to ensure we don't just patch individual bugs but solve the root initialization flow.

Proposed Scope:
I plan to consolidate the CRD validation logic into a dedicated initialization phase using controller-runtime patterns. This would involve:

1. Strict Validation: Ensuring the CRD isn't just "present" but matches the expected schema version before the controller starts.
2. Unified Config Loading: Refactoring the GetMeshsyncCRDConfigs flow to be more declarative.
3. Error Handling: Replacing generic log warnings with the structured MeshKit error patterns from Old MeshSync CRD not handled #422.

Does this scope still align with the project's goals?

[ahmedmadbouly186]

Validation improvements needed in meshsync_controller

Three validations are missing, ordered by priority:

---

1. Broker Validation (highest priority)

Used by reconcileBrokerConfig (line 264), which currently does nothing silently if both broker configs are empty.

a) At least one broker must be configured

Native == {} AND Custom.URL == "" → invalid

Without this, PublishingTo stays empty — MeshSync deploys but never publishes events (silent failure).

b) Both brokers cannot be configured simultaneously

Native != {} AND Custom.URL != "" → conflict (ambiguous: which one wins?)

c) If Native broker is chosen, both fields are required

Native.Name == "" OR Native.Namespace == "" → invalid

Currently brokerpackage.GetEndpoint would receive empty name/namespace and fail with a cryptic K8s error.

---

2. Size Validation (medium priority)

// +kubebuilder:validation:Minimum=1
// +kubebuilder:validation:Maximum=10
Size int32

The kubebuilder marker only enforces this if the admission webhook is running. Without it, Size defaults to 0 (Go zero value + omitempty), producing a Deployment with 0 replicas — created but never runs.

Rules needed:

Size == 0 → default to 1  // initialization, not rejection
Size < 0  → invalid

---

3. Version Validation (lower priority)

Version string

Currently unused directly in the reconciler, but PatchCRVersion in crd_config.go reads Server["version"] to patch it. An empty Version could cause MeshSync to deploy with an unknown image tag.

Rule needed:

Version == "" → reject or default to a known stable version

Why this belongs in meshery-operator, not meshsync

The MeshSync CRD is defined and owned by meshery-operator. Its controller (MeshSyncReconciler)
is the first process to handle a MeshSync resource — running before the MeshSync pod is ever scheduled. This means:

• Validation here prevents a bad spec from ever reaching deployment
• The controller can write a ValidationFailed status condition back to the CR, visible via kubectl describe meshsync
• The meshsync app only runs after the operator has already deployed it — by then it's too late to prevent a broken Deployment from being created

meshsync already has its own config validation in crd_config.go (validateLists), but that validates
watch-list content at runtime, not the CR spec at admission time. These are complementary layers, not duplicates.

This issue tracks the operator-side gap. The meshsync-side validation (crd_config.go) is complete as-is.