KEP 831-Kubeflow-Helm-Support: Support Helm as an Alternative for Kustomize

[juliusvonkohout]

Helm KEP from @varodrig @chasecadet @juliusvonkohout Fixed branch from https://github.com/kubeflow/community/pull/830

Placeholder: https://github.com/kubeflow/community/issues/831 Implementation: https://github.com/kubeflow/manifests/issues/2730

[varodrig]

/lgtm

[thesuperzapper]

Foundationally, this is still a discussion around if we have an "official" distribution or not.

This KEP proposes a single "mega" helm chart with all components inside, this is by definition, an opinionated "distribution" of Kubeflow Platform.

The community has discussed and rejected having official distributions in the past, for reasons that are still applicable:

1. The fundamental goal of the project is to make AI/ML tools for Kubernetes (Pipelines, Notebooks, Trainer, Feature Store, etc.)
2. Our strength is that our tools can run on any Kubernetes cluster, with no preference for any deployment method, cloud vendor, or anything else.
3. If we make opinionated deployment decisions, less people will be able to adopt our tools, or include them in downstream platforms.
4. There is strong evidence that it's not possible to create a successful "generic" distribution. See the fact that multiple successful distributions exist today, each with different opinionated approaches.
5. Those in the OWNERS file of an official distribution would have the ability to make decisions that affect the whole community. This likely means that 1-3 consulting/cloud/platform companies make decisions that benefit them, rather than the goal of making our tools the standard.

PS: I want to stress that your motivations about making Kubeflow easier to use are great, and I am sure some users would love a Kubeflow Distribution that looks like this. (In fact, there are at least 2 that I am aware of which are similar to your proposal already, so perhaps you can collaborate with them). However, it's critical to keep the project neutral and focused on the tools themselves.

---

Also, while it's clearly not the intention of this KEP, there is a separate discussion around if automatically-generated helm charts based on the existing component kustomize manifests would be useful for downstream distributions. But that would be a completely separate proposal.

[lburgazzoli]

there is a separate discussion around if automatically-generated helm charts based on the existing component kustomize manifests would be useful for downstream distributions.

@thesuperzapper is this discussion already happening somewhere ?

[shaikmoeed]

Thanks for this great feature—it's really going useful for us! As a suggestion, it would be awesome to include some migration documentation on transitioning from Kustomize to Helm in Goals. Also, any guidance on achieving a zero-downtime migration would be much appreciated. It will help users who are willing to utilise this.

Thanks again for all the great work!

[chasecadet]

Thanks for this great feature—it's really going useful for us! As a suggestion, it would be awesome to include some migration documentation on transitioning from Kustomize to Helm in Goals. Also, any guidance on achieving a zero-downtime migration would be much appreciated. It will help users who are willing to utilise this.

Thanks again for all the great work!

Hey @shaikmoeed thanks for the feedback! One thing that would really help with this initiative is if you would be willing to tell us how Helm would help you and what you are looking for from these Helm charts. Your insights would be super awesome!

[shaikmoeed]

Hey @shaikmoeed thanks for the feedback! One thing that would really help with this initiative is if you would be willing to tell us how Helm would help you and what you are looking for from these Helm charts. Your insights would be super awesome!

@chasecadet Thanks for asking! We maintain a customized local version of kubeflow/manifests (with patches like Istio, OAuth2 and other fixes), which makes our upgrades challenging. As we manage most of our k8s service using Helm with ArgoCD, this initiative would simplify our process by letting us enable only the needed components and manage our patches more cleanly—eliminating the need to maintain local copies and keeping our upgrade PRs much smaller and easier to review.

[chasecadet]

Hey @shaikmoeed thanks for the feedback! One thing that would really help with this initiative is if you would be willing to tell us how Helm would help you and what you are looking for from these Helm charts. Your insights would be super awesome!

@chasecadet Thanks for asking! We maintain a customized local version of kubeflow/manifests (with patches like Istio, OAuth2 and other fixes), which makes our upgrades challenging. As we manage most of our k8s service using Helm with ArgoCD, this initiative would simplify our process by letting us enable only the needed components and manage our patches more cleanly—eliminating the need to maintain local copies and keeping our upgrade PRs much smaller and easier to review.

Good to know! Also, we'd love to know about how you use Kubeflow and your use cases, but probably for a different medium. Feel free to hit me up on the CNCF slack (chasecadet) if you'd like to share. Also let's ensure your org is on the adopters list so you get credit for being bleeding edge!

