René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Feast operator always deploys an online store, regardless of CR configuration","articleBody":"## Expected Behavior \n\nThe Feast operator should deploy only the services declared in a FeatureStore CR. It should be possible to deploy a standalone registry or a standalone offline store, with no online store, by simply not specifying spec.services.onlineStore. This mirrors how registry and offlineStore already behave and is required by the documented [federated / shared registry pattern](https://docs.feast.dev/how-to-guides/feast-snowflake-gcp-aws/federated-feature-store).\n\n## Current Behavior\n\nThe operator always deploys an online store service (including a serving pod), even when the CR does not declare spec.services.onlineStore. Root cause is in ApplyDefaultsToStatus ([internal/controller/services/util.go](https://github.com/feast-dev/feast/blob/master/infra/feast-operator/internal/controller/services/util.go#L166)):\n\n```go\n// default to onlineStore service deployment\nif services.OnlineStore == nil {\n    services.OnlineStore = \u0026feastdevv1.OnlineStore{}\n}\n// ...\nif services.OnlineStore.Server == nil {\n    services.OnlineStore.Server = \u0026feastdevv1.ServerConfigs{}   // forces a serving pod\n}\n```\n\nUnlike registry `(if services.Registry != nil)` and `offlineStore (if services.OfflineStore != nil)`, which are only defaulted when declared, and whose `.Server` is only defaulted when already present, the onlineStore block runs unconditionally and creates Server from nil.\n\nDownstream:\n\n1. `isOnlineStore()` is always true → `reconcileServices()` always deploys the online store, and `isOnlineServer()` is always true. There's no opt-out, the `OnlineStore` CRD type has no `disabled` field. (This also makes the \"at least one local server must be configured\" guard in `Deploy()` unreachable.)\n2. The scaling admission validation is asymmetric ([api/v1/featurestore_types.go](https://github.com/feast-dev/feast/blob/master/infra/feast-operator/api/v1/featurestore_types.go#L148)): the offline rule allows the store to be absent (`!has(self.services.offlineStore) || ...`), but the online rule requires it to exist and be DB-backed. So scaling a registry-only/offline-only store fails admission with `Scaling requires DB-backed persistence for the online store. Configure services.onlineStore.persistence.store when using replicas \u003e 1 or autoscaling.`, forcing DB persistence for an online store the user never asked for.\n\n## Steps to reproduce\n\n1. Apply a CR declaring only a registry (or only an offline store), with no `spec.services.onlineStore`.\n2. `kubectl get deploy -l feast.dev/name=\u003cname\u003e` → an online/feature-server container is deployed alongside the registry (expected: registry only).\n3. Add `spec.replicas: 2` (or `services.scaling.autoscaling`) to that registry-only CR → rejected at admission with the online-store DB-persistence error, despite no online store being declared.\n\n### Specifications\n\n- Version: 0.64.0\n- Platform: Kubernetes\n- Subsystem: feast-operator — internal/controller/services\n\n## Possible Solution\n\n1. Guard the online-store block in `ApplyDefaultsToStatus` with if `services.OnlineStore != nil { ... }` (and only default Server when already present), making it symmetric with registry/offline. Preferable to adding a new opt-out API field.\n2. Add an \"online store absent\" escape hatch to the online CEL rule (`!has(self.services.onlineStore) || (...)`), matching the offline rule.\n3. Keep `noLocalCoreServerConfigured()` enforcing that at least one core server is deployed.\n\nHappy to open a PR! 😄 \n","author":{"url":"https://github.com/dbbvitor","@type":"Person","name":"dbbvitor"},"datePublished":"2026-07-07T13:06:16.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/6586/feast/issues/6586"}