This PR provides Operator users the ability to deploy the following ephemeral feast services:
Online Store (optional)
Offline Store (optional)
Registry
Any k8s services related to these feast service types, that are created/owned by the Operator CR, will be cleaned up should a user change their mind and remove said service from the CR config.
A user can affect several k8s container configs for each service type:
image
imagePullPolicy
resources
Additionally, we allow the user to point to a remote registry if they so choose. This would be instead of deploying a local registry with the FeatureStore CR.
CR w/ onlineStore, offlineStore, and a remote registry set in status... this deploys ephemeral online & offline stores, both pointed to a remote registry running in a separate namespace -
What this PR does / why we need it:
This PR provides Operator users the ability to deploy the following ephemeral feast services:
Any k8s services related to these feast service types, that are created/owned by the Operator CR, will be cleaned up should a user change their mind and remove said service from the CR config.
A user can affect several k8s container configs for each service type:
Additionally, we allow the user to point to a remote registry if they so choose. This would be instead of deploying a local registry with the
FeatureStore
CR.Which issue(s) this PR fixes:
Relates to https://github.com/feast-dev/feast/issues/4561
Misc
Deployed CR examples
CR w/ defaults set in status... this deploys an ephemeral registry server -
CR w/ onlineStore, offlineStore, and a remote registry set in status... this deploys ephemeral online & offline stores, both pointed to a remote registry running in a separate namespace -
The above CR, produces the following
feature_store.yaml
config for the running onlineStore service -It also produces the following ConfigMap w/ client
feature_store.yaml
-