The red `unit-test-python (3.11, macos-14)` leg is an unrelated CI flake, not caused by this change (which is Go-only, scoped to `infra/feast-operator/`):

```
ERROR sdk/python/tests/unit/test_feature_server.py::test_push_and_get
AssertionError: stdout: b''
stderr: b"Command timed out after 120s: [\x27apply\x27]"
2259 passed, 47 skipped, 1 error
```

A `feast apply` subprocess timed out after 120s on the macOS-14 runner. The macOS-3.12 leg and all Ubuntu legs (3.10/3.11/3.12) passed on this same commit, and `operator-test` is green. I do not have permission to re-run the job from the fork — a maintainer re-run of that single leg should clear it.

@nikolauspschuetz instead I think fix should be to allow online server deployment to opt-out.

Thanks @ntkathole — that makes sense for backward compatibility. Omitting onlineStore today implicitly deploys one, so flipping that default (what this PR currently does) is a breaking change on upgrade for anyone relying on the implicit default.

To make it opt-out instead, I'd keep the current default-on behavior and add an explicit disable switch on the online store spec, mirroring the existing DisableInitContainers idiom already in the CRD:

type OnlineStore struct {
    // Disabled skips deploying the online store service.
    // +optional
    Disabled bool `json:"disabled,omitempty"`

    Server      *ServerConfigs          `json:"server,omitempty"`
    Persistence *OnlineStorePersistence `json:"persistence,omitempty"`
    // ...
}

ApplyDefaultsToStatus would skip the onlineStore defaulting/deployment when disabled is true; omitting the block keeps deploying it exactly as before. The standalone-registry / federated pattern from #6586 would then be expressed explicitly as spec.services.onlineStore.disabled: true.

One clarification so I build the right thing: do you want the opt-out at the whole online-store level (skip both persistence and the serving pod), or only the online server (serving pod), keeping the online store config? Happy to rework the PR either way once you confirm.

opt-out at the whole online-store level (skip both persistence and the serving pod), or only the online server (serving pod), keeping the online store config?

opt-out at the whole onlineStore level (disabled: true), not server-only.

Thanks — reworked it to opt-out. The default is back to deploying the online store, so nothing changes on upgrade for existing setups. Setting spec.services.onlineStore.disabled: true now skips it entirely (serving pod and persistence), which covers the registry-only / offline-only case from #6586. It's gated through isOnlineStore(), so metrics and the service monitor drop off with it too.