@tokoko @shuchu @HaoXuAI @sudohainguyen hey all, may I kindly ask for your considerations of the effort here? We'd love to hear any feedback or questions/convo around technical and/or objective aspects from some of our heavier contributors, so if you're able, we'd really appreciate it!

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.

I'll be completely honest, this is my first time hearing of a helm-based operator and I'm not sure I understand the point. 😄What's the difference with normal helm deployment in any practical sense other than the fact that parameters are used to populate a CRD instead of helm values file? Previously I thought (maybe just my limited experience) that controllers came in handy when you needed some very custom behavior in cluster or maybe even orchestrating stuff outside the cluster. So my questions right now are 1) Is something like that even possible with helm-based operators? and 2) do we have any use case for it (actual or expected)? java feature server deployment doesn't look that unusual to me. I'm probably unaware of some other benefits, so some more context there will be appreciated...

Another slightly unrelated point to note here. I think feast has bit of an identity crisis when it comes to deployments like this. For example we have lambda feature server which has it's own registry object and is actually deployed when user runs feast apply (not a fan of this myself). At the same time we have ways to start servers either with cli or deploy with helm. I think we should try to make all this less confusing. Personally I think deploying anything anywhere with a feast apply needs to be killed off.

Another slightly unrelated point to note here. I think feast has bit of an identity crisis when it comes to deployments like this. For example we have lambda feature server which has it's own registry object and is actually deployed when user runs feast apply (not a fan of this myself). At the same time we have ways to start servers either with cli or deploy with helm. I think we should try to make all this less confusing. Personally I think deploying anything anywhere with a feast apply needs to be killed off.

I think we need to be able to allow users to pick and choose based on tradeoffs. Being able to deploy feature changes via feast apply is a choice that has been very successful for some and not within the risk tolerance of others. So I don't think we should be overly prescriptive on that.

@franciscojavierarceo sorry, let me clarify. I wasn't referring to feature changes, I meant deployments like aws lambda feature server.

@tokoko let me know if you have additional Qs

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.

I'll be completely honest, this is my first time hearing of a helm-based operator and I'm not sure I understand the point. 😄What's the difference with normal helm deployment in any practical sense other than the fact that parameters are used to populate a CRD instead of helm values file?

• The Operator’s controller will automatically recover missing objects in the cluster, and fix misconfigured ones. For example, if a feature server’s k8s Service or Deployment were accidentally deleted, the operator will recreate it. In critical environments, this is invaluable.
• Once an admin installs the operator to a cluster, all users can take advantage using native k8s tools to deploy their own feature servers, with the use of the new FeastFeatureServer CR. No helm knowledge or installation is required. This will be identical to how a user might create a Deployment object in their own namespace.
• Changes made to a FeastFeatureServer CR in-cluster will automatically be reflected in the feature server deployment. Nothing else has to be done.

Previously I thought (maybe just my limited experience) that controllers came in handy when you needed some very custom behavior in cluster or maybe even orchestrating stuff outside the cluster. So my questions right now are 1) Is something like that even possible with helm-based operators?

• Helm-based operators are limited in that respect. We would have to use a Go-based operator instead. But, as I stated in the related issue (Add a Kubernetes Operator for the Feast Feature Server, to the infra directory #4144), a go-based operator would add significant complexity to the development and maintenance of feast. Given that feast and its users already utilize, and prefer, helm… this seemed unnecessary. My intention with this approach was to continue to funnel future deployment contributions to the helm charts… rather than other deployment methods. Any future changes made to the helm charts will be automatically reflected in this helm-based operator.
• That said, do we think the community would prefer a Go-based operator instead? They can be a lot to take on and maintain, but i have significant experience with them.

and 2) do we have any use case for it (actual or expected)?

• IMO, aside from the controller benefits stated above, it's a great way to potentially consolidate all of the helm charts into a single, optional deployment mechanism. In the future, should the community so choose, all helm chart installs could be handled by this same feast-operator. Each would have its own CRD. e.g. FeastJavaFeatureServer or FeastTransformationService, etc.
• Also, should the community choose to, in the future this feast-operator could be added to https://operatorhub.io/ for greater visibility to potential k8s users… or to OpenShift’s internal OperatorHub, which is then made available to all OpenShift & OKD cluster users.
• More immediately, we’d be able to easily integrate the feast-feature-server into the Open Data Hub (ODH) Operator.

java feature server deployment doesn't look that unusual to me. I'm probably unaware of some other benefits, so some more context there will be appreciated...

totally support this, since there's a lot of room to consolidate deployment for feast
I would prefer going with the helm-based operator first due to its simplification 🙌

@tchughesiv thanks for the lengthy response. I do see the benefits and since people will also be able to use normal helm charts as well, I don't see why we shouldn't do this. as for the go-based approach, I agree with Harry, right now helm is enough. If a suitable use case arises for a go-based one, we can revisit this later.

thanks @tokoko @sudohainguyen @HaoXuAI @franciscojavierarceo
if you get a minute, there's a related PR #4161 that affects the full functionality of this operator. very simple helm fix.