CNCF lfx-mentorship Term 01: call for project ideas

[XiShanYongYe-Chang]

Dear Karmada adopters, lfx-mentorship Term 01 - 2026 March - May is coming soon. We sincerely invite you to submit your project ideas.

If you have any business needs for Karmada, or have made some code modifications to the community and want to push these changes into the community, you can leave a comment. In addition, you can also contact us to recommend mentees to apply for the LFX event.

LFX Background Information

• Introduction of LFX Platform: https://docs.linuxfoundation.org/lfx
• Become a mentor: https://docs.linuxfoundation.org/lfx/mentorship/mentors
• Become a mentee
  • Eligibility Rules for Mentees: https://docs.linuxfoundation.org/lfx/mentorship/mentees
  • Mentee Stipends: https://docs.linuxfoundation.org/lfx/mentorship/mentee-stipends
• TimeLine for Term 01: https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2026/01-Mar-May

Mentees are not limited to students; they can also be beginners in open-source projects.

Given that the Term 01 2026 project submission has time requirements Wednesday, January 7 – Tuesday, January 20, 2026, we would like to remind you to pay special attention to the deadlines.

Once the community has finalized the projects to be applied for, the community will arrange the submission of applications uniformly, so you don't need to worry about it.

Expectations for the project

Based on our experience with LFX projects, an ideal project should have the following characteristics:

• Clear project objectives with a relatively well-defined plan (complete solutions are not required, leaving some room for student learning).
• Moderate difficulty level; for large-grained features in community roadmaps, sub-tasks can be derived.
• A development cycle of approximately 2.5 months, with work volume matching this timeline and allowing for community communication lead times.
• Project topics can be derived from:
  • Actual business needs of users
  • Planned features
  • Iteration features
  • Testing
  • Dashboard
  • Documentation
  • Performance
• Projects should provide positive value to the community rather than future development burdens.

Q&A

Q: Who can submit projects?
A: All Karmada adopters and active contributors in the Karmada community can submit projects. Even if projects lack a complete plan and don't make it in LFX term 1, the community encourages iterating on proposals and applying to subsequent programs (LFX, Open Source Summer, GSoC, etc.).

Q: LFX project quantity limits?
A: Each CNCF project can submit 4-5 project proposals per LFX quarter (term). Based on experience, this number is ample, so you can feel free to propose.

Q: How to Become a Project Mentor
A: Each LFX project proposal should provide information about two mentors. The person who provides the project idea has the priority to become a mentor, or may recommend someone else to be a mentor, provided that the mentor is informed and agrees in advance.

Welcome to leave comments below. Thank you!

[XiShanYongYe-Chang]

Hi team, hope you're all doing great! Quick note that your feedback as adopters would be super valuable – feel free to share whatever insights you have.
/cc @karmada-io/karmada-adopter-group

[agrawalcodes]

Hi @XiShanYongYe-Chang,
Currently karmada repo seems to have a test coverage of around 47% and pkg directory specifically 49%. This can be a possible LFX project considering the amount of improvements that can be done and impact on reliability. It would also be good project for newbie karmada contributors like me.

[FAUST-BENCHOU]

@XiShanYongYe-Chang
I believe we can leverage the opportunity with Term1 to address the entire umbrella issue (karmada-io/karmada#6780
) in order to reduce unnecessary resource watch events. This should not be a difficult task for community newcomers, but the progress on the open PRs in this issue has currently stalled.

[RainbowMango]

Propose one project idea based on the background:

Karmada is a multi-cluster orchestration system that manages multiple Kubernetes clusters. The project consists of several components (e.g., controller-manager, scheduler, karmada-search, etc.), each accepting various command-line flags for configuration. These flags come from multiple sources:

1. Third-party dependencies (e.g., Kubernetes, controller-runtime)
2. Custom flags defined by Karmada itself

During dependency upgrades or internal refactoring, flags can be unexpectedly added, removed, or modified, potentially impacting users who rely on specific configurations. This project aims to create comprehensive documentation and tooling to track and document all flags for Karmada's maintained components, establishing a baseline to detect and manage flag changes carefully.

Protect Karmada Component Flags from Unexpected Changes

• Description: The Karmada project consists of several components (e.g., controller-manager, scheduler, karmada-search, etc.), each accepting various command-line flags for configuration. These flags come from multiple sources: third-party dependencies (e.g., Kubernetes, controller-runtime) and custom flags defined by Karmada itself. During dependency upgrades or internal refactoring, flags can be unexpectedly added, removed, or modified, potentially impacting users who rely on specific configurations. This project aims to create comprehensive documentation and tooling to track and document all flags for Karmada's maintained components, establishing a baseline to detect and manage flag changes carefully.
• Expected Outcome:
  • Comprehensive flag documentation for all Karmada components (controller-manager, scheduler, karmada-search, webhook, aggregated-apiserver, descheduler, metrics-adapter, scheduler-estimator)
  • Automated flag extraction and documentation generation tool
  • CI/CD pipeline integration to detect and alert on flag changes
  • Documentation of flag lifecycle management (deprecation, removal)