[juliusvonkohout]

Foundationally, this is still a discussion around if we have an "official" distribution or not.

This KEP proposes a single "mega" helm chart with all components inside, this is by definition, an opinionated "distribution" of Kubeflow Platform.

Actually that is not the case. It is not a distribution, since they would still be the community manifests, not derived/deviated from it.

But you are right in the sense that we should have helm charts for the individual components and combine them as we combine the kustomize manifests of the individual components. In the end we have a wonderful heterogeneous userbase and they want both options . If possible we should just combine the smaller ones in a meta helm chart or so similar to the kustomize overlay https://github.com/kubeflow/manifests/blob/master/example/kustomization.yaml . In the end the goal is to have something helm based with a similar structure / goal as the current kustomize manifests. Please make constructive suggestions in the KEP how we can emphasize this more.

"Also, while it's clearly not the intention of this KEP, there is a separate discussion around if automatically-generated helm charts based on the existing component kustomize manifests would be useful for downstream distributions. But that would be a completely separate proposal.

Also here I have to object, this is not a separate discussion. Automatically-generated helm charts are within this KEP. But that is an implementation detail of the single source of truth requirement. CC @lburgazzoli

[juliusvonkohout]

Hey @shaikmoeed thanks for the feedback! One thing that would really help with this initiative is if you would be willing to tell us how Helm would help you and what you are looking for from these Helm charts. Your insights would be super awesome!

@chasecadet Thanks for asking! We maintain a customized local version of kubeflow/manifests (with patches like Istio, OAuth2 and other fixes), which makes our upgrades challenging. As we manage most of our k8s service using Helm with ArgoCD, this initiative would simplify our process by letting us enable only the needed components and manage our patches more cleanly—eliminating the need to maintain local copies and keeping our upgrade PRs much smaller and easier to review.

Hello, are you familiar with https://github.com/kubeflow/manifests?tab=readme-ov-file#upgrading-and-extending ? Maybe this can help you until the helm manifests are ready.

[juliusvonkohout]

@shaikmoeed https://github.com/kubeflow/community/blob/master/ADOPTERS.md is the file where you can add your company.

[google-oss-prow[bot]]

New changes are detected. LGTM label has been removed.

[chasecadet]

@andreyvelich, let's try a well-known technique: Observation, Feeling, Need, Request. This approach can help us unpack details rather than relying on "certainty in correctness," which is something I constantly challenge myself on while staying curious. I appreciate all the great insights you're sharing here. Observation

I noticed you said:

"The manifests should just copy the code assets from the upstream app repos. This is not what is proposed here."
"kubeflow/manifests is a good starting point to explore Kubeflow's capabilities. I believe Kustomize works well for this purpose."

Feeling

I'm feeling a bit confused because I’ve seen community members express concerns that Kustomize is too complex and instead request a Helm chart. I suspect this stems from a misalignment in who Kustomize is best suited for. My perspective is that Kustomize works well for experts like you—SMEs in manifests who deploy custom components at a high level. However, many users seem to prefer Helm because it abstracts away complexity with its templating engine. re @juliusvonkohout

"Can we actually gather a feedback from real users who are using kubeflow/manifests today and complaining about Kustomize" it is one of the most requested features and you can take a look at the kubeflow-helm channel. That is what you typically hear at conferences and from companies (requiring it to even start with Kubeflow) as well. That is also why there are 10 different community efforts for helm charts. CC @chasecadet.

Need

I want to better understand what makes you uncomfortable or unsatisfied with this request.

What scenarios are you considering?
How do you view the trade-offs between Kustomize and Helm?
How do you think this KEP might impact your work or the project’s direction?

Request

Would you be open to unpacking your full perspective so I can understand it more clearly? Overcommunication here would really help me.

One additional thought: Do we need to explore a new approach? re:

"Yes, we can provide our "opinionated" solution for auth with Dex and Istio, but this is not mandatory for folks to integrate with Kubeflow projects." Oauth2-proxy and Dex is not really opinionated. They are just the two endpoints where companies connect to the companies internal IDP for the single-sign-on. They do not build the authentication in Kubeflow themselves

Are we dealing with two separate deployment needs—one for standalone, callable components (e.g., the Training Operator) and another for a full platform experience where users have isolated namespaces with authentication?
When you deploy individual components, do you deploy one per namespace?  
 How do you handle security and isolation?

Looking forward to your thoughts! 😊

[thesuperzapper]

