Feast Kubeflow integration as an add-on.

[lokeshrangineni]

We would like to add the feast manifest files back to kubeflow. The feast manifest files have been deleted previously and this issue is tracking the progress of adding them back. Get the community feedback to resolve any issues along the way.

[franciscojavierarceo]

FYI @tokoko @breno-costa @job-almekinders @EXPEbdodla @shuchu

[lokeshrangineni]

After spending some time on this task here is the conclusion. things tried:

1. I could not spin up the kubeflow on my local machine using minikube due to the compute restrictions.
2. I have tried to deploy the manifests on the openshift cluster on the cloud but there is a version incompatibility. We need to try with the kubernetes cluster if it works. We need to create separate manifests files to support Open datahub.
3. I have tried deploying the kubeflow component as a standalone component using command kustomize build feast/base | kubectl apply -n feast -f - which yielded me into the errors with the versions. Later figured it out the current manifest file using older version of feast.
4. The repository used by current manifest files is not having most recent versions of feast releases. We need to figure out where is our most recent feast docker releases are stored.
5. The current manifests are generated using helm template from the feast and kf-feast charts. After introspecting the generated resource.yaml file it is still following the legacy way of deploying feast. We need to revisit and modify the generation of manifest files to deploy online server, registry and offline server. Some work is needed here to adopt the new structure of recent helm chart.

[shuchu]

Thank you for your support @lokeshrangineni !

[shuchu]

It seems we need to split the current Feast code into different components.

[lokeshrangineni]

After spending time working with Kubeflow, here’s the current status:

1. Updated KF manifests: Updated the manifest files to deploy the online server, registry server, and offline server using the latest Helm chart version (v0.40.1). The Helm chart requires a feature_store.yaml to be deployed. For now, I’ve used a simple example, though it may not be sufficient for production deployments. Now we need to have feature_store.yaml file to be ready before deploying it on to the kubeflow. In production environment we need to figure it out how to deploy/integrate with all the feast dependent services such as possible offline server, online server services.

2. Feast topology on Kubernetes: We need to standardize (or recommend) a deployment topology for Kubernetes clusters. How to deploy all the servers which are needed and communicate with each other.

3. Kubeflow UI changes: The current manifests do not include any updates to display Feast services on the Kubeflow UI or control board. As of now, there is no way for users to easily discover Feast services within Kubeflow. While this is a longer-term goal, the aim would be to provide visibility into all available Feast services and associated metadata through the Kubeflow control board.

4. Kubeflow Multi-tenancy with feast: In terms of Kubeflow integration, each Feast server currently operates on a single feature_store.yaml. We need to evaluate and scope the requirements if we plan to support multiple feature stores. Further analysis is needed if we want to support Feast's multitenancy on the Kubeflow platform. If we opt for a shared service approach, this discussion may not be necessary. cc: @dmartinol