KubeVela

Term 2 · Jun-Aug · 2 projects

• LRU Cache Eviction for the Native Helm Provider

  LFX Mentorship · Listed in the official cohort

  @roguepikachuSource IssueLFX portal

  KubeVela's native Helm provider currently uses a plain sync.Map to cache fetched charts on the controller, keyed by chart-version with TTL-based expiry (24h immutable / 5m mutable). Because the reconciler is stateless and re-renders every Application on every 5-minute resync, this cache sits on the hot path for every reconcile. At scale — 100+ Applications consuming different charts — the unbounded sync.Map grows monotonically until the controller pod is OOM-killed. Parsed *chart.Chart Go objects are 2–10MB each, so 200 cached charts can mean 1–2GB of memory with no eviction until TTL expires. Deleted Applications' charts also linger for the full TTL window, and there is no mechanism to reclaim memory under pressure. This mentorship will design and implement an LRU eviction layer with configurable byte-size limits, packaged as a generic, Helm-agnostic cache in pkg/utils/cache/ so it can be reused by the workflow engine and other providers. The mentee will build a generic LRUByteStore on top of hashicorp/golang-lru/v2 with per-entry TTL, byte accounting, and three eviction triggers: synchronous byte-pressure on Put, lazy TTL check on Get, and a periodic background sweep. The Helm provider will switch from caching parsed *chart.Chart objects to compressed .tgz bytes (~20–25× memory reduction), with chartutil.Save / loader.LoadArchive handled in the provider so the cache stays opaque. New controller flags (--helm-cache-max-bytes, --helm-cache-sweep-interval) will be wired through Helm chart values, and the immutable-version TTL extended from 24h to 30d now that LRU handles memory pressure. OnEvicted callbacks will feed Prometheus metrics for hits, misses (by reason), and current cache bytes. The result is a production-ready, reusable cache package that closes a real OOM risk in KubeVela deployments today, with hands-on exposure to Kubernetes controller patterns, Go concurrency, Helm internals, and CUE-driven configuration.

  • Go (idiomatic Go
  • structs
  • interfaces
  • generics
  • sync primitives)
  • Kubernetes (controllers
  • +19

• Native Secret-Sourced HTTP Headers and CRD-Based Config Management with Server-Side Validation

  LFX Mentorship · Listed in the official cohort

  @Chaitanyareddy0702Source IssueLFX portal

  KubeVela's workflow engine and config management layer have two long-standing production gaps that this mentorship will close together. First, the request workflow step has no native way to source HTTP headers (bearer tokens, API keys, basic auth) from Kubernetes Secrets — users wanting to call authenticated APIs are forced to hardcode credentials directly in the workflow definition, where they end up visible in kubectl get output and Git history. On top of that, attempts to interpolate values into the header map using Go templates or CUE string interpolation regularly conflict with native CUE syntax, producing un-rendered strings or silent execution failures. Second, KubeVela's Config Management today stores ConfigTemplates as labeled ConfigMaps (config-template-* prefix) and Configs as labeled Secrets — there are no proper Kubernetes API types (kubectl get configs returns nothing meaningful), and all CUE schema and validation.$returns checks run client-side in the vela CLI. Configs created through any other path (workflow steps, VelaUX, direct kubectl apply) bypass validation entirely, so the same template enforces different rules depending on the entry point. The mentee will tackle both. The first deliverable extends the HTTP provider in kubevela/workflow with a headerFromSecret field that resolves values from Kubernetes Secrets natively in Go (mirroring how the same provider already handles Secrets for tlsConfig), and exposes it as a first-class CUE parameter — bypassing the templating layer entirely. The second introduces a proper Kubernetes API group, config.oam.dev/v1alpha1, with ConfigTemplate and Config CRDs, event-driven controllers built on controller-runtime, and validating admission webhooks that move CUE validation server-side. Sensitive properties never live in the CRD — they sit in a separate Secret referenced via propertiesFrom.secretRef. A dual-read controller preserves full backward compatibility: legacy ConfigMap templates, old CLI versions, and existing Secret-based configs continue to work without disruption. Together, the two deliverables harden KubeVela's HTTP integration surface and modernize its configuration layer into a Kubernetes-native, GitOps-friendly API.

  • Go (idiomatic Go
  • structs
  • interfaces
  • error handling
  • net/http
  • context)
  • +20

Term 1 · Mar-May · 1 project

• Support versioning for definitions

  LFX Mentorship · Listed in the official cohort

  @FogDongSource IssueLFX portal

  In KubeVela, X-Definitions provide the foundation for users to construct their applications. Currently we will automatically upgrade the definitions' version for our users, however, we still need the capability of explicit versioning in definitions. With this feature, our users can now manage the version easily for application upgrades and migrations.

  • Go
  • Kubernetes

Term 3 · Sep-Nov · 1 project

• Support auto generation of multiple languages SDK from CUE II

  LFX Mentorship · Listed in the official cohort

  @chivalryqSource IssueLFX portal

  In KubeVela, we use CUElang to code the X-Definition. We want to support auto generation of multiple languages SDK from CUE, so that users can buidling KubeVela Application in their own language. This helps to adoptors to build platform based on KubeVela.

  • Java
  • Typescript
  • Python
  • Kubernetes
  • CUE

Term 2 · Jun-Aug · 2 projects

• Auto-generate the TypeScript and Java languages API SDK

  LFX Mentorship · Listed in the official cohort

  @chivalryqSource IssueLFX portal

  The VelaUX API server follows the Open API schema. It could auto-generate the swagger configs via CLI. When VelaUX frontend or other projects need to call these API, they must write the model code and request the API code. We can provide SDK for them to start faster. OpenAPI generator could help to generate most codes. But there are still some special cases like: Dynamic component/trait/policy/workflowsteps properties need to be generated according to CUE. Automatically handles the user authentication process, including automatically refreshing tokens. The API definition may be incomplete accuracy, we should check it to generate high-quality code.

  • Go
  • Kubernetes
  • Backend APIs Development
  • OpenAPI schema
  • CUE

• Expand multiple database drivers for the API server

  LFX Mentorship · Listed in the official cohort

  @chivalryqSource IssueLFX portal

  Now KubeVela's VelaUX uses two kinds of Database to store metadata: Kubernetes ConfigMap and MongoDB. As more users are expecting using different kinds of database. We proposing to expanding multiple database drivers for the VelaUX API server.

  • Go
  • Kubernetes
  • Backend APIs Development

Term 1 · Mar-May · 3 projects

• Extend the capability of KubeVela by making several useful addons

  LFX Mentorship · Listed in the official cohort

  @wonderflowSource IssueLFX portal

  KubeVela currently have a variety of addons , including experimental options, that address scenarios such as Continual Delivery and observability. To further enhance the out-of-box functionality for users of KubeVela, we can offer additional useful addons.

  • Go
  • kubernetes
  • cueLang

• Support auto generation of CUE schema and docs from Go struct

  LFX Mentorship · Listed in the official cohort

  @FogDongSource IssueLFX portal

  In KubeVela's provider system, we can use our defined Go functions in CUE schema. The Go providers usually have a parameter and return. Fields in Go providers are the same as fields in CUE schema, so it is possible and important to support automatic generation of CUE schemas and documents from Go structs.

  • Go
  • CUE

• Support auto generation of multiple languages SDK from CUE

  LFX Mentorship · Listed in the official cohort

  @chivalryqSource IssueLFX portal

  In KubeVela, we use CUElang to code the definition. We want to support auto generation of multiple languages SDK from CUE, so that users can use KubeVela in their own language.

  • Go
  • Kubernetes
  • CUE

Term 0 · 2022 Spring (Mar-May) · 3 projects

• Enhance multi-cluster observability

  LFX Mentorship · Listed in the official cohort

  @wonderflowSource IssueLFX portal

  KubeVela is a modern application delivery platform based on Kubernetes. It is currently a CNCF Sandbox project. KubeVela supports managing application delivery in multi-clusters. One of the basic problem is to validate the health status of managed clusters. Besides, it is also useful to integrate other metrics like CPU core usage or number of available graphical cards. This project aims to establish a mechanism to support these features.

  • Go
  • Kubernetes

• Extend monitoring through VelaQL

  LFX Mentorship · Listed in the official cohort

  @wonderflowSource IssueLFX portal

  KubeVela is a modern application delivery platform based on Kubernetes. It is currently a CNCF Sandbox project. In KubeVela, a CUE-based query mechanism is developed to satisfy the demands of advanced queries behind Kubernetes resources, which is called VelaQL. This project aims to make extensions to this mechanism and support monitoring Kubernetes resources through VelaQL. For example, monitoring the logs of pods in KubeVela Application behind Grafana.

  • Go
  • Kubernetes

• Management of Terraform state

  LFX Mentorship · Listed in the official cohort

  @zzxwillSource IssueLFX portal

  To some extent, Terraform state is the most essential component for cloud resources provisioned by Terraform Controller. We need to better manage the state.

  • Go
  • Terraform

Term 0 · 2021 Fall (Sep-Nov) · 4 projects

• Build Gitops continuous deployment tools on kubevela

  LFX Mentorship · Listed in the official cohort

  @leejaneeSource IssueLFX portal

  Kubevela is like Lego, you can build any platform you need based on kubevela. And GitOps is very popular and user friendly. In this project, we will build Gitops continuous deployment tools on kubevela.

  • Go
  • Kubernetes

• Building An Machine Learning Platform on KubeVela

  LFX Mentorship · Listed in the official cohort

  @hongchaodengSource IssueLFX portal

  Data scientists need a ML platform to develop, test, and deploy ML models easily. In this project, we will design and build a self-service ML platform on top of KubeVela. We will use KubeVela to provide high level workflow and APIs to glue and simplify deployment pipelines. We will also use Cloud resources to support deployment and operations tasks like domain routing, monitoring, health checking, etc.

  • Go
  • Kubernetes

• Integration with developing time to provide consistent experience

  LFX Mentorship · Listed in the official cohort

  @wonderflowSource IssueLFX portal

  Users can use KubeVela to do application delivery and management. In this project, we hope to integrate KubeVela with developing time. So developers can have a consitent experience between local development and production deploy. There're multiple developing tools such as Tilt or Nocalhost, both of them can integrate with KubeVela by supporting KubeVela Application YAML.

  • Go
  • Kubernetes

• Support remote Terraform HCL (Git repo or ConfigMap) in Terraform Controller

  LFX Mentorship · Listed in the official cohort

  @zzxwillSource IssueLFX portal

  Currently Terraform Controller supports inline HCL, but community users normally already stored Terraform HCLs remotely (in Git repo or ConfigMap). Terraform Controller should support remote HCLs.

  • Go
  • Terraform