First, I want to thank everyone for their passion for Kubeflow. I especially want to thank @juliusvonkohout for his work on kubeflow/manifests that enables many distributions and custom deployments of Kubeflow that make our tools available to end users.

My understanding is that this KEP comes from discussions with your customers that want to deploy and manage a Kubeflow Platform with Helm and ArgoCD.

You make a compelling case why some users want Helm+ArgoCD, however, I'm trying to understand why this deployment method needs to be officially developed under the Kubeflow organization?

Was the alternative of making a Kubeflow Distribution considered?

[juliusvonkohout]

First, I want to thank everyone for their passion for Kubeflow. I especially want to thank @juliusvonkohout for his work on kubeflow/manifests that enables many distributions and custom deployments of Kubeflow that make our tools available to end users.

Thank you, the goal of this KEP is to make platform/manifests more attractive for the end users, whether it is a one man private distribution or a large companies public distribution. I think we need to improve at a high technical speed to stay relevant as the platform for orchestrating ML Workflows on Kubernetes.

My understanding is that this KEP comes from discussions with your customers that want to deploy and manage a Kubeflow Platform with Helm and ArgoCD.

You make a compelling case why some users want Helm+ArgoCD, however, I'm trying to understand why this deployment method needs to be officially developed under the Kubeflow organization?

Was the alternative of making a Kubeflow Distribution considered?

Regarding "My understanding is that this KEP comes from discussions with your customers that want to deploy and manage a Kubeflow Platform with Helm and ArgoCD." and "You make a compelling case why some users want Helm+ArgoCD; however, I'm trying to understand why this deployment method needs to be officially developed under the Kubeflow organization?" I have to politely say no. You can see here that I even want to write the opposite:

""" This platform/manifests charter describes the working mode / reality / status quo of the last 5 years as of March 2025. It tries to be as lean as possible and balance community and commercial interests.

Scope

• Enable users / distributions to install, extend and maintain Kubeflow as a multi-tenant platform for multiple users
• This includes dependencies, security efforts and exemplary integration with popular tools and frameworks.
• Synchronize the manifests (Helm, Kustomize) between working groups
• We try to be compatible with the popular Kubernetes clusters (Kind, Rancher, AKS, EKS, GKE, ...)
• We do not support a specific deployment tool (e.g., ArgoCD, Flux)
• The default installation shall not contain deep integration with external cloud services or closed source solutions, instead we aim for Kubernetes-native solutions and light authentication and authorization integration with external IDPs
• We provide hints and experimental examples how a user / distribution could integrate non-default external authentication (e.g. companies Identity Provider) and popular non-default services on his own
• There is the evolving and not exhaustive list of dependencies for a proper multi-tenant platform installation: Istio, KNative, Dex, Oauth2-proxy, Cert-Manager, ...
• There is the evolving and not exhaustive list of applications: KFP, Trainer, Dashboard, Workspaces / Noteboks, Kserve, Spark, ...

Communication Tasks

With Application Owners

• Aid the application owner in creating manifests (Helm, Kustomize) for his application
• Aid the application owner regarding security best practices
• Communicate with the application owner regarding releases and versioning

With Users / Distribution Owners

• Distributions are strongly opinionated derivatives of Kubeflow platform/manifests, for example replacing all databases with closed source managed databases from AWS, GKE, Azure, ...
• A distribution can be created by an arbitrary amount of users / companies in private or in public by deriving from Kubeflow platform/manifests, see the definition above
• Coordinate with "distribution owners" / users to take part in the testing of Kubeflow releases. ...

"""

"Was the alternative of making a Kubeflow Distribution considered?" I have my personal distribution; I do not need another one. As I said, this is not for me, and I personally do not need Helm, because I mostly build the helm templating functionality myself on top of kustomize, but many end users want Helm for that functionality.

The question is rather, how do we not miss out on the users/companies that require Helm manifests? How do we make it simple to modify, maintain, and extend Kubeflow for full multi-user installations to keep it attractive? How do we consolidate the ten different Helm approaches with synergy to avoid spending ten times the amount of time on maintaining manifests and reinventing the wheel?

How can we get distributions to work more together? How can we get them to upstream some changes so that the platform as a whole progresses and each distribution has reduced maintenance overhead? In the end, we need to have a good product that offers ML as a platform without requiring every adopter to reinvent the wheel. We are failing the ML platform goal if only third-party derivative projects offer essential features like Helm manifests or robust multi-tenancy and enforced security best practices.

I (subjectively) see the multiple single-tenant approach as a lower value offering or only an offering for a special edge case / subset of the user base with significant additional integration efforts for the end user for each separate component compared to the (subjectively more valuable) less integration and maintenance effort multi-tenancy platform way. But no one should be blocked from building individually from scratch and no one should be blocked from experiencing and contributing to an integrated End-to-end platform. Let the people choose how they want to build and contribute. We, or at least I, do not have the time and priority to redesign each individual component with individual authentication and multi-tenancy from scratch as individual mini platform in the short term with a proper upgrade path from our current architecture. I still want to continue to reduce the complexity long-term step by step, but this will take at least a year. I think we have already reduced the complexity a lot. We are now rather decoupled from the Kubernetes version for example and support a wider range of dependency versions with way better documentation and there are also other lower hanging fruits (new kubernetes-native object storage for example and the security efforts to even be allowed to run Kubeflow by your CISO office) that I would personally prioritize higher. Maybe someone else has different priorities and volunteers to spend his personal time on this per WG topic sooner than myself. However, my estimation is that we will not have much progress in the next 12 months, given the ratio of discussion vs. implementation. In the end we are volunteers, so I can only expect others to work on what is interesting and a priority for them, not what I think should be interesting / priority for them. If we stop people too hard from working on what is interesting for them, they will just stop contributing. The reason that I offered to mentor this is not just the knowledge of manifests/platform and the testing infrastructure, but keeping Kubeflow as a platform maintainable for end users / distributions. The first installation is only a fraction of the effort while adjusting, templating etc. Is the major effort. Helm with its integrated templating engine could help a lot in this regard.

This is an effort I am pushing for the community, not for myself. But it is getting too broad since this clear Helm manifests discussion becomes tangled up with architecture restructuring discussions as well as other topics. For other topics such as authentication architectural redesigns everyone is free to create a separate non-helm KEP, to keep this one here focused. It also often deteriorates into a broad political governance discussion rather than a constructive search for in-scope (status quo with Helm for GSoC PoC ) solutions. This amount of derailing / defocusing and debating instead of constructive in-scope code / text suggestions and direct improvements is slowing us down and might result in losing platform users and synergies.

@chasecadet, I tried to push for community synergies and Kubeflow platform Helm user adoption, but I can only do so much with a limited amount of time.

[juliusvonkohout]

To have a more focused discussion I have moved the charter into https://github.com/kubeflow/community/pull/837.

[juliusvonkohout]

From the long discussion on slack: "Another interesting thing is that more and more manifests come in helm form (spark, istio, etc) and right now we render them out to be usable with kustomize. At some point it could be more feasible to just call them directly from kustomize with the right values, since kustomize has some form of helm integration. I tried it recently to include a helm manifest with parameters via kustomize. This way we could step by step replace the kustomize parts with templatable helm manifests and keep the same ci/cd to make sure that stuff is not breaking and the output stays the same."

See https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md for examples.

[juliusvonkohout]

See for example this example from the proposal from one of the GSOC students https://github.com/akagami-harsh/manifests/blob/helm-charts/kustomize-helm-poc/README.md It uses the trainer helm chart via kustomize @akagami-harsh

[Mohamed-ben-khemis]

See for example this example from the proposal from one of the GSOC students https://github.com/akagami-harsh/manifests/blob/helm-charts/kustomize-helm-poc/README.md It uses the trainer helm chart via kustomize @akagami-harsh

Thanks for sharing this! And big thanks to @akagami-harsh for the effort 🙌 @juliusvonkohout One potential concern is the added complexity: contributors would need to understand both Helm and Kustomize to make changes or debug issues. As we scale to more Kubeflow components, maintaining consistency across this hybrid model could become increasingly challenging.

[TheCodingSheikh]

Hey, i made a helm chart to install kubeflow. Doesnt require modification, helm install will work out of the box, it is based on the manifets repo and argo. Highly customizable, there is an example to expose with ingress and integrate keycloak.

Check it out and open to feedback

https://github.com/TheCodingSheikh/helm-charts/tree/main/charts/kubeflow

[chasecadet]

Hey, i made a helm chart to install kubeflow. Doesnt require modification, helm install will work out of the box, it is based on the manifets repo and argo. Highly customizable, there is an example to expose with ingress and integrate keycloak.

Check it out and open to feedback

https://github.com/TheCodingSheikh/helm-charts/tree/main/charts/kubeflow

This is awesome! I think what the KSC is working on determining is whether this is a "distribution" or something we move within the main Kubeflow repos. The boundaries of what is core Kubeflow vs. component manifests we support etc.. Right now you can in theory install everything with a single kustomize command, but using best in breed cloud services or other configurations requires effort. Then do you template the patches and how do you potentially tie that into a CI/CD system nicely or just use ArgoCD. This is a great contribution and we eagerly await the KSCs decision so we can figure out the best path forward. Please continue to give feedback here if you have it!

[juliusvonkohout]

From the @kubeflow/kubeflow-steering-committee meeting today:

Voted for by all meeting attending KSC members (4). "Kubeflow Working Groups (WGs) are allowed, but not required, to provide standalone helm charts for their projects."

Not more not less, so do not interpret too much. This is not supposed to answer all questions and possibilities, but to allow us to move forward with the GSOC project and see how far we get.

@chasecadet

[rareddy]

Good news! Thank you for sharing the information.

[kromanow94]

Hi all,

Thanks for the detailed proposal and all the great work in pushing forward official Helm support for Kubeflow.

I'd like to propose and outline an alternative chart structure that addresses some of the limitations of Helm's dependency system while supporting modularity, reusability, and vendor extensibility.

---

🔍 Motivation

The current proposal describes a structure where each Kubeflow component maintains its own Helm Chart, and a top-level AIO (all-in-one) chart acts as an umbrella by declaring those components as dependencies. While this works well, it introduces a known limitation:

Helm only supports one level of dependencies. This means that the AIO Helm Chart cannot itself be used as a dependency of another Helm Chart (e.g., by a vendor or platform team), because Helm does not allow recursive umbrella charts. Reference: https://github.com/helm/helm/issues/2247

To support advanced use cases such as vendor charts or GitOps-first workflows, I propose an alternative that avoids Helm dependencies altogether. This structure introduces a clear separation between rendered manifests and reusable logic. It uses Git submodules for composition rather than relying on Helm’s dependency resolution, making the architecture more extensible and suitable for complex multi-layered setups.

---

🧩 Proposed Structure

Each major component (e.g., Pipelines, Central Dashboard, Notebooks) is maintained under their respective repository. In this structure, the templates/ directory is consistently split into two subdirectories:

• helpers/: contains shared template functions (e.g., _*.tpl), brought in via git submodules pointing to helm-toolkit

• manifests/: contains component-specific Kubernetes YAML templates rendered by Helm The file structure separates templated manifests from helper functions, and uses Git submodules to compose the AIO chart. Here's how it looks in practice:

Shared Templates Repository (helm-toolkit)

helm-toolkit/
└── templates/
    ├── _common.labels.tpl
    ├── _kubeflow.centraldashboard.tpl                 <- Helpers to be reused in controller, jupyter-web-app
    ├── _kubeflow.centraldashboard.controller.tpl
    ├── _kubeflow.centraldashboard.jupyter-web-app.tpl
    ├── _kubeflow.pipelines.tpl                        <- Helpers to be reused in mlpipeline, mlpipeline-cache, and so on
    ├── _kubeflow.pipelines.mlpipeline.tpl
    ├── _kubeflow.pipelines.mlpipeline-cache.tpl
    └── ...

🔁 This repo is included as a submodule in all components under templates/helpers/.

Component Chart Example (kubeflow/experimental/helm/{centraldashboard,notebooks})

kubeflow/
└── experimental/
    └── helm/
        ├── centraldashboard/
        │   ├── Chart.yaml
        │   └── templates/
        │       ├── helpers/             ← Git submodule → helm-toolkit/templates
        │       └── manifests/
        │           ├── deployment.yaml
        │           └── configmap.yaml
        └── notebooks/
            ├── Chart.yaml
            └── templates/
                ├── helpers/             ← Git submodule → helm-toolkit/templates
                └── manifests/
                    ├── controller
                    │   ├── deployment.yaml
                    │   └── configmap.yaml
                    └── jupyter-web-app
                        ├── deployment.yaml
                        └── configmap.yaml

# Alternative setup with one Helm Chart for all components under this repo

kubeflow/
└── experimental/
    └── helm/
        ├── Chart.yaml
        └── templates/
            ├── helpers/                  <- Git submodule → helm-toolkit/templates
            └── manifests/
                ├── centraldashboard/
                │    ├── deployment.yaml
                │    └── configmap.yaml
                └── notebooks
                     ├── controller
                     │   ├── deployment.yaml
                     │   └── configmap.yaml
                     └── jupyter-web-app
                         ├── deployment.yaml
                         └── configmap.yaml

Component Chart Example (pipelines/experimental/helm)

pipelines/
└── experimental/
    └── helm/
        ├── Chart.yaml
        └── templates/
            ├── helpers/                  <- Git submodule → helm-toolkit/templates
            └── manifests/
                ├── mlpipeline-api
                │   ├── deployment.yaml
                │   └── configmap.yaml
                ├── mlpipeline-cache
                │   ├── deployment.yaml
                │   └── configmap.yaml
                ├── metadata-writer
                │   ├── deployment.yaml
                │   └── configmap.yaml
                └── scheduledworkflow
                    ├── deployment.yaml
                    └── configmap.yaml

AIO Helm Chart (manifests/experimental/helm)

manifests/
└── experimental/
    └── helm/
        ├── Chart.yaml                  ← AIO Chart - does NOT use dependencies in Chart.yaml
        └── templates/
            ├── helpers/                ← Git submodule → helm-toolkit/templates
            ├── centraldashboard/       ← Git submodule → kubeflow/.../centraldashboard/templates/manifests
            ├── pipelines/              ← Git submodule → pipelines/.../templates/manifests
            ├── istio-integration/      ← Templated manifests like Gateway, cluster-jwks-proxy, RequestAuthentication. This could also be a part of the helm-toolkit.
            │   ├── cluster-jwks-proxy/
            │   ├── external-auth/
            │   ├── istio-m2m/
            │   └── gateway.yaml
            └── dex-integration/        ← Templated manifests like VirtualService. This could also be a part of the helm-toolkit.
                └── virtualservice.yaml

---

✅ Benefits

Structural Scalability

• Avoids Helm's recursive dependency limitation — the AIO chart does not define dependencies, allowing it to be included in vendor charts.

• Modular and composable architecture — components are deployable standalone, and can be composed without Helm’s dependency system.

• Vendor flexibility — enables easy extension or composition without hitting Helm’s single-level dependency limit.

Maintainability & Reusability

• Clear separation of concerns — reusable template logic (helpers/) is decoupled from component manifests.

• Centralized helper management — shared _*.tpl functions are maintained in helm-toolkit, reducing duplication.

• DRY by design — all charts pull from the same set of helpers via submodules, ensuring consistency.

Compatibility & Workflow

• GitOps-friendly — works seamlessly with tools like ArgoCD and Flux due to the flat structure and explicit submodules.

---

🧠 Origin and Reference

This structure comes from my experience developing and maintaining a working "Mega Kubeflow Helm Chart", available here: ➡️ https://github.com/kromanow94/kubeflow-manifests/releases/tag/kubeflow-0.5.0

It also draws inspiration from other large-scale Helm projects such as openstack-helm, which has a similar modular layout. In openstack-helm:

• Common logic is extracted into a dedicated chart called helm-toolkit,

• Each service (e.g., Neutron) is defined as a separate Helm chart,

• AIO-style orchestration is done in the openstack chart.

You can explore more here:

• openstack-helm (all-in-one chart)

• helm-toolkit (shared helpers)

• neutron (single component example)

🚀 Final Thoughts

If one-level nesting is acceptable, the current direction is sound. But if we want to support higher-level reuse and allow vendors/platforms to compose Kubeflow flexibly, this alternative provides a scalable, modular, and Helm-compliant solution.

Would the community be open to exploring this model as a prototype or RFC-style implementation? I'm happy to contribute a working example or engage in further discussion!

[juliusvonkohout]

@kromanow94 do you want to guide @kunal-511 regarding "AIO Helm Chart (manifests/experimental/helm)"

he started here https://github.com/kubeflow/manifests/pull/3154/files

[juliusvonkohout]

The GSOC project with Helm is ongoing, so i plan to merge this proposal soon. /approve

[google-oss-prow[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: juliusvonkohout

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [juliusvonkohout]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[andreyvelich]

@juliusvonkohout Before merging this KEP, we need to ensure that we update the proposal. For example, we will only maintain Helm Charts for individual projects. /hold

[juliusvonkohout]

@juliusvonkohout Before merging this KEP, we need to ensure that we update the proposal. For example, we will only maintain Helm Charts for individual projects. /hold

can you make direct code suggestions then ?

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[juliusvonkohout]

The implementation is progressing as experimental POC.