• Recommended Skills:
  • Go programming language
  • Kubernetes and its flag management patterns
  • Bash/shell scripting
  • CI/CD systems (GitHub Actions)
  • Documentation tools and best practices
• Mentor(s): Zhen Chang @XiShanYongYe-Chang, changzhen5@huawei.com, Hongcai Ren @RainbowMango qdurenhongcai@gmail.com
• Upstream Issue: TBD

[NickYadance]

@XiShanYongYe-Chang A simple idea based on my daily usage of Karmada.

The pp and op of one particular resource almost always pair with each other, it might save some management headache if they can be grouped into one policy, and make the resource more 'What You See Is What You Get'. Take sample nginx deployment for example, it needs a pp:

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2

and a op:

apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
  name: nginx-op
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  overrideRules:
    - targetCluster:
        clusterNames:
          - member2
      overriders:
        ...
...

A grouped policy can be like:

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationAndOverridePolicy
metadata:
  name: nginx-propagation-and-overwride-policy
spec:
  resourceSelectors:
      - apiVersion: apps/v1
        kind: Deployment
        name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2
  overrideRules:
    - targetCluster:
        clusterNames:
          - member2
      overriders:
         ...

Besides putting policy in one place, another thing that matters is that sometimes i wish that updates to pp and op can work at the same time, without a temporary stage. This can be useful when new clusters come in, the resource won't be propagated without corresponding op after pp updated.

[XiShanYongYe-Chang]

The pp and op of one particular resource almost always pair with each other, it might save some management headache if they can be grouped into one policy, and make the resource more 'What You See Is What You Get'.

Hi @NickYadance, Thank you for your feedback. This idea involves changes to the core API of Karmada, and the decision might not be made in the short term. If you are willing, you can first come to the community meeting to discuss this.

updates to pp and op can work at the same time, without a temporary stage.

I think this temporary situation may be caused by the cache not being updated in a timely manner. We can also fully discuss the impact of this. WDYT. By the way, there is a community meeting tomorrow afternoon.

[RainbowMango]

@NickYadance Great, thanks for the feedback. I'm interested in the use case, and it makes sense to me regarding the pain point you mentioned. Would you be available to join the community meeting to discuss it and figure out the next move?

@XiShanYongYe-Chang We are going to discuss all the project ideas at the next community meeting, right?

[XiShanYongYe-Chang]

We are going to discuss all the project ideas at the next community meeting, right?

Here's the thing, let me add an agenda item.

Hi @agrawalcodes @FAUST-BENCHOU If it is convenient for you, you are also welcome to join the meeting.

[zhzhuang-zju]

Propose one project idea:
Enhance Karmada's Quick Start Experience and Incorporate macOS Support

• Description: The initial interaction for many users with a project often begins with its "Quick Start" guide. Ensuring this guide is of high quality and up-to-date is crucial. Currently, the community offers several quick start methods, including a one-click setup script (hack/local-up-karmada.sh), installation tools such as Helm, karmadactl, and the operator, alongside learning tutorials on Killercoda.

  Although the community's CI effectively maintains these installation methods, it lacks support for different operating systems, notably macOS. Furthermore, some Killercoda tutorials are outdated and do not reflect the latest features and best practices. This project aims to ease the entry barrier for new users by enhancing the quick start process, ensuring cross-platform compatibility, and updating educational content.

• Expected Outcome:

  • Verify the feasibility of installing hack/local-up-karmada.sh on macOS environments, including both macOS ARM and Intel and address any issues that arise.
  • Implement a new CI workflow in GitHub Actions to test Karmada's installation and basic functionalities on macOS. GitHub Actions can select specific environments through runs-on, covering both macOS ARM and Intel.
  • Revise existing outdated scenarios on Killercoda and develop valuable new scenarios to guide users through current features. This includes:
    • Extracting common functions from various scenarios to reduce code duplication.
    • Updating the course information of existing scenarios by correcting outdated content and optimizing the material to enhance learning outcomes.
    • Adding new scenarios, such as:
      • A tutorial on FHPA usage.
      • An application-level failover guide.
      • Multi-component workload scheduling (support for workloads common in AI and big data).

• Recommended Skills:

  • Go programming language
  • Familiarity with macOS
  • Bash/shell scripting
  • CI/CD systems (e.g., GitHub Actions)
  • Documentation tools and best practices

• Mentor(s):

  • @zhzhuang-zju
  • @RainbowMango

• Upstream Issue: TBD

[NickYadance]

The pp and op of one particular resource almost always pair with each other, it might save some management headache if they can be grouped into one policy, and make the resource more 'What You See Is What You Get'.

Hi @NickYadance, Thank you for your feedback. This idea involves changes to the core API of Karmada, and the decision might not be made in the short term. If you are willing, you can first come to the community meeting to discuss this.

updates to pp and op can work at the same time, without a temporary stage.

I think this temporary situation may be caused by the cache not being updated in a timely manner. We can also fully discuss the impact of this. WDYT. By the way, there is a community meeting tomorrow afternoon.

Yes i understand, let's discuss this in the community meeting. Also let me explain this with a bit more detail.

The idea of atomic resource propagation policy: combine propagationpolicy and overwridepolicy together to propagate resource atomicly.

User Case:

1. User manages a multi-subset resource with openkruise UnitedDeployment. Subsets topology is decided by pp for different regions, and op set region specific values for each subset. User needs to update pp and op sequentially to update subsets topology, which can result in temporarily topology broken.
2. User manages resource through the openapi of karmada control panel, needs consistent resource update process without worrying about rollback when pp or op failed.
3. User manages many pp and op, updates in different places are more prone to errors.

[zach593]

The idea of atomic resource propagation policy: combine propagationpolicy and overwridepolicy together to propagate resource atomicly.

@NickYadance However, if we think one step further, atomicity still cannot be guaranteed between updating the resource template and updating OP/COP. In practice, modifying both as part of the same release is actually more common. But if we merge PP, OP, and the template all together, we would essentially be going back down the old Kubefed path.

---

Improve Karmada's Quick Start Experience and Add macOS Support

@zhzhuang-zju I recently ran into an issue where this script could not be used on macOS, even though I did notice some macOS-related hints when starting the script. At first, I thought the failure was caused by my use of Podman (Docker is not allowed on our work machines), but this may only be part of the reason. Perhaps supporting different OCI implementations could also be considered as part of this effort.

[NickYadance]

@zach593 True, the atomicity needs to be considered carefully. The template cannot be mixed with op/pp, that is the baseline for sure.

[vie-serendipity]

Proposal Information

Make each controller operation auditable in the karmada controller manager.

• Description: The current Karmada Controller Manager contains multiple controllers, and some resources may be operated by different controllers simultaneously. From an auditing perspective, it is currently impossible to determine which specific controller performed an operation on the resource. Therefore, it should be reasonable that every controller use its specific user agent name, just like what kube controller manager does right now. It'd be better to abstract this capability in a non-customized way so that future-added controllers or user-developed controllers can directly adapt.

• Expected Outcome:

  • Users can quickly see which controller did a particular action on a resource from audit logs. This would be helpful for troubleshooting and locating the problem.

• Recommended Skills:

  • Familiarity with Golang, Kubernetes, and Karmada.
  • Basic understanding of auditing.

• Mentor(s): TBD

• Upstream Issue: TBD

Example

• enhance: separate clients for yurt-manager  openyurtio/openyurt#2069
• https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/controller-manager/pkg/clientbuilder/client_builder.go

I think every controller should use different client. But for RBAC, it might be unnecessary. We also should pay attention to the problems that come with it, such as how qps and burst adapt into new arch when different controllers use different clients.

[warjiang]

placeholder for 「OminiControl for Karmada Dashboard」

OmniControl for Karmada Dashboard

Description:
We have already implemented management for all types of resources on the control plane and for particial resources on member clusters in the Karmada Dashboard. However, resource management is currently atomic, and the relationships between resources are not presented intuitively. As a result, users may find it difficult to understand and manage relationship across resources.

For example:

1. On the control plane, after a user creates a ResourceTemplate, it is not easy to tell which Policy matched that ResourceTemplate and then generated the corresponding ResourceBinding and subsequent Work resources.
2. Across the control plane and member clusters plane, users cannot easily see which member clusters a ResourceTemplate has been propagated to, or the status of the distributed resources in each member cluster.

Therefore, we aim to provide a unified management and control capability (OmniControl). From the perspective of ResourceTemplate, users should be able to view the resource’s status on both the control plane and member clusters plane, building on the existing atomic capabilities. This will help users understand the end-to-end status of resources more intuitively and quickly identify and resolve issues when propagation or distribution failures occur.

Expected Outcome:

• Comprehensive design and API documentation
• Topology visualization of Karmada core resources and Kubernetes resources (Karmada architecture diagram)
• Control-plane resource integration: users can view details of policy resources and multi-cloud resources by clicking the corresponding nodes in the topology graph (read-only)
• Member-cluster resource integration: users can view details of Kubernetes resources (including workloads, configs, and services) with the same UX
• A demo showcasing abnormal resource distribution cases (e.g., insufficient GPU resources; one example is sufficient)

Recommended Skills:

• Go
• Kubernetes
• React
• CI/CD systems (GitHub Actions)
• Documentation tools and best practices

Mentor(s): TBD @warjiang @RainbowMango

Upstream Issue: TBD karmada-io/dashboard#227