You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We should leverage the power of kubernetes controllers to manage the deployment state of the feast-feature-server. This is more operationally sound, as it can “repair” issues with deployments in a cluster. It also simplifies the management of multiple deployments within a cluster and opens the door to integrations with other operator-based projects.
Describe alternatives you've considered
I considered creating a go-based operator instead. This would add significant complexity to the development and maintenance of feast. Given that feast and its users already utilize helm, this seemed unnecessary.
Additional context
This new helm-based operator will leverage a few static kustomize manifests to deploy the operator, but it will utilize the helm chart to deploy the feature server(s) themselves. Users will not have to install helm, the operator will handle everything. Those familiar with the existing helm chart will be able to easily port their settings if they so choose.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
We should leverage the power of kubernetes controllers to manage the deployment state of the feast-feature-server. This is more operationally sound, as it can “repair” issues with deployments in a cluster. It also simplifies the management of multiple deployments within a cluster and opens the door to integrations with other operator-based projects.
Describe the solution you'd like
Wrap the existing feast-feature-server helm chart into a simple helm-based operator.
Describe alternatives you've considered
I considered creating a go-based operator instead. This would add significant complexity to the development and maintenance of feast. Given that feast and its users already utilize helm, this seemed unnecessary.
Additional context
This new helm-based operator will leverage a few static kustomize manifests to deploy the operator, but it will utilize the helm chart to deploy the feature server(s) themselves. Users will not have to install helm, the operator will handle everything. Those familiar with the existing helm chart will be able to easily port their settings if they so choose.
The text was updated successfully, but these errors were encountered: