[ { "path": ".github/ISSUE_TEMPLATE/lfx-mentoring.md", "content": "---\n[Asana task link (CNCF internal)]()\n" }, { "path": ".github/labeler.yml", "content": "#\n# Add project labels\n#\n\n# Add 'summer of code' label to any files in the Summer of Code project\n'summer of code':\n - programs/summerofcode/*\n - programs/summerofcode/**/*\n\n# Add 'season of docs' label to any files in the season of docs project\n'season of docs':\n - programs/seasonofdocs/*\n - programs/seasonofdocs/**/*\n\n# Add 'lfx mentorship' label to any files in the lfx mentorship project\n'lfx mentorship':\n - programs/lfx-mentorship/*\n - programs/lfx-mentorship/**/*\n\n#\n# Add date/term specific labels\n#\n\n# Add '2023' to any change to 2023 project files\n2023:\n - programs/summerofcode/2023.md\n - programs/lfx-mentorship/2023/*\n - programs/lfx-mentorship/2023/**/*\n - mentoring-wg/2023-meeting-minutes.md\n\n# Add '2024' to any change to 2024 project files\n2024:\n - programs/summerofcode/2024.md\n - programs/lfx-mentorship/2024/*\n - programs/lfx-mentorship/2024/**/*\n\n# Add '2025' to any change to 2025 project files\n2025:\n - programs/summerofcode/2025.md\n - programs/lfx-mentorship/2025/*\n - programs/lfx-mentorship/2025/**/*\n\n# Add '2026' to any change to 2026 project files\n2026:\n - programs/summerofcode/2026.md\n - programs/lfx-mentorship/2026/*\n - programs/lfx-mentorship/2026/**/*\n\n# Add 'Term 1: March-May' label to files for that term\n'Term 1: March-May':\n - programs/lfx-mentorship/2023/01-Mar-May/*\n - programs/lfx-mentorship/2023/01-Mar-May/**/*\n - programs/lfx-mentorship/2024/01-Mar-May/*\n - programs/lfx-mentorship/2024/01-Mar-May/**/*\n - programs/lfx-mentorship/2025/01-Mar-May/*\n - programs/lfx-mentorship/2025/01-Mar-May/**/*\n - programs/lfx-mentorship/2026/01-Mar-May/*\n - programs/lfx-mentorship/2026/01-Mar-May/**/*\n\n# Add 'Term 2: June-Aug' label to files for that term\n'Term 2: June-Aug':\n - programs/lfx-mentorship/2023/02-Jun-Aug/*\n - programs/lfx-mentorship/2023/02-Jun-Aug/**/*\n - programs/lfx-mentorship/2024/02-Jun-Aug/*\n - programs/lfx-mentorship/2024/02-Jun-Aug/**/*\n - programs/lfx-mentorship/2025/02-Jun-Aug/*\n - programs/lfx-mentorship/2025/02-Jun-Aug/**/*\n - programs/lfx-mentorship/2026/02-Jun-Aug/*\n - programs/lfx-mentorship/2026/02-Jun-Aug/**/*\n\n# Add 'Term 3: Sept-Nov' label to files for that term\n'Term 3: Sept-Nov':\n - programs/lfx-mentorship/2023/03-Sep-Nov/*\n - programs/lfx-mentorship/2023/03-Sep-Nov/**/*\n - programs/lfx-mentorship/2024/03-Sep-Nov/*\n - programs/lfx-mentorship/2024/03-Sep-Nov/**/*\n - programs/lfx-mentorship/2025/03-Sep-Nov/*\n - programs/lfx-mentorship/2025/03-Sep-Nov/**/*\n - programs/lfx-mentorship/2026/03-Sep-Nov/*\n - programs/lfx-mentorship/2026/03-Sep-Nov/**/*\n" }, { "path": ".github/settings.yml", "content": "repository:\n # See https://developer.github.com/v3/repos/#edit for all available settings.\n\n # The name of the repository. Changing this will rename the repository\n name: mentoring\n\n # A short description of the repository that will show up on GitHub\n description: 👩🏿‍🎓👨🏽‍🎓👩🏻‍🎓CNCF Mentoring + CommunityBridge + Summer of Code\n\n # A URL with more information about the repository\n homepage: https://mentoring.cncf.io\n\nlabels:\n - name: lfx mentorship\n color: a2dcf2\n - name: enhancement\n color: 84b6eb\n - name: help wanted\n color: ffff54\n - name: good first issue\n color: ff8c00\n - name: hold\n color: d93f0b\n - name: time-sensitive\n description: issues or PRs that have a due date\n color: b60205\n - name: getting started\n color: 3B8924\n - name: outreachy\n color: 7fd811\n - name: season of docs\n color: f4af97\n - name: summer of code\n color: 00ffff\n - name: season of docs\n color: 00ff80\n - name: spring\n color: 1ED626\n - name: \"Term 1: March-May\"\n color: 1ED626\n - name: summer\n color: FBCA04\n - name: \"Term 3: Sept-Nov\"\n color: FBCA04\n - name: fall\n color: C5DEF5\n - name: \"Term 2: June-Aug\"\n color: C5DEF5\n - name: '2022'\n color: 0052CC\n - name: '2023'\n color: 0052CC\n - name: '2024'\n color: 0052CC\n - name: '2025'\n color: 0052CC\n - name: '2026'\n color: 0052CC\n - name: discussion\n color: af17d7\n - name: administration\n color: e3ead3\n - name: Awaiting Mentor Confirmation\n color: E99695\n - name: Mentors Confirmed\n color: D93F0B\n - name: Awaiting Maintainer/Contribex Approval\n color: D4C5F9\n - name: Maintainer/Contribex Approved\n color: 5319E7\n # one \"blank\" line\n - name: blank\n\n" }, { "path": ".github/workflows/prlabeler.yml", "content": "# This workflow is based on github action official label action v4.\n# This workflow action is triggered on pull request event(on both fork & inside repo)\n# Labels will be applied based on filepath modification in PR.\n# This workflow uses a regex based labeling config file(.github/labeler.yml) to take labeling decision.\n\nname: \"PR Labeler\"\non:\n- pull_request_target\njobs:\n label:\n permissions:\n contents: read\n pull-requests: write\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions/labeler@v4\n with:\n repo-token: \"${{ secrets.GITHUB_TOKEN }}\"\n configuration-path: \".github/labeler.yml\"\n sync-labels: false" }, { "path": "CONTRIBUTING.md", "content": "# Contributing to cncf/mentoring\n\nThis is the starting point for contributing to the [CNCF TOC Mentoring Subproject](https://github.com/cncf/mentoring/blob/main/cncf-toc-mentoring-subproject/README.md). Welcome, and thanks for your interest!\n\n\n## Prerequisites\n\nBefore contributing, you must:\n\n- Read and follow the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)\n- Familiarize yourself with the [repository structure](README.md) and existing content\n- Read this guide in full\n\n\n## Labels\n\nIssues in this repository use labels to indicate the type of contribution needed. Pay attention to these labels before starting work:\n\n\n### `administration`\n\nIssues labeled `administration` involve the operational work of running the mentoring subproject (scheduling, process changes, tooling, etc.). These require context and coordination with the subproject team. **Do not open PRs for `administration` issues without first discussing with the subproject team**. see [How to reach us](#how-to-reach-us) below.\n\n\n### `discussion`\n\nIssues labeled `discussion` are conversation starters, not tasks. They are used to gather input and explore ideas. A `discussion` issue does not mean \"write a document and open a PR.\" Participate in the discussion on the issue itself, or bring it up in a meeting or on Slack.\n\n\n## How to reach us\n\n- **Monthly meeting**: [CNCF TOC Mentoring Subproject public meeting](https://zoom-lfx.platform.linuxfoundation.org/meetings/toc-mentoring-subproject?view=month) 3rd Thursday of the month at 10:00 AM Pacific Time\n- **Slack**: [#toc-mentoring-subproject](https://cloud-native.slack.com/archives/C09C9EGPJAC) on [CNCF Slack](https://slack.cncf.io/)\n- **Discussion boards**: [GitHub Discussions](https://github.com/cncf/mentoring/discussions)\n- **Email**: mentoring@cncf.io (for private matters only; use public channels when possible)\n\n\n## Contributing mentorship projects\n\nTo propose a project for one of the mentoring terms ([LFX Mentorship](programs/lfx-mentorship/README.md), [GSoC](programs/summerofcode/README.md)), you should:\n\n1. **Be a maintainer or approver** of the CNCF project you are proposing work for, and have a maintainer's explicit support\n2. Follow the project idea template in the relevant program folder ([LFX Mentorship](programs/lfx-mentorship/README.md), [GSoC](programs/summerofcode/README.md)) each program has its own template with program-specific requirements\n3. Submit your PR to the appropriate term folder (e.g., `programs/lfx-mentorship/2026/01-Mar-May/`)\n4. Ensure the project scope is appropriate for a full-time, 12-week mentorship\n\nDo not propose mentorship projects on behalf of a CNCF project without the project maintainers' involvement. This volunteers them for significant work they may not have planned for.\n\n\n## Contributing to mentorship guides and processes\n\nBefore starting work on a guide or process update, please do **at least one** of the following:\n\n- Join the [monthly CNCF TOC Mentoring Subproject public meeting](https://zoom-lfx.platform.linuxfoundation.org/meetings/toc-mentoring-subproject?view=month) to discuss your proposal\n- Join us in the [CNCF Slack's](https://slack.cncf.io/) [#toc-mentoring-subproject](https://cloud-native.slack.com/archives/C09C9EGPJAC) channel to discuss\n- Discuss the updates you'd like to make on the relevant issue before opening a PR\n\n**Guide and process pull requests opened without prior discussion are very likely to be closed without consideration.**\n\nMany of the guides and processes in this repository reflect decisions made over time by the subproject team. Changes to them require context that may not be obvious from reading the issue alone. When in doubt, ask first.\n\n\n## General PR guidelines\n\n- Read the issue carefully before starting work. Make sure you understand what is being asked and whether the issue is ready for a PR.\n- Comment on the issue with your intended approach. Describe what you plan to change and why. Wait for acknowledgement from a project admin before opening a PR.\n- PRs opened without prior discussion and explicit approval of the implementation approach will not be reviewed and will be closed without consideration.\n- **Keep PRs focused**. Don't include unrelated changes from other issues or previously declined PRs.\n- Check if an issue is still open and active before working on it. Issues may have been closed or decisions may have changed.\n- Respond to review feedback promptly. PRs that go stale will be closed.\n\n\n## Developer Certificate of Origin\n\nThis project uses the [DCO (Developer Certificate of Origin)](https://probot.github.io/apps/dco/). All commits must be signed off to certify that you wrote or have the right to submit the code.\n\nSign your commits with:\n```\ngit commit -s -m \"your commit message\"\n```\nThis appends a `Signed-off-by: Your Name ` line to your commit. PRs with unsigned commits will not be merged.\n\n\n## A note on AI-generated contributions\n\nWe welcome contributions from anyone, but we expect contributors to understand what they are submitting. Pull requests that appear to be generated by AI tools without the contributor understanding the context, content, or implications of their changes, will be closed.\n\nIf you use AI tools to assist with your contribution, that's fine but you are responsible for the accuracy, relevance, and quality of the final result. If you can't explain why your change is needed and how it fits into the project, it's not ready to submit.\n\n" }, { "path": "LICENSE", "content": " Apache License\n Version 2.0, January 2004\n http://www.apache.org/licenses/\n\n TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n 1. Definitions.\n\n \"License\" shall mean the terms and conditions for use, reproduction,\n and distribution as defined by Sections 1 through 9 of this document.\n\n \"Licensor\" shall mean the copyright owner or entity authorized by\n the copyright owner that is granting the License.\n\n \"Legal Entity\" shall mean the union of the acting entity and all\n other entities that control, are controlled by, or are under common\n control with that entity. For the purposes of this definition,\n \"control\" means (i) the power, direct or indirect, to cause the\n direction or management of such entity, whether by contract or\n otherwise, or (ii) ownership of fifty percent (50%) or more of the\n outstanding shares, or (iii) beneficial ownership of such entity.\n\n \"You\" (or \"Your\") shall mean an individual or Legal Entity\n exercising permissions granted by this License.\n\n \"Source\" form shall mean the preferred form for making modifications,\n including but not limited to software source code, documentation\n source, and configuration files.\n\n \"Object\" form shall mean any form resulting from mechanical\n transformation or translation of a Source form, including but\n not limited to compiled object code, generated documentation,\n and conversions to other media types.\n\n \"Work\" shall mean the work of authorship, whether in Source or\n Object form, made available under the License, as indicated by a\n copyright notice that is included in or attached to the work\n (an example is provided in the Appendix below).\n\n \"Derivative Works\" shall mean any work, whether in Source or Object\n form, that is based on (or derived from) the Work and for which the\n editorial revisions, annotations, elaborations, or other modifications\n represent, as a whole, an original work of authorship. For the purposes\n of this License, Derivative Works shall not include works that remain\n separable from, or merely link (or bind by name) to the interfaces of,\n the Work and Derivative Works thereof.\n\n \"Contribution\" shall mean any work of authorship, including\n the original version of the Work and any modifications or additions\n to that Work or Derivative Works thereof, that is intentionally\n submitted to Licensor for inclusion in the Work by the copyright owner\n or by an individual or Legal Entity authorized to submit on behalf of\n the copyright owner. For the purposes of this definition, \"submitted\"\n means any form of electronic, verbal, or written communication sent\n to the Licensor or its representatives, including but not limited to\n communication on electronic mailing lists, source code control systems,\n and issue tracking systems that are managed by, or on behalf of, the\n Licensor for the purpose of discussing and improving the Work, but\n excluding communication that is conspicuously marked or otherwise\n designated in writing by the copyright owner as \"Not a Contribution.\"\n\n \"Contributor\" shall mean Licensor and any individual or Legal Entity\n on behalf of whom a Contribution has been received by Licensor and\n subsequently incorporated within the Work.\n\n 2. Grant of Copyright License. Subject to the terms and conditions of\n this License, each Contributor hereby grants to You a perpetual,\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n copyright license to reproduce, prepare Derivative Works of,\n publicly display, publicly perform, sublicense, and distribute the\n Work and such Derivative Works in Source or Object form.\n\n 3. Grant of Patent License. Subject to the terms and conditions of\n this License, each Contributor hereby grants to You a perpetual,\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n (except as stated in this section) patent license to make, have made,\n use, offer to sell, sell, import, and otherwise transfer the Work,\n where such license applies only to those patent claims licensable\n by such Contributor that are necessarily infringed by their\n Contribution(s) alone or by combination of their Contribution(s)\n with the Work to which such Contribution(s) was submitted. If You\n institute patent litigation against any entity (including a\n cross-claim or counterclaim in a lawsuit) alleging that the Work\n or a Contribution incorporated within the Work constitutes direct\n or contributory patent infringement, then any patent licenses\n granted to You under this License for that Work shall terminate\n as of the date such litigation is filed.\n\n 4. Redistribution. You may reproduce and distribute copies of the\n Work or Derivative Works thereof in any medium, with or without\n modifications, and in Source or Object form, provided that You\n meet the following conditions:\n\n (a) You must give any other recipients of the Work or\n Derivative Works a copy of this License; and\n\n (b) You must cause any modified files to carry prominent notices\n stating that You changed the files; and\n\n (c) You must retain, in the Source form of any Derivative Works\n that You distribute, all copyright, patent, trademark, and\n attribution notices from the Source form of the Work,\n excluding those notices that do not pertain to any part of\n the Derivative Works; and\n\n (d) If the Work includes a \"NOTICE\" text file as part of its\n distribution, then any Derivative Works that You distribute must\n include a readable copy of the attribution notices contained\n within such NOTICE file, excluding those notices that do not\n pertain to any part of the Derivative Works, in at least one\n of the following places: within a NOTICE text file distributed\n as part of the Derivative Works; within the Source form or\n documentation, if provided along with the Derivative Works; or,\n within a display generated by the Derivative Works, if and\n wherever such third-party notices normally appear. The contents\n of the NOTICE file are for informational purposes only and\n do not modify the License. You may add Your own attribution\n notices within Derivative Works that You distribute, alongside\n or as an addendum to the NOTICE text from the Work, provided\n that such additional attribution notices cannot be construed\n as modifying the License.\n\n You may add Your own copyright statement to Your modifications and\n may provide additional or different license terms and conditions\n for use, reproduction, or distribution of Your modifications, or\n for any such Derivative Works as a whole, provided Your use,\n reproduction, and distribution of the Work otherwise complies with\n the conditions stated in this License.\n\n 5. Submission of Contributions. Unless You explicitly state otherwise,\n any Contribution intentionally submitted for inclusion in the Work\n by You to the Licensor shall be under the terms and conditions of\n this License, without any additional terms or conditions.\n Notwithstanding the above, nothing herein shall supersede or modify\n the terms of any separate license agreement you may have executed\n with Licensor regarding such Contributions.\n\n 6. Trademarks. This License does not grant permission to use the trade\n names, trademarks, service marks, or product names of the Licensor,\n except as required for reasonable and customary use in describing the\n origin of the Work and reproducing the content of the NOTICE file.\n\n 7. Disclaimer of Warranty. Unless required by applicable law or\n agreed to in writing, Licensor provides the Work (and each\n Contributor provides its Contributions) on an \"AS IS\" BASIS,\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or\n implied, including, without limitation, any warranties or conditions\n of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A\n PARTICULAR PURPOSE. You are solely responsible for determining the\n appropriateness of using or redistributing the Work and assume any\n risks associated with Your exercise of permissions under this License.\n\n 8. Limitation of Liability. In no event and under no legal theory,\n whether in tort (including negligence), contract, or otherwise,\n unless required by applicable law (such as deliberate and grossly\n negligent acts) or agreed to in writing, shall any Contributor be\n liable to You for damages, including any direct, indirect, special,\n incidental, or consequential damages of any character arising as a\n result of this License or out of the use or inability to use the\n Work (including but not limited to damages for loss of goodwill,\n work stoppage, computer failure or malfunction, or any and all\n other commercial damages or losses), even if such Contributor\n has been advised of the possibility of such damages.\n\n 9. Accepting Warranty or Additional Liability. While redistributing\n the Work or Derivative Works thereof, You may choose to offer,\n and charge a fee for, acceptance of support, warranty, indemnity,\n or other liability obligations and/or rights consistent with this\n License. However, in accepting such obligations, You may act only\n on Your own behalf and on Your sole responsibility, not on behalf\n of any other Contributor, and only if You agree to indemnify,\n defend, and hold each Contributor harmless for any liability\n incurred by, or claims asserted against, such Contributor by reason\n of your accepting any such warranty or additional liability.\n\n END OF TERMS AND CONDITIONS\n\n APPENDIX: How to apply the Apache License to your work.\n\n To apply the Apache License to your work, attach the following\n boilerplate notice, with the fields enclosed by brackets \"{}\"\n replaced with your own identifying information. (Don't include\n the brackets!) The text should be enclosed in the appropriate\n comment syntax for the file format. We also recommend that a\n file or class name and description of purpose be included on the\n same \"printed page\" as the copyright notice for easier\n identification within third-party archives.\n\n Copyright {yyyy} {name of copyright owner}\n\n Licensed under the Apache License, Version 2.0 (the \"License\");\n you may not use this file except in compliance with the License.\n You may obtain a copy of the License at\n\n http://www.apache.org/licenses/LICENSE-2.0\n\n Unless required by applicable law or agreed to in writing, software\n distributed under the License is distributed on an \"AS IS\" BASIS,\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n See the License for the specific language governing permissions and\n limitations under the License.\n" }, { "path": "PROJECT_IDEA_TEMPLATE.md", "content": "### Template\n\n```\n#### CNCF Project Name\n##### Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s): # It is recommended to have at least 2 mentors, and at least one of them should be the primary mentor. For GSoC, it is **required** to have at least 2 mentors.\n - Jane Doe (@jane-github, jane@email.address) - primary\n - John Doe (@john-github, john@email.address)\n- Upstream Issue (URL):\n```\n\n### Sample:\n\n#### Prometheus\n##### Refactor the APIs for better readability and less maintenance overhead\n\n- Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n- Expected Outcome: A refactored HTTP API that is easier to maintain and extend.\n- Recommended Skills: golang\n- Mentor(s):\n - Jane Doe (@jane-github, jane@email.address) - primary\n - John Doe (@john-github, john@email.address)\n- Upstream Issue: https://github.com/prometheus/prometheus/issues/3416\n" }, { "path": "README.md", "content": "# CNCF Mentoring Initiatives\n\nThe Cloud Native Computing Foundation (CNCF) participates in a variety of mentoring programs. CNCF is a great place to spend time learning, coding, documenting, participating, and contributing. We look forward to your application and your project ideas!\n\nThis repository contains resources and information for the CNCF Mentoring Program. The program is designed to match experienced mentors with mentees who are interested in learning about cloud native technologies and contributing to open source projects in the ecosystem.\n\n## Resources\nIn this repository, you will find a number of resources to help you get started and make the most of your mentoring experience. \n\nThese include:\n\nThe [mentors](/mentors#readme) and [mentees](mentees#readme) folders provide guidance on how to be an effective mentor or mentee.\nThe [programs](/programs#readme) folder provides a list of programs for mentees to work on with their mentors.\nThis initiative is guided by the [CNCF Mentoring Subproject](/cncf-toc-mentoring-subproject#readme). More information about meetings, communication and activities can be found in the [cncf-toc-mentoring-subproject](/cncf-toc-mentoring-subproject#readme) section of this repository.\n\n## Participation\nParticipation in the CNCF Mentoring Program is open to anyone who is interested in learning about cloud native technologies and contributing to open source projects in the ecosystem.\n\nContact\nIf you have any questions or need help getting started, please reach out through our various [communication channels](/mentoring-wg/communications.md).\n\n## Mentoring Programs\n\n| Program | Purpose | Details and historical data |\n| ------------------------------------------------------------------------ | --------------------------------------------------------------------------------- | ------------------------------------------ |\n| [LFX Mentorship](https://mentorship.lfx.linuxfoundation.org) | Mentoring initiative by the Linux Foundation | [lfx-mentorship](/programs/lfx-mentorship#readme) |\n| [Google Summer of Code](https://summerofcode.withgoogle.com/) | Mentoring program for open source beginners | [summerofcode](/programs/summerofcode#readme) |\n| [Outreachy](https://www.outreachy.org) | Mentoring initiative for the communities traditionally underrepresented in tech | [outreachy](/programs/outreachy#readme) |\n\n## Program Statistics\n\nThese are the number of successful internships per year for each program.\n\n| Year | Program | Internships | Total (per year) |\n|------|----------------------------------|-------------|------------------|\n| 2025 | LFX Mentorship | 64 | 64 (so far) |\n| | GSoC | 11 | |\n| 2024 | LFX Mentorship | 134 | 147 |\n| | GSoC | 11 | |\n| | Outreachy | 2 | |\n| 2023 | LFX Mentorship | 127 | 144 |\n| | GSoC | 14 | |\n| | GSoD | 2 | |\n| | Outreachy | 1 | |\n| 2022 | LFX Mentorship | 87 | 106 |\n| | GSoC | 16 | |\n| | GSoD | 3 | |\n| 2021 | LFX Mentorship | 86 | 104 |\n| | GSoC | 16 | |\n| | GSoD | 1 | |\n| | Outreachy | 1 | |\n| 2020 | LFX Mentorship (CommunityBridge) | 50 | 71 |\n| | GSoC | 16 | |\n| | GSoD | 4 | |\n| | Outreachy | 1 | |\n| 2019 | CommunityBridge | 4 | 20 |\n| | GSoC | 15 | |\n| | Outreachy | 1 | |\n| 2018 | GSoC | 7 | 8 |\n| | Outreachy | 1 | |\n| 2017 | GSoC | 6 | 8 |\n| | Outreachy | 2 | |\n\n## Code of Conduct\n\nPlease note that CNCF Mentoring programs follow the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). By participating in this project you agree to abide by its terms.\n\n## Thank you for participating in the CNCF Mentoring Program!\n\n" }, { "path": "cncf-toc-mentoring-subproject/2022-meeting-minutes.md", "content": "---\ntitle: TAGCS Mentoring Working Group Monthly Meeting (2022)\ntags: Meeting Minutes, 2022\n---\n\nThis file has been archived. Please find the [2023 meeting minutes here](https://hackmd.io/@tag-cs-mentoring-wg/monthly-meeting-2023).\n\n[![hackmd-github-sync-badge](https://hackmd.io/7vA7fKNrRG6KrGbA01oupw/badge)](https://hackmd.io/7vA7fKNrRG6KrGbA01oupw)\n\n\nCNCF TAG Contributor Strategy\n# Mentoring Working Group\n\n\n## About TAGCS Mentorship Working Group\n\n* [Primary repository](https://github.com/cncf/mentoring)\n* CNCF Slack: [#tag-contributor-strategy](https://cloud-native.slack.com/archives/CT6CWS1JN)\n* [Discussion boards](https://github.com/cncf/mentoring/discussions)\n* [Email list](https://lists.cncf.io/g/tag-cs-mentoring-wg/)\n\n\n## Meeting details\n\n### Recurring monthly\n* 2nd Tuesday of the month at 9PM UTC\n* 4th Tuesday of the month at 9PM UTC (during the setup phase)\n\n[CNCF Public Events - TAG CS Mentoring WG](https://tockify.com/cncf.public.events/monthly?search=CNCF%20TAG%20Contributor%20Strategy%20Mentoring%20WG)\n\n### Zoom\n\nZoom Meeting \nhttps://zoom.us/my/cncftagcontributorstrategy?pwd=TnI0WU9Eb2I1RlRWdkl1R0k1WkZXUT09\n\nPasscode: 77777\n\n\n# Past Meetings\n\n## Dec 13, 2022\n\n21:00 UTC (1:00 PM PDT on 2022-12-13; 10:00 AM NZST on 2022-12-14) \n\n### Attendance\n\n* Nate W.\n* Jay Tihema\n* Riaan Kleinhans\n* Josh Berkus\n* Victor Lu\n* \n\n\n### Updates/reminders\n\n* \n\n### Agenda\n* General Progress report\n * Mentoring programs\n * 2022 diversity data: https://github.com/cncf/workflow/issues/332 (please reach out to Nate W. if you don't have access to the document).\n * Mentoring repo\n * Outreachy engagement\n * Possible alignment w/ Contributor.io\n* Plans for 2023\n * Goals\n * What are our specific goals around diversity?\n * do we want more folks from different places?\n * do we want more non-male mentees?\n * do we want a wider range of ages represented?\n * reach out to LF Research team to participate and help us design \n * discuss with LF privacy\n \n### Notes\n* Shared location previously, DE&I data has now been collated as well, meaning we can now potentially see patterns in engagement from past years\n* Possible split between mechanical and informational content for Repo\n* We can help develop Contributor-specific content for the site\n* Mentoring stuff under 'Maintainer' or mentoring-specific; \n * Where would the most beneficial place to host this; should be intertwined w/ Contributor focus in general\n* Maintainers link - joining a program\n\nMentoring Uptake 2022\n* General improvement in participation; unsure of what to attribute this increase to directly\n* How to encourage more diversity in applications and selections?\n * Specific goals/targets needed - more global reach, non-male mentees, career-changers vs. early students etc. \n * Would be beneficial to gauge feedback from the community, LF research team etc.\n * Should also be exposed to Mentors; navigate privacy etc. to help determine applicant diversity\nGeneral project numbers increasing\n* Challenge to increase to 150 mentees in 2023\n* Maintainers need to be considered throughout to avoid burnout; support health & wellbeing\nCurrent LFX doesn't filter effectively\n* More applications per project might be 'fatal'; grow from projects first to support maintainer evaluations\n**What might be other good goals for 2023?**\n* website alignment\n* increasing diversity\n* mentee numbers\n* organised effort around CLOtributor including mentor availability - develop a template of what that could look like\n\n\n---\n\n\n## Nov 22, 2022\n\n21:00 UTC (1:00 PM PDT on 2022-11-22; 10:00 AM NZST on 2022-11-23) \n\n### Attendance\n\n* Nate W.\n* Jay Tihema\n* Riaan Kleinhans\n* Alexandre N.\n\n### Updates/reminders\n\n* n/a\n\n### Agenda\n\n* LFX Mentoring Term 3: Sept-Nov completing this week\n * stipends are getting paid out\n * mentee survey sent out (no responses yet)\n * TODO:\n * Update repo with new statistics/results\n * reach out to CNCF marketing (Jesse) \n* [GSoC 2023 Timeline](https://developers.google.com/open-source/gsoc/timeline)\n* Outreachy\n * Looks like OTel will be doing 2 projects (CNCF funding one), starts Jan 2023\n * We should contact Outreachy and see if there is an org option for participation\n* GSoD - still showing 2022 timeline, but we should keep an eye out for when they start their 2023 program.\n* Mentoring Repo review\n * [Moved archive info form readme to the archive file #744](https://github.com/cncf/mentoring/pull/744)\n * [Next steps for Mentee section #737](https://github.com/cncf/mentoring/issues/737)\n * [Next steps for Mentor section #736](https://github.com/cncf/mentoring/issues/736)\n * https://hackmd.io/80wBLa5WSx6pTOUGXXleTg - draft mentee section\n\n**Notes**\n* GSoC deadlines critical - steps to be taken to meet these. \n* **TODO** - Create a calendar for CNCF Mentoring; collect dates for mentoring Programs where timeline can be developed\n* Nate may be able to action; will check w/ Amye - CNCF permission needed\n * [Public Mentoring Calendar #741\n](https://github.com/cncf/mentoring/issues/741)\n* **Outreachy update** - Otel will be doing two projects; one is CNCF funded - volunteers from team should contact their team to learn more about the program.\n * 'Research Round' needed prior to learn more about programme then reach out to request meeting\n* **Repo:** \n * Key notes first then look at refactoring ReadMe etc. \n * Keep 2022 as a live file, as opposed to an archived file; keep a year's worth of content oepn for access/review\n * Add a ticket to create a proper Readme for the front page once all links are finalised\n * Archives should rigidly stay as they are to retain integrity of history e.g. program seasons; unless it becomes/is a security risk\n * Establish some standard of record of changes to track/monitor analytics e.g. stats etc. for new work incoming. \n * e.g. some sub-folders assigned 'per year' under project folders\n * May be difficult with each Program running at its own cadence \n * Detail to be re-populated in ReadMe (currently empty)\n * Repo to be refactored to include new statistics e.g. project numbers\n * Repo reorganised to downsize number of folders, key info outlined in ReadMe\n * Nate to support with high-level detail \n * Can this be used as a documentation framework - part of this purpose is to align with (likely) the Contributor.io website \n * Once ready and approved by team we can contact w/ Chris Abrams to assess linking w/ site\n* KubeCon Maintainer Track talks should still be available for submissions\n* Alexandre to start Contributor Board match-making (C-S initiative); connect people wanting to contrib and build experience towards a system that links projects, maintainers etc. (not Mentoring-specific) - research, feedback etc.\n\n\n## Nov 8, 2022\n\n21:00 UTC (1:00 PM PDT on 2022-11-08; 10:00 AM NZST on 2022-11-09) \n**Note**, the end of Daylight Saving Time in NA has affected the time of this meeting.\n\n### Attendance\n\n* Nate W.\n* Jay Tihema\n* Alexandre N.\n* Riaan Kleinhans\n\n### Updates/reminders\n\n* \n\n### Agenda\n\n* [KubeCon 2023 EU CFP](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/cfp/)\n * Deadline for CFP is Nov 18. Do we want to have a mentoring talk?\n\n* Repo Refactor\n\n**Notes:**\n\n**Kubecon EU Talk CFP**\n* Possible workshop on how to put together a proposal, how to select a good scope of work - invite others to discuss potential projects e.g. mentorship proposal 'how to'\n* CFP required only - Repo refactor possible; not expected to \"do the work before doing the work\"\n* 'Speed Mentoring' - mentoring 'in general' e.g. how does it work vs. specific projects\n * Mentoring information session to educate on the detail of 'what?'\n * 2nd phase - connect with the mentor directly to learn more about processes etc. \n * Mentee information session - receiving more students; provide support for newcomers\n\n*Volunteer to provide individual career guidance as an extension of this.*\n\n**To-do:** CNCF Events team (?) and figure out who runs speed mentoring , maybe not be a CFP-level decision. Also gives others a chance to start notifying mentees/tors. \n\n**Mentoring Repo Refactor**\n\nCurrent refactor underway; general content/focus includes:\n\n**Mentors:** How do I make a proposal?\n**Mentees:** how do I get involved etc.?\n\nV2 branch and several issues in development. \n\n*Can promote/update this work in Slack for others to contribute/provide feedback on.*\n\n***\n\n\n## October 25 - at KubeCon (either in person or online)\n\n20:00 UTC (1:00 PM PDT on 2022-10-25; 8:00 AM NZST on 2022-10-26)\n\n### Attendance\n\n* Nate W.\n* Jay Tihema\n* Riaan Kleinhans\n\n### Updates/reminders\n\n* KubeCon this week\n\n### Agenda\n\n* Repo chat\n* Talk tomorrow\n\n\n## Oct 11, 2022\n\n20:00 UTC (1:00 PM PDT on 2022-10-11; 9:00 AM NZST on 2022-10-12)\n\n### Attendance\n\n* Nate W.\n* Jay Tihema\n* Alexandre N.\n* Riaan Kleinhans\n\n### Updates/reminders\n\n* KubeCon maintainers track talk\n * Presentation Upload to Sched Deadline: **Friday, October 14**\n * [Google slides](https://docs.google.com/presentation/d/1dssl7RbFX64Eo3BbkWZll6nc03tWsEag2GEZWzh3HbA/edit?usp=sharing)\n * [Notes from working session](https://hackmd.io/@nate-double-u/mentoring-wg-kubecon-22-na)\n* CNCF LFX Mentorship Term 3: Sept-Nov midterm\n * Nate W. working through stipends with mentees\n * 1 withdrawal\n * 24/24 remaning projects/mentees are passing\n* GSoC 2022\n * 2 projects ongoing\n * One finishes Oct 17, the other Nov 14\n* NZ progress \n * Community Digital Infrastructure\n* General \n * Cloud Native Students (Kunal)\n * Pathway mapping, Repo > website\n\nstories from LFX Mentorship last term:\n* https://www.cncf.io/blog/2022/07/07/cncf-congratulates-36-successful-interns-with-spring-term-lfx-program/\n\n### Agenda\n\n\n### Notes/Actions\n* Project to help map academic progression - TBC, Alexandre and Nate to investigate - ChaoSS community\n* https://github.com/chaoss\n* https://chaoss.community/\n* Also maps project health but from an academic standpoint; contribution lifecycles e.g, menteeship etc.\n* Nate managing spreadsheets re LFX etc. due to sensitive information such as payment details\n* Need to plan Term 1 for 2023, before CTA at Kubecon; inviting Maintainers to make project suggestions in the corresponding Repo *(26m onwards - video ref)*\n* Not explicit that work conducted during mentorships made visible in known repo *(31m)*\n* As part of process, should request that project pages should be updated accordingly to reflect changes\n* Move/shutdown of #mentoring channel on Slack to address bot update issue - Nate will investigate as CNCF admin. Desire to move community into Github discussions board owing to comms limitations in Slack; preference to have a central space for core comms.\n> [name=Nate W.][time=Thu, Oct 13, 2022 9:17 AM] Followup: The bot has been removed.\n* Organisational discussions in TAG-CS etc.\n\n\n## Sept 27, 2022\n\n20:00 UTC (1:00 PM PDT on 2022-09-27; 9:00 AM NZST on 2022-09-28)\n\n### Attendance\n\n* Nate W.\n* Jay Tihema\n* Alexandre N.\n* Riaan Kleinhans\n* Josh Berkus\n\n### Updates/reminders\n\n* CNCF students (previous meeting) https://community.cncf.io/cloud-native-students/\n* Kunal Kushwaha may be involved?\n\n### Agenda\n\n* Outreachy - recruit someone to help run this program?\n* \"Community responsibility\"\n* Strategic overview\n * https://docs.google.com/presentation/d/1cL0ZwzigoGNqFIDuuJ_Daz_4x2RXgeRK/edit?usp=sharing&ouid=107340980254524659898&rtpof=true&sd=true\n * Should be addressed through TAG issues i.e. Mentoring Repo or a project board\n* Contributor Opportunities board\n* Working session for KubeCon Mentorship talk/session (last half of meeting)\n\n---\n### **Notes**\n\n**Outreachy** - some interest in Kubernetes etc.; Josh suggested might be of value from someone in the community to support with Outreachy \n\n* Ideally someone who would reach out to various programs to gauge interest\n* May be more 'participant-driven' - Ambassador-type role, help with administration\n* Put a call-out on (TAG Contributor Strategy) mailing list and chat channel to encourage a response\n* May escalate to TOC list\n* Would be good to implement same thing (not yet K8s) - treat short-term internship opps...\n* Timing is key between programs (as well as overhead)\n* No current plan exists to 'improve' LFX - or to be executed\n* Outreachy - up to 3 admins; you don't have to cancel your own admin rights to action that\n* Q: *What's the CNCF funding situation for Outreachy?* \n * (K8s sorted but status of other projects?) - Nate to follow-up; need to know before recruitment call goes out.\n * LFX accepts direct donations, built-in funding mechanism. No compensation for mentors; sometimes for Outreachy - often dependent as to whether mentor is currently in employment etc.\n * Smallest staff-base which may restrict access/availability in certain countries, can also affect payment.\n \n* todo: list (or collect lists) countries that we support internships in\n\n\n**GSoC** - **'Community responsibility'**\nhttps://docs.google.com/presentation/d/1YKEEIGZPlTQtlggtNDEf-_BU718Sr9aQH4WDs1fpL0s/edit?usp=sharing -- slide ~68\nhttps://github.com/cncf/tag-contributor-strategy/tree/main/mentoring\n\n* Detail not currently reflected in Charter: \n - https://docs.google.com/document/d/1B_hpVAKxxNaSgVYAsHdjq_57eZEkYUuxcxecbcl3H9c/edit\n - https://github.com/cncf/tag-contributor-strategy/tree/main/mentoring\n* Potentially help in developing Mission Statement etc. \n \"promote growth and sustainability for projects through mentoring new and existing contributors\"\n \"provide support and advice for the projects\"\n \n* Open a new PR with proposed changes to the statement - need to bounce to liaisons for final approval.\n * Update to mission statement proposal:\nhttps://github.com/Riaankl/tag-contributor-strategy/compare/main...Update-Mission-statement \n - https://github.com/cncf/tag-contributor-strategy/pull/236\n\n**Contributor Opportunities board**\n* Not a project with a deadline attached\n* Past efforts i.e. K8s have failed\n* Better to engage with wider community over time to improve chances of success and quality\n* Contributor Survey will help to identify focus areas in the meantime\n* One of the biggest obstacles is encouraging Maintainers etc. to keep info up-to-date; how can we make it easy for them to do so?\n* Building something new immediately implies/requires maintenance\n\n**Mentoring Website**\n* Should be a part of Contributor website\n* Request help w/ mentoring discussions board - common Q is 'how to get started'? - use for discussion vs. using #mentoring Slack\n* 'Getting Started' page would provide value\n* Two main constituents are (new) Contributors and Maintainers - \n*Tentative actions:*\n * research what's available in mentoring in repo\n * build out diagram to map/canvas contents\n * figure out what's wanted/needed\n * look at existing Contributor.io infrastructure and determine what should be integrated\n\n\n## Sept 13, 2022\n\n20:00 UTC (1:00 PM PDT on 2022-09-13; 8:00 AM NZST on 2022-09-14)\n\n### Attendance\n\n* Natali Vlatko\n* Alexandre Nicastro\n* Jay Tihema\n* Riaan Kleinhans\n\n### Updates/reminders\n\n* https://docs.google.com/presentation/d/1cL0ZwzigoGNqFIDuuJ_Daz_4x2RXgeRK/edit?usp=sharing&ouid=107340980254524659898&rtpof=true&sd=true\n\n### Agenda\n\n* Strategy Draft\n * Main areas:\n * Culture\n * Knowledge\n * Systems & Processes\n * LFX mentorship:Season three\n * Propose a pre and post program increase of activity to support the \"Mentorship lifecycle\".\n * Mentees becoming mentors\n * AI: Jay: Share the slides from the meeting with the community.\n\n* Website\n * Engaging with Charley Mann\n * Looking at creating a Mentoring website after the pattern of Contributor web site\n * resource listing on the site linking all areas that engage with Mentoring\n * [Natali] https://community.cncf.io/cloud-native-students/ is still active.\n * Would be a good point of engagement.\n\n\n\n---\n\n\n### August 23, 2022\n20:00 UTC (1:00 PM PDT on 2022-08-23; 8:00 AM NZST on 2022-08-24)\n\n### Attendance\n\n* Jay Tihema\n* Josh Berkus\n* Hippie Hacker\n* Alexandre Nicastro\n* Riaan Kleinhans\n\n### Updates/reminders\n\n* [Recent events](https://sunlive.co.nz/news/301041-tauranga-helping-young-women-into-it-careers.html) (Canvas, STTS, KHM)\n* CloudNative.nz site \n* Mentoring info session at ii [Meetup event](https://www.meetup.com/cloudnative-nz/events/287887918/)\n\n### Agenda\n\n* Revisiting focus\n* WG participation/actions\n* Supporting messaging/engagement for potential contributors\n\n\n### Notes\n\n**Optimising Channels**\n* Potential split/separation between communication and GitHub app comms/bot; establish a thread\n* Separate #'Mentoring Bot' etc. - can the bot be configured accordingly?\n* Separate channel for TAG Contributor Strategy - process for infrastructure change? Wait until Nate's back to review. Probably create #tag-cs-notices, direct all auto traffic to that\n> [name=Nate W.]\n> [time=Thu, Aug 25, 2022 3:32 PM] I question if we need the github/slack notifications bot at all. I'll look into the historical rationale for it. We have been trying to push towards using https://github.com/cncf/mentoring/discussions instead of slack for comms with mentees/potential mentees.\n\n**Managing Engagement**\n* Hippie receiving alot of contact re LFX project including questions, CVs etc. - how to best manage comms\n* Possible CRM to manage communications - HubSpot, AirTable etc. - spreadsheet can be difficult to modify later if/when needed. Can adjust later as required\n* Steps/processes may be unclear to mentees e.g., project submission, redirection, balancing correspondence.\n* Need to review existing LFX systems - consider legalities as mentees are technically short-term 'employees'; \n> [name=Nate W.] \n> [time=Thu, Aug 25, 2022 3:04 PM] Mentees are specifically _not_ employees (https://docs.linuxfoundation.org/lfx/mentorship/mentees): \"NOTE: Mentees are not employed by the Linux Foundation. The Linux Foundation’s employment opportunities are available at https://www.linuxfoundation.org/about/careers.\" \n> I agree we should review and understand what mentee status actually is.\n* Recognising two channels w/ mentoring: \n 1. increasing awareness for new/potential contributors \n 1. the need for the WG to be proactive in reaching out to those already in the ecosystem \n* Most projects may not be aware this initiative exists - share success stories as often as possible to help provide clarity; can we create blogs, interviews etc. to do this?\n\n**Strategy & Resource/Knowledge Base**\n* Need to create strategy to build a culture and community around mentorship; if people become involved, how can we share positive experiences and develop a 'flow' within community.\n* Possible platform to share knowledge - when the program runs there are likely to be similar questions among participants; GitHub etc? Need to decide appropriate platform, learn from past mentorships\n * e.g. Mentorship experience - how to make a PR, mentee/mentor public profiles, Q&As (categorised) - can iterate over time\n* **Can Contributor Docs be written in a way that are more beneficial for maintainers**, current documentation doesn't exist; direct mentee/mentor engagement can be more difficult\n* Can possibly be implemented together - current lack of building tools from CNCF/LF.\n* Support mentors in providing resources for mentees e.g. markdown docs on GitHub, search function i.e. Develop template - see existing Contributor Guide templates\n * Difficulties in explaining e.g. PRs processes, providing clear examples would help alot towards this\n * **The obstacle is getting the guide written in the first place!** e.g. can a question raised in Slack become a bulletpoint in the guide.\n* Inventory of existing resources - what are permissions for partnerships, collaboration etc. \n* Not sure of known policies re exclusive permissions - does someone have a knowledge-base app to support\n* **Objective is to optimise Mentors' time**; source key info for easy mentee reference \n* Scope for CNCF funding - more for knowledge-base for Sandbox projects, separate for NZ projects\n\n#### Next Actions:\n* Follow up w/ Nate: recommended LFX mentee engagement process to clarify mentor communication/interaction\n* Map mentee/mentor pathway to identify onboarding journey and areas for focus/improvement \n* Draft strategy doc \n* Stocktake of existing processes, resources, knowledge bases\n* List common barriers to new contributors\n* Investigate separation of Mentoring channel - general communications from GitHub bot updates\n\n---\n\n\n## August 9, 2022\n20:00 UTC (1:00 PM PDT on 2022-08-09; 8:00 AM NZST on 2022-08-10)\n\nrecording: https://zoom.us/rec/share/x3XXpHv91ZwO9w2bpjXLSMWdFlUegkknq_98g7kpOOlfR3q6FWUyyvWdrJxwSg27.hPrVbHafYMnDmJjf\n\n### Attendance\n\n* Nate W. (CNCF)\n* Jay Tihema (ii)\n* Natali Vlatko (Wayfair)\n* Josh Berkus (Red Hat)\n* Hippie Hacker (ii)\n* Riaan Kleinhans (ii)\n\n### Agenda\n* Introductions/Whanaungatanga\n* Term 3 accepting project proposals! (Not many projects proposed yet for [CNCF LFX Mentoring 2022 term 3-Sept-Nov](https://github.com/cncf/mentoring/tree/main/lfx-mentorship/2022/03-Sept-Nov))\n * related tweets:\n * https://twitter.com/CloudNativeFdn/status/1555227042345533440\n * https://twitter.com/CloudNativeFdn/status/1557015611385036803\n * unofficial extension to encourage more proposal submissions\n* Nate W. on vacation Aug 15 - Aug 26, then travelling Aug 29 - Sept 2. \n * Will not be present at next WG meeting\n * May need help with email notification coverage for LFX term 3. \n * Uche Obasi now on-board to assist w/ data entry and processes regarding new applications, to introduce Jay as well\n * LFX Programme platform - built to manage at LF level, set-up so there could only be one admin account which limited ability to support w/ data entry. \n * New system set-up so a group can work on it instead\n * Admin will enter all descriptions in; copy-paste in system as Owner of project, add Mentors, once programme is opened people can apply.\n* Past mentee/mentor engagement \n * Uche caught up with Jay\n * Proposed graduate program for mentees\n * Increasing the engagement\n * Monthly meetups or other social between mentees\n * Also for mentors\n * Mentor survey?\n * https://hackmd.io/@tag-cs-mentoring-wg/2022-previous-mentor-survey/edit\n* Target cohorts moving forward\n * Diversity in mentees - can we get historical data?\n * Diversity in mentors - can we have more than just maintainers, possibly a shadow system?\n * NV: projects have also kept diversity in mind in their own selection process\n* LFX promotion NZ\n * NZ Career Expo August 12-13\n* Call to action for tommorrow's CNCF Webinar\n * Best link to share for LFX term 3 Sept-Nov: https://github.com/cncf/mentoring/tree/main/lfx-mentorship/2022/03-Sept-Nov\n * This page should be updated with info on how to apply\n * https://github.com/cncf/mentoring/issues/684\n* CNCF Students group?\n* [x] Update meeting info to use the TAG CS zoom link (auto set to record) [Nate W. & Josh B.]\n * [NW] New zoom link added to calendar and noted above.\n\n---\n\n# Meeting Template\n\n## August 9, 2022\n20:00 UTC (1:00 PM PDT on 2022-08-09; 8:00 AM NZST on 2022-08-10)\n\n### Attendance\n\n* \n\n### Updates/reminders\n\n* \n\n### Agenda\n\n* \n\n# Archive\n\n* [June 30, July 12, July 26, 2022](https://docs.google.com/document/d/1ZVFf_GRB5yrcTQieudtk3W-gWL6KuwHn1QG8XKdrARo/edit?usp=sharing)" }, { "path": "cncf-toc-mentoring-subproject/2023-meeting-minutes.md", "content": "---\ntitle: TAGCS Mentoring Working Group Monthly Meeting (2023)\ntags: Meeting Minutes, 2023\n---\n\n[![hackmd-github-sync-badge](https://hackmd.io/7vA7fKNrRG6KrGbA01oupw/badge)](https://hackmd.io/7vA7fKNrRG6KrGbA01oupw)\n\n\nCNCF TAG Contributor Strategy\n# Mentoring Working Group\n\n\n## About TAGCS Mentorship Working Group\n\n* [Primary repository](https://github.com/cncf/mentoring)\n* CNCF Slack: [#tag-contributor-strategy](https://cloud-native.slack.com/archives/CT6CWS1JN)\n* [Discussion boards](https://github.com/cncf/mentoring/discussions)\n* [Email list](https://lists.cncf.io/g/tag-cs-mentoring-wg/)\n\n\n## Meeting details\n\n### Recurring monthly\n* 2nd Tuesday of the month at 9PM UTC\n\n[CNCF Public Events - TAG CS Mentoring WG](https://tockify.com/cncf.public.events/monthly?search=CNCF%20TAG%20Contributor%20Strategy%20Mentoring%20WG)\n\n### Zoom\n\nZoom Meeting \nhttps://zoom.us/my/cncftagcontributorstrategy?pwd=TnI0WU9Eb2I1RlRWdkl1R0k1WkZXUT09\n\nPasscode: 77777\n\n\n# Past Meetings\n\n## December 12, 2023\n\n21:00 UTC (1:00 PM PDT on 2023-12-12; 9:00 AM NZST on 2023-12-13)\n\n### Attendance\n\n* Nate W.\n* Riaan K.\n* Josh B.\n\n### Updates/reminders\n\n* Diane & Nate did a talk at Open Source Summit Japan (2023): [The Mentoring Effect: Measuring Effectivenes of LFX Mentoring Programs](https://www.youtube.com/watch?v=bcOowyAxfxc) \n\n### Agenda\n\n* LFX 2023 Term 3 (mostly) complete: https://github.com/cncf/mentoring/issues/1053\n * Still need to post a blog entry\n * Still need to plan LFX 2024 Term 3\n * Mentor gift sent out :)\n* [LFX 2024 Term 1](https://github.com/cncf/mentoring/issues/1077) starting early in the new year ([CFP starts Jan 8](https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2024/01-Mar-May))\n * NW would like to start doing a Mentor zoom meeting before the term to set expectations\n* LFX Mentee Summit usually happens early in January - Nate to put Shellea & Ali in touch with Shuah to help\n* Availability note: Nate will be away on vacation from Dec 15 to Jan 14.\n\n\n## November 21, 2023 (postponed from November 14, 2023)\n\n21:00 UTC (1:00 PM PDT on 2023-11-21; 9:00 AM NZST on 2023-11-22)\n\n### Attendance\n\n* Nate W.\n* Abby Crimlis\n* Jay Tihema\n* Ali Ok\n* Riaan\n\n### Agenda\n\n* [New Mentoring WG chair](https://github.com/cncf/tag-contributor-strategy/pull/554)\n* KubeCon NA 2023 debrief\n* Update org-admins guides \n * [NW] After attending GSoC mentor summit, KubeCon, and noting some issues we had in term 3, I'd like to suggest we create an org guide specifically for the LFX mentorship program, like we have for [GSoC](https://github.com/cncf/mentoring/blob/main/mentoring-wg/gsoc-org-admin-guide.md). We may be able to base it off of the umbrella issues we have (https://github.com/cncf/mentoring/issues/1077), but I think there is more to it than just that (and maybe the umbrella issue becomes a template)\n* End of LFX 2023 Term 3 coming up\n * NW to open evaluation form, send mentors link. Evaluations due: Nov 22, last day of term: Nov 30\n * [NW] Several projects have requested extensions, I've approved Nov 29 as their new date for evals\n* [Archive GSoD program](https://github.com/cncf/mentoring/issues/1098)\n * issue: https://github.com/cncf/mentoring/issues/1027\n * PR: https://github.com/cncf/mentoring/pull/1099\n* LFX Virtual Mentorship Showcase 2024\n\n### Notes\n\n* Rotation of chairs/responsibilities\n * Maybe 18 months\n * Related https://github.com/cncf/tag-contributor-strategy/issues/541\n * Seek/create clarity around similar roles and responsibilies e.g. members, facilitators etc.\n * Project in coming months - efforts w/ LFX, GSOC; create an org admin guide in response to mentors dropping out to date\n * 'Impress upon folx' about the nature of mentoring - although voluntary, still critical to demonstrate commitment to uphold the overall success of the program and relationships\n * Factor investment of time, energy, resources etc.\n * Mentoring info session - outlining expectations, understanding the program etc.\n * Mentees to create blog posts (weekly in other programs) to help program administration\n * google doc?\n * google form checkin?\n * Greater involvement/oversight needed e.g. monitoring Github activity to identify potential sticking points\n * (Mentors) - response to consistently late submissions; work together to create contingency plans to ensure timely submission\n * Remind folx of benefits to companies as well\n * Mentor guide may be useful here too\n* GSoC 24 starting - let's setup everything in January\n \n\n## October 10, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-10-10; 10:00 AM NZST on 2023-10-11)\n\n### Attendance\n\n* Nate W.\n* Ali Ok\n* Diane Mueller\n* Riaan Kleinhans\n\n### Agenda\n\n* [Planning LFX 2024 Term 02: Jun-Aug](https://github.com/cncf/mentoring/pull/1094) \n* Google Mentor Summit\n* Diane & Nate speaking at LF Member Summit \n* Mentorship content in website: [issue](https://github.com/cncf/tag-contributor-strategy/issues/539)\n\n### Notes\n\n* GSOC Mentor Summit: Nate, see if GSoC has a site like LFX listing info about the program\n * what are Google's plans for publishing project/mentee data after a cohort is completed\n * https://summerofcode.withgoogle.com/\n * https://summerofcode.withgoogle.com/organizations/cncf/projects \n * is there a listing? helpnig mentees share that they have been a participant\n * Perhaps: https://summerofcode.withgoogle.com/programs/2022/projects\n * Perghaps: https://summerofcode.withgoogle.com/programs/2022/organizations/cncf \n\n## Sept 12, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-09-12; 10:00 AM NZST on 2023-09-13)\nLink to recording: https://www.youtube.com/watch?v=d1w7UmZFyic\n### Attendance\n\n* Diane Mueller (Bitergia)\n* Nate W. (CNCF)\n* Ali Ok (Red Hat)\n* Daniel Krook (CNCF)\n* Riaan Kleinhans (ii)\n\n### Agenda\n\n* Mentoring Effect research update - Nate W. & Diane M.\n* [Riaan] Ashutosh Kumar (ashutoshak5386) offered to work on issue [Update \"Full List FAQs\" for Mentees #1022](https://github.com/cncf/mentoring/issues/1022)\n* [Grace Hopper Celebration 2023](https://ghc.anitab.org/) - Nate W. Attending, will be working the CNCF booth with an eye to Mentorship programs.\n * I have given some guidance in the issue and invited him to the meeting.\n* Plan LFX mentorship program 2024 Term 1: Mar-May (https://github.com/cncf/mentoring/issues/1070)\n* Number of mentors suggestion for LFX and GSoC (https://github.com/cncf/mentoring/pull/1081#discussion_r1322633005)\n * Action items:\n * Ask Google if we can tell mentors that we need a co-mentor\n * Change the org admin rules to tell mentors about being reachable and the deadlines during proposal approval\n\n\n## August 8, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-08-08; 10:00 AM NZST on 2023-08-09)\n\n### Attendance\n\n* Ali Ok\n* Josh Berkus\n* Riaan Kleinhans\n* Corey Leong\n* Jay Tihema\n\n### Updates/reminders\n\n* [Term 02 of LFX Mentorship](https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2023/02-Jun-Aug) is approaching to an end\n * Final mentee evaluations due August 23 \n* [Term 03 of LFX Mentorship](https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2023/03-Sep-Nov) is starting soon\n * 36 project proposals, 17 projects represented, 47 mentors\n * We're in mentee application period (August 2 - 15)\n* GSoC 2023 is almost finished\n * August 21 - 28 is the final week - [timeline](https://developers.google.com/open-source/gsoc/timeline)\n\n### Agenda\n\n* [Corey] Mentorship opportunities for the university students\n* Project board grooming - ([board1](https://github.com/orgs/cncf/projects/25/views/6)) ([board2](https://github.com/orgs/cncf/projects/25/views/9))\n* [Jay] Updates TBA\n\n### Notes\n\n* [Higher Ed initiative](https://github.com/cncf/tag-contributor-strategy/issues/460)\n* [GSoC @ CNCF](https://github.com/cncf/mentoring/tree/main/programs/summerofcode)\n* [LFX Mentorship @CNCF](https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship)\n* [Guide - Getting started to Open Source](https://contribute.cncf.io/contributors/getting-started/)\n* [#tag-contributor-strategy](https://cloud-native.slack.com/archives/CT6CWS1JN)\n\n\n## July 11, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-07-11; 10:00 AM NZST on 2023-07-12)\n\n### Attendance\n\n* Nate W.\n* Josh Berkus\n* Riaan Kleinhans\n* Catherine Paganini\n* Diane Mueller\n* Jay Tihema\n* Paris Pittman\n* Rohan Dahibhate\n\n### Agenda\n\n* Riaan - [Project board](https://github.com/orgs/cncf/projects/25/views/1) grooming\n * Workflows have been created to auto-add issues and PRs to the “New” Column - Thanks Nate for pointing out the way!\n - For managing the project board we need some time in every meeting to triage and groom tickets in the “New” column. \n - First task is to evaluate the 8 Mentor WG issues currently in “New” for being valid or stale.\n - If an issue is valid, let's move it to “Backlog” or another appropriate column.\n - If it is stale, let’s close it.\n - Let’s try and label all issues, so the board filters work\n - Some explanations about the columns have been added at the top of each column. Please let me know if changes to the columns or descriptions are needed. \n* Program updates\n * **LFX** - Term 2 Midterm evals due tomorrow (July 12, 2023)\n * **GSoC** - Midterm evals due July 14 (for most projects, one has extended and will have different dates)\n * **Deaf/hoh**: \n * Updated [issue](https://github.com/cncf/tag-contributor-strategy/issues/421) with audience, mission, goals\n * Scheduled first official meeting (with ALS interpreter, captions, gallery view recording)on the 4th Tuesday of each month at 5pm ET\n * Focus: recruit more deaf/hoh members\n * Kickstarted social media campaign\n * Two new members joined after seeing the social media posts\n * [LinkedIn](https://www.linkedin.com/posts/iansmith13_cloud-community-deaf-activity-7084214874095943680-iU_7/)\n * [Twitter](https://twitter.com/metaforgotten/status/1678446702825721856)\n * [Mastodon](https://mastodon.social/@Deafveloper/110690520567866407) \n * One deaf/hoh member to attend KubeCon (first time ever!)\n * CNCF encouraged deaf/hoh to apply for scholarships\n * Provided feedback on gaps in scholarship and registration form\n* Mentorship statistics & reporting - Nate, Diane, Josh & Dawn\n * New position proposal: Mentoring WG Tech Lead\n * Nomination: Diane Mueller \n * Nate W. suggests that we invite Diane Mueller to participate officially as a Tech Lead so that we can provide access to internal docs that would normally be private in order to facillitate statistics research & reporting around our programs.\n * process question - this discussion is a start, but do we need to add something to cncf/mentoring, or cncf/tag-contributor-strategy?\n* NZ Updates\n * KCD Sydney\n * Shadowtech, Canvas events\n * Training & Certs\n* [Paris] Program documentation for mentoring initiatives that are not 1:1 and/or focused on growing contributors that are already there into maintainer roles \n * maintainer circle\n * documentation / templates / etc\n* Sickness policy\n * what happens if someone falls ill and is unable to complete their menteeship duties (mentees or mentors both)\n\n### Notes\n(Riaan) \n* Project board - workplace created, new columns with all open issues collated - label as needed\n * Busy closing issues; seeking consensus for closure\n * Slack discussion reference >\n\n(Nate)\n* LFX progressing well - mid-terms due tomorrow\n * Seeking advice on policy around illness and how this affects mentees' ability to complete program\n* GSOC evals recenty opened, 1/3 submissions received\n\n(Catherine)\n* DHH - issue update w/ audience goals\n* 1st official meeting - CNCF providing ASL interpreter to support recording \n* Focused on recruiting more DHH; ideally to be driven by the community themselves\n* 2 new members have joined, 1 new attendee for Kubecon NA; Chris A has also encouraged new scholarship applicants - has highlighted gaps in application forms/processes esp. re disability and associated factors\n\n(Nate/Diane)\n* Potential Tech Lead role in Mentoring WG for Diane - stats, recording etc would provide ability to access Google Drive, relevant resources\n * Creating dashboards for tracking mentorship comms, progress, reflections etc. \n * Focus on both mentees and mentors\n * Aim to share findings at monthly meetings to help drive potential improvements in ongoing efforts\n\n(Paris)\n* Efforts to grow contributor base, managing engagement at scale; ideally beyond 1:1s\n* Current WG streams accommodate 'many-to-1' mentoring models primarily - open to discussing other programs and methods \n* Focus to date has been entry-level programs, historically haven't had sufficient help to look further\n * Explore scope for CNCF to support with a sign-up tool\n * Reviewer cohorts, shadow programs, buddy systems, AMAs\n * Open issue/discussion to promote the opportunity; seeking assistance\n\n(Nate)\n* Sickness policy - will be determined by duration of illness; in some cases partial payment has been issued to mentees\n * LFX has more flexibility than GSOC by comparison; may be able to manage on case-by-case basis\n * Can be difficult with no means of verifying illness status; to consider\n * https://docs.linuxfoundation.org/lfx/mentorship\n\n\n## June 13, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-06-13; 10:00 AM NZST on 2023-06-14)\n\n### Attendance\n\n* Nate W.\n* Catherine Paganini\n* Riaan Kleinhans\n* Ali Ok\n* Josh Berkus\n* Jay Tihema\n\n### Agenda\n\n* [Meeting cadence](https://github.com/cncf/mentoring/issues/1015)\n* [Is GSoD a good fit for the Mentoring WG?](https://github.com/cncf/mentoring/issues/1011)\n* GSoC mentor summit\n * NW planning to attend\n * Discussion: https://github.com/cncf/mentoring/discussions/848#discussioncomment-6149827 \n* (aliok) [Mentor guide](https://docs.google.com/document/u/1/d/1Zozg3g5qE4jkdVEdiVtCoXvc_iuuOls1hfCgW6Pf7jQ/edit?usp=sharing) - good enough to create a PR?\n* Update on the [DHH initiative](https://github.com/cncf/tag-contributor-strategy/issues/421) \n * Met with Gallaudet professor\n * IT department not super deep\n * Schedule a talk to get a sense of interest\n * #dhh-in-cloud-native channel\n * [4 volunteers](https://docs.google.com/document/d/18OMOIhTYSa0v6dVi9u6WMQq25dpy3fc0kxjjzE_gzEk/edit#) (two DHH, one hearing and fluent in ASL)\n* Update on NZ efforts\n\n### Notes\n\n* **Cadence** - Proposal to reduce to frequency to one-monthly meetings - special topics meetings vs. general updates \n * Need to review/revise our goals in terms of progress and performance. \n * Initial goals of obtaining more help w/ community support, working towards mentee numbers objective tracking wells\n * Nate to add calendar note to reflect change\n* *To do: Fix calendar note for meeting link*\n* **GSOD fit** - may not be the right fit for Mentoring WG objectives\n * (Issue opened to discuss further if needed)\n * Previously coordinated through Tech Docs dept.- if not through WG; may not be worth tracking through CNCF esp. if low Cloud Native project submissions\n * Tracking - informing community of cycles; application dates, assistance, relevant comms\n * Doesn't match the key description of focus mentoring programs e.g. LFX - what is needed for inclusion in CNCF mentorship/initiatives\n * Consensus to remove from workstream\n* **GSOC Mentor Summit**\n * Will fund one org person and mentor to attend (incentivised); one expression of interest so far\n * Limited space available only\n * Notify mentors list for feedback on next actions\n * > Many orgs want to send more than one delegate to the Mentor Summit. If your organization has more than one delegate that wishes to attend the Mentor Summit, please have them put their name on the waitlist.\n* (Ali) **Mentor Guide**\n * Google doc created; please review and add comments/feedback\n * Will allow review time then create a PR\n * Open PR to link to doc for view\n* (Catherine) **DHH initiative**\n * Connected w/ IT dept in Gallaudet Uni; met w/ professor to discuss\n * Primarily liberal arts college; expressed interest in collaboration - proposed talk to students about cloud native\n * 4 volunteers to support effort; deaf or have family that are, high initial engagement\n * Need to keep working w/ deaf community to determine key considerations as things progress\n * How can Mentoring WG/community best support? Plan > role of TAG > decide actions to implement etc. \n * Identified professor who might develop an open source curriculum; current skillset doesn't exist in Gallaudet\n * Will find the right place for it to sit if not in Mentoring e.g. TAG C-S\n * Review possibility of all CNCF calls etc. use close-captioning etc. to support communication/participation\n* **Kubecon NA**\n * Any CFPs for talks? e.g:\n * Getting Started guide\n * Ali at KCD Istanbul\n * Nothing at TAG level yet\n * Talk in sign language\n\n\n## May 23, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-05-09; 10:00 AM NZST on 2023-05-10)\n\n### Attendance\n\n* Nate W.\n* Ali Ok\n* Riaan Kleinhans\n* Jay T\n* Brad McCoy\n\n### Agenda\n* [Nate W.] working with LF to get some support for LFX mentoring platform\n * LFX Platform admin access for non-CNCF-employees?\n* [Riaan] From the last CNCF TAG Contributor Strategy Meeting’s ROADMAP topic I have created the [TAG Contributor Strategy Project Board](https://github.com/orgs/cncf/projects/25/views/1) with a specific view for [Mentoring WG](https://github.com/orgs/cncf/projects/25/views/6).\n * This give an overview of all issues and PR’s marked with the Mentoring label\n * Status is controlled on the main “Project Board view”\n * I added 2 issues from the https://github.com/cncf/mentoring/issues repo. For the issue to show up on the \"Mentoring view\" I had to create the \"Mentor label\"\n * Is this the way we want to go?\n * If yes, I will add the rest of the mentoring repo's issues & PRs to the board (and also add the \"Mentor\" label to each)\n * > [name=Ali Ok] I can't see the boards, are they public?\n * It is set to Private - do not have owners rights. Will get someone to change that.\n* LFX '23 Term 1\n * End of semester evaluations due May 24, 5:00 PM PST\n * Final day of semester: May 31\n * There has been several questions about why the end of semester and when the evals are due are on different dates\n* LFX '23 Term 2\n * Applicications due today\n * Mentor email list created - at 5:01 PM PDT an email is scheduled for selections. Selections are due Mon May 29, 5:00 PM PDT\n* (Ali) GSoC - coding starts next week!\n * Should we reach out to mentors asking \n * if they reached out to their mentees\n * if there are any inactive mentees (28 May is the deadline for informing Google about this)\n* (Ali) _Underground_ mentoring program video - Kube release team orientation: https://www.youtube.com/watch?v=5ZYrgQrOeHA\n* maintainers cirle\n * Nate & Lee - Tue May 30 @ 9:00 am PDT\n* stipends process update\n* Move / surface program statistics to the top level\n * [Resurface program statistics #1000](https://github.com/cncf/mentoring/issues/1000)\n\n### Notes\n* Be mindful in reviewing/approving PR requests - dates were overlooked in the latest LFX intake and the end date clashed with the new intake. No single person accountable but critical for future actions\n* Nate working to get support from Linux Foundation (met w/ John recently) - seeking help w/ LFX platform admin. \n * Most exists in Google etc. and becomes time-consuming transferring to the platform. Ali actively supporting in the meantime. \n* (Riaan) Project boards are currently private; need to be made public. Prev. raised to create a central TAG C-S board to review ongoing workstreams; immediate focus on Mentoring efforts.\n * Nate will action to make boards public\n * (Nate) This board should be able to be linked to the Mentoring Repo; remove Mentoring label for ease of use/actioning. Consider reviewing alternative methods of tracking for simplicity across various mentoring-related issues.\n * Nate to seek Admin status for the board to connect to Repo. Riaan has introduced all issues manually to date; can be optimised. \n * (Ali) Decide/clarify intended purpose for the project board overall. Consider enforcing labels to help keep track of issues that remain unresolved and may generate from multiple sources etc. \n* LFX - end of semester evals due. Mentees work should be completed day before evals are due; impacting evaluations otherwise - should be explicit about these expectations. \n* Should greater emphasis be placed on mentee blogs in last week of LFX? Would need to add to documentation if so. \n * Benefits/considerations:\n * Offer training or swag to incentivise\n * Helps to identify areas for improvement\n * Supports current and future mentees/mentors\n * Would create more work for admins to review blogs etc.(esp. if 30-60+!) - capacity dependent\n* LFX Term 2 applications due today. \n* GSOC coding starts next week 29/5 - should contact mentors to identify inactive mentees to notify Google asap so as not to prolong failures etc. Due date Sun 28/5.\n* (Brad) Sharing under-grad mentoring program vid - shadow orientation for K8s mentoring program. 2 other projects adopting it including Cluster API. \n* (Nate) Lee Calcote, Dave Sudia working on Maintainer Circle - Nate to intro WG, overview of programs and impact/successes, how CNCF supports access to programs, encourage others to contribute etc. (1hr pres). \n* (Nate) LFX stipends process 57/60 mentees approved to be paid. Prev. approval system inefficient; working internally to seek help in improving, WIP.\n* (Nate) - Chris A couldn't find program stats page and requested 'unburying' this for easier access. Need to relocate as top-level information; at least most-recent stats. \n * Expected this will help raise awareness + uptake of programs\n * Should we consider a Mentoring website alongside the Repo? Currently in Q3 so timing might not be optimal.\n * Need to build out current Repo content beforehand\n * Markdown content can be embedded easily\n * If content on site; shouldn't be 'loose' in the Repo\n * Purpose of website? Highlighting programs etc. \n * Repo copy etc. 2-3-fold audience/stakeholders: \n * CNCF, TAG, Governing Board\n * Mentees seeking program info\n * Mentors needing to understand specifics for those eligible. \n* (Riaan) Re-locating program stats to front page without mess e.g. disclaimer paragraph to provide context on decision for placement vs. physically moving the page etc. \n * Consider adding most recent stats only to reduce/manage 'noise' vs. complete archives\n * Nate working w/ Dawn & Josh to see whether people have contributed since end of mentorships.\n * Nate proposes continuing this decision in the relevant Issue - consider what will be least demand on work \n\n\n## May 9, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-05-09; 10:00 AM NZST on 2023-05-10)\n\n### Attendance\n\n* Ali Ok\n* Josh Berkus\n* Jay Tihema\n* Riaan Kleinhans\n\n### Agenda\n\n* [aliok] GSoC selection and ranking is done - Google's deadline is April 27\n* [aliok] GSoD - 2 out of 13 accepted proposals is from CNCF - [announcement](https://github.com/cncf/mentoring/discussions/843#discussioncomment-5492931)\n* [aliok] LFX Mentorship date shift (?)\n * https://github.com/cncf/mentoring/pull/943\n* [aliok] contribute.cncf.io website updates\n * Now mentions Mentoring WG - [link](https://contribute.cncf.io/about/working-groups/)\n * Main \"I want to be a contributor\" page is now up-to-date with simpler instructions - [link](https://contribute.cncf.io/contributors/)\n* [Jay] Explore alignment/overlap w/ CNCF Students (Kunal), repo content\n * Collaborate & coordinate, but two seperate groups\n * Like: LFX, we handle the mentors, they work with the students\n * Also they want to do some things out of our scope (e.g. Campus Ambassadors)\n* [Jay] Establishing/coordinating Peer Mentoring Group (?) or similar initiatives (see notes for reference)\n\n\n### Notes\n\n* LFX PRs open - Nate to create in platform; offered support - might be limited to CNCF admins only\n* Kunal alignment w/ TAG.C-S - to review\n\n**What are the main goals of this WG and what do we see as barriers to achieving them?**\n•\tBuild sustainable growth of existing mentoring programs\n•\tSupport the pipeline/ladder from Contributor/Mentee > Mentor/Maintainer\n\n**What do we see as the key actions/opportunities we could take to achieve them?**\n•\tSupporting/integrating existing or proposed initiatives\n•\tImproving onboarding and navigation documentation \nWhat are the main considerations we’d need to have moving forward?\n\n**What is most conducive to the WG and its ability to contribute?**\n•\tTime commitment, compatibility, structure, guidance, coordination etc.\n•\tAvoiding replication of existing efforts\n\n* Retention is an ongoing issue, expected to be low with given target audience\n* Mentoring program towards professionals - wouldn't mean being part of a paid program for instance\n* DO we fill all slots applying for programs? (Mentees)\n* Ability to track pathways post-programme completion\n* Many career-changers or newcomers; lots of experimenters to determine whether or not they want to stick around\n* Want to set efforts with different target audiences\n* Mentoring ppl who are regulare contributors into Reviewes (group mentoring, common)\n * Would need help in setting up a structure and operating - expect a high retention rate from this\n* Front-end engagement prioritised? Managing new and professional (preferred for mentors) mentees - what systems/processes can best support this? Same 'pre-work' needed\n* *System to collect project proposals for communities, independent of any mentorship programme?*\n* 'Rejekts' idea; might be left to communities to manage those who aren't initially accepted to established programs\n* Documentation on advising next/backup steps for unsuccessful applicants \n\n\n\n[Jay] *Current active/proposed mentoring or pathway initiatives for review/consideration*\n\n***Supporting Maintainers/Developing Mentors***\n\n* '**Buddy System**' (leonardpahlke) - 1:1 peer matching, anticipated issues with time commitment, compatibility and impact \n* '**Maintainers Circle** *(Paris)* **'How to build shadow programs'** Guidance on how to create roles, identify roles, etc.\n* '**Group Mentoring Programs**' *(Paris)* - Structured, time-bound format towards key goals \nhttps://github.com/cncf/tag-contributor-strategy/issues/393\n* '**Shadow Mentoring**' (*Hippie*) - Operationalizing mentoring/shadowing programs that exist in K8S SIG Docs, etc.\nhttps://github.com/cncf/mentoring/issues/950\n\n***Supporting Newcomers***\n* **'CNCF newcomer buddy groups'** (*xinity*) - Linking newbies to potential mentors\nhttps://github.com/cncf/tag-contributor-strategy/issues/393\n* **'Student Pipeline'***(Kaiwalya)* - proposal in development https://docs.google.com/document/d/1oIBJmhIYDHkDYYzi8PCD8JuUMHqGNTTNtTRXIPkeQMs/edit?usp=sharing\n* **'Pathways for disabled communities**' *(Catherine, TAG)* - in discussion\n* **CNCF Students** *(Kunal)* - (full link needed,including repo) https://community.cncf.io/cloud-native-students/\n\n---\n\n## April 25, 2023 (Cancelled due to no attendance)\n\n21:00 UTC (2:00 PM PDT on 2023-04-25; 10:00 AM NZST on 2023-04-26)\n\n### Attendance\n\n* (Cancelled: no attendance)\n\n### Agenda\n\n* [aliok] GSoC selection and ranking is done - Google's deadline is April 27\n* [aliok] GSoD - 2 out of 13 accepted proposals is from CNCF - [announcement](https://github.com/cncf/mentoring/discussions/843#discussioncomment-5492931)\n* [aliok] LFX Mentorship date shift (?)\n * https://github.com/cncf/mentoring/pull/943\n* [aliok] contribute.cncf.io website updates\n * Now mentions Mentoring WG - [link](https://contribute.cncf.io/about/working-groups/)\n * Main \"I want to be a contributor\" page is now up-to-date with simpler instructions - [link](https://contribute.cncf.io/contributors/)\n\n\n## April 11, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-01-11; 10:00 AM NZST on 2023-01-12) \n**Note**: this meeting may be cancelled or postponed due to its proximity to KubeCon EU.\n\n### Attendance\n\n* Riaan Kleinhans\n* Josh Berkus\n* Nate W. (briefly) \n\nMore of a conversation than a meeting, should not be posted to Youtube.\n\n### Updates/reminders\n\n* Nate W. availability updates:\n * travelling for KubeCon EU April 13-21, 2023\n * vacation April 24-28, 2023 (Note, Nate can be available during this time as there is a GSoC deadline this week)\n * Move out to 5 May 2023\n\n### Agenda\n\n* LFX Term 02-Jun-Aug\n * We should draft an email to open the next term of LFX: https://github.com/cncf/mentoring/tree/main/lfx-mentorship/2023/02-Jun-Aug\n * issue: https://github.com/cncf/mentoring/issues/926\n * Should note that any GSoC projects that aren't accepted would be a great project for LFX term 02\n * previous email: https://lists.cncf.io/g/tag-cs-mentoring-wg/message/7\n * should send to: tag-cs-mentoring, toc list, add to Maintainer newsletter, cncf/mentoring discussions board, #mentoring slack\n * Should we push the deadline for project ideas back a week? - Move out to 5 May 2023\n * Should we create a templates folder in the cncf/mentoring repo for common communications like this?\n * Yes, that make sense\n * Make sure we do not forget any info\n * Let's make templates and review as a group\n* LFX Term 01-Mar-May\n * Currently going through evaluations, evals due Wednesday Apr 12 @ 5:00pm pacific time\n* GSoC\n * Currenly assessing contriubtor proposals\n * details & dates: https://github.com/cncf/mentoring/discussions/918#discussioncomment-5548149 \n* Mentoring repo refactor:\n * https://github.com/cncf/mentoring/pull/927 - update to call out draft pages\n * https://github.com/cncf/mentoring/pull/899\n * Happy day!! It is merged!! :tada: \n\n\n## March 28, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-01-28; 10:00 AM NZST on 2023-01-29)\n\n### Attendance\n\n* Nate W.\n* Jay Tihema\n* Ali Ok\n* Riaan Kleinhans\n\n### Agenda\n\n* Nate W. goofed a sync merge, and accidentally merged it into `main` rather than `v2`\n * Mistake was reverted\n * Some history seems to have been lost\n * Need to recrate the v2 PR as the original one was closed in the mistake\n * Some issues tied to PR 773 have been closed as part of the \"fixes:\" automation\n * **Lessons learned:**\n 1. Don't do complex (or even simple) merges on important projects when you're tired or otherwise disctracted\n 2. Don't bypass security measures put in place to protect the `main` branch -- especally when doing 1. above\n 3. The revert function works suprisingly well, but seems to have stripped out some of the history. Revert doesn't undo closed issues or PRs.\n 4. Don't be afraid of making changes or mistakes because there's very little that can't be undone (though, don't be afraid to ask for help if you get git in over your head)\n* **Walk through of cncf/mentoring v2 repo update**\n - https://github.com/cncf/mentoring/pull/733 - closed accidentally. Nate to open new one.\n - **New tracking PR**: https://github.com/cncf/mentoring/pull/899\n - Riaan & Jay\n* **KubeCon**\n * TAG Contributor Strategy: What We Get Out of It (and You Could Too!) \n Date and time: Thursday April 20, 2023 15:25 - 16:00 CEST \n Room: Auditorium Center | G109 \n https://sched.co/1HzdC\n * Mentorship Office Hours\n Date and Time: Wed, 19 April, 14:30 - 16:30 \n Room: E101 \n Seating: Boardroom 16pax \n https://sched.co/1KWw8\n * Tech Docs Office Hours (if you're interested 🙂) \n Date and Time: Thur, 20 April, 11:00 - 12:30 \n Room: E101 \n Seating: Boardroom 16pax \n https://sched.co/1KWw2\n* **When is the good time to merge v2?**\n\n### Notes\n**V2 merge accident**\n* Set of GitHub actions hacks that can provide some functions of PROW - Rob Kielty has done some work on these and might offer some solutions to avoid recurring/similar issues\n* Can be helpful to let people know these kind of mistakes are ok and can happen - and important they know they can seek help/support when needed to navigate the space\n\n**Walk through of cncf/mentoring v2 repo update**\n* Updated V2 repo, initial changes made, Riaan/Nate made additional updates in mentee/mentor section. \n* New PR #899 - (initial changes shown)\n* Main branch currently shows multiple scattered files and info. V2 is a rearrangement of pre-existing information to be more accessible for various user types\n* Have created new content sitting under Mentee or Mentor-specific ReadMes with a more logical flow and consistent layout across both sections\n* Will need to be set up so things are obvious and organised in their flow moving forward; also factoring other points such as *'How to be a mentor in GSOC'* etc.\n* Project Board - mentoring issues, public calendar and CoC to be addressed\n* *Will need to double-check Nate's PR cleanup to ensure things are set out as needed*\n* May be some broken links from outside, but can be detected internally e.g. Google Analytics(?) or other automated systems, but possibly not high-priority at this stage\n* Working on this Repo can likely be a recommended 'Good First Issue' for new Contributors\n* Shouldn't need TOC approval with it not being website content, but TAG review would be appreciated with lots of changes having been made\n* Can possibly look at integrating mentee/mentor/program info into Contributor.io eventually\n* *Josh will review w/ Carolyn before approval*\n\n**KubeCon**\n* *TAG Contributor Strategy: What We Get Out of It (and You Could Too!)* - panel discussion \n* *Mentorship Office Hours* - room booked for a couple of hours to chat w/ maintainers on how to write proposals; first come, first served\n * More in attendance, the better (Weds 2.30pm-4.30pm)\n* *Tech Docs Office Hours*\n\nJoin us at times listed!\n\n**When is the good time to merge v2?**\n* Would like to merge sooner than later; mindful of upcoming Kubecon. GSOC deadlines few weeks away so timing is good\n* Would be ideal to have set up before KC EU\n\n\n## March 14, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-03-14; 10:00 AM NZST on 2023-03-15)\n\n### Attendance\n* Nate W.\n* Riaan Kleinhans\n* Hippie Hacker\n* Justin Vice\n* Alexandre Nicastro\n* Josh Berkus\n\n### Agenda\n\n* All comments have been addessed in [start contributing to open source\n#339](https://github.com/cncf/tag-contributor-strategy/pull/339)\n - Should we merge it?\n - Clotributor question\n - Nate to put Riaan in touch with CNCF blog team\n - NATE: YouTube Series : Getting Started\n - process, downloading, finding issues\n - how to contribute to Open Source\n - Maybe Ambassador?\n* GSoD PRs in today -- could use some help reviewing\n - https://github.com/cncf/mentoring/pull/877\n - https://github.com/cncf/mentoring/pull/875 \n - Org applicaitons due March 24, 2023 at 18:00 UTC\n* GSoC\n - Admin guide PR: https://github.com/cncf/mentoring/pull/871\n - March 20th, mentors can start giving feedback at that time\n - Mentors are already in the system\n* simple coder templates\n - https://github.com/cncf-infra/coder-templates/tree/main/simple\n - https://github.com/cncf-infra/coder-templates/tree/main/simple-packet\n - https://github.com/ii/emacs-coder/blob/master/templates/emacs-pod/main.tf\n* Tauranga Kids Day March 31st\n - https://github.com/orgs/workshop-coop/projects/3\n* KubeCon EU Kids Day April 15th\n - https://github.com/orgs/workshop-coop/projects/1\n - workshop.coop hosted coder instance with templates for littil.org KubeCon Kids Day.\n - https://hackmd.io/rHr0DSGpRnmlGzI1p-WzWw\n* KubeCon mentoring office hours \n - 2 hours, time date tbd\n - free form discussion, have a question about CNCF Mentoring, come by and say hi \n* V2 review\n - https://github.com/cncf/mentoring/pull/733\n\n## February 28, 2023\n\n21:00 UTC (1:00 PM PST on 2023-02-28; 10:00 AM NZST on 2023-03-01)\n\n### Attendance\n\n* Nate W.\n* Jay Tihema\n* Ali Ok\n* Riaan Kleinhans\n* Josh Berkus\n* Alexandre Nicastro\n* Parashar Singh\n\n### Agenda\n\n* Adding Ali Ok to GSoC CNCF administration team\n* LFX Mentorship Term 1 updates\n * Nate W. would like to accept applicants as mentors make selections, rather than as a batch on Friday/Monday. (This also gives us more opportunity to adjust when mentors make the same selection)\n* Project Board/Management \n https://github.com/orgs/cncf/projects/16/views/1\n\n### Notes\n\n* Ali Ok accepted as GSOC admin, new process in ongoing review, operations/comms will be conducted in open and continue refinement going forward. \n* LFX Term 1 updates - 20% all mentors have made their selections; may have missed deadline notification prior > 7 March. \n * Suggested acceptance process starts now to reduce admin processes w/ Nate and LFX. Nate will send an email and post to confirm\n* Contacts to go to Natali from previous meeting\n* Question about GSoD: https://github.com/cncf/mentoring/discussions/843#discussioncomment-5052374\n * Not yet run as an org (Nate); GSOD issue last year - allowed only one project per year previously. **Reach out to Google and clarify/confirm any project submission limitations.**\n * (Previously one project per OS project)\n * > (b) Each Organization may submit one (1) Organization Application. https://developers.google.com/season-of-docs/terms/program-rules\n * Timeline: https://developers.google.com/season-of-docs/docs/timeline\n* Alexandre experiencing multiple enquiries regarding getting started in Mentoring\n * (Josh) need clarity about target audiences; persona-based responses \n * Queries generally broad and inconsistent - general 'guidance'-based questions\n * Resources/guides would need to linked to support navigation; conscious of large workload to inform/build fundamental understanding\n * Potential contributors might be cautious of needing 'permission' of getting involved to begin with\n * This would go at: https://contribute.cncf.io/contributors/\n * Maybe a short video can be recorded (can be asked from CNCF Ambassadors)(example) https://www.youtube.com/watch?v=msyGybzCKRs\n * Potential personas\n * new to open source\n * new to cloud native\n * folks changing careers(?)\n * may not lead to sustained contributions (NW + JB)\n * may be an in to opensource regardless (JT + AN)\n * Ongoing discussion needed; to refer to TAG-CS\n * File an issue, attach to draft doc in HackMD/Google Docs, mention on Slack - pertains to both mentoring and Contributor Growth\n * folks assigned by their company to work on open source\n * AN to open issue: https://github.com/cncf/tag-contributor-strategy/\n * Previous Slack discussion https://cloud-native.slack.com/archives/CT6CWS1JN/p1675715555437939\n* 65 projects proposed for LFX, not all proposals have viable candidates at this stage\n* GSOC - March 20 potential contributors to propose, expecting comms in boards re upstream issues \n\n## February 14, 2023\n\n21:00 UTC (1:00 PM PST on 2023-02-14; 10:00 AM NZST on 2023-02-15)\n\n### Attendance\n* Nate W \n* Jay Tihema\n* Ali Ok\n* Alexandre Nicastro\n* Natali Vlatko\n* Riaan Kleinhans\n\n### Agenda\n* Google Season of Docs -- Org applications start tomorrow\n * Next steps?\n * Historically we only get 1-2 slots\n* Notification template - informing Mentees of preferred processes > TAG-CS template\n * https://cloud-native.slack.com/archives/CT6CWS1JN/p1675715555437939\n* Timeline proposals for LFX Mentorship Terms 2 & 3: https://github.com/cncf/mentoring/pull/833\n* LFX promotion on available channels\n * Social boosts for LFX Mentorship Term 1 applciations\n * https://twitter.com/CloudNativeFdn/status/1625192237587111936\n * https://mstdn.ca/@natew/109864484786454672\n * https://www.linkedin.com/feed/update/urn:li:activity:7031335091217809408 \n* v2 additions, workload > PRs\n\n### Notes\n\n**GSOD** \n* Applications starting tomorrow. Would like to apply as an org; requires doc project proposals to support application submission.\n* Not expected to have as many slots available this year, but would like to proceed regardless. Nate will create PR to set up GSOD.\n\n**Notification template for Mentees**\n* Following thread in TAG-CS Slack - response to lots of 'noise' in #mentoring w/ general questions vs. support of upstream issues.\n* Msg replies not necessarily helpful in redirecting or addressing issue. Need to create more effective responses e.g. *template as well as support/training to also foster positive engagement and retention.*\n* Need multiple fronts to 'teach' the preferred behaviour; in addition to Ambassadors supporting this, having coordinated responses\n* Matter of coaching people out of learned behaviours that might not be constructive to attaining opportunities or impacting future relationships; may be less about *contributing* than not even investigating the project to begin with.\n* Better to have template 'available', or respond to every such request/query each time - how to best manage overall 'noise'? e.g. responding to multiple instances than every single one.\n* https://hackmd.io/W-VB1zZtTnOJFBSWR3frUA (working doc)\n\n**Timeline proposals for LFX mentorships Term 2-3**\n* Open for discussion\n\nSocial links boost, need support/please share!\n* Deadline is 21/2/23\n\n**V2**\n* Current layout/format ineffective in guiding mentees/mentors effectively, as well as structuring/archiving program information. \n* User perspective vs. group view on what's needed in this Repo - to help group determine what needs to be updated first e.g. who will be engaging with this resource.\n* Can utilise mentees/mentors to review and provide feedback - previous mentees for could be more beneficial (even limited numbers)\n * TODO: Nate to reach out to find folks, Natali to run interviews\n* Could potentially request mentees at program completion review the Repo as well. \n* Need to confirm what is needed to produce an MVP ahead of potential merge in the next month\n* Contributions - comment PR-level discussions; link any new PRs against V2 to maintain visibility.\n* Umbrella PR: https://github.com/cncf/mentoring/pull/733\n\n**CLOTributor**\n* Being positioned as preferred 'job boards' to promote opportunities for contributors; recommended to focus here for development.\n\n## January 24, 2023\n\n21:00 UTC (1:00 PM PST on 2023-01-24; 10:00 AM NZST on 2023-01-25)\n\n### Attendance\n\n* Nate W.\n* Ali Ok\n* Josh \n* Alexandre\n* Riaan\n* Jay\n\n### Agenda\n\n* LFX Mentorship Project Proposals\n * https://github.com/cncf/mentoring/tree/main/lfx-mentorship/2023/01-Mar-May\n* 2023 Goals\n * https://hackmd.io/@tag-cs-mentoring-wg/2023-goals\n* Repo revisions\n * project board: https://github.com/orgs/cncf/projects/16/views/1\n* GSoC Org applications\n * Nate W. to work with Chris A. to apply as an org\n * https://groups.google.com/d/msgid/google-summer-of-code-discuss/649212c4-fe0d-4cb6-8e48-17f961e3d0ben%40googlegroups.com?utm_medium=email&utm_source=footer\n\n- Ali:\nCould we have the [Ideas page](https://github.com/cncf/mentoring/blob/main/summerofcode/2022.md) open earlier? Motivation for the ask is that the potential mentees want to start exploring the project ideas earlier. Similarly, maintainers want to list their ideas earlier for encouraging a head start.\n\n- Options are making the Ideas page availible through out the year\n- Incorporate CLOtributor with the process with `Help wanted` & `Mentor Available` labels\n - AI: Riaan & Jay add CLOTributor to the Mentoring repo\n- **Could use Git discussions for this as well.** \n - GSOC 2022 - Nate opened a thread to support this, however only 15% of this thread was used; also creating alot of overhead to maintain. Because this will all link back to upstream issues; preferred this would occur off the boards. \n - Might also be hard to filter convos back into the issues themselves as well. An ideas page however would give a centralised reference point for those seeking information. \n - We should keep encouraging mentees to reach out to potential mentors; aiming to give mentors more time to make their selections as well.\n - Having alot of mentees/applicants can be difficult to filter/process effectively otherwise.\n - Another option might be for mentees to 'source' their own mentors to support/drive projects as well > Application Process\n - If a potential mentee is interested in a CNCF project and wants to do a mentorship, this should put the impetus on the mentee themselves; this mechanism currently exists but is not explicitly communicated.\n - This might be an issue especially for paid mentorships such as LFX. This could be exploited from a faculty of an education provider for instance that could implement their own mentee without following the preferred process. \n**How to incorporate Clotributor into the existing onboarding process?** Future working session(s) to determine best course of action.\n\n**Repo update**\n- Thank you for review Ali & Nate\n- Next step might be to merge in v2 branch\n - Then clean up and distill information in Mentee and Mentor files to a single readme for people to the contribute\n - Try and make the info clear one stop place to find info\n - Might have to hold back on merging in the v2 branch because links have been publish to current repo info.\n - When would be a good time to remove the WIP label from the PR.\n - Likely after updating Mentee and Mentor sections is in a workable state + FAQs\n* Should be rebasing but leave number of commits\n* Folder restructure, mentee/mentor page and FAQ\n* GitHub doesnt have a redirection tool; maintainters have been notified, potential applicants will seek this information - work can be continued once ideas have been confirmed/agreed upon, possibly next week.\nQ. Keep v1 page blank with link to v2 page\nEdit page we would link to, highlight page move. Can hold off on this until the last minute; let's keep it clean in the meantime. \n\nLinks important to share with others - Mentoring tree main, LFX Mentorship 2022... [link](https://github.com/cncf/mentoring/tree/main/lfx-mentorship/2023/01-Mar-May)\n\n## January 10, 2023\n\n21:00 UTC (1:00 PM PST on 2023-01-10; 10:00 AM NZST on 2023-01-11)\n\n### Attendance\n\n* Nate W.\n* Riaan K.\n* Asare N.\n* Josh Berkus\n* Alexandre N.\n\n### Updates/reminders\n\n* [2022 Meeting Minutes](https://hackmd.io/@tag-cs-mentoring-wg/monthly-meeting) file has been set to read only for most users and [is being archived](https://github.com/cncf/mentoring/pull/756).\n\n### Agenda\n\n* Mentoring WG Calendar https://calendar.google.com/calendar/u/0?cid=Y18wNTMzNWEwNDhjYjMyNTk3NTRmZjAzYzgwM2MyN2FjMDhmMjFkZTc4OTYyMDhkMmI1NWFjMmM1MTIzNDlhZDFiQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20\n* LFX Mentorship Project proposals open Jan 16\n * https://github.com/cncf/mentoring/tree/main/lfx-mentorship/2023/01-Mar-May\n * email toc mailing list\n* Repo revisions - to create a work session to discuss/rework.\n* [Nate W.] Do we still need the temp 2nd monthly meeting? (We should defer this question to a meeting that Jay can attend)\n* KubeCon Amsterdam\n * workshop re: how to be a good mentor (proposal writing, selecitng mentees, etc.)\n * Speed mentoring co-operation\n * find out who to chat with about this\n* 2023 Mentorship goals\n * Increase diversiy of participants\n * How do we increase awareness in geographical diverse places?\n * Students in academic communities in new locations\n * LM\n * Africa\n * 150 mentees participating across all programs\n * work with LF research team to better understand trends\n * work with LF training to create a training course for mentors\n * work with LF mentoring admins to reach out to universities to work with co-op programs\n * increase number of programs we participate in\n * ex. Outreachy\n * recruit community members to help manage/run the programs\n * others?\n * [name=Nate W.][time=Thu, Jan 12, 2023 10:05 AM] Look into creating a 2-term program for longer/larger projects (How would this work with the req that mentees can only participate in one mentorship)\n * [name=Nate W.][time=Thu, Jan 12, 2023 1:13 PM] Reduce percentage of failed/withdrawn mentees\n \n* Organize projects (and SIGs and TAGs) to supply an ongoing list of mentorship opportunities based on the Clotributor.\n * https://clotributor.dev/\n * That way we can reach out based on existing tasks\n * Plus skim a list of potential mentors\n* Participate in MC, doing session on \"participating in mentorship programs\"\n * Nate + 1-2 project maintainers who did mentorships\n\n\n---\n\n# Meeting Template\n\n## March 14, 2023\n\n21:00 UTC (2:00 PM PDT on 2023-01-10; 10:00 AM NZST on 2023-01-11)\n\n### Attendance\n\n* \n\n### Updates/reminders\n\n* \n\n### Agenda\n\n* \n\n### Notes\n\n* \n\n---\n\n# Archives\n\n* [2022 Meeting Minutes](https://github.com/cncf/mentoring/blob/main/TAGCS-Mentoring-WG/2022-meeting-minutes.md)\n* [June 30, July 12, July 26, 2022](https://docs.google.com/document/d/1ZVFf_GRB5yrcTQieudtk3W-gWL6KuwHn1QG8XKdrARo/edit?usp=sharing)\n" }, { "path": "cncf-toc-mentoring-subproject/2024-meeting-minutes.md", "content": "---\ntitle: TAGCS Mentoring Working Group Monthly Meeting (2024)\ntags: Meeting Minutes, 2024\n---\n\n# Mentoring Working Group\n\nThis file’s location: \n[1\\. Technical Advisory Groups / TAG Contributor Strategy / Mentoring](https://drive.google.com/drive/folders/1IlgEbbspQTpSthEuXgZqZsUCEJxH5NBZ?usp=drive_link) \nGitHub location: [https://github.com/cncf/mentoring/blob/main/mentoring-wg/2024-meeting-minutes.md](https://github.com/cncf/mentoring/blob/main/mentoring-wg/2024-meeting-minutes.md)\n\n# About TAGCS Mentorship Working Group\n\n* [Primary repository](https://github.com/cncf/mentoring)\n* CNCF Slack: [\\#tag-contributor-strategy](https://cloud-native.slack.com/archives/CT6CWS1JN)\n* [Discussion boards](https://github.com/cncf/mentoring/discussions)\n* [Email list](https://lists.cncf.io/g/tag-cs-mentoring-wg/)\n\n## Meeting details\n\n### Recurring monthly\n\n3rd Thursday of the month at 10AM Pacific Time \n[CNCF Public Events \\- TAG CS Mentoring WG](https://tockify.com/cncf.public.events/monthly?search=CNCF%20TAG%20Contributor%20Strategy%20Mentoring%20WG)\n\n### Zoom\n\nZoom Meeting: \n[https://zoom.us/my/cncftagcontributorstrategy?pwd=TnI0WU9Eb2I1RlRWdkl1R0k1WkZXUT09](https://zoom.us/my/cncftagcontributorstrategy?pwd=TnI0WU9Eb2I1RlRWdkl1R0k1WkZXUT09) \nPasscode: 77777\n\n---\n\n# Upcoming Meetings\n\n## November 21, 2024\n\n10:00 AM Pacific Time (18:00 UTC on 2024-11-21)\n\n### Attendance\n\n*\n\n### Updates/reminders\n\n*\n\n### Agenda\n\n*\n\n### Notes\n\n*\n\n# Past Meetings\n\n## October 17, 2024\n\n10:00 Pacific Time (17:00 UTC on 2024-10-17)\n\n### Attendance\n\n* Ali Ok\n* Nate W.\n\n### Updates/reminders\n\n* LFX Term 3 in-flight\n * Midterm evaluations due\n * Some evals still outstanding, Nate has reached out to mentors.\n * Only 1 person failed\n* Mentorship monitor\n * There might be issues\n * Some PRs not shown\n * Let’s do a walkthrough\n* KubeCon\n * Tech-docs side of Nate’s job: skill-up at project pavilion stage\n * Let’s do a 20 minute informal session\n * Could base it on this talk: [https://docs.google.com/presentation/d/1O8Z5p2R9-9cj2dQBfK7kk4KlIRhG\\_eKZ30rI0bTsZRE/edit?usp=sharing](https://docs.google.com/presentation/d/1O8Z5p2R9-9cj2dQBfK7kk4KlIRhG_eKZ30rI0bTsZRE/edit?usp=sharing)\n * Audience: projects looking to grow their contributor pool\n * NW to chat with Jorge to see if there’s slots available and when we can run this.\n* GSoC 2024\n * 1 project is still running\n * All pass\\!\n* New docs needed (discussed before)\n * LFX mentorship org admin guide\n * Mentee guide, more specific to CNCF\n * Blog post template for mentees\n* Info sessions\n * 2025 Term 1 schedule: [https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2025/01-Mar-May](https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2025/01-Mar-May)\n * Proposal: schedule info sessions in advance, published with teh rest of the term schedule.\n * Mentor session: within Wednesday, January 8 \\- Tuesday February 4, 2025\n * Mentee session: on the week of Monday, March 3, 2025\n\n## September 19, 2024\n\n10:00 Pacific Time (17:00 UTC on 2024-09-19)\n\n### Attendance\n\n* Nate W.\n* Josh B.\n* Prasanth B.\n* Faseela K.\n\n### Updates/reminders\n\n* End of LFX Term 2 CNCF blog post should go up tomorrow\n* LFX Term 3 has started: 47 mentees, 69 mentors, across 20 CNCF projects\n* [2025 Term 1 schedule](https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2025/01-Mar-May)\n * This is a draft, updates/comments welcome\n* Governing Board meeting info (here’s what CNCF is sharing with the GB):\n * [https://docs.google.com/spreadsheets/d/e/2PACX-1vQPfUX9-yuEAXN\\_pO-bpRShHbp70YUTHY1UEnHYKOsqOL5O0VpdkxnH-DsyNf4GxMmylsoRQ79cblON/pubchart?oid=1556086465\\&format=interactive](https://docs.google.com/spreadsheets/d/e/2PACX-1vQPfUX9-yuEAXN_pO-bpRShHbp70YUTHY1UEnHYKOsqOL5O0VpdkxnH-DsyNf4GxMmylsoRQ79cblON/pubchart?oid=1556086465&format=interactive)\n * (source: [CNCF Mentoring Stats Overview (ongoing summary)](https://docs.google.com/spreadsheets/d/13xybjxyWOHcfNn3Mmpd6zbq61gLp5Kprdsda-nJ50lM/edit?usp=sharing))\n* Outreachy: CNCF has approved funding for 1 participant (OTel)\n* Revisit blog posting and work reports (NW to write up new mentee guide of how this would work)\n * Need templates\n * Strongly suggest blog posts (not require)\n\n### Notes\n\n* NW to explore automating meeting announcements\n\n## August 15, 2024\n\n10:00 Pacific Time (17:00 UTC on 2024-08-15)\n\n[TAG Contributor Strategy: Mentoring WG 2023-08-14](https://youtu.be/Sujcok2ETQA)\n\n### Attendance\n\n* Nate W.\n* Josh B.\n* Vesyl\n\n### Agenda\n\n* LFX Mentorship\n * Term 2\n * Ending Aug 28, mentors and mentees should be thinking about how to finish up\n * Term 3\n * Applications closed, mentors making candidate selections\n * 2025 Term 1\n * We’re holding the [2024 term 1 umbrella issue](https://github.com/cncf/mentoring/issues/1077) open still because we’ve not planned 2025 Term 1 yet. We should plan Term 1\\.\n * \\[NW\\] Proof of work\n * Now that we’re able to monitor mentees productivity more closely, [https://mentorship-monitor-ui.netlify.app/](https://mentorship-monitor-ui.netlify.app/), I’d like to discuss the possibility of requiring proof of work in order for mentees to pass the evaluations.\n * Historically, the administrators have always deferred to the mentors\n * If the mentors say that the work submitted isn’t sufficient to pass the evaluation, the administrators could not overrule that, and I’d like to keep that part the same.\n * Moving forward, *I’d like the mentors and administrators to agree that the work is sufficient*. In most cases this is obvious, and if the mentors say the work is good it is; however, in some cases we see that some mentors have said the work is good but the public record appears to show a lack of progress. This can be due to several factors\n * Not all projects lend themselves to GitHub (for instance UI projects will often use Figma to do the work).\n * Some projects require a lot of research before changes can be made in GitHub\n\n If a mentor is able to explain this then I’m happy for the mentee to be passed, receive their stipend, and continue.\n\n What then would the criteria for disagreeing with the mentors be, and how could we override the mentors while preserving the trust of the maintainers?\n\n* Revisit blog post requirements\n * \\[NW\\] We’ve discussed this before, but CNCF leadership has asked if we are requiring blog posts. I told them the reasons we don’t, but I’d like to revisit what recommendations we make around end of term blog posts and how we make them.\n * \\[JB\\] Need to provide a template \\- currently folks write about the program, and a little about what they did. We’re interested in what they did primarily.\n * Video option?\n\n### Notes\n\n* NW to invite LFX team to meet with mentoring wg\n* Clotributor chat: [https://clotributor.dev/](https://clotributor.dev/)\n\n## July 9, 2024\n\n21:00 UTC (2:00 PM PDT on 2024-07-09; 10:00 AM NZST on 2024-07-10)\n\n[TAG Contributor Strategy: Mentoring WG 2023-07-09](https://youtu.be/xXk1rZullJQ?si=ui1Faum7uSeyJ8Ly)\n\n### Attendance\n\n* Nate W.\n* Faseela K\n* Josh B\n\n### Agenda\n\n* LFX Term 3\n * [https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2024/03-Sep-Nov](https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2024/03-Sep-Nov)\n* Issues with LFX platform ([https://github.com/cncf/mentoring/issues/1262](https://github.com/cncf/mentoring/issues/1262))\n * LFX team says upload issues should be resolved no later than July 19, meaning we don’t have to postpone the term\n * Much better responsiveness, fixing things from LFX team\n * Issues: please report at [https://community.lfx.dev/](https://community.lfx.dev/)\n* Changing Meeting times:\n * Move to 3rd Thursday of the month starting August\n * First meeting on new schedule: August 15, 10am PDT / 7pm CET / 10:30pm IST\n* RCOS\n * Nate had a meeting with [https://new.rcos.io/](https://new.rcos.io/) folks\n * RedHat quite involved – Nate & Josh to chat offline\n* GSoC 2024\n * Midterm evals this week\n\n## June 11, 2024\n\n21:00 UTC (2:00 PM PDT on 2024-01-11; 10:00 AM NZST on 2024-01-12)\n\n[TAG Contributor Strategy: Mentoring WG 2023-06-11](https://youtu.be/QlSJtuu0Pz4?si=_5wsnLj-TYwQozzU)\n\n### Attendance\n\n* Nate W.\n* Ali Ok\n* Josh Berkus\n* Kushal Agrawal\n* Sunil Ravipati\n\n### Agenda\n\n* \\[aliok\\] Changing time for the Mentoring WG meeting\n * Nate is going to create a Doodle\n * One slot should be the empty TAG thursday slot (TAG meets 3 times a month, we can grab the 4th)\n* \\[aliok\\] Discussion around mandatory blogposts / webinars / recordings for mentees\n* [https://github.com/cncf/mentoring/issues/1216](https://github.com/cncf/mentoring/issues/1216)\n* We already encourage mentees to write blog posts\n* We don’t want to mandate it to block the stipend payments\n* We already have a few mentees every term writing blog posts\n* Mentors/mentees might not have the skills\n * We would need to provide assistance, which might be hard due to resource constraints\n * We might provide a blogpost template, which might help with mentees to write the blog posts. This might help with having more blog posts.\n* Ali [commented](https://github.com/cncf/mentoring/issues/1216#issuecomment-2161620387) on the issue, and asked the issue author if they’re interested in providing such a template.\n * Also created [a ticket](https://github.com/cncf/mentoring/issues/1256)\n* \\[Sunil\\] Anything to participate in or help with this WG?\n * Josh’s suggestion: a semi-structured mentoring program for security tasks on CNCF projects, as Sunil is part of TAG Security\n* \\[Nate W.\\] Need to schedule info sessions for LFX term 2 (Mentors, mentees, whole group)\n * Invite alumni to attend mentee info session\n* \\[aliok\\] How to recruit more people to this WG?\n * Target alumni\n * Mentees might be better candidates than mentors, as mentors are busy\n * Ambassadors can also help\n * Find curated tasks (e.g. find out about / run Outreachy)\n * Ask help, similar to: [https://github.com/kubernetes-sigs/lwkd/issues/205](https://github.com/kubernetes-sigs/lwkd/issues/205)\n * When we get more people, we can:\n * Formalize/structure various Kubernetes mentoring programs\n * Participate in other mentorship programs (Outreachy, etc)\n* \\[Josh\\] Collecting mentorship proposals continuously\n * Perhaps with issues with specific labels\n * Fork Clotributor? Or, talk to Chris\n * Ali to create a ticket\n* \\[aliok\\] Ali is on PTO next 3 weeks\n* \\[Nate W.\\] One Kubernetes project dropped out of LFX, cited lack of time to make selections\n* \\[Nate W.\\] GSoC Mentor Summit\n\n## May 14, 2024\n\n21:00 UTC (2:00 PM PDT on 2024-01-10; 10:00 AM NZST on 2024-01-11)\n\n### Attendance\n\n* Nate W.\n\n### Updates/reminders\n\n* Meeting canceled due to lack of attendance.\n\n### Agenda\n\n* \\[aliok\\] Discussion around mandatory blogposts / webinars / recordings for mentees\n * [https://github.com/cncf/mentoring/issues/1216](https://github.com/cncf/mentoring/issues/1216)\n* \\[Nate W.\\] Need to schedule info sessions for LFX term 2 (Mentors, mentees, whole group)\n\n## April 09, 2024\n\n21:00 UTC (2:00 PM PDT on 2024-01-10; 10:00 AM NZST on 2024-01-11)\n\n### Attendance\n\n* Nate W.\n* Victor L.\n\n### Updates/reminders\n\n* LFX\n * Term 1 \\- midterms\n * Term 2 \\- open for proposals ([https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2024/02-Jun-Aug](https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2024/02-Jun-Aug))\n * Maintainers email went out, will also forward to TOC email list as well as work with socials team to boost\n * Term 3 \\- planning ([https://github.com/cncf/mentoring/issues/1107](https://github.com/cncf/mentoring/issues/1107) review requested)\n* GSoC\n * Mentors making “I want to mentor this” selections (due April 16\\)\n * Reminder email to go out tomorrow\n\n## March 12, 2024\n\n### Attendance\n\n* Nate W\n* Ali Ok\n* Riaan K\n\n### Agenda\n\n* \\[aliok\\] GSoC \\- applications start next week\n * Need to add mentors\n * Next steps:\n * Mentors to make their selections by 16th April latest\n * Mail to send to mentors about this after 2nd April (applications closed)\n* \\[aliok\\] GSoDocs [https://developers.google.com/season-of-docs/docs/timeline](https://developers.google.com/season-of-docs/docs/timeline)\n * Some projects interested: Buildpacks\n* \\[aliok\\] KubeCon mini-summit\n* \\[aliok\\] KubeCon TAG CS canvassing\n * [KubeCon EU 2024 - Project booth visit pairing](https://docs.google.com/spreadsheets/d/1NyUSu1F5OKL4VYpWrf6735wb34x4BwTkcQZt1KYipbw/edit#gid=0)\n * [KubeCon EU 2024 - Project Pavillion Canvass Details](https://docs.google.com/document/d/1PLkN6ZM5kndrfiNP6HchbzQsI2XF-qLZ_Q0BkRgG_fs/edit#heading=h.uc3pmzl4kaa)\n* Details about keeping an eye on mentees?\n\n## February 13, 2024\n\n21:00 UTC (1:00 PM PDT on 2024-02-13; 10:00 AM NZST on 2024-02-14)\n\n### Attendance\n\n* Nate W.\n* Josh Berkus\n* Riaan Kleinhans\n* Jay Tihema\n\n### Agenda\n\n* LFX\n * Mentee candidate applications due today\\!\n* GSoC\n * Org application in, we have several proposals. More welcome.\n * Josh to include GSoC info in newsletter\n* Outreachy\n * OTel?\n * Josh to help recruit admin\n\n### Notes\n\n* Google doc vs Hackmd?\n * We might have to switch\n * Discussed issues for sharing, Chinese contributors\n * Need to put stuff into TAG shared drive\tDocument created to move to for 2024 in [CNCF/TAG\\_CS/Mentoring](https://docs.google.com/document/d/1sSYRo-5yxJggGg3JVATxMKdxVWbY_ZGD2mhKlPNW7qM/edit)\n\n---\n\n# Meeting Template\n\n## August 15, 2024\n\n10:00 AM Pacific Time (17:00 UTC on 2024-08-15)\n\n### Attendance\n\n*\n\n### Updates/reminders\n\n*\n\n### Agenda\n\n*\n\n### Notes\n\n*\n\n---\n\n# Archive\n\n* [2023 Meeting Minutes](https://hackmd.io/zNzH0LTMQ16Lkjg16FZEcw?both)\n* [2022 Meeting Minutes](https://hackmd.io/zNzH0LTMQ16Lkjg16FZEcw?both)\n* [June 30, July 12, July 26, 2022](https://docs.google.com/document/d/1ZVFf_GRB5yrcTQieudtk3W-gWL6KuwHn1QG8XKdrARo/edit?usp=sharing)\n\n" }, { "path": "cncf-toc-mentoring-subproject/2025-meeting-minutes.md", "content": "---\ntitle: CNCF TOC Mentoring Subproject Monthly Meeting (2025)\ntags: Meeting Minutes, 2025\n---\n\n# CNCF TOC Mentoring Subproject\n\nThis file’s location: [1\\. Technical Advisory Groups / TOC Subprojects / TOC Mentoring Subproject](https://drive.google.com/drive/folders/1IlgEbbspQTpSthEuXgZqZsUCEJxH5NBZ?usp=drive_link) \nGitHub location: [https://github.com/cncf/mentoring/blob/main/mentoring-wg/2024-meeting-minutes.md](https://github.com/cncf/mentoring/blob/main/cncf-toc-mentoring-subproject/2025-meeting-minutes.md) \n\n# About CNCF TOC Mentoring Subproject\n\n* [Primary repository](https://github.com/cncf/mentoring) \n* CNCF Slack: [\\#tag-contributor-strategy](https://cloud-native.slack.com/archives/CT6CWS1JN) \n* [Discussion boards](https://github.com/cncf/mentoring/discussions) \n* [Email list](https://lists.cncf.io/g/tag-cs-mentoring-wg/)\n\n## Meeting details\n\n### Recurring monthly\n\n3rd Thursday of the month at 10AM Pacific Time \n[CNCF TOC Mentoring Subproject Public Calendar](https://zoom-lfx.platform.linuxfoundation.org/meetings/toc-mentoring-subproject?view=month)\n\n[Zoom Meeting](https://www.google.com/url?q=https://zoom-lfx.platform.linuxfoundation.org/meeting/98463708370?password%3D72ace7ec-4348-4061-af62-6a1307ea4127&sa=D&source=calendar&ust=1744034815660936&usg=AOvVaw0uMwWpmXH-NinIYp76V561) \n---\n\n# Upcoming Meetings\n\n## April 17, 2025\n\n10:00 AM PDT \n[Timezone calculator](https://www.worldtimebuddy.com/?qm=1&lid=6173331,100,2193733&h=100&date=2025-3-20&sln=17-18&hf=1)\n\n### Attendance\n\n* \n\n### Updates/reminders\n\n* \n\n### Agenda\n\n* \n\n### Notes\n\n* \n\n# Past Meetings\n\n---\n\n# Meeting Template\n\n## August 15, 2024\n\n10:00 AM Pacific Time (17:00 UTC on 2024-08-15)\n\n### Attendance\n\n* \n\n### Updates/reminders\n\n* \n\n### Agenda\n\n* \n\n### Notes\n\n* \n\n---\n\n# Archive\n\n* [2023 Meeting Minutes](https://hackmd.io/zNzH0LTMQ16Lkjg16FZEcw?both) \n* [2022 Meeting Minutes](https://hackmd.io/zNzH0LTMQ16Lkjg16FZEcw?both) \n* [June 30, July 12, July 26, 2022](https://docs.google.com/document/d/1ZVFf_GRB5yrcTQieudtk3W-gWL6KuwHn1QG8XKdrARo/edit?usp=sharing)\n\n" }, { "path": "cncf-toc-mentoring-subproject/README.md", "content": "# CNCF TOC Mentoring Subproject\n\n## About\n\n[Mentoring Subproject Charter](https://github.com/cncf/toc/blob/main/toc_subprojects/mentoring-subproject/charter.md)\n\n* CNCF Slack: [#cncf-mentoring](https://cloud-native.slack.com/archives/CGPK98JNQ)\n* [Discussion boards](https://github.com/cncf/mentoring/discussions)\n* [Email list](https://lists.cncf.io/g/tag-cs-mentoring-wg/)\n\n\n## Meeting details\n\n### Recurring monthly\n* 3rd Thursday of the month at 10:00 AM Pacific Time\n\n[CNCF TOC Mentoring Subproject Public Calendar](https://zoom-lfx.platform.linuxfoundation.org/meetings/toc-mentoring-subproject?view=month)\n\n### Zoom\n\n[Zoom Meeting](https://zoom-lfx.platform.linuxfoundation.org/meeting/98463708370?password=72ace7ec-4348-4061-af62-6a1307ea4127)\n\n# Meeting Minutes\n\n* [2024](https://docs.google.com/document/d/1sSYRo-5yxJggGg3JVATxMKdxVWbY_ZGD2mhKlPNW7qM/edit?usp=sharing) (current)\n* [2023](./2023-meeting-minutes.md)\n* [2022](./2022-meeting-minutes.md)\n* [June 30, July 12, July 26, 2022](https://docs.google.com/document/d/1ZVFf_GRB5yrcTQieudtk3W-gWL6KuwHn1QG8XKdrARo/edit?usp=sharing)\n\n" }, { "path": "cncf-toc-mentoring-subproject/communications.md", "content": "CNCF TAG Contributor Strategy\n# Mentoring Working Group\n\n\n## About TAGCS Mentorship Working Group\n\n[Mentoring WG Charter](https://github.com/cncf/tag-contributor-strategy/tree/main/mentoring)\n\n* CNCF Slack: [#tag-contributor-strategy](https://cloud-native.slack.com/archives/CT6CWS1JN)\n* [Discussion boards](https://github.com/cncf/mentoring/discussions)\n* [Email list](https://lists.cncf.io/g/tag-cs-mentoring-wg/)\n\n## Communications\n\nPlease reach out to us using GitHub [Discussions](https://github.com/cncf/mentoring/discussions).\n\nWe are also available on the [CNCF Slack Workspace](https://slack.cncf.io/). Avoid sending direct messages to organization admins and project maintainers unless strictly necessary as doing so has the potential of overwhelming project maintainers and prevents others with similar questions from benefitting from your public discussion.\n\nWhile its best to relay your inquiries in a public forum, should you need to communicate in private, please feel free to send the admins a note at mentoring@cncf.io. Be sure to use public channels for any project-related discussion.\n" }, { "path": "cncf-toc-mentoring-subproject/gsoc-org-admin-guide.md", "content": "# CNCF GSoC admin guide\n\n## Introduction\n\n> **Note**\n> This is a guide for Google Summer of Code admins at CNCF.\n\nWhile Google [defines](https://developers.google.com/open-source/gsoc/help/responsibilities#org_admin_responsibilities) responsibilities for organization admins and gives some [tips](https://developers.google.com/open-source/gsoc/help/oa-tips), there are variations in how organizations run the program suitable for their communities.\n\n> **Note** \n> The \"contributor\" term throughout this document is used as \"mentee.\" Please do not mix the word \"contributor\" with regular contributors and maintainers of the CNCF projects. Here, the term \"contributor\" follows Google's terminology for the GSoC program.\n\n## Outline of responsibilities\n\nFirst of all, GSoC admins are required to read these documents from Google:\n\n* [GSoC admin responsibilities](https://developers.google.com/open-source/gsoc/help/responsibilities#org_admin_responsibilities)\n* [GSoC admin tips](https://developers.google.com/open-source/gsoc/help/oa-tips)\n\nIn summary, responsibilities can be outlined as follows:\n\n* Recruitment: GSoC admins are responsible for recruiting mentors from among the maintainers of the CNCF projects. They also recruit new contributors to participate in the program as mentees. They reach out to communities, promote the program, and answer questions from interested parties.\n* Mentor management: GSoC admins ensure mentors are qualified and have the experience to mentor contributors effectively. They provide guidance and feedback to help mentors improve their mentoring skills.\n* Contributor management: GSoC admins set up the foundation for communication between the mentors and the contributors. They provide guidance for contributors and mentors to connect, monitor the progress of projects, and provide non-technical support as needed.\n* Program coordination: GSoC admins coordinate the program logistics. This may include applying to the program, ranking proposals, setting deadlines, communicating with involved parties, and ensuring that all contributors and mentors have the resources they need to be successful.\n* Program evaluation: Admins evaluate the program's success and identify areas for improvement. They do this by analyzing program data, collecting feedback from contributors and mentors, and making recommendations for future program iterations.\n\nThe following are not responsibilities of a GSoC admin:\n* Verifying the eligibility of contributors in terms of age, country of residence, and similar criteria. Google does this.\n* Providing technical support to mentors or contributors about the project.\n* Technically mentoring the contributors (e.g., technical troubleshooting), other than giving general guidance and/or replying to questions by pointing at possible places to find an answer.\n* Providing non-technical mentoring to the contributors (e.g., career advice, personal advice, etc.).\n\n## Checklist\n\n### GSoC program announcement\n\nAt this stage, Google announces it will have GSoC in the upcoming year. There is no guarantee from Google that CNCF will be accepted to GSoC.\n\nTasks:\n* Create GSoC ideas page in [`cncf/mentoring`](https://github.com/cncf/mentoring/tree/main/programs/summerofcode) repository. An ideas page will be necessary during the organization application.\n* [Announce](#Announcements) the intention to participate in the program ([example announcement](https://github.com/cncf/mentoring/discussions/777)). Mention these:\n * Deadline to add ideas is the contributor application period start date.\n * CNCF has not yet been accepted into the program.\n * We are collecting ideas.\n * We encourage communities to add ideas earlier rather than later to give potential contributors more time.\n* Start monitoring PRs to ideas page, review ideas added by mentors using the [proposal review guideline](#Project-idea-proposal-review-guidelines).\n\n### Pre- organization application period\n\nAt this stage, there is still no guarantee from Google that CNCF will be accepted to GSoC. CNCF is collecting ideas for potential contributors and preparing for the organization's application to GSoC.\n\nTasks:\n\n* Send a reminder to CNCF project communities to add ideas as stated in the previous stage.\n\n\n### Organization application\n\nAt this stage, an ideas page should be listed with a few ideas.\n\nTasks:\n* Apply to the program.\n\n### Acceptance announcement\n\n* [Announce](#Announcements) the acceptance in the program ([example announcement](https://github.com/cncf/mentoring/discussions/848)). Mention these:\n * CNCF is accepted to the program.\n * It is still possible to add ideas until the contributor application period start date.\n * We encourage communities to add ideas earlier rather than later to give potential contributors more time.\n * We encourage contributors to explore project ideas and engage with mentors and communities.\n* Although there can be ideas/mentors added until contributor applications, it is encouraged to get mentors ([example Github task](https://github.com/cncf/mentoring/issues/864)):\n * Added to GSoC platform\n * Added to GSoC program for the current year in GSoC platform\n\n### Contributor applications\n\n* [Announce](#Announcements) that the contributor applications have started ([example announcement](https://github.com/cncf/mentoring/discussions/892)). \n* Mention these:\n * We encourage contributors to submit proposals early to be able to get feedback from mentors and fix any issues.\n * We are no longer collecting ideas from mentors.\n* Inform member mentors (mentors who added an idea) about these:\n * They need to review proposals from contributors before they submit the final proposal.\n* As we are not collecting ideas anymore, finalize getting mentors:\n * Added to GSoC platform\n * Added to GSoC program for current year in GSoc platform\n\n\n### Rankings\n\n* Ask mentors to\n * Review proposals and select contributors they want to mentor\n * Provide feedback in the GSoC system around the matters listed in the [contributor+proposal selection and ranking process](#Contributorproposal-selection-and-ranking-process), such as community interaction, proposal quality, etc.\n * Refrain from commenting on any contributor's chances of being accepted.\n * (Example Github discussion [announcement](https://github.com/cncf/mentoring/discussions/918))\n* Run the ranking process\n\n### Accepted projects announcement\n\n* [Announce](#Announcements) that accepted contributors and projects have been chosen ([example announcement](https://github.com/cncf/mentoring/discussions/954)).\n* Create a mailing list specific to the current GSoC session, which will be used to communicate with accepted mentors.\n* Add selected mentors to the mailing list created earlier\n* Inform mentors and contributors about:\n * Community bonding\n * Getting up to speed to begin working on projects\n * Other mentoring program opportunities ([example](https://github.com/cncf/mentoring/discussions/918#discussioncomment-5810110))\n\n### Community bonding\n\n* Send a reminder email to mentors about (example email can be found in mailing lists of previous sessions):\n * Reaching out to mentees to let them know how to kick-start coding\n * Informing GSoC admins about any inactive mentees to ask Google to remove them from the program\n\n### Coding period\n\n* Inform mentors and contributors about the following:\n * Coding starting date\n * Midterm evaluation date\n* Send periodic reminders to mentors, possibly on Slack as direct messages about:\n * How the progress is\n * Is there a need for extension\n\n### Midterm evaluations\n* Inform mentors and contributors about:\n * Midterm evaluations and deadlines\n * [Google's evaluation guide](https://google.github.io/gsocguides/mentor/evaluations)\n* Send a reminder 2 weeks before the deadline and at the first day of evaluation period about the deadline.\n* During the week of evaluation, emails sent should be a personal email like \"Hello Name, LastName\" instead of to the mailing list. \n\n\n### Final evaluations\n* Inform mentors and contributors about:\n * Final evaluations and deadlines\n * [Google's evaluation guide](https://google.github.io/gsocguides/mentor/evaluations)\n* Follow the emailing guidelines from the [Midterm evaluations](#Midterm-evaluations) section.\n\n### Results\n* Run a retrospective using processes such as:\n * Feedback survey for contributors and mentors\n * Analyze data\n * Retrospective session for GSoC admins\n* Fill Google's feedback survey.\n* [Announce](#Announcements) the results.\n\n### Additional tasks\n\n* Mentor stipend: This can be only done by CNCF staff.\n* Maintain this guide\n\n## Project idea proposal review guidelines\n\n* Make sure the mentor is in the [project-maintainers.csv](https://github.com/cncf/foundation/blob/main/project-maintainers.csv) file for the related project. If not, ask the PR author to ask for a `lgtm` from the people on that list.\n* Check if the formatting is right.\n* Make sure the upstream ticket actually exists and is open and unassigned.\n* Check if the project size in hours is one of the values provided by Google.\n* Check if the mentors have names, Github usernames and emails listed.\n* Make sure that the description provides a good sense of context and motivation for the idea to attract contributors.\n* Ensure the expected outcome benefits contributors (e.g. learning, growth) and the project (e.g. new features/functionality, bug fixes).\n* Check if the idea is a coding project. Projects such as documentation-only tasks are not accepted to GSoC per [program rules](https://summerofcode.withgoogle.com/rules).\n* Remind the mentor about the deadlines with this text, before merging their PR:\n> Please note that GSoC is a program known for its strict deadlines. In addition to responding to your mentee on time, you will be required to submit evaluations on time. Failures to meet the deadlines might affect CNCF's future participation in GSoC.\n* Make sure the proposal has at least to mentors and one is noted as the primary mentor.\n\n## Contributor+proposal selection and ranking process\n\nThis process is documented in the [Contributor+proposal selection and ranking process](./gsoc-selection-and-ranking-process.md) document.\n\n## Contributor guidance\n\nTBA\n\n## Announcements\n\n* Target channels for the public announcements:\n * Create a Github discussion on [`cncf/mentoring`](https://github.com/cncf/mentoring/discussions), which serves as the main announcement page. Tag people when applicable with `/cc @username`.\n * Post a link to the discussion on the CNCF Slack #mentoring channel.\n * Do the social media promotions of the announcement page.\n\n\n## References\n\n* [GSoC timeline](https://developers.google.com/open-source/gsoc/timeline)\n* [GSoC org admin tips](https://developers.google.com/open-source/gsoc/help/oa-tips)\n" }, { "path": "cncf-toc-mentoring-subproject/gsoc-selection-and-ranking-process.md", "content": "# Contributor+proposal selection and ranking process\n\nThe selection and ranking process for GSoC Contributors and proposals is performed by the CNCF GSoC administrators, who will use information provided by mentors to make the final decision. The baseline of this process is outlined by Google in their [slot allocation](https://developers.google.com/open-source/gsoc/help/slot-allocation) and [organization admin tips](https://developers.google.com/open-source/gsoc/help/oa-tips#reviewing_gsoc_contributor_proposals) documents.\n\nTo summarize:\n- Mentors mark the applicants they would like to mentor. They do that based on the quality of the proposals, their belief in the ability of the applicant successfully doing the project and also their experience from the interaction with the applicant so far.\n- CNCF GSoC admins select and rank the proposals and submit their requests to Google (detailed below)\n- Google allocates a number of slots to CNCF and fills the slots based on the rankings provided by CNCF GSoC admins.\n\nThe selection and ranking process of CNCF GSoC admin consists of three passes:\n\n- First pass: Ignore the proposals that had no mentor interest\n- Second pass: Review the proposals and identify the ones that are not a good fit for the program. Google's [rule](https://developers.google.com/open-source/gsoc/help/slot-allocation#important_notes_about_slot_requests) is to only accept proposals that are good or excellent, rather than just \"okay\".\n- Third pass: Rank the proposals based on the following criteria (not in any particular order):\n - Existing community interaction of the applicant\n - Number of mentors who want to mentor the applicant\n - Proposal quality (lower weight, as GSoC admins might not know the technical details of the project)\n - Applicant profile that shows the applicant is capable of implementing the project, such as contributions to other projects\n - Impact and alignment of the project idea\n - Number of proposals for a community (to avoid overloading a community)\n\nFollowing cannot be used in the selection and ranking process:\n\n- Applicant's reasons for applying GSoC\n- Applicant's plans after GSoC\n\nThe goals of this process are to use the limited number of slots available as best and fairly as possible and to minimize the number of withdrawals and failures.\n\nPlease note that certain information, such as mentor interest and rankings, may need to be kept private in accordance with Google's policies. See the \"8.1 (d) Visibility\" section in Google Summer of Code [rules](https://summerofcode.withgoogle.com/rules).\n" }, { "path": "cncf-toc-mentoring-subproject/org-admins.md", "content": "CNCF TAG Contributor Strategy\n# Mentoring Working Group\n\n## About TAGCS Mentorship Working Group\n\n[Mentoring WG Charter](https://github.com/cncf/tag-contributor-strategy/tree/main/mentoring)\n\n* CNCF Slack: [#tag-contributor-strategy](https://cloud-native.slack.com/archives/CT6CWS1JN)\n* [Discussion boards](https://github.com/cncf/mentoring/discussions)\n* [Email list](https://lists.cncf.io/g/tag-cs-mentoring-wg/)\n\n## Organization Admins\n\nIf you need help with anything mentoring at CNCF, you can file an issue in this repo or reach out to us using GitHub [Discussions](https://github.com/cncf/mentoring/discussions).\n\nOrganization admins for specific mentorship programs are listed on the program's respective pages.\n\n## Organization admin guides\n\n* [Google Summer of Code organization admin guide](gsoc-org-admin-guide.md)\n" }, { "path": "mentees/README.md", "content": "# Become a Mentee\n\nCongratulations on choosing to take part in a mentorship program available with the CNCF and some of its valued members. Contributing as a mentee can be a rewarding and fulfilling experience that connects you with a range of experts and development opportunities unique to these programs. \n\nIn addition to providing a high-quality learning experience that can help to kickstart your career, while adding tangible value to one of CNCF's 140+ open source projects; participating in mentorship programs also offer a range of other benefits that help both yourself and the CNCF community:\n* **Community:** Your contribution matters! Participating in mentorship programs can help to strengthen the community and its work by fostering innovation and collaboration while improving overall project quality.\n* **Network:** Learn and work alongside experts developing some of the most influential open source technologies in the world, as well as other passionate mentees eager to help bring these projects to life. \n* **Recognition:** Many programs offer stipends and other incentives to support your contribution. Amounts can be based on varying factors including your location or specific projects. \n\nBecoming a mentee in a CNCF mentorship program provides numerous benefits, including access to experienced professionals in the field, opportunities for personal and professional growth, and a supportive network for guidance and feedback. It can also help you to acquire new skills and knowledge, develop a deeper understanding of the industry, and increase your chances of success in your career.\n\n## Mentee Expectations\n\nOur program aims to cultivate the next generation of open source leaders and maintainers. Therefore, applicants for mentee roles are expected to be good open source citizens. This means contributing to a positive environment, collaborating well with others, always being respectful and professional when interacting in CNCF community and project spaces, and following the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).\n\nParticipating in a mentorship program can require a lot of time, effort and dedication. In exchange for that commitment, a seasoned mentor offers their valuable time and expertise to aid your learning and development. \n\nTo ensure the experience is positive for everyone involved, there are a few key things you as a mentee can do to maximise your opportunity:\n\n* **Make sure you can devote yourself to the minimum required hours throughout the program.** This can vary between projects, but often you will be expected to invest a significant amount of time on a weekly basis to your work.\nTo avoid confusion, *be realistic about how much time you can put into the program*, and communicate openly with your mentor to confirm your proposed commitment is also feasible for them.\n* **Be open about your skill level.** Applying for opportunities that exceed your level of skill or experience can mean more work, and possibly frustration, for those involved as the program progresses. \nEven if you are selected for a project, it's important to have a transparent and honest conversation with your mentor(s) about the level of difficulty involved. This can help to establish a clear understanding and agreement about your ability to complete set tasks, and ensure you have the necessary resources to succeed. \n\n*Overall, having a positive experience in any mentorship program will be dependent on good communication, diligence and taking initiative.* Your mentors and the wider community are invested in your success, so being proactive and assuming responsibility for your progress is essential. \n\n## Mentee Eligibility Requirements\n\nBefore applying for a CNCF mentorship program, please review the full eligibility criteria to ensure you meet all requirements.\n\n* **Code of Conduct Compliance:** **No violations of the Code of Conduct of the Linux Foundation or any Linux Foundation project within the last 12 months.**\n* **Detailed Eligibility:** For the most up-to-date and complete eligibility details, especially for the LFX Mentorship program, please consult the official documentation:\n * [Am I Eligible?](https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible)\n * [LFX Mentorship Program Details](https://docs.linuxfoundation.org/lfx/mentorship/mentees)\n\n## Understanding the Mentee Selection Process\n\nPlease understand that our mentorship programs are highly competitive, often receiving hundreds of applications for a limited number of spots. When there are several well-qualified candidates, our mentors have hard decisions to make.\n\n* **Selection Criteria:** Each individual project sets its own criteria for candidate selection. There is a [Mentor Code of Conduct](https://docs.linuxfoundation.org/lfx/mentorship/mentor-guide/code-of-conduct), and we encourage mentors to consider diversity in selections as a tie-breaker when there are two or more equally qualified candidates, but ultimately each project selects a candidate who best fits their specific needs.\n* **Experience Level:** CNCF LFX Mentorships are open to students and working professionals alike. We [don't limit our programs to just students](https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible); they are open to all. Some of our projects involve very complex software, and therefore, more experienced candidates may have an advantage in certain roles.\n* **Prior Contribution:** Selecting a candidate with few or no contributions to a project before applying is not discouraged, as we are committed to growing our communities and understand that all contributors need to start somewhere.\n* **If You Are Not Selected:** Not being selected is not a reflection of your worth as a contributor. We encourage you to seek and respond to feedback gracefully, continue contributing to projects that interest you, and apply again in future terms. Please note that comparing your qualifications to those of a selected candidate is not grounds for an appeal. Mentors evaluate many factors—some of which may not be visible in a public profile—and their decisions are final.\n\n## Support Networks\n\nHaving a solid support network provides a safe and productive environment for mentees to seek advice and receive guidance and feedback. It can be critical in navigating challenges and obstacles, building confidence, and feeling encouraged to continue your personal and professional growth.\n\n* **Your relationship with your mentor** will be your most important connection throughout your program. In addition to providing valuable new skills and coaching, mentors can also support your professional networking and overall guidance in your career. Communicating any barriers to your learning or commitments and working together to find solutions can go a long way to developing a good working rapport.\n* **Communication channels, groups and forums**, such as Slack, can be a great way to find solutions to common problems you'll likely encounter on your journey. Some popular options include:\n\n[CNCF Slack channels](https://slack.cncf.io) such as **#mentoring**; where you can engage to share your knowledge to solve specific problems.\n\n***Important Note:*** *It is not recommended to request general guidance or to express interest in working on issues that might be raised on these channels. Refer to the '[What is Contribution?](#what-is-contribution)' section in FAQs for the preferred process.*\n\n[CNCF Community Groups and events](https://community.cncf.io/) - Conferences, workshops, and other events such as Meetups bring together individuals from the Cloud Native community to collaborate and share knowledge.\n\nThese and other support networks can provide you with opportunities to connect with others in the field, learn from experienced professionals, and gain a deeper understanding of cloud native technologies. \n\nMentorship programs can be highly rewarding, yet challenging commitments to undertake. To make the most of your experience and improve your chances of success, be sure to reach out if:\n* You're unsure about next steps in your mentorship or its requirements\n* You're having doubts about your ability to complete your work\n* You're looking for other development opportunities to support your work\n* You're struggling to balance your commitments, especially if they're affecting your health and well-being \n\nIn summary, there are multiple contacts and resources available to guide you, and a supportive network can play a crucial role in the success and fulfillment of your mentorship experience.\n\n## Programs\n\nThere are numerous open source mentoring and internship programs available, with each emphasising different criteria such as specific skillsets, demographics, industries and specialisations. \n\nCurrently, the CNCF concentrates on a limited selection of such programs, featuring a range of projects to encourage interest from a broad pool of talent and backgrounds. \n\nThese are as follows:\n\n**LFX** \nThe [Linux Foundation Mentorship program](https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/introduction), also known as '**LFX**', plays a crucial role in providing mentees, including students and both new and experienced programmers; with structured hands-on learning opportunities in open source software development. \nThrough the program, mentees are paired with mentors based on their skills and interests to gain valuable experience by participating in and contributing to open source projects, all while [getting paid for it](https://docs.linuxfoundation.org/lfx/mentorship/mentees).\n \n**Google Summer of Code** \nThe [Google Summer of Code](https://summerofcode.withgoogle.com/), often abbreviated to GSoC, is an international annual program in which Google awards stipends to contributors who successfully complete a free and open-source software coding project during the summer. In addition to CNCF eligibility requirements, GSoC also has their own eligibility requirements. Be sure to plan your mentorship path so you don’t lock yourself out of a program by participating in another one first.\n\n\n*If you're interested in applying for one of these programs, be sure to read through the application details outlined in the links provided to determine your eligibility.*\n\n### Selecting a program\n\nIf you're struggling to choose which program to apply for, there's a number of considerations to factor: \n\n1. ***Goals and expectations*** \nDetermine what you hope to accomplish with the program and seek out opportunities that align with your aspirations and interests.\n2. ***Industry expertise*** \nChoose a program that specializes in your preferred industry and offers mentors with relevant experience. Be sure to carefully review the required skills to ensure you can manage the workload.\n3. ***Mentor-mentee fit*** \nChoose a program that matches you with a mentor whose skills, experience, and personality ideally align with your needs and goals. It can also help to study the project or company that the mentor represents to gain an understanding of their values and the nature of their work.\n4. ***Program structure*** \nConsider the program's format, length, and frequency of meetings to determine if it will provide the level of support and structure that you need. This is also important in deciding whether you can balance the time commitment with any existing responsibilities you might have.\n5. ***Availability and accessibility*** \nEnsure that the program is accessible and that mentors are available to provide support and guidance. Consider things like location, timezones and potential language barriers which might impact your participation and development.\n6. ***Feedback and evaluation:*** \nLook for programs that provide regular feedback and evaluations to help you track your progress and adjust your goals as needed.\n\nAs a final note, reach out to program graduates via the channels listed in the **'Support Networks'** section for guidance; or review related blogs, articles or videos to help inform your decision. \n\nTo maximize the benefits of a mentorship program, it is important to choose one that aligns with your personal goals and objectives. Each program has its own unique strengths and benefits, so by applying and learning more about the experience as it progresses, you can ensure that you select the best program for your needs.\n\n## Remuneration\n\n> **How do people find paid work through Open Source contribution?**\n\n*(Points/questions for consideration as below)*\n\n**What are the job roles and job descriptions that are available in the industry?**\n\n**How long does it generally take for someone to start earning?**\n\n**What can I do to increase my employability/attractiveness to potential employers?**\n\n## Skills & Experience\n\nAs a contributor and potential mentee, it's important to have a diverse technical and professional skillset in order to make the most impact. CNCF projects rely on a wide range of skills to thrive, including software development, design, project management, documentation, testing, and more.\n\n***Choosing a project to contribute to***\n\nSelecting a project according to: *(paragraph needed)*\n* personal interests and preferences\n* existing or desired skills such as specific programming languages\n* reviewing the [CNCF Landscape](https://landscape.cncf.io/) to gain an understanding of different projects and researching to determine the best match\n* reviewing graduate profiles and communications such as blogs, Tweets and **Success Stories** to learn more about individual experiences. \n\n***Developing as a professional alongside your mentor***\nYour technical experience will be critical to your work during your mentorship. Professional excellence however can only be achieved by balancing that knowledge with strong soft skills.\n\nWhether you are a developer, designer, or anything in between, there is a place for you in mentoring programs on offer, and your unique skills and perspectives will be valuable assets to any project you choose to contribute to.\n\n* Provide a general overview of skills common in recent LFX projects e.g. Go (provide link to skills map or similar resource from previous intake as indication?)\n* Dependent on individual projects, subject to change over time\n* Emphasise soft skills such as communication; critical regardless of technical expertise required\n\n---\n\n# FAQs\n\n#### I’m new to Open Source and CNCF. Where should I start?\n\nWelcome to the community! It would be good to note before diving in, that there is no singular way to become a Contributor. Like most careers, your path will be determined by your unique goals, skills, personality, commitment, and available opportunities over time. \n\n_Article_: \"[Do you want to start contributing to open source and need help figuring out where to begin?](https://contribute.cncf.io/contributors/getting-started/)\"\n\nThere are however a few proven areas you can check out to get the ball rolling:\n\n* If you're completely new to Open Source, there are countless blogs, articles, videos and resources that can be located with a simple web search. There are also popular short courses available, such as those offered by [Linux](https://trainingportal.linuxfoundation.org/learn/course/a-beginners-guide-to-open-source-software-development-lfc102/course-introduction/course-information) or [EDX](https://www.edx.org/course/open-source-software-development-linux-for-developers?index=product&queryID=54e7a9a4b82d487dd017ff72baabd439&position=2) that will help you to learn the fundamentals quickly.\n* Understand that contributions can be either code-based (technical skills required) and non-code (improving documentation, offering feedback), depending on the needs of specific projects.\n* **If you have some basic experience**, check out the following for different opportunities:\n * Many sites related to CNCF and its projects, like the [CNCF Contributor page](https://contribute.cncf.io/contributors/), will have Contributor guides which outline tasks; as well as lists with several actions you can take to begin your contributor journey.\n * [CLOTributor](https://clotributor.dev/) is a searchable database with dozens of tasks from [Cloud Native projects](https://www.cncf.io/projects/) you can tackle to build your experience.\n This can be a great way to familiarise yourself with various projects before choosing to commit to one offered in a specific mentorship program.\n * Look for issues labeled 'good first issue'. You may also want to start with some of the documentation projects (like the website itself). This is often a good place to start when learning about a new project and looking to contribute.\n\n**Final piece of advice:** The best way to start is to contribute immediately; make mistakes and learn from them. This will help you to get familiar with different processes and community members as your work is reviewed, evaluated or approved. \n\n---\n\n#### What is 'Contribution'?\n\nSimply put, contribution is about adding value by giving back. The open source community thrives on the efforts of its millions of members globally to help shape, develop and maintain its systems and infrastructure, one incremental step at a time.\n\nWhether you're fixing a minor typo in documentation, or your code is helping to create the next game-changing project, every (approved!) action you make towards development is a critical piece of a bigger puzzle.\n\nBeing active in GitHub, meetings, events and blogs or articles are also examples of contribution that show your commitment and consistency, and overall will help both your own journey and the wider community over time.\n\nThe best way to start contributing is:\n* Learn how to use the project, read the docs, try the tutorial/quickstart, and find ways to gain experience using the project and understanding how it works\n* Read the [CONTRIBUTING](https://github.com/cncf/tag-contributor-strategy/blob/main/CONTRIBUTING.md) guide.\n* Volunteer to work on an open issue that you know how to fix.\n* Attend [meetings or join our Slack channel](https://github.com/cncf/tag-contributor-strategy#communicating-with-us).\n* Contribute a bug fix for a problem that is impacting you.\n\nThe CNCF Contributor website is a great starting point for new contributors. \n\n---\n\n#### Can I contribute if I don't have a tech background?\n\nAbsolutely. In addition to the countless code-based efforts available in the open source community, there are also numerous roles and opportunities to contribute that don't require specific technical experience.\n\nDocumentation, community engagement, project management and even blogging about your experiences in the space are all beneficial to the overall growth and sustainability of the community.\n\nTake some time to explore [relevant articles and resources] that can provide more clarity in different options available to you.\n\nExample reference(s): TBC\n\n---\n\n#### What's the best way to communicate with the community or get support with questions?\n\nThere are various communication channels/platforms the open source community uses to interact (Slack, Discussion Boards etc.); whether providing support, coordinating work or recognising contribution for instance.\n\nTo ensure that any responses to your questions don’t get split across platforms, stick to one channel at a time so answers can be collected in one space and are easier for others to reference in the future.\n\n**I'm excited about contributing to Open Source with CNCF but overwhelmed by its complexity. How else can I build my understanding?**\nOS can be jargon-heavy, getting familiar with the vocab/terminology can be helpful\nIf in doubt, reach out - the community is built upon supportive relationships\nExample reference(s): (Paragraph) CNCF Glossary\n\n**What are the benefits to becoming a Mentee?**\n* Skills, experience and confidence\n* Guidance from industry experts\n* Internationally-recognised programs\n* Networking opportunity; employers and community\n\n---\n\n**How do I apply?** \n*(see 'Programs' section)*\n\n---\n\n**What if I'm not skilled/experienced enough to participate yet?**\nSuggest complementary short courses to upskill\nContinue to interact with the community to build experience and understanding\n\n**What support is available during mentorships?**\nMentorship programs such as LFX and Google Summer of Code are coordinated by various Maintainers who help to facilitate your experience.\n\nQuestions, feedback, liaising between involved parties\nMentors provide guidance, encouragement and expertise\nCommunity e.g. other mentees\nSupport system in ongoing development according to identified need\n\n**I'm applying for LFX and am interested in a project, but am stuck on next steps. What should I do?**\nBrowse the [current and past mentorship projects](../programs) to find one that matches your background\n\nEach project has a link to a corresponding GitHub issue, so if you see something interesting, use this to reach out to the relevant project Maintainers. This will help you both get a sense of your suitability and what is needed to progress.\n\n\n**Are mentorships suitable for career changers?**\nYes. CNCF mentorships are open to students and working professionals at all stages, including career changers. The LFX Mentorship program is specifically designed for people who are newer to a project — in fact, eligibility requires that you are *not* already a maintainer or recurring contributor with more than minimal involvement in the project offering the mentorship.\n\nFor full eligibility details, see the [Am I Eligible?](https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible) guide.\n\n**I think I've missed the deadline to apply! Can I still submit my application?**\n*State date flexibility or not? - Especially re LFX* (TBC)\n(Additional miscellaneous)\n\n* Support tickets for specific issues e.g. application process\n* Career Paths\n\n" }, { "path": "mentors/README.md", "content": "# Introduction\n\nCNCF participates in and organises a variety of mentoring programs. CNCF is a great place to spend time learning, coding, documenting, participating, and contributing. We look forward to receiving your application to become a mentor, along with your innovative project ideas!\n\nIn this guide, we aim to provide you with valuable insights into the importance of being a mentor, the steps to becoming one, and what you can anticipate in your role as a mentor. Additionally, we offer a range of resources to support you in getting started and maximising your mentoring experience.\n\n## Why become a mentor?\n\nMentoring allows you to give back to the community and support others in their learning journey, and presents an opportunity for personal and professional growth. Mentoring enables you to acquire new skills and enhance your existing knowledge. It is a profoundly fulfilling experience that fosters personal and professional development.\n\nMoreover, mentoring serves as an effective means to attract new contributors to your project and community while simultaneously improving their skills. It creates a positive cycle of mentorship and collaboration that benefits both the mentor and the mentee.\n\nLinux Foundation has a very good article titled \"Why to Become a Mentor\" [document](https://docs.linuxfoundation.org/lfx/mentorship/mentor-guide/getting-started/why-to-become-a-mentor) which provides valuable insights into the numerous benefits of being a mentor. This document shares compelling success stories and offers further information to illustrate why mentoring is such a rewarding experience.\n\n## Expectations from Mentors\n\nMentors are expected to:\n- Generate project ideas for potential mentees before the program starts\n- Evaluate mentees and proposals submitted by mentees for acceptance into the program\n- Be available to answer questions and provide guidance to mentees\n- Help mentees get involved in the community, including code reviews, documentation, and other contributions\n- Help mentees learn some soft skills, such as communication, teamwork, time management, and community mechanics\n- Provide feedback on the mentee's work\n\nMentors are encouraged to evaluate candidates based both on their technical skills and their ability to work well with others. It’s important that mentees demonstrate potential to become active contributors and \"good citizens\" of open source. This means contributing to a positive environment, following the CNCF Code of Conduct, being respectful and professional, and demonstrating a willingness to help others.\n\nEvery mentorship program CNCF participates in or organizes is a full-time mentorship program. While the mentees are expected to spend 30-40 hours per week on the programs, mentors are expected to spend 3-6 hours per week per mentee. This includes time spent on project ideas, reviewing proposals, answering questions, and providing feedback. Each project, mentee, and mentor is unique in their own way, and the time commitment may vary. Collaborating with fellow mentors can assist in distributing the time commitment.\n\nIn general, anyone can become a mentor; however, we do require that you possess substantial experience with the project you are mentoring for and familiarity with the community and its processes. Additionally, you should be capable of answering questions and providing guidance to the mentees.\n\n## Non-duties of Mentors\n\nThe following are not within the scope of the mentor's duties:\n- Do the work for the mentees\n- Be available 24/7\n- Find a job for the mentees\n- Push mentees to do the project tasks\n\n## How to become a mentor?\n\nShort answer: Generate a project proposal that is suitable for a mentorship and present it to the CNCF mentoring group by submitting a PR!\n\nLong answer:\n1. **Watch out for the announcements**: CNCF mentoring programs are announced on CNCF Twitter ([@CloudNativeFdn](https://twitter.com/CloudNativeFdn)) and CNCF Slack ([#mentoring](https://cloud-native.slack.com/archives/CGPK98JNQ)). You can also watch the announcements on the CNCF mentoring repository.\n2. **Find a project idea**: Either come up with a new mentorship project idea or find an existing mentorship project idea that you would like to mentor for.\n The definition of a good project idea varies from program to program. Different mentorship programs and project initiatives have their own unique focuses and areas of emphasis. For instance, some projects place a greater emphasis on coding and software development, while others prioritise documentation and technical writing. The specific goals and objectives of each program may vary, but generally, they strive to provide valuable learning experiences and support to participants in their respective fields.\n3. **Submit your project idea**: Submit your project idea to the [CNCF mentoring repository](https://github.com/cncf/mentoring). You can use the [project idea template](https://github.com/cncf/mentoring/blob/main/PROJECT_IDEA_TEMPLATE.md). Information on how to submit your project idea will be provided in the program announcement that will be sent out.\n4. **Review mentee profiles and proposals**: Once the mentee profiles and proposals are submitted for your project idea, you will have the opportunity to review them. Program administrators will provide you with more information on how to review the proposals and the main criteria for acceptance.\n5. **Mentor the mentees**: Once the mentees are accepted into the program, you will be able to start mentoring them!\n\nWhile the processes may vary from program to program, you will receive detailed instructions from the program administrators at each step, including a timeline. This ensures that you are well informed about what needs to be done and how to proceed throughout the program!\n\n## Programs\n\nFor the up-to-date list of programs, please check the [CNCF mentoring repository](https://github.com/cncf/mentoring).\n\n## Best Practices\n\n### Attracting Mentees\n\nTo attract mentees to your project idea, we recommend the following best practices:\n\n- It is crucial that you have a well-defined project idea that is suitable for the mentorship program you are aiming to participate in.\n- Submit your project idea early to give mentee candidates enough time to learn more about the project and interact with the community.\n- Be available to answer questions when candidates ask questions about your project idea.\n\n### Reviewing Mentee Applications and Proposals\n\nTo make the mentoring experience pleasant for you and for your mentee:\n\n- Do not accept \"just good enough\" applications and proposals. Look for enthusiastic candidates with high quality proposals.\n- Only accept as many mentees as you can handle. If you are unsure how many mentees you can handle, ask the program administrators.\n- Set your expectations right in the project idea. You would want to avoid being in a situation where you and the mentee have mismatched expectations.\n- Provide feedback to the candidates and help them improve their proposals. This will help you and your mentee in the long run.\n\n### Mentoring Mentees\n\nTo make the most of your mentoring experience, we recommend the following best practices.\n\nBefore the mentorship begins:\n\n- Start by reading the great resources in the [Mentor Resources](#mentor-resources) section.\n- Introduce your mentee to the community and help them get familiar with the community processes.\n- Ask your mentee to submit their work early and often and ask them to request community feedback.\n\nDuring the mentorship:\n\n- Be available for the mentee! This is the most important thing you can do for your mentee and will be the most rewarding.\n- Encourage your mentee to interact with the community, and not just with you. While you will be the main person responsible for supporting the mentee’s work. A mentee interacting with the community will help to share your load. However, mentees may not have the confidence or experience to have this interaction and may need guidance from you.\n\nAfter the mentorship:\n\n- Look for opportunities to retain the mentee in the community after the program ends. This can be done by helping them find a new project to work on.\n- Share your mentoring experience with your community and the broader open source community by collaborating on writing a blog post, delivering a joint talk, or creating a demo together. Such efforts will contribute to your personal growth and help your community attract more mentees in the future.\n\n## Support\n\nMentors have a direct line to us!\n\nIf you have any questions, please contact the CNCF mentoring group on [CNCF Slack](https://cloud-native.slack.com/archives/CGPK98JNQ) or on [CNCF Mentoring repository discussions](https://github.com/cncf/mentoring/discussions). We are happy to help you mentor your mentees!\n\n## Mentor Resources\n\nThe Linux Foundation’s \"What Makes a Good Mentor\" [document](https://docs.linuxfoundation.org/lfx/mentorship/mentor-guide/getting-started/what-makes-a-good-mentor) is very useful. We encourage you to read it, regardless of the program you are participating in.\n\n### Google Summer of Code\n\nIn addition to Google Summer of Code [official documentation](https://summerofcode.withgoogle.com/help), Google provides a lot of resources targeting mentors. We recommend you to check out the following resources:\n\n- [GSoC Mentor Guide](https://google.github.io/gsocguides/mentor/)\n- [GSoC FAQ for Mentors](https://developers.google.com/open-source/gsoc/faq#mentorsorganization_administrators)\n- [GSoC Mentor Responsibilities](https://developers.google.com/open-source/gsoc/help/responsibilities#mentor_responsibilities)\n\n### LFX Mentorship\n\nLFX Mentorship [official documentation](https://docs.linuxfoundation.org/lfx/mentorship) has specific information for mentors. We encourage you to check out the following documents:\n\n- [LFX Mentorship - Mentor Information](https://docs.linuxfoundation.org/lfx/mentorship/mentors)\n- [LFX Mentorship - Mentor Guide](https://docs.linuxfoundation.org/lfx/mentorship/mentor-guide)\n\n" }, { "path": "programs/README.md", "content": "# CNCF Mentoring: Programs for 2022 - 2025\r\n\r\n- [LFX](#lfx)\r\n - [2025](#2025)\r\n - [Term 3: Sept-Nov](#2025-term-3-september---november)\r\n - [Term 2: Jun-Aug](#2025-term-2-june---august)\r\n - [Term 1: Mar-May](#2025-term-1-march---may)\r\n - [2024](#2024)\r\n - [Term 3: Sept-Nov](#2024-term-3-september---november)\r\n - [Term 2: Jun-Aug](#2024-term-2-june---august)\r\n - [Term 1: Mar-May](#2024-term-1-march---may)\r\n - [2023](#2023)\r\n - [Term 3: Sept-Nov](#term-3-september---november)\r\n - [Term 2: Jun-Aug](#term-2-june---august)\r\n - [Term 1: Mar-May](#term-1-march---may)\r\n - [2022](#2022)\r\n - [Term 3: Sept-Nov](#term-3-september---november)\r\n - [Summer](#summer)\r\n - [Spring](#spring)\r\n\r\n### LFX\r\n\r\n#### 2025\r\n\r\n##### 2025 Term 3: September - November\r\n\r\n| Project | Mentors | Mentee |\r\n|---|---|---|\r\n| [CNCF - Cartography: IAM Whatever You Say IAM – GCP & Azure (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/28c3d20f-2bb6-42d1-93b5-45bdb33c72bf) | [Alex Chantavy](https://github.com/achantavy), [Kunaal Sikka](https://github.com/kunaals) | [Daksh Rathore](https://github.com/Daksh1603) |\r\n| [CNCF - Cartography: Map Azure and GCP cloud resources (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/6e60c1da-b78a-40c5-b527-613c00375e72) | [Alex Chantavy](https://github.com/achantavy), [Kunaal Sikka](https://github.com/kunaals) | [Janithashri G](https://github.com/janithashri) |\r\n| [CNCF - Cilium: Evaluate SEO, AEO, and AIO for cilium.io (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/ab291439-bfbe-411f-ae31-91e552f01e66) | [Bill Mulligan](https://github.com/xmulligan) | [Peace Sandy](https://github.com/Peacesandy) |\r\n| [CNCF - CloudNativePG: Chaos Testing (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/0858ce07-0c90-47fa-a1a0-95c6762f00ff) | [Gabriele Bartolini](https://github.com/gbartolini), [Francesco Canovai](https://github.com/fcanovai), [Jonathan Gonzalez](https://github.com/sxd), [Marco Nenciarini](https://github.com/mnencia) | [Yash Agarwal](https://github.com/XploY04) |\r\n| [CNCF - CloudNativePG: Rebuild documentation for multi-version support with Docusaurus (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/86a647c1-88c7-474f-b093-6abb58197083) | [Gabriele Bartolini](https://github.com/gbartolini), [Francesco Canovai](https://github.com/fcanovai), [Leonardo Cecchi](https://github.com/leonardoce) | [Anushka Saxena](https://github.com/SaxenaAnushka102) |\r\n| [CNCF - Harbor: Extend Harbor's Pluggable Scanner API for Runtime Behavior Profiles (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/f6cffefc-f326-4313-bc1d-3f44111c2938) | [Vadim Bauer](https://github.com/vad1mo), [Prasanth Baskar](https://github.com/bupd) | [Dr Constanze Roedig](https://github.com/entlein) |\r\n| [CNCF - Harbor: Harbor CLI - System Settings and Configuration (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/19eb2e9d-df35-4a19-a0dd-cf42103a9a5d) | [Vadim Bauer](https://github.com/vad1mo), [Prasanth Baskar](https://github.com/bupd) | [Nucleo Fusion](https://github.com/NucleoFusion) |\r\n| [CNCF - Jaeger: Next-Generation Jaeger Demo with OpenTelemetry and OpenSearch (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/216f0f5d-6a7a-45f1-9592-2336ce734b2c) | [Jonah Kowall](https://github.com/jkowall), [Yuri Shkuro](https://github.com/yurishkuro) | [Danish Siddiqui](https://github.com/danish9039) |\r\n| [CNCF - Kagent: Building cloud native agents for Kagent (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/cda38f44-e4b4-4f86-8b5a-a89bc08ac34a) | [Lin Sun](https://github.com/linsun), [Eitan Yarmush](https://github.com/EItanya) | [Jet Chiang](https://github.com/supreme-gg-gg) |\r\n| [CNCF - Karmada: RayCluster and RayJob Resource Interpreters (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/cf5e8dff-48ec-4ce6-ad92-cfb963f2d6b1) | [Junhua He](https://github.com/whitewindmills), [Hongcai Ren](https://github.com/RainbowMango) | [Owen Lin](https://github.com/owenowenisme) |\r\n| [CNCF - Karmada: TFJob and PyTorchJob Resource Interpreters (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/5b276804-9268-44c8-b339-1699c04397eb) | [Yiheng Ci](https://github.com/lfbear), [Hongcai Ren](https://github.com/RainbowMango) | [xinyuan lyu](https://github.com/pokerfaceSad) |\r\n| [CNCF - Karmada: TrainJob and SparkApplication Resource Interpreters (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/10cff3a7-3993-450f-a385-ebbcbf923805) | [Zhuang Zhang](https://github.com/zhzhuang-zju), [Hongcai Ren](https://github.com/RainbowMango) | [Lecheng Liao](https://github.com/liaolecheng) |\r\n| [CNCF - Karmada: Volcano Job and Notebook Resource Interpreters (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/1419023b-5f92-49af-a550-8cc25dc85290) | [Zhen Chang](https://github.com/XiShanYongYe-Chang), [Hongcai Ren](https://github.com/RainbowMango) | [dekai hu](https://github.com/dekaihu) |\r\n| [CNCF - kgateway: Improve Ecosystem Integrations Documentation (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/1badb86d-1aa1-4879-9399-3bb459f2aa0e) | [Nina Polshakova](https://github.com/npolshakova), [Lin Sun](https://github.com/linsun) | [Aryan Parashar](https://github.com/AryanParashar24) |\r\n| [CNCF - kgateway: Observability Improvements for agentgateway (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/0a9d8439-6c3b-49f6-8167-503f05161b43) | [Nina Polshakova](https://github.com/npolshakova), [Joe McGuire](https://github.com/jmcguire98) | [Dev Goel](https://github.com/corsairier) |\r\n| [CNCF - Kmesh: Improve IPsec Stability and Usability (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/a72ca16e-c309-45b3-a2fe-40bdd5e8e754) | [ZhenCheng Li](https://github.com/LiZhenCheng9527), [Zhonghu Xu](https://github.com/hzxuzhonghu) | [haobin huang](https://github.com/zrggw) |\r\n| [CNCF - Kmesh: Replace Waypoint with Orion (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/532690f7-802d-488e-a5e6-2e4ba532d189) | [Zengzeng Yao](https://github.com/yaozengzeng), [Zhonghu Xu](https://github.com/hzxuzhonghu) | [Eeshu Yadav](https://github.com/Eeshu-Yadav) |\r\n| [CNCF - Knative: Enhancing the Knative func CLI Experience (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/42557ffb-deb4-4b9f-a0b2-78f7f397216c) | [Prajjwal Yadav](https://github.com/prajjwalyd), [Luke Kingland](https://github.com/lkingland), [Calum Murray](https://github.com/Cali0707) | [Rayyan Seliya](https://github.com/RayyanSeliya) |\r\n| [CNCF - Krkn: Implementing the resiliency score feature (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/e3a6c68a-d3c5-414d-91a2-3681f4bc4473) | [Tullio Sebastiani](https://github.com/tsebastiani), [Naga Ravi Chaitanya Elluri](https://github.com/chaitanyaenr), [Paige Patton](https://github.com/paigerube14) | [Abhinav Sharma](https://github.com/abhinavs1920) |\r\n| [CNCF - Kube State Metrics: Automate the release process (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/6f4f89b9-16e8-4cd5-933e-5478c32c448f) | [Pranshu Srivastava](https://github.com/rexagod), [Manuel Rüger](https://github.com/mrueg) | [Rishab Kumar](https://github.com/Rishab87) |\r\n| [CNCF - KubeArmor: Observability Spectrum Enhancement (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/ca9220f2-1d8d-4977-80fd-068a6f756cc6) | [Rishabh Soni](https://github.com/rootxrishabh), [Aryan Sharma](https://github.com/Aryan-sharma11), [Ramakant Sharma](https://github.com/rksharma95), [Barun Acharya](https://github.com/daemon1024) | [Saurav Teli](https://github.com/fromsaurav) |\r\n| [CNCF - KubeArmor: Unit Test Coverage Audit (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/c0ae5caa-3c82-4b4a-8890-703278ca7fda) | [Rishabh Soni](https://github.com/rootxrishabh), [Aryan Sharma](https://github.com/Aryan-sharma11), [Ramakant Sharma](https://github.com/rksharma95), [Nishant Singh](https://github.com/tesla59) | [gaurav deep](https://github.com/GAURAV-DEEP01) |\r\n| [CNCF - KubeEdge: Comprehensive Example Restoration for Ianvs (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/82d71e63-2e1e-48d6-8c93-91c9e8bf8d5d) | [Zimu Zheng](https://github.com/MooreZheng), [Shijing Hu](https://github.com/hsj576) | [Abhishek Kumar](https://github.com/abhishek-8081) |\r\n| [CNCF - KubeEdge: Deep Integration with AMD Edge Nodes (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/15043686-0866-4d5a-9016-3a6cbfd448fc) | [Hongbing Zhang](https://github.com/HongbingZhang), [Shelley Bao](https://github.com/Shelley-BaoYue) | [Si Li](https://github.com/pangfufuf) |\r\n| [CNCF - KubeEdge: Deploy Small Language Models & OPEA Integration (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/2e9d0538-0941-4f10-8c52-9afd6294e16e) | [Hongbing Zhang](https://github.com/HongbingZhang), [Elias Wang](https://github.com/wbc6080) | Yijie Chen |\r\n| [CNCF - KubeEdge: Device Anomaly Detection Framework (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/8cf4ff37-e638-4b73-a5a1-521806ac8db1) | [Liwei Shen](https://github.com/meixiezichuan), [Elias Wang](https://github.com/wbc6080) | [Haojie Zhang](https://github.com/HaojieZhang6848) |\r\n| [CNCF - KubeEdge: Industrial Benchmark Dataset for Ianvs (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/c066ac53-5435-4057-a84c-0e0be62e8b65) | [Zimu Zheng](https://github.com/MooreZheng), [Mengzhuo Chen](https://github.com/IcyFeather233) | [RONAK RAJ](https://github.com/RONAK-AI647) |\r\n| [CNCF - Kubernetes: Graduate kubeadm WaitForAllControlPlaneComponents to GA (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/c546b376-f57d-4181-b2fe-4acf6586e0cb) | [Shida Qiu](https://github.com/SataQiu), [Paco Xu](https://github.com/pacoxu) | [Lubomir I. Ivanov](https://github.com/neolit123) |\r\n| [CNCF - Kubernetes: Improve Reference Docs Generator (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/79146277-961a-4f69-af48-4c9ae0e1a7fd) | [Kat Cosgrove](https://github.com/katcosgrove), [Nate Waddington](https://github.com/nate-double-u), [Xander Grzywinski](https://github.com/salaxander), [Rey Lejano](https://github.com/reylejano) | [Lavish Pal](https://github.com/lavishpal) |\r\n| [CNCF - KubeSlice: Comprehensive Unit and Integration Tests for kubeslice-cli (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/617cbe05-da5f-4955-8745-28cce769d511) | [Gourish Biradar](https://github.com/gourishbiradar), [Rahul Kumar](https://github.com/Rahul-D78), [Prabhu Navali](https://github.com/pnavali) | [Alok Pathak](https://github.com/Alokzh) |\r\n| [CNCF - KubeSlice: Enhance and Automate E2E Testing Across the Ecosystem (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/999f25bb-988c-48d5-a547-f353f8bcdf0d) | [Gourish Biradar](https://github.com/gourishbiradar), [Rahul Kumar](https://github.com/Rahul-D78), [Prabhu Navali](https://github.com/pnavali) | [Prashant Andoriya](https://github.com/andoriyaprashant) |\r\n| [CNCF - KubeSlice: Implement Custom Topology Definition for a Slice (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/db7a4bc3-3489-4ca9-9d6a-13f27fbee7fc) | [Gourish Biradar](https://github.com/gourishbiradar), [Rahul Kumar](https://github.com/Rahul-D78), [Prabhu Navali](https://github.com/pnavali) | [Priyansh Saxena](https://github.com/Transcendental-Programmer) |\r\n| [CNCF - KubeSlice: Implement Dynamic IPAM for the Slice Overlay Network (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/6123c24e-41ce-4335-88d1-dbd0f72e3631) | [Gourish Biradar](https://github.com/gourishbiradar), [Rahul Kumar](https://github.com/Rahul-D78), [Prabhu Navali](https://github.com/pnavali) | [Ankit Chowdhury](https://github.com/ani1609) |\r\n| [CNCF - KubeStellar: Developer Relations & Community Growth for KubeStellar UI (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/72839cf1-1b27-4008-aa11-dfea483bd6ee) | [Onkar Shelke](https://github.com/onkar717), [Andy Anderson](https://github.com/clubanderson), [Rishi Mondal](https://github.com/MAVRICK-1), [Aayush Saini](https://github.com/AayushSaini101) | [Sagar Utekar](https://github.com/Sagar2366) |\r\n| [CNCF - KubeStellar: Implement KubeStellar controller logic to map WECs resources (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/7b85c3fc-57ab-451d-a43a-c84251c4bc91) | [Franco Stellari](https://github.com/francostellari), [Rupam Manna](https://github.com/Rupam-It) | [Gaurab Khanal](https://github.com/gaurab-khanal) |\r\n| [CNCF - KubeStellar: Implementing End-to-End Playwright Testing for KubeStellar UI (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/b992256e-ed5f-44f3-8c13-8f3d8726fe00) | [Shivam Kumar](https://github.com/btwshivam), [Andy Anderson](https://github.com/clubanderson), [Rishi Mondal](https://github.com/MAVRICK-1), [Onkar Shelke](https://github.com/onkar717) | [Nupur Shivani](https://github.com/Nupurshivani) |\r\n| [CNCF - KubeStellar: KubeStellar Design System Implementation and Cloud Hosting (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/df6a6816-6c24-4464-98ca-38acc0764f83) | [Saumya Kumar](https://github.com/oksaumya), [Shivam Kumar](https://github.com/btwshivam), [Andrea Velázquez](https://github.com/andreuxxxx), [Kevin Roche](https://github.com/KPRoche) | [Naman Jain](https://github.com/naman9271) |\r\n| [CNCF - KubeStellar: Model Context Protocol and A2A Communication Framework (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/ee612f4c-ddb8-4f80-8692-3c975bc500a3) | [Rishi Mondal](https://github.com/MAVRICK-1), [Andy Anderson](https://github.com/clubanderson), [Onkar Shelke](https://github.com/onkar717), [Shivam Kumar](https://github.com/btwshivam) | [Hemanshu Baviskar](https://github.com/per0x1de-1337) |\r\n| [CNCF - Kyverno: Convert Sample Policies to CEL (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/ae18aaf2-374a-4657-8294-a0066b9a11bd) | [Mariam Fahmy](https://github.com/MariamFahmy98), [Shuting Zhao](https://github.com/realshuting) | [Mohab Yaser](https://github.com/Mohab96) |\r\n| [CNCF - Kyverno: Enhance Documentation for CEL Policies (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/6efc64ce-3fd5-4489-b4c0-846f661ecb6b) | [Cortney Nickerson](https://github.com/CortNick), [Luc Chmielowski](https://github.com/lucchmielowski) | [Elizabeth Bassey](https://github.com/Dev-Liz) |\r\n| [CNCF - Kyverno: Support Namespaced CEL-Based Policies (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/6ad81eb7-295b-4ec8-b9b4-db20e1f3a346) | [Charles-Edouard Brétéché](https://github.com/eddycharly), [Frank Jogeleit](https://github.com/fjogeleit) | [Dhruv puri](https://github.com/slashexx) |\r\n| [CNCF - Meshery: Relationships for AWS services (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/6c0bb714-9858-43b0-9c04-2f4b14d6c263) | [Mia Grenell](https://github.com/miacycle), [Lee Calcote](https://github.com/leecalcote), [Sangram Rath](https://github.com/sangramrath) | [Darshan N](https://github.com/Darshan174) |\r\n| [CNCF - Meshery: Relationships for GCP services (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/ed9d4af5-823a-4127-afdf-643c2b623f22) | [James Horton](https://github.com/hortison), [Lee Calcote](https://github.com/leecalcote) | [Sheikh Mohammad](https://github.com/winkletinkle) |\r\n| [CNCF - Meshery: Solutions architecture for cloud-native deployments (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/a183c51e-22c6-473b-93f4-6c286993e435) | [Rian Cteulp](https://github.com/ritzorama), [Lee Calcote](https://github.com/leecalcote), [Sangram Rath](https://github.com/sangramrath) | [Naman Verma](https://github.com/Namanv0509) |\r\n| [CNCF - OpenCost: Develop MCP Server for Agentic AI interaction with OpenCost (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/3a83e46e-b950-4c57-bfa1-4b44bdadfad6) | [Alex Meijer](https://github.com/ameijer), [Matt Bolt](https://github.com/Mbolt35) | [sneax sneax](https://github.com/sneaxhuh) |\r\n| [CNCF - OpenCost: OpenCost Data Model 2.0 (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/c64774be-9c42-4405-9536-1e77977a5414) | [Alex Meijer](https://github.com/ameijer), [Sean Holcomb](https://github.com/Sean-Holcomb), [Niko Kovacevic](https://github.com/nikovacevic) | [Sparsh Raj](https://github.com/spa-raj) |\r\n| [CNCF - OpenKruise: Adaptive Sidecar Resources in SidecarSet (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/6226f066-2de6-4417-b985-6cbcab6163d8) | [Zhao Mingshan](https://github.com/zmberg) | [HrimfaxiYKW HrimfaxiYKW (Colvin-Y)](https://github.com/Colvin-Y) |\r\n| [CNCF - OpenKruise: Enhance Robustness and Observability of Kruise-Game (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/2994906f-deff-4539-bf6d-e767b5cfcc31) | [Qiuyang Liu](https://github.com/chrisliu1995), [Zhongwei Liu](https://github.com/ringtail) | [Wenxue Zhao](https://github.com/ballista01) |\r\n| [CNCF - OpenKruise: Progressive Delivery for Native DaemonSet (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/f8a528a7-4473-4ce5-8cb5-9b6e412d93b0) | [Zhong Tianyun](https://github.com/AiRanthem) | [Marco Ma](https://github.com/marcoma2018) |\r\n| [CNCF - OpenKruise: Promote API Version to v1beta1 (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/7426f5d7-1879-46cc-a933-880ee790d0eb) | [Zhang Zhen](https://github.com/furykerry) | [jian zhihao](https://github.com/PersistentJZH) |\r\n| [CNCF - OpenTelemetry: Developing Guidelines for OTel Survey Analysis and Comms (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/4a1f10ed-82f8-4611-95c4-3bac0b165609) | [Adriana Villela](https://github.com/avillela), [Andrej Kiripolsky](https://github.com/AndrejKiri) | [Ernest Owojori](https://github.com/E-STAT) |\r\n| [CNCF - OpenYurt: Docker Extension for Simplified Deployment (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/d100c331-0f18-4728-9aa2-0c77bb486702) | [Lu Chen](https://github.com/luc99hen), [Bingchang Tang](https://github.com/zyjhtangtang), [Karan karanngi](https://github.com/karanngi) | [Sorabh Preet](https://github.com/sorabhopps) |\r\n| [CNCF - PipeCD: Prepare documentation for PipeCD v1 release (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/cd5b3190-26c8-4b71-8ebc-4b83677bd30e) | [Khanh Tran](https://github.com/khanhtc1202), [Shinnosuke Sawada-Dazai](https://github.com/Warashi), [Yoshiki Fujikane](https://github.com/ffjlabo), [Tetsuya Kikuchi](https://github.com/t-kikuc) | [Eeshaan Sawant](https://github.com/eeshaanSA) |\r\n| [CNCF - Podman Container Tools: Implement flushing of conntrack entries in Netavark (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/07efb861-3c5b-4bc2-9986-593656750ffc) | [Matthew Heon](https://github.com/mheon), [Paul Holzinger](https://github.com/Luap99) | [Shivang K Raghuvanshi](https://github.com/shivkr6) |\r\n| [CNCF - Prometheus: Prometheus Native Summaries (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/6bd5c5e0-25fc-4214-89ca-a48456d477b9) | [Bartek Plotka](https://github.com/bwplotka), [Jonathan Silva](https://github.com/perebaj) | [Naman Parlecha](https://github.com/Naman-B-Parlecha) |\r\n| [CNCF - Prometheus: Prometheus Remote Write 2.0 stability (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/cc7aedbe-d634-4b91-9d18-62df9e7d858b) | [Juraj Michalek](https://github.com/jmichalek132), [Bartek Plotka](https://github.com/bwplotka), [Saswata Mukherjee](https://github.com/saswatamcode) | [Minh Nguyen](https://github.com/pipiland2612) |\r\n| [CNCF - Prometheus: Prototyping Prometheus for exploratory use cases (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/d16f520b-2b77-4eac-bbd9-5c4cc5fdccf5) | [Arthur Silva Sens](https://github.com/ArthurSens), [Amy Super](https://github.com/amy-super) | [Ana Muenz](https://github.com/vampirarte) |\r\n| [CNCF - WasmEdge: Implement Remaining Features of wasmedgeup (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/54acdf6e-e53f-4a18-9b4b-8797da503150) | [Hung-Ying Tai](https://github.com/hydai) | [ARSHDEEP SINGH](https://github.com/Arshdeep54) |\r\n| [CNCF - WasmEdge: Pointer Alignment Checking for WASI Host Functions (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/a0542cf9-a862-4055-8961-d2aede3d91a6) | [YiYing He](https://github.com/q82419) | [Archit Dabral](https://github.com/Minimega12121) |\r\n| [CNCF - WasmEdge: Support Responses API in Llama Nexus (2025 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/31044818-fe9d-478d-b740-5d4c8a4c49c2) | [Michael Yuan](https://github.com/juntao), [Sam Liu](https://github.com/apepkuss) | [Ashish Dalal](https://github.com/ashish-dalal) |\r\n\r\n##### 2025 Term 2: June - August\r\n\r\n| Project | Mentors | Mentee |\r\n|---|---|---|\r\n| [CNCF - Antrea: Automate dependency updates with Renovate (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/62d69fd5-6c90-4ba1-b260-a5dc247fc3cf) | [Quan Tian](https://github.com/tnqn), [Lan Luo](https://github.com/luolanzone), [Antonin Bas](https://github.com/antoninbas) | [Ghadeer Elsalhawy](https://github.com/ghadeer-elsalhawy) |\r\n| [CNCF - Antrea: Enhance PacketCapture with IPv6 and flexible filters (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/7dc05f9c-b90d-4fe0-bf43-d6bf10ea29a2) | [Hang Yan](https://github.com/hangyan), [Antonin Bas](https://github.com/antoninbas) | [Harsh Gupta](https://github.com/g4rud4kun) |\r\n| [CNCF - Cartography: Fill in missing AWS resource types for CloudGoat scenarios (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/de67557d-4c27-4ca6-9c93-015636d28682) | [Kunaal Sikka](https://github.com/kunaals), [Alex Chantavy](https://github.com/achantavy) | [Drishti Aggarwal](https://github.com/d-aggarwal) |\r\n| [CNCF - Cilium: Document technical outcomes on website (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/8c677ed1-cec0-44b7-93aa-60f90ddb7949) | [Bill Mulligan](https://github.com/xmulligan) | [Oluchi Nwenyi](https://github.com/LuluNwenyi) |\r\n| [CNCF - CloudNativePG: Declarative Management of PostgreSQL FDWs (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/53fa853e-b5fa-4d68-be71-f005c75aea89) | [Gabriele Bartolini](https://github.com/gbartolini), [Leonardo Cecchi](https://github.com/leonardoce), [Marco Nenciarini](https://github.com/mnencia), [Armando Ruocco](https://github.com/armru) | [Ying Zhu](https://github.com/EdwinaZhu) |\r\n| [CNCF - Copacetic: Wiz Scanning Support (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/a4839420-3881-46cd-849a-f57784158f49) | [Ashna Mehrotra](https://github.com/ashnamehrotra), [Leonard Wang](https://github.com/leodewang), [Robbie Cronin](https://github.com/robert-cronin) | [Aman Yadav](https://github.com/amanycodes) |\r\n| [CNCF - Harbor: Ground Control for Harbor Satellite (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/c445172e-5a5f-41f9-b4eb-89cbfe2f3434) | [Vadim Bauer](https://github.com/vad1mo), [Orlin Vasilev](https://github.com/OrlinVasilev), [Prasanth Baskar](https://github.com/bupd) | [Narhari Motivaras](https://github.com/narharim) |\r\n| [CNCF - Harbor: Harbor CLI enhancements (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/0d80c83f-259b-46e7-98af-47406891649a) | [Vadim Bauer](https://github.com/vad1mo), [Orlin Vasilev](https://github.com/OrlinVasilev), [Prasanth Baskar](https://github.com/bupd) | [Patrick Eschenbach](https://github.com/qcserestipy) |\r\n| [CNCF - Headlamp: Gateway API Service Mesh Visualization (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/62e272ef-e950-45dd-9c57-71d216d22ed2) | [Rene Dudfield](https://github.com/illume), [Kautilya Tripathi](https://github.com/knrt10), [Santhosh Nagaraj](https://github.com/yolossn) | [Aditya Chaudhary](https://github.com/useradityaa) |\r\n| [CNCF - Headlamp: Karpenter Autoscaling Insights and Management (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/5ca70394-f568-4bbf-a88d-4e5af8b235cf) | [Kautilya Tripathi](https://github.com/knrt10), [Santhosh Nagaraj](https://github.com/yolossn), [Rene Dudfield](https://github.com/illume) | [Anirban Singha](https://github.com/SinghaAnirban005) |\r\n| [CNCF - Headlamp: Kubernetes API caching, pagination & search (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/1b9a4a99-2d92-4c1a-ac34-7fe554bf6393) | [Santhosh Nagaraj](https://github.com/yolossn), [Rene Dudfield](https://github.com/illume), [Kautilya Tripathi](https://github.com/knrt10) | [Saurav Upadhyay](https://github.com/upsaurav12) |\r\n| [CNCF - Headlamp: UX Audit and Design Improvements for Plugins (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/4d736149-aa95-4f31-b01c-a54c754614d0) | [Joaquim Rocha](https://github.com/joaquimrocha), [Ivelisse Capellan Heyer](https://github.com/ivelisseca), [Grant Florence](https://github.com/Gflo3) | [Aishwarya Ghatole](https://github.com/AishwaryaGhatole2102) |\r\n| [CNCF - Inspektor Gadget: Traceloop GTM Strategy and Execution (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/a5f01d86-252f-48c2-90b7-c616dc5072d8) | [Maya Singh](https://github.com/mayasingh17), [Slava Falico](https://github.com/vfalico) | [OPALUWA EMIDOWOJO](https://github.com/Emidowojo) |\r\n| [CNCF - Istio: Multi-cluster Ambient testing expansion (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/958b17bf-e4f2-42fc-a7f3-01d95c53ee73) | [Steven Jin](https://github.com/stevenjin8), [Steven Landow](https://github.com/stevenctl) | [Harish D](https://github.com/harish2773) |\r\n| [CNCF - Istio: Update documentation CMS build pipeline (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/3c42c0b6-cd32-42ca-b32e-1865f42a9f21) | [Craig Box](https://github.com/craigbox) | [Ajay Singh](https://github.com/Ajay-singh1) |\r\n| [CNCF - Jaeger: Jaeger demo on Kubernetes (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/14c5fcdd-61b9-40a1-8a10-27a1bba76b3d) | [Jonah Kowall](https://github.com/jkowall), [Yuri Shkuro](https://github.com/yurishkuro) | [Chahat Sagar](https://github.com/chahatsagarmain) |\r\n| [CNCF - Jaeger: Upgrade Jaeger-UI to React v19 (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/6816e614-2e9e-492e-9d28-c91506cde073) | [Yuri Shkuro](https://github.com/yurishkuro), [Jonah Kowall](https://github.com/jkowall) | [Vishvamsinh Vaghela](https://github.com/vishvamsinh28) |\r\n| [CNCF - Kgateway: Automated scale tests for kgateway (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/d713bc73-3257-4d21-b533-97e0ccadf7bb) | [Nina Polshakova](https://github.com/npolshakova), [Lawrence Gadban](https://github.com/lgadban) | [Mayowa Fajobi](https://github.com/MayorFaj) |\r\n| [CNCF - Kgateway: OpenTelemetry Observability for AI Extensions (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/347952bc-15c6-48f7-9c4e-aad7dffb3817) | [Nina Polshakova](https://github.com/npolshakova), [Steven Landow](https://github.com/stevenctl) | [Zhengke Zhou](https://github.com/zhengkezhou1) |\r\n| [CNCF - Krkn: Chaos scenario rollback feature (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/92e42a9c-fc0a-46bf-8ca7-69ad673dcce0) | [Tullio Sebastiani](https://github.com/tsebastiani), [Naga Ravi Chaitanya Elluri](https://github.com/chaitanyaenr), [Paige Patton](https://github.com/paigerube14) | [Zhe-You(Jason) Liu](https://github.com/jason810496) |\r\n| [CNCF - kube-burner: Enhancements around k8s performance testing (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/fa247b88-8f80-4b1e-97b3-903ae3ea2be5) | [Vishnu Challa](https://github.com/vishnuchalla), [Raul Sevilla](https://github.com/rsevilla87) | [Niladri Adhikary](https://github.com/niladrix719) |\r\n| [CNCF - KubeEdge: Industrial embodied intelligence benchmarking framework (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/bd625cf2-dba9-4246-8c32-746fcc05c8e0) | [Zimu Zheng](https://github.com/MooreZheng), [Mengzhuo Chen](https://github.com/IcyFeather233) | [Ansh Rastogi](https://github.com/anshRastogi02) |\r\n| [CNCF - KubeEdge: LLM-generated unit and e2e tests automation (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/c936cda3-d842-4286-a38a-7138d5b04f51) | [Yue Li](https://github.com/liyuerich), [Shelley Bao](https://github.com/Shelley-BaoYue) | [Vivek Bisen](https://github.com/vivekbisen04) |\r\n| [CNCF - KubeEdge: Support RK3588 edge nodes (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/6ea6aa02-023f-492f-addd-28087e9810a3) | [Hongbing Zhang](https://github.com/HongbingZhang), [Shelley Bao](https://github.com/Shelley-BaoYue) | [Sachin Jha](https://github.com/sachin21212121) |\r\n| [CNCF - Kubernetes: Graduate kubeadm WaitForAllControlPlaneComponents to GA (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/c546b376-f57d-4181-b2fe-4acf6586e0cb) | [Shida Qiu](https://github.com/SataQiu), [Paco Xu](https://github.com/pacoxu) | [Lubomir I. Ivanov](https://github.com/neolit123) |\r\n| [CNCF - KubeStellar: Building a Plugin System (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/cf08311b-a7cf-4309-9989-5f85ba2b05b3) | [Rishi Mondal](https://github.com/MAVRICK-1), [Andy Anderson](https://github.com/clubanderson), [Rahul Vishwakarma](https://github.com/manzil-infinity180) | [Aayush Saini](https://github.com/AayushSaini101) |\r\n| [CNCF - KubeStellar: Design System Foundations (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/1cd69035-2bab-47f1-9774-952e9ec0d43e) | [Andrea Velázquez](https://github.com/andreuxxxx), [Kevin Roche](https://github.com/KPRoche) | [Saumya Kumar](https://github.com/oksaumya) |\r\n| [CNCF - KubeStellar: Extending KubeFlex with a new Control Plane (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/d5499737-549b-498a-922a-695ef3955725) | [Paolo Dettori](https://github.com/pdettori), [Braulio Dumba](https://github.com/dumb0002) | [Rainui Ly](https://github.com/Rxinui) |\r\n| [CNCF - KubeStellar: Marketplace UI and UI Optimization (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/a23f93b7-e384-4515-a165-c01e4ecd00ad) | [Rishi Mondal](https://github.com/MAVRICK-1), [Andy Anderson](https://github.com/clubanderson), [Onkar Shelke](https://github.com/onkar717) | [Shivam Kumar](https://github.com/btwshivam) |\r\n| [CNCF - KubeStellar: Reduce Helm chart initContainers reliance (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/a56d987c-f754-4e2f-b159-2ea578ca5e56) | [Franco Stellari](https://github.com/francostellari), [Andy Anderson](https://github.com/clubanderson) | [Rupam Manna](https://github.com/Rupam-It) |\r\n| [CNCF - Kyverno: Improve Test Coverage and Docs for New Policy Types (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/ef446774-4fe7-4027-8c9b-e1e125c643ae) | [Charles-Edouard Brétéché](https://github.com/eddycharly), [Frank Jogeleit](https://github.com/fjogeleit) | [Rohan Raj](https://github.com/Rohanraj123) |\r\n| [CNCF - Kyverno: Optimize Kyverno CLI In-cluster Resource Loader (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/98a5686a-3f18-4a79-ac9d-9ffa228a6e26) | [Mariam Fahmy](https://github.com/MariamFahmy98), [Shuting Zhao](https://github.com/realshuting), [Yugandhar](https://github.com/yrsuthari) | [Abhishek Dhiman](https://github.com/dhimanAbhi) |\r\n| [CNCF - Meshery: Model relationships for AWS services (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/d548f403-0d7f-4ca5-88f1-393ae592a05a) | [Lee Calcote](https://github.com/leecalcote), [Sangram Rath](https://github.com/sangramrath), [Mia Grenell](https://github.com/miacycle) | [Divya V](https://github.com/arctic-beep) |\r\n| [CNCF - Meshery: Model support for kro ResourceGraphDefinitions (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/b993ee7d-6b52-47e8-a651-e1c6c91e5d2b) | [Lee Calcote](https://github.com/leecalcote), [Aabid Sofi](https://github.com/aabidsofi19) | [Zihan Kuang](https://github.com/zihanKuang) |\r\n| [CNCF - Meshery: Solutions architecture for cloud-native deployments (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/b1fcdcd9-0066-4a9a-a879-7d5624b02727) | [Sangram Rath](https://github.com/sangramrath), [Lee Calcote](https://github.com/leecalcote) | [Ahmed Jamil](https://github.com/codeahmedjamil) |\r\n| [CNCF - Meshery: Workflow engine integration (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/6244b48c-1fc6-4b1c-b965-7df7e117b06d) | [Lee Calcote](https://github.com/leecalcote), [Rian Cteulp](https://github.com/ritzorama) | [Faheem Mushtaq](https://github.com/FaheemOnHub) |\r\n| [CNCF - OpenCost: Enterprise Ready OpenCost: Integration Testing (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/79cfd37e-3259-49ff-82d2-58970fbbef6f) | [Alex Meijer](https://github.com/ameijer), [Cliff Colvin](https://github.com/cliffcolvin), [Matt Bolt](https://github.com/Mbolt35) | [Manas Sivakumar](https://github.com/Manas23601) |\r\n| [CNCF - OpenKruise: Best practice for Karmada/OCM integration (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/8e20df07-bd63-48ba-8078-18567c42597f) | [Zhao Mingshan](https://github.com/zmberg), [Sun Weixiang](https://github.com/veophi) | [Abhiswant Chaudhary](https://github.com/abhi0324) |\r\n| [CNCF - OpenKruise: OpenKruiseGame HA deployment support (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/411dea84-5f3c-46d5-823f-67b7c8f3d0e9) | [Qiuyang Liu](https://github.com/chrisliu1995), [Zhongwei Liu](https://github.com/ringtail) | [Zhenghui Yan](https://github.com/kagaya85) |\r\n| [CNCF - OpenKruise: progressDeadlineSeconds for CloneSet (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/f249fa01-8c21-4898-ab02-234653cb8256) | [Yuxing Yuan](https://github.com/ABNER-1), [Zhao Mingshan](https://github.com/zmberg) | [haoshi ren](https://github.com/MichaelRren) |\r\n| [CNCF - OpenKruise: Simple dashboard for workloads (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/217a88a5-ecbc-46b8-9e90-b68993a8ae45) | [Zhang Zhen](https://github.com/furykerry), [Zhong Tianyun](https://github.com/AiRanthem) | [Vaibhav K](https://github.com/vaibhaavv8) |\r\n| [CNCF - OpenYurt: OpenYurt Dashboard Enhancements (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/0d59f3ef-8de1-4264-9a0e-96afbe3558af) | [Lu Chen](https://github.com/luc99hen), [Bingchang Tang](https://github.com/zyjhtangtang) | [Karanjeet Singh](https://github.com/karanngi) |\r\n| [CNCF - PipeCD: OpenTofu deployment plugin (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/ca6413f6-6f97-4e41-aad8-8d2bbe17251d) | [Khanh Tran](https://github.com/khanhtc1202), [Shinnosuke Sawada-Dazai](https://github.com/Warashi), [Yoshiki Fujikane](https://github.com/ffjlabo) | [Sagnik Das](https://github.com/sagnik3788) |\r\n| [CNCF - PipeCD: SQL schema management plugin (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/f56d4b7f-be23-4349-8066-f6526b863068) | [Khanh Tran](https://github.com/khanhtc1202), [Shinnosuke Sawada-Dazai](https://github.com/Warashi), [Yoshiki Fujikane](https://github.com/ffjlabo) | [Davy Lu](https://github.com/kadai0308) |\r\n| [CNCF - Volcano: Enhance JobFlow Functionality (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/6e853798-e2a3-445f-89f4-63c2e5acc58b) | [Jiang Dong](https://github.com/dongjiang1989), [Xuzheng Chang](https://github.com/Monokaix) | [Mahdi Khashan](https://github.com/mahdikhashan) |\r\n| [CNCF - Volcano: Enhance Volcano Dashboard UX and Functionality (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/e81c895a-69f9-4c63-b4fe-e9352c3fa2e7) | [Xuzheng Chang](https://github.com/Monokaix), [Zicong Chen](https://github.com/JesseStutler) | [Kuldeep Singh](https://github.com/de6p) |\r\n| [CNCF - Volcano: Enhance Volcano Official Documentation (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/a8bafeea-f608-4e73-9a44-ca60c309536f) | [Xuzheng Chang](https://github.com/Monokaix), [Zicong Chen](https://github.com/JesseStutler) | [Bearix Bearix](https://github.com/bearslyricattack) |\r\n| [CNCF - Volcano: Implement Volcano Scheduler Simulator (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/017774aa-f821-49c6-b701-fef1a0fae17b) | [lowang-bh](https://github.com/lowang-bh), [Xuzheng Chang](https://github.com/Monokaix) | [Charles Pan](https://github.com/chaospan) |\r\n| [CNCF - WasmEdge: Create an MCP-based AI agent to help LF certificate prep (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/5070cba4-8c1e-4392-8cf8-cd9bebb5277e) | [Michael Yuan](https://github.com/juntao), [Vivian Hu](https://github.com/alabulei1) | [Mohan Kumar](https://github.com/ItshMoh) |\r\n| [CNCF - WasmEdge: Port WasmEdge and WASI-NN ggml backend to s390x (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/d82c102b-4f82-4ca8-9627-25ef9d745321) | [Hung-Ying Tai](https://github.com/hydai), [dm4](https://github.com/dm4) | [Vishruth Thimmaiah](https://github.com/vishruth-thimmaiah) |\r\n| [CNCF - WasmEdge: Support bitnet.cpp as a new WASI-NN plugin (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/d7ee97d4-ee89-4cce-a128-34f87fe2fb5a) | [Hung-Ying Tai](https://github.com/hydai), [dm4](https://github.com/dm4) | [Khush Agrawal](https://github.com/Khushmagrawal) |\r\n| [CNCF - WasmEdge: Use Runwasi with WasmEdge runtime to test multiple WASM apps (2025 Term 2)](https://mentorship.lfx.linuxfoundation.org/project/e54744c7-0435-42bb-b9aa-60e8df1c9081) | [Vincent Lin](https://github.com/CaptainVincent), [yi](https://github.com/0yi0) | [Vatsal Keshav](https://github.com/vatsalkeshav) |\r\n\r\n##### 2025 Term 1: March - May\r\n\r\n| Project | Mentors | Mentee |\r\n| --- | --- | --- |\r\n| [CNCF - Antrea: Support L4 protocol filters in PacketCapture API (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/c1b6fda9-e2e6-41e1-8495-68abe9e980ca) | Antonin Bas, Hang Yan | Aryan Bakliwal |\r\n| [CNCF - Envoy Gateway: Enhancing Envoy Gateway Documentation Using CNCF Tech Docs Analysis Framework (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/2b752e3d-d55b-40de-a702-13b88aff974a) | Erica Hughberg, Arko Dasgupta | Melissa Salazar |\r\n| [CNCF - Envoy Gateway: Integrating CNCF Fuzzing Framework for Envoy Gateway (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/44020e81-1218-49aa-95e0-ee3e03998eb3) | Arko Dasgupta, Teju Nareddy | Sudipto Baral |\r\n| [CNCF - Harbor: Harbor CLI (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/769b7e87-f2f5-4532-b247-392b1897ea50) | Vadim Bauer, Orlin Vasilev, Prasanth Baskar | Rizul Gupta |\r\n| [CNCF - Harbor: Harbor Satellite (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/ff3431c0-3cb1-4c07-bd10-21a8e495c897) | Vadim Bauer, Orlin Vasilev, Prasanth Baskar | Viswanath sai |\r\n| [CNCF - Headlamp: Build Plugin Installation Container (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/992fc67e-ff9e-41fd-8062-28ec8733903f) | Kautilya Tripathi, Santhosh Nagaraj, Rene Dudfield | Faakhir Zahid |\r\n| [CNCF - Headlamp: Instrument with OpenTelemetry (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/d961bfc7-00e1-4c05-bf1a-f9c7ddf1756a) | Rene Dudfield, Kautilya Tripathi, Santhosh Nagaraj | Dhairya Amrish |\r\n| [CNCF - Headlamp: Make a Headlamp plugin for KEDA (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/ceebb991-978f-4782-8435-195637f433aa) | Santhosh Nagaraj, Rene Dudfield, Kautilya Tripathi | Adwait Godbole |\r\n| [CNCF - Inspektor Gadget: Building gadgets with Rust (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/42dd5a60-47f9-4f7c-b895-49ce6c81a59a) | Mauricio Vasquez Bernal, Francis Laniel | Daksh Kaushik |\r\n| [CNCF - Inspektor Gadget: Implementing unit tests (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/d3a1a899-1ca0-4e10-a402-01ef6fde26f2) | Burak Ok, Qasim Sarfraz | Shaheer Ahmad |\r\n| [CNCF - Inspektor Gadget: Inspekting and analysing gadgets (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/a6d66c40-3d12-4fa4-88bf-18574f6b4ec0) | Alban Crequy, Jose Blanquicet | Kapil Sareen |\r\n| [CNCF - Istio: Implement new site search (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/a8165dc1-fb52-40ca-bd1f-862a5176df98) | Craig Box | Adesh Ghadage |\r\n| [CNCF - Istio: Improve documentation build infrastructure (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/2fe99eb2-abc3-454f-b80a-ffd336fa2788) | Craig Box | Sam Begin |\r\n| [CNCF - Istio: Support TLS for Istio metrics endpoints (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/9b1a1e87-2757-4f4f-aa58-49d55fc07b16) | Faseela K, Benjamin Leggett, Jianpeng He, Ian Rudie | Harsh Pratap Singh |\r\n| [CNCF - Jaeger: Upgrade charts and graphs in Jaeger UI (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/48ebfb59-eab7-4d22-8373-30a0bbfb12f7) | Yuri Shkuro, Jonah Kowall | Hariom Gupta |\r\n| [CNCF - Jaeger: Upgrade Storage Backends to V2 Storage API (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/5ce2b62c-94a9-44e9-95bc-b83a13c0a0e6) | Yuri Shkuro, Mahad Zaryab | MANIK MEHTA |\r\n| [CNCF - Karmada: Implement multi-cluster management in the Karmada dashboard (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/4fb84d25-bcc0-4190-a233-760ef0b22797) | Wenjiang Ding, Zhen Chang | Sayem Khan |\r\n| [CNCF - Karmada: Karmada Self-Signed Certificate Content Standardization (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/8d2d522f-8838-4baa-9be4-d13dab30289b) | Chaosi Pan, Zhen Chang | fu zhaoyi |\r\n| [CNCF - KCL: KPM & LSP Integrated (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/012a9fb4-286b-4a76-ad7a-2de644427109) | Heipa, Zhe Zong | Siddhi Agrawal |\r\n| [CNCF - Kmesh: Kmesh eBPF unit test (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/58b458ba-6be0-4dd9-b194-bfe6f98d2a2c) | Xin Liu, Changye Wu | Zhenxiong Tian |\r\n| [CNCF - Kmesh: Metrics for TCP Long Connection (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/c5dadaed-445e-4a74-825b-3e2f1a8b2be1) | Changye wu, ZhenCheng Li | YASH PATEL |\r\n| [CNCF - Kmesh: Re-design and implement the Kmesh website (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/6269bdd1-1004-465c-bbdc-6a230988c899) | ZhenCheng Li, Zhonghu Xu | jayesh savaliya |\r\n| [CNCF - Knative: Design and Implement Levels for Educational Game (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/58392ddd-4d5a-491e-9b09-6035aa4c907e) | Calum Murray, Zainab Husain, Angelina Zhai | Ankita Jana |\r\n| [CNCF - KubeArmor: Providing Zero-Trust policies for popular workloads (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/5f7ef24a-a57b-477d-940f-9989f1bec481) | Rishabh Soni, Prateek Nandle, Barun Acharya | Daksh Jain |\r\n| [CNCF - KubeEdge: Community Website Comprehensive Upgrade Project: Homepage Renewal and Expansion of Core Pages (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/576c6710-942b-41cc-9e51-113c1957fc02) | Hongbing Zhang, Shelley Bao | qin su |\r\n| [CNCF - KubeEdge: Domain-specific large model benchmarks: the edge perspective (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/e3fc44d9-9ddd-42e6-a9be-8f6c2a114672) | Zimu Zheng, hsj576 | Mengzhuo Chen |\r\n| [CNCF - KubeEdge: Enhance Dependency Management and Documentation for KubeEdge-Ianvs (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/8961c0b4-0e34-43be-9022-384a4847f5d3) | FuryMartin, hsj576 | Aryan Nanda |\r\n| [CNCF - KubeEdge: Enhance KubeEdge testing coverage (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/a85be883-5139-4e69-8859-6662f7ffd71d) | Elias Wang, Fisher Xu | Dhiren Mhatre |\r\n| [CNCF - KubeEdge: KubeEdge Dashboard Enhancement - BFF (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/16217666-64ec-45e7-842b-9df5ceb07382) | Chen Su, Elias Wang | chuanhao jin |\r\n| [CNCF - KubeStellar: Implement a WDS Backend to Support UI Frontend Operations (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/885239e6-6a95-410f-9aae-00fd8b4c5f09) | Andy Anderson, Braulio Dumba | Rahul Vishwakarma |\r\n| [CNCF - KubeStellar: Implement a WDS Frontend Supported by WDS Backend (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/e549191d-6880-4a98-8fd2-ec5fc47ecc92) | Andy Anderson, Braulio Dumba | Onkar Shelke |\r\n| [CNCF - KubeStellar: Implement an ITS Frontend Supported by ITS Backend Endpoints (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/b3805d32-03c4-4d5f-b56e-613ac24629c1) | Andy Anderson, Braulio Dumba | Rishi Mondal |\r\n| [CNCF - KubeStellar: Implement Binding Policy Backend to Support UI Frontend (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/d9f46954-3b56-4e42-b83c-dd3dee2b8b6d) | Andy Anderson, Braulio Dumba | Ashish Kumar |\r\n| [CNCF - KubeStellar: Implement Binding Policy Frontend with Backend Endpoints (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/8bbb76e3-07e5-404d-9335-28cc0d8ecf0c) | Andy Anderson, Braulio Dumba | Kunal Dugar |\r\n| [CNCF - Kyverno: Chainsaw Tests For New Policy Types (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/d9683d35-0ad4-4c32-b32d-f058d37cf94f) | Charles-Edouard Brétéché | Arnab Nandi |\r\n| [CNCF - Kyverno: Mutating Admission Policy Integration (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/1db4df12-49f2-467e-93c2-1625e462eb20) | Mariam Fahmy, Shuting Zhao | Kushal Agrawal |\r\n| [CNCF - Kyverno: Sample Policies For New Policy Types (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/59295005-33de-4665-82b5-d315d108da31) | Jim Bugwadia | Mohd Kamaal |\r\n| [CNCF - LitmusChaos: CI/CD Integration, SDK Development & Chaos-CI-Lib Revamp (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/445a6158-3ba7-429e-b0e1-f7417ff9a724) | Shubham Chaudhary, Vedant Shrotria | Akash Singh |\r\n| [CNCF - LitmusChaos: Expand Tutorials – Day 0, Day 1 & Day 2 User Flows (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/e10bdb01-ef2b-41c5-9a84-6891ecaf6364) | Sayan Mondal, Smriti Satyanarayana | Sindhu Sundar |\r\n| [CNCF - LitmusChaos: Improve code coverage for observability in LitmusChaos components (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/55d8f0a4-86d5-4a90-890b-e8750a27dc60) | Namkyu Park, Adarsh Kumar | Suhyen Im |\r\n| [CNCF - Meshery: Expanding end-to-end test coverage in Meshery using Playwright (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/abd10fed-e03f-4425-863e-157accfe354f) | Lee Calcote, Aabid Sofi | Ali Mohd |\r\n| [CNCF - Meshery: Hands-on tutorials using Meshery Playground (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/4cca92b8-ede6-4396-8d3f-68cfa2ec911c) | Lee Calcote, James Horti | Sumit Narayan |\r\n| [CNCF - Meshery: Meshery Model Support for kro ResourceGraphDefinitions (RGDs) (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/2ce4cf0b-05e0-430a-b9e1-3df46d917ef6) | Lee Calcote, Mia Grenell | Amit Amrutya |\r\n| [CNCF - Microcks: Community-Driven Docs for Deploying Microcks in Cloud Production (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/1b766ba2-3de6-4eb4-8e0d-f79105b000b0) | Yacine Kheddache, Laurent Broudoux | Md Khurshid Alam |\r\n| [CNCF - Microcks: Expand Microcks Hub Sandbox & Mocking for Key Industry APIs (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/04da9d38-b9f8-435f-9200-8359f55ccf92) | Yacine Kheddache, Laurent Broudoux | Vicky Besra |\r\n| [CNCF - Microcks: Expanding Microcks community documentation for advanced installations (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/6b4c516d-fc01-4ab3-8147-13273fcde76b) | Yacine Kheddache, Laurent Broudoux | Krishi Agrawal |\r\n| [CNCF - Microcks: Improve delivery & validation with GitHub Actions CI deployment tests (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/0c667baa-94bf-405c-ada6-c2bea3bf3e56) | Yacine Kheddache, Laurent Broudoux | Meet Soni |\r\n| [CNCF - Microcks: Improving Microcks CLI (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/7ceac2ef-6290-4e2a-87aa-db93d909b27b) | Yacine Kheddache, Laurent Broudoux | Harshvardhan Parmar |\r\n| [CNCF - Microcks: Streamlining Microcks Deployment on AWS Marketplace (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/51c0d803-95ea-48c1-b966-5946b8599662) | Yacine Kheddache, Laurent Broudoux | Vaishnav Kale |\r\n| [CNCF - Microcks: Update the Microcks Hub frontend and make it deployable on-premises (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/faccb875-1d96-44f5-aef7-95c53403d636) | Yacine Kheddache, Laurent Broudoux | Mohd Aquib |\r\n| [CNCF - OpenKruise: Implement Fuzz testing for OpenKruise (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/82bfa5b9-67a9-41ce-ba8b-f027cda4521e) | Zhang Zhen, Zhao Mingshan | Jun Kana, 淳 叶 |\r\n| [CNCF - Prometheus: Get PrometheusRemoteWriteReceiver in OTel-Collector to Alpha Maturity (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/47603a7d-4dc7-48f0-968f-21c2f18f4e3c) | Arthur Sens | Jonathan Silva |\r\n| [CNCF - Prometheus: UX Research: How users expect to use OTLP Resource Attributes in Prometheus (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/36e3f336-ce78-4074-b833-012015eb59be) | Arthur Sens, Amy Super, Andrej Kiripolsky | Victoria Nduka |\r\n| [CNCF - Thanos: Add support for new PromQL aggregations (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/d58c0d26-e276-4ca5-b2ca-21e6582fbcf7) | Giedrius Statkevičius, Saswata Mukherjee | Saumya Shah |\r\n| [CNCF - TUF: Metadata Repository Visualization (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/ea1a5098-29ce-4799-82e0-07416ab4b56a) | Lukas Pühringer, Jussi Kukkonen | Desh Deepak Kant |\r\n| [CNCF - Vitess: Develop an FAQ Chatbot for Vitess using Retrieval-Augmented Generation (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/077e714c-63ad-477d-8124-e879a7ea8fe2) | Rohit Nayak, Manan Gupta | Sakshi Kumar |\r\n| [CNCF - Vitess: Enhance flag support across Vitess Components (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/2bb1bdc0-3fd7-4537-b44f-9afde27ed9fe) | Deepthi Sigireddi, Rohit Nayak | Mounica Sruthi |\r\n| [CNCF - Volcano: Coordinate descheduler and Volcano to support resource defragmentation (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/607246c3-f48b-446c-a7cc-10c0068c553f) | Xuzheng Chang, Zicong Chen | Yichen Jiang |\r\n| [CNCF - Volcano: Volcano dashboard feature enhancements (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/438c1fec-d3d3-4ab0-82ce-499993f8b681) | Xuzheng Chang, Zicong Chen | Shruti Murthy |\r\n| [CNCF - Volcano: Volcano supports queue-level scheduling policies (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/a785c059-fb70-41aa-88a2-62692ab2ca98) | Xuzheng Chang, Zicong Chen | Yuqi Wu |\r\n| [CNCF - WasmEdge: Create a Japanese translation agent for CNCF videos (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/5ba528fe-9704-4e11-b46d-607a5ad1e838) | Michael Yuan, Miley Fu, Vivian Hu | Ai Nozaki |\r\n| [CNCF - WasmEdge: Implement a new WasmEdge installer in Rust (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/79119ceb-7c52-4b9f-b1f2-694b9d1117e3) | Hung-Ying Tai | Li-Lun Lin |\r\n| [CNCF - WasmEdge: Implement component model's validator (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/97f77900-7f5c-45e4-9b0c-638c2db6a8e4) | Lîm Tsú-thuàn | Sridhar Sivakumar |\r\n| [CNCF - WasmEdge: Improve the WasmEdge-based Rust coding assistant for inference-time scaling (2025 Term 1)](https://mentorship.lfx.linuxfoundation.org/project/626ca1e4-9869-4401-8e45-68041ebc98cf) | Michael Yuan | Arnav Raj |\r\n\r\n#### 2024\r\n\r\n##### 2024 Term 3: September - November\r\n\r\n| Project | Mentor(s) | Mentee |\r\n| --- |--------------------------------------------------------------------------------------------------------| --- |\r\n| [CNCF - Harbor: Harbor CLI (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/11beb7c5-02b3-4f33-9dc5-3480a43b0869) | Vadim Bauer, Yan Wang, Orlin Vasilev | Althaf Asharaf |\r\n| [CNCF - Kyverno: Kyverno CLI for the Mutate Existing Rule (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/56bf0ae9-a919-42df-bd0e-e3d6910cbeef) | Shuting Zhao, Mariam Fahmy | Ammar Yasser |\r\n| [CNCF - Jaeger: Jaeger v2 Kubernetes Operator (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/f15ad171-503c-41ae-b573-1e3088312dba) | Yuri Shkuro, Jonah Kowall | Ankit Kurmi |\r\n| [CNCF - Meshery: UI Migration from MUI v4 to MUI v5 and Sistent (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/c98d0652-03c1-4409-bf1c-7240a4947d39) | Lee Calcote, Antonette Caldwell | Ankita Sahu |\r\n| [CNCF - Karmada: Enhance Karmada controller-manager and schedule testing coverage (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/78bd7568-0f36-4648-8a5c-2ba6444ac76a) | Zhen Chang, Zhuang Zhang | Anuj Agrawal |\r\n| [CNCF - WasmEdge: Create a Wasm-based LLM app for financial analysts (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/75feef58-e372-4797-846a-c6a5d6087a19) | Michael Yuan, Hung-Ying, Tai | Arnav Shah |\r\n| [CNCF - WasmEdge: Create an LLM app with deep understanding of a GitHub repo (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/7909e713-a081-49d9-b14e-4ee5a36e0e97) | Michael Yuan, Hung-Ying, Tai | Aru Sharma |\r\n| [CNCF - KubeEdge: Multimodal Large Model Joint Learning via KubeEdge-Ianvs Reproduction (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/d5d315c7-aaee-46ee-895e-a0f9e6ffed4b) | Chuang Hu, Zimu Zheng | Aryan Yadav |\r\n| [CNCF - Inspektor Gadget: Exploring Chaos Engineering with eBPF and Inspektor Gadget (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/c99b5a1f-a1e8-4a9c-93f1-3ee965dabbae) | Michael Friese, Mauricio Vasquez Bernal | Bharadwaja Meherrushi Chittapragada |\r\n| [CNCF - KubeArmor: Support Podman and OCI Hooks support for unorchestrated environments (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/c693a6b1-d034-4140-8aba-dfe02fbef48a) | Barun Acharya, Rudraksh Pareek, Abdulrahman Elawady, Rishabh Soni | Cheithanya PR |\r\n| [CNCF - Konveyor AI: Data Querying for Kai & InstructLab Integration Potential (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/8493016e-975f-4559-8833-db4c884b2fc5) | Jonah Sussman, Fabian von Feilitzsch | Dev Patel |\r\n| [CNCF - Antrea: Application-Level DNS Caches for FQDN-Based Security Rules (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/99e8e0a0-4d82-4ac5-88bc-55b1d1a2c1f4) | Quan Tian, Yang Ding, Antonin Bas | Hemant Kumar |\r\n| [CNCF - WasmEdge: Fix bugs found by fuzzer (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/824beced-74a9-4b65-9db3-c20589b9d0f6) | Hung-Ying, Tai, Yi-Ying He | Himanshi Srestha |\r\n| [CNCF - OpenKruise: Visualize Kruise Rollout progress with kubectl plugin (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/766ae869-a807-470c-aec2-e63ead04e0e2) | Zhang Zhen, Zhao Mingshan | Jaskirat Singh |\r\n| [CNCF - Meshery: End-to-End Testing with Playwright (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/a9113576-7216-46a7-bc9a-f922c1c62f8d) | Aabid Sofi, Lee Calcote | Jerens Soerjadi Lensun |\r\n| [CNCF - Prometheus: Remote-Write v2 in otel-collector's prometheusremotewriteexporter (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/3fa26f90-87aa-46a4-80f9-00195ae276e8) | Arthur Silva Sens, Arve Knudsen, David Ashpole | Juraj Michálek |\r\n| [CNCF - Envoy Gateway: IPv4/IPv6 Dual Stack Support (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/408607a5-22a7-469e-ba9b-773e8fb06ace) | Jianpeng He, Arko Dasgupta | Juwon Hwang |\r\n| [CNCF - Inspektor Gadget: DNS/HTTP Event Generation Capabilities (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/c7ba30b5-625d-4086-ad09-c60071e01a8c) | Qasim Sarfraz, Burak Ok | Kapil Sharma |\r\n| [CNCF - Prometheus: Enhance Prometheus Benchmark Suite (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/b9a0e569-0f73-40dc-94d2-8dc3d376dbc6) | Bryan Boreham, Kemal Akkoyun | Kushal Shukla |\r\n| [CNCF - Karmada: Collect and visualize Karmada metrics (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/5af36c01-f146-4092-8920-97322df6589c) | Wenjiang Ding, Zhen Chang | Md Asiful Alam |\r\n| [CNCF - Jaeger: Jaeger v2 Helm Chart (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/330c6397-06ed-481c-8c86-13fdcbce3896) | Yuri Shkuro, Jonah Kowall | Mehul Gautam |\r\n| [CNCF - Harbor: Harbor Satellite (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/ed963c1b-6697-4b3f-bef6-578cd9722f47) | Vadim Bauer, Yan Wang, Orlin Vasilev | Mehul Kumar |\r\n| [CNCF - Thanos: Add support for hedged requests (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/541a5bb5-09fd-47a9-a244-a65386aa7f7c) | Giedrius Statkevičius, Saswata Mukherjee | Milind Dethe |\r\n| [CNCF - WasmEdge: WASM Serializer with new proposals (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/c96de5c4-e1c3-4a02-a18a-65507d1cb675) | Yi-Ying He, Hung-Ying, Tai | Mohamed Atef |\r\n| [CNCF - Karmada: Enhance Test Coverage for Search, Operator, and Webhook Components (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/1a732552-02b6-4b69-bbf6-d7ea12354e8d) | Zhen Chang, Chaosi Pan | Mohamed Awnallah |\r\n| [CNCF - KCL: The checksum check of the three-party dependencies (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/ade2c7db-ce6e-4c9c-bb4d-8a9e6ff1cf17) | Pengfei Xu, Zhe Zong, Akash Kumar | Nishant Bansal |\r\n| [CNCF - KubeArmor: Non K8s KubeArmor Enhancements (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/87d64083-e1fa-4aa4-a828-ca24e5ae96b3) | Barun Acharya, Rudraksh Pareek, Prateek Nandle, Rishabh Soni | Nishant Singh |\r\n| [CNCF - KubeArmor: Implement Fuzz testing for KubeArmor Components (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/91bd7201-e83f-444c-9157-f82f4c56d060) | Barun Acharya, Rudraksh Pareek, Prateek Nandle | Pradyot Ranjan |\r\n| [CNCF - KubeEdge: Elastic Inference for Deep Learning Models Using KubeEdge (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/1f58cbe5-fe3a-4d0f-9875-b1725ecac223) | ming tang, Shelley Bao | Qijie Huang |\r\n| [CNCF - KCL: KCL Language Server Protocol Support on Lsp4IJ for Jetbrains IDEs (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/dd72885b-3f85-44af-a176-dd04717fb6dc) | Zheng Zhang, Zhe Zong | Rehan Chalana |\r\n| [CNCF - Inspektor Gadget: Testing Inspektor Gadget gadgets on different kernel versions (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/a0e8bcc0-5c52-48ec-9959-506ce27ad46e) | Mauricio Vasquez Bernal, Alban Crequy | Sanskar Sharma |\r\n| [CNCF - OpenKruise: Game operation and maintenance API (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/1f2605c8-c9f3-4a13-95d5-062bd024f9be) | Liu Zhongwei, Liu Qiuyang | Scott Liu |\r\n| [CNCF - TAG Network: CNCF Challenges: Technical Content Creation (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/5c1b69c5-2315-4ec2-8883-7d59f1650a11) | Lee Calcote, Nic Jackson | Shalini Kumari |\r\n| [CNCF - KubeEdge: Integrate KubeEdge, Sedna, and Volcano for Efficient Task Scheduling (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/49fa6dab-9cb5-4889-bbeb-66c4a5545f8f) | Shelley Bao, Fisher Xu | Shao Wang |\r\n| [CNCF - Kyverno: Cleanup policy - Add deletion propagation support (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/6d3ce005-6d61-48ad-a50c-00e3bed91c29) | Charles-Edouard Brétéché, Vishal Choudhary | Shivam Shivam (Shivam Kumar) |\r\n| [CNCF - Service Mesh Performance: CNCF Project Performance Test Dashboard (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/f0add302-47e2-4918-ba86-7a3570b3540c) | Lee Calcote, Xin Huang | Shlok Mishra |\r\n| [CNCF - Inspektor Gadget: New gadget for detecting deadlocks (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/7fdda09c-0eb8-466b-9fdf-e4b3c6a1d5b3) | Alban Crequy, Burak Ok | Snehil Shah |\r\n| [CNCF - Konveyor AI: IntelliJ plugin for Real-Time Updates with analyzer-lsp (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/0d392e44-e3ce-4799-8082-35ae48910f24) | Hiteshwari Patel, Savitha Raghunathan | Soham Banerjee |\r\n| [CNCF - KubeEdge: Decouple Node Cooperation and Batch Management in EdgeApplication (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/89fe7f6c-052b-4597-9ba3-c016858b1835) | Willard, Elias Wang | Tejas Kumar |\r\n| [CNCF - Kyverno: Controller autogen - Implement new approach to autogen (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/0f2bbc4b-6caa-42fa-a697-d20c1e89ca09) | Charles-Edouard Brétéché, Vishal Choudhary | Utsab Sapkota |\r\n| [CNCF - KubeEdge: Cloud-Edge Speculative Decoding for LLM via KubeEdge-Ianvs (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/bfa8251f-a975-4e07-8e7a-915df3518551) | Shijing Hu, Zimu Zheng | Yu Fan |\r\n| [CNCF - Meshery: Migrate APIs to be schema-driven (2024 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/796982d7-09b9-40b3-94f2-3b32cdcdfbf6) | Lee Calcote, Yash Sharma | Zoe Caleb Boris |\r\n\r\n##### 2024 Term 2: June - August\r\n\r\n| Mentoring Project | Mentor(s) | Mentee |\r\n|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------|\r\n| [CNCF - WasmEdge: Finetune LLM models for Rust coding assistance](https://mentorship.lfx.linuxfoundation.org/project/d52d172e-598d-4817-be97-3338d5b96432) | [Michael Yuan](https://github.com/juntao), [Hung-Ying Tai](https://github.com/hydai) | Akshat Shrivastava | \r\n| [CNCF - KCL: KCL Package Management Dependencies Sparse Checkout](https://mentorship.lfx.linuxfoundation.org/project/09391266-0de5-426b-9e11-ceb4c28202ef) | [Zhe Zong](https://github.com/zong-zhe), [Pengfei Xu](https://github.com/Peefy) | Asish Kumar | \r\n| [CNCF - Harbor: Harbor CLI](https://mentorship.lfx.linuxfoundation.org/project/a8a71ad1-4a1b-422e-9928-01c153ac2daf) | [Vadim Bauer](https://github.com/vad1mo), [Yan Wang](https://github.com/wy65701436), [Orlin Vasilev](https://github.com/OrlinVasilev) | Bishal Das | \r\n| [CNCF - KWOK: Enhancement of Technical Outcomes](https://mentorship.lfx.linuxfoundation.org/project/ef8e7637-2eb6-4672-8f6c-c9f9f0677da0) | [Shiming Zhang](https://github.com/wzshiming), [Zhenghao Zhu](https://github.com/Zhuzhenghao) | Charles Uneze | \r\n| [CNCF - KubeEdge: Iterating Enhancement for KubeEdge Dashboard](https://mentorship.lfx.linuxfoundation.org/project/174db042-047a-4036-a523-1598fa386325) | [Hongbing Zhang](https://github.com/HongbingZhang), [Shelley Bao](https://github.com/Shelley-BaoYue) | Chen Su | \r\n| [CNCF - Kubernetes SIG Project Kubespray: bug fixes & enhance helm support for add-ons](https://mentorship.lfx.linuxfoundation.org/project/22b0ef86-d390-4ea2-b302-79e819dcbdfc) | [Kay Yan](https://github.com/yankay), [Mohamed Zaian](https://github.com/mzaian) | Cheng Hao Yang | \r\n| [CNCF - Copacetic: Add new scenarios to Copa's existing image patching features](https://mentorship.lfx.linuxfoundation.org/project/955a5956-de58-44ea-8760-d606feb82165) | [Ashna Mehrotra](https://github.com/ashnamehrotra), [Robert Kielty](https://github.com/RobertKielty) | Cynthia Toporowski | \r\n| [CNCF - LitmusChaos: Revamp Litmus Helm Agent, UBI migration of Images](https://mentorship.lfx.linuxfoundation.org/project/98777e02-dc5b-4380-b6cb-c57603b56e37) | [Sayan Mondal](https://github.com/S-ayanide), [Vedant Shrotria](https://github.com/Jonsy13), [Raj Babu Das](https://github.com/imrajdas) | Dahyeon Kang | \r\n| [CNCF - in-toto: Documentation Boost!](https://mentorship.lfx.linuxfoundation.org/project/34314eb1-0fc3-4802-ab04-2265418c2e48) | [Justin Cappos](https://github.com/JustinCappos), [Patrice Chalin](https://github.com/chalin), [Lukas Pühringer](https://github.com/lukpueh) | Dariksha Ansari | \r\n| [CNCF - TAG Network: Technical Content Creation CNCF Challenges ](https://mentorship.lfx.linuxfoundation.org/project/1a620529-f2be-4a6f-8b4d-0562731cb840) | [Lee Calcote](https://github.com/leecalcote), [Nic Jackson](https://github.com/nicholasjackson) | Emeka Ama | \r\n| [CNCF - Crossplane: Make Crossplane Easy - Improving the Developer Experience](https://mentorship.lfx.linuxfoundation.org/project/87e81040-eb5e-4628-babd-820ef23cd261) | [Jared Watts](https://github.com/jbw976), [Ezgi Demirel](https://github.com/ezgidemirel) | Enes Onuş | \r\n| [CNCF - Knative: Improve Knative Eventing Onboarding](https://mentorship.lfx.linuxfoundation.org/project/1da7e3d2-b170-4236-a2c6-0fa4b0e792e3) | [Leo Li ](https://github.com/Leo6Leo), [Mariana Mejia](https://github.com/mmejia02) | Fırat Bezir | \r\n| [CNCF - Jaeger: Jaeger-V2 Kafka-based architecture](https://mentorship.lfx.linuxfoundation.org/project/6c6181c6-030a-4053-af29-18f09e5e2c4f) | [Yuri Shkuro](https://github.com/yurishkuro), [Jonah Kowall](https://github.com/jkowall), [Yash Sharma](https://github.com/Yahsharma1911) | Harshith Mente | \r\n| [CNCF - Service Mesh Performance: Convergence of Network and Graph topologies](https://mentorship.lfx.linuxfoundation.org/project/c605139b-8736-477a-835a-c6b45112bee4) | [Lee Calcote](https://github.com/leecalcote), [Xin Huang](https://github.com/gyohuangxin) | Iram Sofi | \r\n| [CNCF - Vitess: Improve the website of our automated-benchmarking tool (migrate to shadcn ui and typescript)](https://mentorship.lfx.linuxfoundation.org/project/cba8a6c6-4b09-4618-98f7-bf24391e8c9e) | [Florent Poinsard ](https://github.com/frouioui), [Frances Thai ](https://github.com/notfelineit) | Jad Chahed | \r\n| [CNCF - LitmusChaos: Enhancements in Chaoscenter: GitOps Support for Azure Git, Group Chaos Infra by Environments in Infrastructure Selection Modal](https://mentorship.lfx.linuxfoundation.org/project/e9bf62a9-a7f6-41bb-be7a-e16b7a35a58a) | [Shubham Chaudhary](https://github.com/ispeakc0de), [Amit Das](https://github.com/amityt), [Sahil Kumar](https://github.com/SahilKr24) | Janhavi Alekar | \r\n| [CNCF - Kubescape: Advanced Kubescape plugin features for VSCode](https://mentorship.lfx.linuxfoundation.org/project/b846284b-76e6-45f1-85da-cd36b9bb489e) | [Ben Hirschberg ](https://github.com/slashben), [David Wertenteil](https://github.com/dwertent) | Jayant Pranjal | \r\n| [CNCF - in-toto: Sigstore support for in-toto-jenkins](https://mentorship.lfx.linuxfoundation.org/project/fd34fe37-e736-47bb-b0d5-54a2a0d9875a) | [Santiago Torres-Arias](https://github.com/SantiagoTorres), [Pradyumna Krishna](https://github.com/PradyumnaKrishna) | Jyothi Kiran Satya Raju Jamy | \r\n| [CNCF - LitmusChaos: Implementing Upgrade Agent Support in Litmus 3.x](https://mentorship.lfx.linuxfoundation.org/project/9ac6f8b4-4f76-41d0-b02b-89c79534e619) | [Saranya Jena](https://github.com/Saranya-jena), [Sarthak Jain](https://github.com/SarthakJain26) | Kartikay Kartikay | \r\n| [CNCF - Vitess: Community building and engagement](https://mentorship.lfx.linuxfoundation.org/project/1e395914-9adb-4254-a02d-08e6e03e3b93) | [Deepthi Sigireddi](https://github.com/deepthi), [Florent Poinsard ](https://github.com/frouioui) | Kirtan Chandak | \r\n| [CNCF - KCL: Supports tree-sitter for KCL](https://mentorship.lfx.linuxfoundation.org/project/47661e9d-d390-45d8-b05e-0fb3a30612f4) | [Zheng Zhang](https://github.com/He1pa), [Zhe Zong](https://github.com/zong-zhe) | Korada Vishal | \r\n| [CNCF - Kubescape: Backstage plugin that adheres to the new plugin system](https://mentorship.lfx.linuxfoundation.org/project/1e20bf55-4bcf-40ef-afee-d2b73948cd79) | [Rotem Refael ](https://github.com/rotemamsa), [Matthias Bertschy ](https://github.com/matthyx) | Leo Yang | \r\n| [CNCF - KubeEdge: KubeEdge Documentation Improvement](https://mentorship.lfx.linuxfoundation.org/project/0add127b-8504-4940-97ac-ad989f58e109) | [zhiying ](https://github.com/zhiyingfang2022), [wbc6080](https://github.com/wbc6080) | Mingdi Xue | \r\n| [CNCF - Prometheus: Prometheus Remote Write Benchmarking Capabilities](https://mentorship.lfx.linuxfoundation.org/project/0462446f-aeea-4a19-9bd6-f4241ee5e8f2) | [Callum Styan](https://github.com/cstyan), [Jesús Vázquez](https://github.com/jesusvazquez) | Moeka Mishima | \r\n| [CNCF - KubeArmor: Improve System Test Coverage and Pratices for KubeArmor](https://mentorship.lfx.linuxfoundation.org/project/a6a22ae5-856d-472f-9a11-17a2375b86ba) | [Barun Acharya](https://github.com/daemon1024), [Rudraksh Pareek](https://github.com/DelusionalOptimist), [Anurag Kumar](https://github.com/kranurag7), [Prashant Mishra](https://github.com/primalpimmy) | Navin Chandra | \r\n| [CNCF - KWOK: Enhancement of Test Cases](https://mentorship.lfx.linuxfoundation.org/project/1969ce6c-5468-4842-89a2-06c020bd2ad1) | [Shiming Zhang](https://github.com/wzshiming), [Zhenghao Zhu](https://github.com/Zhuzhenghao) | Neeraj Nagure | \r\n| [CNCF - Harbor: Harbor Satellite](https://mentorship.lfx.linuxfoundation.org/project/93a94aec-8026-4587-b840-52c96ab25020) | [Vadim Bauer](https://github.com/vad1mo), [Yan Wang](https://github.com/wy65701436), [Orlin Vasilev](https://github.com/OrlinVasilev) | Prasanth B | \r\n| [CNCF - Jaeger: Jaeger-V2 Service Performance Monitoring](https://mentorship.lfx.linuxfoundation.org/project/574c4759-09fa-468d-9cfd-4fbb0fb98c09) | [Yuri Shkuro](https://github.com/yurishkuro), [Jonah Kowall](https://github.com/jkowall), [Yash Sharma](https://github.com/Yahsharma1911) | Raghuram Kannan | \r\n| [CNCF - Meshery: Project tutorials, design patterns, & publish reference architectures](https://mentorship.lfx.linuxfoundation.org/project/7ec5139b-fca8-43db-bafc-bdb2faa58047) | [Yash Sharma](https://github.com/Yahsharma1911), [Lee Calcote](https://github.com/leecalcote) | Rishab Sharma | \r\n| [CNCF - Meshery: End-to-End Testing with Playwright](https://mentorship.lfx.linuxfoundation.org/project/62f4866e-9461-490d-890d-9f221a3941b4) | [Aabid Sofi](https://github.com/aabidsofi19), [Lee Calcote](https://github.com/leecalcote) | Rudraksh Tyagi | \r\n| [CNCF - OpenKruise: Enhancement for Kruise-Game Dashboard](https://mentorship.lfx.linuxfoundation.org/project/3967228d-75a7-4963-b092-f2e92fcd57c8) | [Qiuyang Liu](https://github.com/chrisliu1995), [Zhongwei Liu](https://github.com/ringtail) | Sahil Gupta | \r\n| [CNCF - TUF: Documentation assessment and improvements](https://mentorship.lfx.linuxfoundation.org/project/e35f28f9-f333-47a8-a76a-119567cf10ca) | [Justin Cappos](https://github.com/JustinCappos), [Patrice Chalin](https://github.com/chalin), [Lukas Pühringer](https://github.com/lukpueh) | Sandra Dindi | \r\n| [CNCF - Jaeger: Jaeger-V2 Observability and Healthchecks](https://mentorship.lfx.linuxfoundation.org/project/bd752f55-9080-4826-af09-ad86d3614ab2) | [Yuri Shkuro](https://github.com/yurishkuro), [Jonah Kowall](https://github.com/jkowall), [Yash Sharma](https://github.com/Yahsharma1911) | Saransh Shankar | \r\n| [CNCF - Meshery: Support versioning for Meshery designs](https://mentorship.lfx.linuxfoundation.org/project/8e1ab317-9043-4f29-8b83-9b9ffa2b8b40) | [Lee Calcote](https://github.com/leecalcote), [Uzair Shaikh](https://github.com/muzairs15) | Saurabh Singh | \r\n| [CNCF - Knative: Applying pre-prepared website design](https://mentorship.lfx.linuxfoundation.org/project/e18d5c08-312d-4fc1-884c-47c676c12c87) | [Ali Ok](https://github.com/aliok), [Calum Murray](https://github.com/cali0707), [Zainab Husain](https://github.com/zainabhusain227) | shravani kaware | \r\n| [CNCF - KCL: Optimization of KCL LSP prompt information](https://mentorship.lfx.linuxfoundation.org/project/6d85e491-332b-4667-9b57-6ec052310494) | [Pengfei Xu](https://github.com/Peefy), [Zheng Zhang](https://github.com/He1pa) | Shruti Sharma | \r\n| [CNCF - Thanos Compactor: Display TODO plan in UI](https://mentorship.lfx.linuxfoundation.org/project/05b3d261-f874-4b8c-bd7e-c4fa83c979b4) | [Michael Hoffmann ](https://github.com/MichaHoffmann), [Saswata Mukherjee](https://github.com/saswatamcode) | Shu Guan | \r\n| [CNCF - KubeEdge: KubeEdge test cases enhancement](https://mentorship.lfx.linuxfoundation.org/project/ea773daf-d755-46ec-a80c-1eb5f8bbaf16) | [Fisher Xu](https://github.com/fisherxu), [Shelley Bao](https://github.com/Shelley-BaoYue) | Shubham Singh | \r\n| [CNCF - TAG Network: Mapping CNCF Landscape one Relationship-at-a-time](https://mentorship.lfx.linuxfoundation.org/project/bec63054-bc32-4444-b6c5-2b427f527e16) | [Lee Calcote](https://github.com/leecalcote), [Uzair Shaikh](https://github.com/muzairs15) | Shubham Upadhyay | \r\n| [CNCF - WasmEdge: Create a search-enabled API server for local LLMs](https://mentorship.lfx.linuxfoundation.org/project/0a4e08a1-3404-46fc-b0d0-5117ec4ec119) | [Michael Yuan](https://github.com/juntao), [Hung-Ying Tai](https://github.com/hydai) | Suryansh Arya | \r\n| [CNCF - Prometheus: Mark Out-of-order ingestion as stable](https://mentorship.lfx.linuxfoundation.org/project/454caa5a-6fd5-4e27-bde4-7649abf6d8ca) | [Bryan Boreham](https://github.com/bboreham), [Jesús Vázquez](https://github.com/jesusvazquez) | Vanshika Vanshika | \r\n| [CNCF - in-toto: Add GUAC support](https://mentorship.lfx.linuxfoundation.org/project/abfb7093-b057-40da-8be1-c67bd8839698) | [Santiago Torres-Arias](https://github.com/SantiagoTorres), [Pradyumna Krishna](https://github.com/PradyumnaKrishna) | Yashveer | \r\n| [CNCF - Karmada: Certificate Lifecycle Management](https://mentorship.lfx.linuxfoundation.org/project/9120164b-feef-4a5a-bd2a-d9ac42bb8d4a) | [Hongcai Ren](https://github.com/RainbowMango), [Zhen Chang ](https://github.com/XiShanYongYe-Chang) | Ying Zhang | \r\n| [CNCF - WasmEdge: Support piper as a new backend of the WASI-NN WasmEdge plugin](https://mentorship.lfx.linuxfoundation.org/project/61014739-ac16-4188-bdab-c87c0a502470) | [Hung-Ying Tai](https://github.com/hydai), [dm4](https://github.com/dm4) | YU, SHAO-YU | \r\n| [CNCF - KubeEdge: Router Manager Support HA](https://mentorship.lfx.linuxfoundation.org/project/0cf43d24-c7f3-4792-81c9-bff4aa01a96e) | [Shelley Bao ](https://github.com/Shelley-BaoYue), [jiawei ](https://github.com/JiaweiGithub) | zhijia yang | \r\n\r\n##### 2024 Term 1: March - May\r\n\r\n| Mentoring Project | Mentor(s) | Mentee |\r\n|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------|-----------------------|\r\n| [Antrea - Ability to install / upgrade Antrea using the CLI](https://mentorship.lfx.linuxfoundation.org/project/ae950bcf-d16b-4d26-aed0-702c1eedb507) | Quan Tian, Lan Luo, Antonin Bas | Kanha Gupta | \r\n| [Antrea - East-west connectivity monitoring tool for Pod network](https://mentorship.lfx.linuxfoundation.org/project/12b695a0-e05c-46b9-a42d-c7e4709f0129) | Yang Ding, Anlan He, Antonin Bas | Bo Lv | \r\n| [Antrea - Replace deprecated bincover with golang built-in coverage profiling tool](https://mentorship.lfx.linuxfoundation.org/project/8f08ebb1-05a8-41fb-8c4c-85626f63c195) | Antonin Bas, Lan Luo | Shikhar Soni | \r\n| [Chaos Mesh - Observability for StressChaos](https://mentorship.lfx.linuxfoundation.org/project/8ad2c24f-120d-4369-866c-c911a5c885e9) | Zhiqiang Zhou, Yue Yang, Cwen Yin | KAAAsS Gu | \r\n| [Cilium - Governance Documentation](https://mentorship.lfx.linuxfoundation.org/project/eeaec4a9-5a9c-4cae-945d-f99265e85275) | Bill Mulligan, , | Katie Struthers | \r\n| [Cloud Native Buildpacks - Proof of concept making multiarch images with buildkit](https://mentorship.lfx.linuxfoundation.org/project/2c5ced86-d23b-41f5-aec3-59730e29f092) | Jerico Pena, Juan Bustamante, Natalie Arellano | Sai Kiran Maggidi | \r\n| [CNCF TAG Network - Mapping Kubernetes Resources](https://mentorship.lfx.linuxfoundation.org/project/1e9ac76e-0434-45fc-8137-fc5698f29cd0) | Lee Calcote, Uzair Shaikh | Akshay Sharma | \r\n| [CRI-O - Fully Automated CRI-O Releases](https://mentorship.lfx.linuxfoundation.org/project/7ed311c5-6b9b-4056-a8ee-acf04b9f55b9) | Sascha Grunert, Krzysztof Wilczynski | Francis Shonubi | \r\n| [Flux - Conformance tests for AWS](https://mentorship.lfx.linuxfoundation.org/project/61486d56-9b28-42db-9e61-7a74b846cc15) | Stefan Prodan | Sunny Gogoi | \r\n| [Harbor - Harbor CLI](https://mentorship.lfx.linuxfoundation.org/project/8654848d-1233-4e9f-8ed6-559af0ea8298) | Vadim Bauer, Yan Wang, Orlin Vasilev | Amandeep Singh | \r\n| [Harbor - Harbor Satellite](https://mentorship.lfx.linuxfoundation.org/project/31d2e818-5ce1-4f87-aba1-a8b2f71a0e01) | Vadim Bauer, Yan Wang, Orlin Vasilev | Roald Brunell | \r\n| [Inspektor Gadget - Support for new types of eBPF programs](https://mentorship.lfx.linuxfoundation.org/project/f016029e-f15f-4ee9-aaf5-5719bee72b59) | Alban Crequy, Mauricio Vásquez Bernal | TIANYI LIU | \r\n| [Inspektor Gadget - Testing framework for image-based gadgets](https://mentorship.lfx.linuxfoundation.org/project/65719d46-b71f-4778-a29b-3bb878d6ec70) | Alban Crequy, Mauricio Vásquez Bernal | Pranav Pawar | \r\n| [Istio - Improve Test Coverage for Istio Ambient Mesh](https://mentorship.lfx.linuxfoundation.org/project/263ef898-ac07-49d7-9aff-ebd319159163) | Zhonghu Xu, Faseela K | Adil Mohamed M P | \r\n| [Jaeger - Jaeger-V2 Adaptive Sampling](https://mentorship.lfx.linuxfoundation.org/project/00e78fef-e9a7-4e2c-bf29-e6099ac14b65) | Yuri Shkuro, Jonah Kowall | Pushkar Mishra | \r\n| [Jaeger - Jaeger-V2 Observability](https://mentorship.lfx.linuxfoundation.org/project/077f3bec-e3d3-41f7-a527-655c62661f80) | Yuri Shkuro, Jonah Kowall | Harshvir Potpose | \r\n| [Jaeger - Jaeger-V2 Storage Backends](https://mentorship.lfx.linuxfoundation.org/project/66aaa053-e7b1-4682-a285-73ce66420f86) | Yuri Shkuro, Jonah Kowall | James Ryans | \r\n| [K8sGPT - Enhance K8sGPT's analyzers Unit Test Coverage](https://mentorship.lfx.linuxfoundation.org/project/57907615-6548-462d-81dc-62c88476f122) | Alex Jones, Aris Boutselis, Matthis Holleville, JuHyung Son | Vaibhav Malik | \r\n| [KCL - KCL Package Version Management](https://mentorship.lfx.linuxfoundation.org/project/06b5baee-bdcd-4f5e-9a1a-454191445a01) | Pengfei Xu, Zhe Zong | Akash Kumar | \r\n| [Knative - Contributor Journey Research](https://mentorship.lfx.linuxfoundation.org/project/54afaf17-4dc9-4783-9641-a95b5a33af9e) | Calum Murray, Mariana Mejia | PRAJJWAL YADAV | \r\n| [Knative - Cross Namespace Event Links](https://mentorship.lfx.linuxfoundation.org/project/eba6b385-1293-4192-b2b4-7da3afb74476) | Calum Murray, Pierangelo Di Pilato | Yijie Wang | \r\n| [Konveyor - Move2Kube: Exploratory approaches to artifact manipulation.](https://mentorship.lfx.linuxfoundation.org/project/f304369d-62eb-40e0-b52b-630276bf4000) | Akash Nayak, Harikrishnan Balagopal, Mehant Kammakomati | Shashank Sathola | \r\n| [Kubearmor - Dashboards for application behavior and KubeArmor state](https://mentorship.lfx.linuxfoundation.org/project/a604ba9c-565d-4e8c-aed2-dcd4ebedc85d) | Barun Acharya, Prashant Mishra, Rudraksh Pareek, Anurag Kumar | Hari sudarsan | \r\n| [Kubearmor - Kubearmor Kata Container Support](https://mentorship.lfx.linuxfoundation.org/project/0ece2baf-071b-4155-b1e8-696fbe58e991) | Barun Acharya, Prashant Mishra, Rudraksh Pareek | RISHABH SONI | \r\n| [Kubearmor - Leverage OCI Hooks for Container Events](https://mentorship.lfx.linuxfoundation.org/project/70f1ef34-7ddd-466d-a5bc-0f74e98c06f8) | Barun Acharya, Akshay Gaikwad, Rudraksh Pareek | Abdulrahman Elawady | \r\n| [KubeEdge - Auto Generate KubeEdge API Document](https://mentorship.lfx.linuxfoundation.org/project/b36e22c3-ff66-46b8-9422-510c86f1e3c3) | Shelley Bao, Fisher Xu | Lingyu Hou | \r\n| [KubeEdge - Image PrePull Feature Enhancement](https://mentorship.lfx.linuxfoundation.org/project/267cdecd-8ab9-43ab-be0e-ccf70ae1c023) | Shelley Bao, Fisher Xu | 滟飘 韩 | \r\n| [KubeEdge - Keadm Tool Enhancement](https://mentorship.lfx.linuxfoundation.org/project/94e63e48-4b72-4135-b7ca-84687d6f731e) | Willard Hu, Shelley Bao | Ting Huang | \r\n| [KubeEdge - Support latest version in keink and run demo on keink](https://mentorship.lfx.linuxfoundation.org/project/198a9ab4-1f6b-4db5-8e0a-404486235089) | Fisher Xu, Hongbing Zhang | ZHIYUAN GAO | \r\n| [Kyverno - Convert Kubernetes Best Practices Policies to CEL](https://mentorship.lfx.linuxfoundation.org/project/521122b6-aed0-475d-93de-fb2cbfff85d2) | Anusha Hegde, Mariam Fahmy | Chandan DK | \r\n| [Kyverno - Kyverno for Envoy Authorization](https://mentorship.lfx.linuxfoundation.org/project/5da34595-8dd2-4045-a77d-e86d4c64fbc3) | Charles-Edouard Brétéché, Anushka Mittal | Sanskar Gurdasani | \r\n| [Kyverno - Verify Multiple Image Attestations](https://mentorship.lfx.linuxfoundation.org/project/f1041093-65f3-4169-8c70-187a0f286aa4) | Vishal Choudhary, Shuting Zhao | D N Siva Sathyaseelan | \r\n| [LitmusChaos - Chaos Center: Multiple Project Owners & Log Download API](https://mentorship.lfx.linuxfoundation.org/project/0b526c4c-a8ed-4a81-a3f1-1c6ebf328977) | Saranya Jena, Sahil Kumar, Hrishav Kumar | Aryan Bhokare | \r\n| [LitmusChaos - Enhancement of litmusctl: Adding E2E Tests, CRUD Probes Commands, and Package Manager Availability](https://mentorship.lfx.linuxfoundation.org/project/48008595-14d2-4725-a0dc-15d441568bc2) | Vedant Shrotria, Sarthak Jain, Nagesh Bansal | Shivam Purohit | \r\n| [LitmusChaos - Enhancing Chaos Center: E2E Test Cases and Addressing CVE Issues](https://mentorship.lfx.linuxfoundation.org/project/828a5410-6e18-49a8-986e-0ad2dd5ecfa2) | Namkyu Park, Shubham Chaudhary, Raj Babu Das | DHANUSH M R | \r\n| [Meshery - Expand CLI capabilities for registry management](https://mentorship.lfx.linuxfoundation.org/project/441ebbbd-8084-4e4c-b072-bc78112502ef) | Lee Calcote, Uzair Shaikh | Sanjay Kumar Mishra | \r\n| [Meshery - Expand integration with Artifact Hub](https://mentorship.lfx.linuxfoundation.org/project/83c60c5f-3e79-4532-8ee6-1266e30d21e0) | Lee Calcote, Aabid Sofi | Umar Ali | \r\n| [Meshery - UI Migration from MUI v4 to MUI v5 and NextjS 13](https://mentorship.lfx.linuxfoundation.org/project/9dc784dd-dbfb-4d60-81ce-4da95e0b48a0) | Lee Calcote, Antonette Caldwell | Rex Joshua Ibegbu | \r\n| [OpenTelemetry - One Logging Bridge per Language](https://mentorship.lfx.linuxfoundation.org/project/2d114b9d-015e-40f4-bdd7-9acbb836d84e) | Juraci Paixão Kröhling, Andrzej Stencel | Khushi Jain | \r\n| [Prometheus - Client_golang CI/CD improvements](https://mentorship.lfx.linuxfoundation.org/project/8c1ba948-5237-4bae-9dd2-ee9580b5a018) | Arthur Sens, Kemal Akkoyun | Sachin Kumar Sahu | \r\n| [Service Mesh Performance - Adaptive Load Control with Nighthawk](https://mentorship.lfx.linuxfoundation.org/project/98b9a7d7-4dd4-45aa-96f9-145e058efcee) | Lee Calcote, Xin Huang | Shivam Gupta | \r\n| [Service Mesh Performance - Distributed Load Testing with Nighthawk](https://mentorship.lfx.linuxfoundation.org/project/bad94872-bd61-4960-915a-ea1945ddd15c) | Lee Calcote, Xin Huang | Mukesh Sharma | \r\n| [Vitess - Improve Unit Test Coverage](https://mentorship.lfx.linuxfoundation.org/project/efed074b-3c68-4337-90ab-2a3f2d15c836) | Manan Gupta, Harshit Gangal | Noble Mittal |\r\n| [Volcano - Volcano supports DRA integration](https://mentorship.lfx.linuxfoundation.org/project/3c2d290a-6e93-4185-88f5-56736365fe85) | william wang, Xuzheng Chang | SUBHASISH BEHERA | \r\n| [Volcano - Volcano supports multi-cluster AI workloads scheduling](https://mentorship.lfx.linuxfoundation.org/project/132a4971-6969-4ca6-a695-783ece3ac768) | william wang, Xuzheng Chang | 仁天 周 | \r\n| [WasmEdge - Integrate Intel Extension for Transformers as a new WASI-NN backend](https://mentorship.lfx.linuxfoundation.org/project/8b592388-6a17-4a8f-82e4-121131c217d0) | Hung-Ying Tai, Meng-Han Lee | Han-Wen Tsao | \r\n| [WasmEdge - Integrate MLX as a new WASI-NN backend](https://mentorship.lfx.linuxfoundation.org/project/395d3659-e7c2-413f-8f95-42d079c9d0bc) | Hung-Ying Tai, Meng-Han Lee | Aryan Gupta | \r\n\r\n#### 2023\r\n\r\n##### Term 3: September - November\r\n\r\n| Mentoring Project | Mentor(s) | Mentee |\r\n| --- | ---| ---|\r\n| [CNCF - Carvel: kctrl to support exporting package repository as tar](https://mentorship.lfx.linuxfoundation.org/project/91398424-f095-4b85-bb0f-e7c56e777ea0) | Soumik Majumder, Renu Yarday | Ashish Kumar | \r\n| [CNCF - CRI-O: Add additional log drivers to conmon-rs](https://mentorship.lfx.linuxfoundation.org/project/99274b1a-694b-4af5-b7ca-39311f38a646) | Peter Hunt, Sascha Grunert | Yash Sharma | \r\n| [CNCF - CRI-O: CRI stats KEP](https://mentorship.lfx.linuxfoundation.org/project/cb189d71-3943-450a-9d5f-d71bd66d73c9) | Peter Hunt, Sohan Kunkerkar, Sascha Grunert | Mohamed Abdelfatah | \r\n| [CNCF - Istio: Documentation for Ambient Mesh](https://mentorship.lfx.linuxfoundation.org/project/89ee4357-dd58-4e15-a601-c411742a587c) | Lin Sun | Faeka Ansari | \r\n| [CNCF - Istio: Implement performance testing](https://mentorship.lfx.linuxfoundation.org/project/bbebd511-1a3e-4c4f-b106-2f09690825c5) | Lin Sun, Andrea Y Ma | Shuayb popoola | \r\n| [CNCF - Jaeger: Build official support in Jaeger for Elasticsearch 8](https://mentorship.lfx.linuxfoundation.org/project/37cf2714-668d-4014-ac44-953f70f9dc8e) | Yuri Shkuro | Yashwanth Reddy | \r\n| [CNCF - Jaeger: Combine three distinct graph views in Jaeger UI into one](https://mentorship.lfx.linuxfoundation.org/project/1e67c90b-de3e-4c4e-a2be-a5583a948864) | Yuri Shkuro, Yash Sharma | Prathamesh Mutkure | \r\n| [CNCF - Jaeger: Upgrade Jaeger UI to the latest version of React.js](https://mentorship.lfx.linuxfoundation.org/project/83cc55fe-b97a-4195-8dd2-cc9aed7e509c) | Yuri Shkuro | Ansh Goyal | \r\n| [CNCF - Karmada: Add Karmada API documentation on the website](https://mentorship.lfx.linuxfoundation.org/project/54940f04-54b8-41ee-94bf-153f977b31e7) | Zhen Chang, Hongcai Ren | Mohammed Affan | \r\n| [CNCF - Karmada: Karmada supports promote dependent resources automatically](https://mentorship.lfx.linuxfoundation.org/project/60b43efd-79e0-457e-989f-d4d59d55d8a6) | Wei Jiang, Hongcai Ren | Haiyu Zuo | \r\n| [CNCF - Konveyor: Compile Move2Kube to WASM/WASI and run it in the browser](https://mentorship.lfx.linuxfoundation.org/project/c2b5f721-2666-4d9e-85d6-7bedae27e144) | Harikrishnan Balagopal, Mehant Kammakomati | Prakhar Agarwal | \r\n| [CNCF - Konveyor: Extend use-case of detecting deprecated Kubernetes API usage](https://mentorship.lfx.linuxfoundation.org/project/989d0ad3-976a-4514-b2fc-34e9e6081567) | Emily McMullan, Jonah Sussman, John Matthews | Parthiba Hazra | \r\n| [CNCF - Konveyor: Move2Kube: Advanced Resources support - ArgoCD, Tekton, Stateful Set, etc.](https://mentorship.lfx.linuxfoundation.org/project/b9aad4e2-d9c7-405e-8482-5aced0a4ecdb) | Akash Nayak, Harikrishnan Balagopal | Soumil Paranjpay | \r\n| [CNCF - Konveyor: Move2Kube: WASM Transformers](https://mentorship.lfx.linuxfoundation.org/project/ec286a9e-e48d-4c83-a991-9c79a4ec213a) | Harikrishnan Balagopal, Mehant Kammakomati | Vamsi Satyasi | \r\n| [CNCF - KubeArmor: Extend Support Matrix and Document Usecases](https://mentorship.lfx.linuxfoundation.org/project/eba8fbf7-848b-4d69-8b0e-b6852acc7755) | Anurag Kumar, Barun Acharya, Ankur Kothiwal | Anurag Rajawat | \r\n| [CNCF - KubeEdge: Add case study center in website](https://mentorship.lfx.linuxfoundation.org/project/12dda5ae-a123-4e2a-985c-13d33f8a25f0) | Shelley Bao, Fisher Xu | Jingning Du | \r\n| [CNCF - KubeEdge: Support latest version installation demo in killercoda](https://mentorship.lfx.linuxfoundation.org/project/36bfe273-9059-47e0-88f7-afb38b2d9ebb) | Fisher Xu | sarthak negi | \r\n| [CNCF - Kubernetes: Build a Go library and CLI for interacting with OpenBuildService](https://mentorship.lfx.linuxfoundation.org/project/47f53d22-ff5c-4479-b701-3ca3dbc7df0a) | Carlos Panato, Marko Mudrinić | Nitish Kumar | \r\n| [CNCF - Kubescape: Build an admission controller for Kubescape](https://mentorship.lfx.linuxfoundation.org/project/271852c6-3348-4ec7-bf09-035913b1c86e) | Craig Box, Ben Hirschberg | Anant Vijay | \r\n| [CNCF - Kubescape: Upgrade the documentation publishing pipeline for Kubescape controls](https://mentorship.lfx.linuxfoundation.org/project/ccd3fc5f-a0a9-441f-bd4c-5caae8ab6509) | Ben Hirschberg, Craig Box | Rohit T | \r\n| [CNCF - Kyverno: Kyverno Kuttl Enhancements](https://mentorship.lfx.linuxfoundation.org/project/919e8b57-8fc1-4f61-8bc8-3c8b06dd5e7a) | Charles-Edouard Brétéché | Shubham Gupta | \r\n| [CNCF - Kyverno: Pod Security Admission Integrations II](https://mentorship.lfx.linuxfoundation.org/project/a7f754b4-5c8c-48a3-8f5f-b3ff6307b0f4) | Shuting Zhao | Gurmannat Sohal | \r\n| [CNCF - Kyverno: Policy Exceptions 2.0](https://mentorship.lfx.linuxfoundation.org/project/7ffb0f63-e1e4-477b-ab0c-a69cb681f112) | Jim Bugwadia, Mariam Fahmy | Rakshit Gondwal | \r\n| [CNCF - LitmusChaos: Improve Chaoscenter Web and Authentication Server: Add Unit Test Cases, Enhance GQL APIs, Update API Documentation](https://mentorship.lfx.linuxfoundation.org/project/237b7300-d749-4f14-bd4c-9375e5ec39b6) | Sarthak Jain, Neelanjan Manna, Sayan Mondal | MAGNIM THIBAUT FREEDISCH BATALE | \r\n| [CNCF - LitmusChaos: Improve litmusctl UX and codebase and add new functionalities to litmusctl](https://mentorship.lfx.linuxfoundation.org/project/fde90e7f-0410-4b84-ad9c-99f7139267ed) | Saranya Jena, Sayan Mondal, Neelanjan Manna | deep poharkar | \r\n| [CNCF - Meshery: Overhaul UX Design System](https://mentorship.lfx.linuxfoundation.org/project/a61f6cdb-98b4-43c9-8ca2-ea9bb5d5c470) | Lee Calcote, Ritik Saxena | Milan Saxena | \r\n| [CNCF - Meshery: Package Meshery Catalog Artifacts as OCI Images](https://mentorship.lfx.linuxfoundation.org/project/aff716df-c257-4ead-8b48-39a3f9272b7f) | Lee Calcote, Uzair Shaikh | Senali Dilumika | \r\n| [CNCF - Meshery: WASM-based OPA policy evaluation with Rego](https://mentorship.lfx.linuxfoundation.org/project/9faff011-1027-49c0-aa37-8d5be7208d6f) | Lee Calcote, Abhishek Kumar | Aabid Sofi | \r\n| [CNCF - OpenKruise: Integrate Openkruise workload with ArgoCD and Helm](https://mentorship.lfx.linuxfoundation.org/project/f603a2e7-9af2-40b2-a74f-109cad843de1) | Zhang zhen, Zhao Mingshan | Mahesh Kasbe | \r\n| [CNCF - Thanos: Implement fan-out query observability in Thanos](https://mentorship.lfx.linuxfoundation.org/project/5a96f43c-d858-40c2-b556-2770ba6b03d4) | Giedrius Statkevičius, Saswata Mukherjee | A Dattatreya Varma | \r\n| [CNCF - Vitess: Continue the migration to React and enhance existing frontend UI](https://mentorship.lfx.linuxfoundation.org/project/10d70edd-60ec-409b-8801-0fb752501b12) | Florent Poinsard | Spandan Barve | \r\n| [CNCF - Volcano: Build a new elastic resource quota mechinism in Volcano ](https://mentorship.lfx.linuxfoundation.org/project/ffbb6bb3-b9d1-4e96-9f72-4a0566f6b0c3) | William Wang, Lei Wu (Thor Wu) | Zhuoqi Huang | \r\n| [CNCF - WasmEdge: Create a ffmpeg plugin](https://mentorship.lfx.linuxfoundation.org/project/41a8bf79-a903-4c03-afb7-256fd373c0b0) | Michael Yuan | Hrushikesh Rao | \r\n| [CNCF - WasmEdge: Create a Rust crate for YOLO model](https://mentorship.lfx.linuxfoundation.org/project/63adcf97-cd3e-4c96-a5fc-6076b5a5d511) | Michael Yuan | Charles Schleich | \r\n\r\n##### Term 2: June - August\r\n\r\n| Mentoring Project | Mentor(s) | Mentee |\r\n| --- | ---| ---|\r\n| [CNCF - Armada: Build interfaces around Postgres for Armada](https://mentorship.lfx.linuxfoundation.org/project/73d90321-62b3-498e-bf37-d899ec99df9e) | Geoffrey Wilson, Kevin Hannon | El Mehdi Rami |\r\n| [CNCF - Cilium: Tetragon Implement a Kubernetes operator to maintain pod IP to pod metadata mapping](https://mentorship.lfx.linuxfoundation.org/project/659fe584-68e6-46bf-bd13-12653ef60268) | Kornilios Kourtis, Michi Mutsuzaki | prateek singh |\r\n| [CNCF - CNCF Landscape: UX / UI Improvements II](https://mentorship.lfx.linuxfoundation.org/project/c45cc842-278f-4663-9ff4-deecc3fc040d) | Andrea Velázquez, Nate W., Chris Aniszczyk | Avantika Jain |\r\n| [CNCF - CoreDNS: Add DNS-over-QUIC (DoQ) and/or DNS-over-HTTP/3 (DoH3) support](https://mentorship.lfx.linuxfoundation.org/project/dd10bf62-53d1-4a96-bea2-65bbb78bd10e) | Yong Tang, Chris O'Haver | João Henri Carrenho Rocha |\r\n| [CNCF - Jaeger: Implement Critical Path analysis](https://mentorship.lfx.linuxfoundation.org/project/0fc6c44b-5ddf-467f-8016-72cc35b4e3ff) | Yuri Shkuro, Yash Sharma | GLVS Kiriti |\r\n| [CNCF - Jaeger: Upgrade Jaeger's internal telemetry to OpenTelemetry](https://mentorship.lfx.linuxfoundation.org/project/b8009398-1252-4f63-82fe-363846ccc11d) | Yuri Shkuro, Albert Teoh | Afzal Ansari |\r\n| [CNCF - Knative: Porting Knative Serving to Microshift](https://mentorship.lfx.linuxfoundation.org/project/830eb064-cf8a-4a8e-bba3-97d429a6ca79) | Reto Lehmann, Stavros Kontopoulos | Naveenraj Muthuraj |\r\n| [CNCF - Konveyor: Add Integration test suite and components testing to Konveyor](https://mentorship.lfx.linuxfoundation.org/project/78852896-9785-4156-bb9b-bc3c5cb6ed17) | Marek Aufart, David Zager | Yash Khare |\r\n| [CNCF - KubeArmor: Manage KubeArmor policies using OCI registry and use OCI hooks for container events](https://mentorship.lfx.linuxfoundation.org/project/08d245cb-001f-4292-90eb-e8895189c77a) | Anurag Kumar, Barun Acharya, Ankur Kothiwal | Akshay Gaikwad |\r\n| [CNCF - Kubescape: Prometheus exporter for image vulnerabilities](https://mentorship.lfx.linuxfoundation.org/project/8c701687-7cde-42fc-8195-08d35fdb5ee8) | Ben Hirschberg, Craig Box, David Wertenteil | Yash Raj Singh |\r\n| [CNCF - Kubescape: Store Kubescape configuration scan results as CRs](https://mentorship.lfx.linuxfoundation.org/project/1a6a7aaf-7436-431b-9131-9422e4b2fb71) | Ben Hirschberg, Craig Box, David Wertenteil | Tejas Jamdade |\r\n| [CNCF - Kubescape: Vulnerability-based Dockerfile generator](https://mentorship.lfx.linuxfoundation.org/project/fbaf3d52-77ee-469c-8eb4-3e0378896159) | Ben Hirschberg, Craig Box, David Wertenteil | Anubhav Gupta |\r\n| [CNCF - Kubevela: Auto-generate the TypeScript and Java languages API SDK](https://mentorship.lfx.linuxfoundation.org/project/b97b2f2d-4dbd-45f5-9121-0e865aa6dfd9) | Qiao Zhongpei, Yin Da | Zuoning Zhang |\r\n| [CNCF - KubeVela: Expand multiple database drivers for the API server](https://mentorship.lfx.linuxfoundation.org/project/21c95d53-dd75-4a2f-a8fd-92374c54940d) | Qiao Zhongpei, Zeng Qingguo | Neeraj Gartia |\r\n| [CNCF - Kyverno: Cleanup Policies, Phase 2](https://mentorship.lfx.linuxfoundation.org/project/4689c5fa-165e-4015-ad21-951d9babcb7e) | Charles-Edouard Brétéché | Ved Ratan |\r\n| [CNCF - Kyverno: Kuttl tests for the Kyverno policy library](https://mentorship.lfx.linuxfoundation.org/project/85ebe560-e9ee-42fe-9dff-f8dc6a11ef27) | Chip Zoller | Alok N |\r\n| [CNCF - Kyverno: Sigstore Cosign Updates](https://mentorship.lfx.linuxfoundation.org/project/cabb007c-5669-4b16-8778-36d995a71591) | Shuting Zhao, Vishal Choudhary | Amit Kumar |\r\n| [CNCF - Kyverno: ValidatingAdmissionPolicy support, Phase 2](https://mentorship.lfx.linuxfoundation.org/project/e4be265d-fa05-46b7-8fad-2585b6a76082) | Jim Bugwadia, Mariam Fahmy | SANCHITA MISHRA |\r\n| [CNCF - LitmusChaos: Enhance/improve chaos center code base and redesign chaos workflow apis](https://mentorship.lfx.linuxfoundation.org/project/983193ea-9cca-405f-baa5-e6ade4df1ba2) | Amit Kumar Das, Arkajyoti Mukherjee | Soham Ratnaparkhi |\r\n| [CNCF - LitmusChaos: Enhance/Upgrade chaos operator and chaos exporter module](https://mentorship.lfx.linuxfoundation.org/project/bd6e875a-a64c-4405-af1c-677d8c45014b) | Shubham Chaudhary, Vansh Bhatia | Nageshbansal Nageshbansal |\r\n| [CNCF - Meshery: Adopt OCI as the packaging and distribution format for Meshery MeshModels](https://mentorship.lfx.linuxfoundation.org/project/26377c30-9ffd-41e3-bfea-839bf126f8f6) | Lee Calcote | Aarush Singh |\r\n| [CNCF - Meshery: Meshery UI Permissions Framework](https://mentorship.lfx.linuxfoundation.org/project/f4a9804f-2e46-42a4-b2ae-ad3ea7b29734) | Lee Calcote, Abhishek Kumar | Usman Siddique |\r\n| [CNCF - Meshery: OCI compatible Kubernetes ontology](https://mentorship.lfx.linuxfoundation.org/project/bb8ddf84-31d7-4a89-9e4b-e6aa9601c0db) | Lee Calcote | Jamie Plubell |\r\n| [CNCF - Meshery: OPA policy evaluation in-browser using WebAssembly and Rego](https://mentorship.lfx.linuxfoundation.org/project/005db8db-7efe-4433-9605-91d14174c72c) | Lee Calcote, Abhishek Kumar | Mohd. Hamza Shaikh |\r\n| [CNCF - Notary: Design and implement the new Notary website](https://mentorship.lfx.linuxfoundation.org/project/06774504-da91-469e-89f9-14fb18b6e0d8) | Feynman Zhou | Sanjay Kumar |\r\n| [CNCF - Notary: Develop content for Notary documentation and blogs](https://mentorship.lfx.linuxfoundation.org/project/007ca3e9-c121-4428-8e63-57bc0418e98a) | Yi Zha | Roseline Bassey |\r\n| [CNCF - ORAS: Design and implement Artifact Explore web portal](https://mentorship.lfx.linuxfoundation.org/project/9749bc0a-04c9-498d-a16c-e66c0930e819) | Feynman Zhou, Billy Zha | Vasu Devrani |\r\n| [CNCF - ORAS: Refactor the ORAS documentation structure and write new user guides](https://mentorship.lfx.linuxfoundation.org/project/2314fcc1-f09b-4dab-90fb-d0ef092b6c0e) | Terry Howe, Asmit Malakannawar, Feynman Zhou | Deepesha Burse |\r\n| [CNCF - Service Mesh Performance: Service Mesh Performance IDE Plugin](https://mentorship.lfx.linuxfoundation.org/project/4735d0fa-229f-43e7-9415-dff9220bf687) | Lee Calcote, Xin Huang | Ashok Chadha |\r\n| [CNCF - Strimzi: Proof of Concept of an MQTT to Apache Kafka bridge for producing messages](https://mentorship.lfx.linuxfoundation.org/project/8d301adf-94d8-4e5d-821d-f904ed15c3f9) | Paolo Patierno, Kyle Liberti | Antonio Pedro |\r\n| [CNCF - Thanos: Continuation of add query observability for the new engine](https://mentorship.lfx.linuxfoundation.org/project/1953e512-fa8c-4f0e-9b24-0e6c81a7cd39) | Saswata Mukherjee, Giedrius Statkevičius | Nishchay Veer |\r\n| [CNCF - Vitess: Rework the frontend UI of Vitess’ benchmarking tools](https://mentorship.lfx.linuxfoundation.org/project/8299d27a-9e36-4de6-abbc-c9282634ee03) | Florent Poinsard, Rohit Nayak | Camille Metard |\r\n| [CNCF - WasmEdge: A stream log processing framework for WasmEdge](https://mentorship.lfx.linuxfoundation.org/project/55c226fe-d119-4b2c-aba0-e7415867f6e5) | Michael Yuan | TIANYU CHEN |\r\n| [CNCF - WasmEdge: Serialization Completion](https://mentorship.lfx.linuxfoundation.org/project/4a8a4f26-0ca9-4517-8cce-582c92092e33) | Yi-Ying He, Hung-Ying Tai | 龙 顾 |\r\n| [CNCF - WasmEdge: Support Tensorflow and PyTorch in WasmEdge’s Python runtime](https://mentorship.lfx.linuxfoundation.org/project/884ff3f2-3ea3-4010-8928-ca27bbae219a) | Michael Yuan, Asen Alexandrov | Eshaan Agarwal |\r\n| [CNCF - WasmEdge: zlib Plugin Support](https://mentorship.lfx.linuxfoundation.org/project/74cecdf7-e886-4830-8bb0-7814f0d1aa2d) | Yi-Ying He, Hung-Ying Tai | Saikat Dey |\r\n\r\n##### Term 1: March - May\r\n\r\n| Mentoring Project | Mentor(s) | Mentee |\r\n| --- | ---| ---|\r\n| [CNCF - Cilium: Website Use Cases pages](https://mentorship.lfx.linuxfoundation.org/project/81a0e506-1c05-45fa-90c4-6bde8bdc0e61) | Bill Mulligan | Paul Arah | \r\n| [CNCF - Cloud Native Buildpacks: Multi-Architecture Builds](https://mentorship.lfx.linuxfoundation.org/project/ee387e1b-de4e-4c1e-9bef-0239a2e9ca40) | Aidan Delaney, Jerico Pena, Juan Bustamante | Husni Faiz | \r\n| [CNCF - Cloud Native Buildpacks: Pack Performance enhancements](https://mentorship.lfx.linuxfoundation.org/project/33e0747c-4ab8-4074-aa90-3b908b3a588e) | Natalie Arellano, Joe Kimmel | Lingi Wu | \r\n| [CNCF - CNCF Landscape: UX UI improvement](https://mentorship.lfx.linuxfoundation.org/project/df011bb8-8ce1-4092-bfc6-1e92ce40a17d) | Andrea Velázquez, Nate W., Chris Aniszczyk | Hilda Okafor | \r\n| [CNCF - CNCF TAG Network: Representing Kubernetes ontology in MeshModel](https://mentorship.lfx.linuxfoundation.org/project/96080e3d-83e2-46ed-928c-b6e7f3154bf3) | Lee Calcote | Ayush Sharma | \r\n| [CNCF - Cortex: API to import Prometheus & Thanos blocks](https://mentorship.lfx.linuxfoundation.org/project/184ccb3e-6abe-4bf9-9659-b42b5c07c5a5) | Alan Protasio, Daniel Blando | Siddharth Asthana | \r\n| [CNCF - Cortex: Automated nightly benchmarks](https://mentorship.lfx.linuxfoundation.org/project/0071e2ff-f538-4817-978b-07b267cfcd6a) | Ben Ye | Kama Huang | \r\n| [CNCF - Cortex: Experimental Auth Gateway](https://mentorship.lfx.linuxfoundation.org/project/820f9269-ddef-44e9-bf77-95a8d2444c1e) | Friedrich Gonzalez | Doğukan Teber | \r\n| [CNCF - Harbor: An official Golang API client and CLI for Harbor](https://mentorship.lfx.linuxfoundation.org/project/7e8cb88a-5b37-471c-8db8-e11907b5a661) | Vadim Bauer, Yan Wang, Orlin Vasilev | Akshat Akshat | \r\n| [CNCF - Harbor: Harbor Robot accounts with full Harbor API access](https://mentorship.lfx.linuxfoundation.org/project/4a96c735-6480-4464-8b33-4f9c58ba1005) | Vadim Bauer, Yan Wang, Orlin Vasilev | Paarth Agarwal | \r\n| [CNCF - Harbor: Regex replication rules](https://mentorship.lfx.linuxfoundation.org/project/49749be9-5a67-4b2b-9312-7def13ae98b8) | Vadim Bauer, Yan Wang, Orlin Vasilev | Wilfred Almeida | \r\n| [CNCF - Karmada: Bundle third-party resources into the Resource Interpreter framework](https://mentorship.lfx.linuxfoundation.org/project/891b4b92-0a78-409e-8b90-dcd58d126225) | Tiecheng Shen, Hongcai Ren | Yike Bu | \r\n| [CNCF - Karmada: Enhance Karmada testing coverage](https://mentorship.lfx.linuxfoundation.org/project/1b2c5ff4-d6ea-4ca5-b138-75fce03407b4) | Zhen Chang, Hongcai Ren | Xinyu Wu | \r\n| [CNCF - Karmada: Provide interactive environments for Karmada](https://mentorship.lfx.linuxfoundation.org/project/6a6e8093-660a-4b6e-8d29-24b8ef70e4f0) | Wei Jiang, Hongcai Ren | diandian zhang | \r\n| [CNCF - Konveyor: Move2Kube Allow customizations](https://mentorship.lfx.linuxfoundation.org/project/fc06da19-fadd-499f-ae71-3da2caba5aea) | Mehant Kammakomati, Harikrishnan Balagopal | Venkat Bandarupalli | \r\n| [CNCF - Konveyor: Move2Kube Consume Move2Kube through a plugin on VSCode](https://mentorship.lfx.linuxfoundation.org/project/d8a7022f-8c62-4776-9e7c-4cc12f306177) | Mehant Kammakomati, Harikrishnan Balagopal | Roshan Swain | \r\n| [CNCF - Konveyor: Move2Kube Implement a test suite](https://mentorship.lfx.linuxfoundation.org/project/6d457c37-68cb-4d52-b9d6-798b09350255) | Mehant Kammakomati, Harikrishnan Balagopal | Tarun Kumar | \r\n| [CNCF - KubeArmor: Adding OpenTelemetry Support](https://mentorship.lfx.linuxfoundation.org/project/369f081d-398e-4ce8-b645-e9605b62326a) | Anurag Kumar, Ankur Kothiwal, Barun Acharya | Maureen Ononiwu | \r\n| [CNCF - KubeArmor: KubeArmor Telemetry Monitoring and Dashboards](https://mentorship.lfx.linuxfoundation.org/project/a0696db8-509e-44ff-ae61-82a3442853c1) | Anurag Kumar, Ankur Kothiwal, Barun Acharya | SIBASISH BEHERA | \r\n| [CNCF - KubeEdge: Cloud-Robotic AI Benchmarking for Edge-cloud Collaborative Lifelong Learning](https://mentorship.lfx.linuxfoundation.org/project/50cdbd65-e0cd-4c0f-8c63-6bd5c603ba89) | Siqi Luo, Fisher Xu | Shijing Hu | \r\n| [CNCF - KubeEdge: Design and implement the KubeEdge Dashboard](https://mentorship.lfx.linuxfoundation.org/project/4d9d8e17-8484-4c3e-9210-bb911633f57c) | Vincent Lin, Fisher Xu | Qian Chen | \r\n| [CNCF - KubeEdge: Re-design and implement the KubeEdge website](https://mentorship.lfx.linuxfoundation.org/project/a50fec46-7bc6-4fa0-ba84-848f0c136b5c) | Shelley Bao, Fisher Xu | pengfei yang | \r\n| [CNCF - Kubernetes: CAPA Reimagining how we handle AWS account preparation](https://mentorship.lfx.linuxfoundation.org/project/2d76dbe6-43eb-465e-a852-64b2e48f2c68) | Richard Case, Ankita Swamy | Atharva Shinde | \r\n| [CNCF - Kubernetes: CAPG Add telemetry and profiling support](https://mentorship.lfx.linuxfoundation.org/project/55469b74-0c98-44f1-b8e1-4244a736bf82) | Carlos Panato, Richard Case | Phong Nguyen | \r\n| [CNCF - Kubescape: Build debugging capabilities for Helm](https://mentorship.lfx.linuxfoundation.org/project/570b1bba-206d-47ac-9667-22268ff7a6d9) | Ben Hirschberg | Mo Jiehong | \r\n| [CNCF - Kubescape: Implement security controls based on penetration testing best practices](https://mentorship.lfx.linuxfoundation.org/project/db63c23a-2b41-40e0-a833-cf0e2c33c739) | Ben Hirschberg | Karanjot Singh | \r\n| [CNCF - Kubescape: Release engineering: add Kubescape to commonly-requested package managers](https://mentorship.lfx.linuxfoundation.org/project/138e9cac-ec86-43cb-a04f-c2980e3c2865) | Craig Box | Songlin Jiang | \r\n| [CNCF - Kubevela: Extend the capability of KubeVela by making several useful addons](https://mentorship.lfx.linuxfoundation.org/project/51398c19-87c2-4b50-9dd3-760fbd820688) | Jianbo Sun, Wong Yike | Sahil Afroj | \r\n| [CNCF - Kubevela: Support auto generation of CUE schema and docs from Go struct](https://mentorship.lfx.linuxfoundation.org/project/85f61cae-02d7-4931-8d87-d3da3128060e) | Fog Dong, Da Yin | Junyu Liu | \r\n| [CNCF - Kubewarden: Kubewarden SDKs feature parity](https://mentorship.lfx.linuxfoundation.org/project/ddc368b7-1e24-42ed-9e30-02abdf6fcd33) | José Guilherme Vanz, Victor Cuadrado Juan | Khaled Emara | \r\n| [CNCF - Kyverno: Artifact Hub listing of Kyverno Policy Library](https://mentorship.lfx.linuxfoundation.org/project/f502b839-a804-4a6c-8da5-3985ce25883e) | Chip Zoller | Haoyu Guo | \r\n| [CNCF - Kyverno: Kubernetes Validating Admission Policy Support](https://mentorship.lfx.linuxfoundation.org/project/a00294be-06a0-4e66-a2a5-6e2dfb3a097c) | Jim Bugwadia | Mariam Fahmy | \r\n| [CNCF - Kyverno: OCI references support](https://mentorship.lfx.linuxfoundation.org/project/e5da551f-8a3d-42ec-8c00-e9ae10a86aa2) | Jim Bugwadia | Vishal Choudhary | \r\n| [CNCF - Kyverno: Pod Security Admission Integrations](https://mentorship.lfx.linuxfoundation.org/project/59afc794-c33e-4930-a5b8-eb3abd8d9896) | Shuting Zhao | Liang Deng | \r\n| [CNCF - Linkerd: Add dynamic profiling to Linkerd Rust controllers](https://mentorship.lfx.linuxfoundation.org/project/e1ff5120-32e4-44a8-a1be-4e0717ef9ad6) | Oliver Gould, Alex Leong, Alejandro Pedraza | Amit Kumar | \r\n| [CNCF - Linkerd: Prototype multi-cluster service discovery and operations](https://mentorship.lfx.linuxfoundation.org/project/ce8883ce-9e32-4337-8fe0-5c51fed758e4) | Oliver Gould, Matei David | Rushikesh Butley | \r\n| [CNCF - LitmusChaos: Improve code quality and add unit tests of litmus chaos components](https://mentorship.lfx.linuxfoundation.org/project/a222f58a-08ee-4727-80c8-41c4d6f5a2a9) | Amit Kumar Das, Sayan Mondal | NamKyu Park | \r\n| [CNCF - Meshery: Distributed client-side policy evaluation in WASM and Rego](https://mentorship.lfx.linuxfoundation.org/project/7e3382be-5d82-443e-b0bc-4dcd2194705d) | Lee Calcote, Ashish Tiwari, Nikhil Ladha | Ritik Saxena | \r\n| [CNCF - Meshery: Distributed workflow engine](https://mentorship.lfx.linuxfoundation.org/project/73202d21-d4ca-4435-9a73-f326c9b3e796) | Lee Calcote, Ashish Tiwari | Azanul Haque | \r\n| [CNCF - Meshery: Multi-user cloud native playground](https://mentorship.lfx.linuxfoundation.org/project/2ee7a912-e26e-4602-9dfc-4febe3842df3) | Lee Calcote, Abhishek Kumar | Shivam Sood | \r\n| [CNCF - NATS: End-to-end example of a multiplayer game using NATS in Unity](https://mentorship.lfx.linuxfoundation.org/project/127da817-037b-4225-83a6-3a3eeea8b421) | Waldemar Quevedo | Jose de Jesus Garcia Hernandez | \r\n| [CNCF - Notary: HashiCorp Vault plugin](https://mentorship.lfx.linuxfoundation.org/project/9710c834-913d-487d-9ebf-8205cdf48ab4) | Patrick Zheng, Shiwei Zhang | Bingqi Shang | \r\n| [CNCF - OpenKruise: Bring progressive delivery to daemon workload](https://mentorship.lfx.linuxfoundation.org/project/d3a1507a-b132-4c7c-aead-dfe78fd34eb8) | Zhang Zhen, Zhang Lei | Yadan Wei | \r\n| [CNCF - OpenKruise: Support customize arbitary fields of workload subset in UnitedDeployment](https://mentorship.lfx.linuxfoundation.org/project/9e0f01ab-615f-44ed-b65b-0f1296037a48) | Zhang Zhen, Zhang Lei | 程 乐齐 | \r\n| [CNCF - ORAS: Develop .NET SDK for ORAS](https://mentorship.lfx.linuxfoundation.org/project/5d331c88-fc2d-4635-a92c-5d25fb42f47d) | Sylvia Lei, Shiwei Zhang | Samson Amaugo | \r\n| [CNCF - ORAS: Develop ORAS Website](https://mentorship.lfx.linuxfoundation.org/project/7f633ade-64f5-477c-bcbe-7b6693329c63) | Feynman Zhou, Shiwei Zhang | Asmit Malakannawar | \r\n| [CNCF - Service Mesh Performance: Adaptive Load Controller II](https://mentorship.lfx.linuxfoundation.org/project/2597fc3d-eb2c-411f-b02d-940c8347328d) | Lee Calcote, Xin Huang | Harkirat Singh | \r\n| [CNCF - TestGrid: Frontend development inside Lit Component Framework](https://mentorship.lfx.linuxfoundation.org/project/ca622980-cc8c-4f18-8a74-b9a7b4b49e3a) | Sean Chase, Michelle Shepardson | Ankur Patil | \r\n| [CNCF - Thanos: Add query observability for new promql engine](https://mentorship.lfx.linuxfoundation.org/project/a0958ddf-1fd6-4c8e-887f-adb28639a9f4) | Giedrius Statkevičius, Saswata Mukherjee | Pradyumna Krishna | \r\n| [CNCF - Thanos: Querying Apache Parquet files with PromQL](https://mentorship.lfx.linuxfoundation.org/project/a04cfbe4-4dde-4c7e-8b70-9570639b48a7) | Filip Petkovski, Prem Saraswat | Shubham Diwakar | \r\n| [CNCF - Thanos: Series Cardinality API](https://mentorship.lfx.linuxfoundation.org/project/dbce5279-d029-46f3-b117-9e9dd7f84bd6) | Ben Ye | Jatin Agarwal | \r\n| [CNCF - Vitess: Add complete parsing support for Spatial MySQL functions III](https://mentorship.lfx.linuxfoundation.org/project/d338ee93-e767-4f44-a0ea-02dbf803a55a) | Manan Gupta | Ayman Nawaz | \r\n| [CNCF - Vitess: Implement a benchmarking and load testing framework for the VReplication module](https://mentorship.lfx.linuxfoundation.org/project/b903d812-c3ff-47bf-8626-0b9274fec742) | Rohit Nayak | Yash Raj | \r\n| [CNCF - WasmEdge: A Rust library crate for mediapipe models for WasmEdge NN](https://mentorship.lfx.linuxfoundation.org/project/e4e6d486-e6df-475d-8074-a363d0361076) | Michael Yuan | Bo Yang | \r\n| [CNCF - WasmEdge: Streaming data processing with WasmEdge](https://mentorship.lfx.linuxfoundation.org/project/484542b0-84d6-43e3-b3fe-16fb2624f1b2) | Michael Yuan | Tianxiao Shen | \r\n| [CNCF - WasmEdge: Unified WasmEdge tools](https://mentorship.lfx.linuxfoundation.org/project/2ebb39fd-3497-44f3-90d7-e95b444b2bc8) | Hung-ying Tai | Huang WEN_YUAN | \r\n| [CNCF - WasmEdge: WasmEdge C++ SDK](https://mentorship.lfx.linuxfoundation.org/project/1d5d1fcd-b671-4367-b6db-13ef263aece1) | Yiying He | Subhradeep Chakraborty | \r\n\r\n#### 2022\r\n\r\n##### Term 3: September - November\r\n\r\n| Mentoring Project | Mentor(s) | Mentee |\r\n| --- | --- | --- |\r\n| [CNCF - KubeArmor: Use non-privileged containers for KubeArmor daemonset](https://mentorship.lfx.linuxfoundation.org/project/3cc962b4-cd8b-46ea-9c77-83304145fd51) | Rahul Jadhav, Ankur Kothiwal, Barun Acharya | Anurag Kumar | \r\n| [CNCF - Service Mesh Performance: Convergence of Network and Graph topologies](https://mentorship.lfx.linuxfoundation.org/project/2c4510d6-7b73-4082-a3f4-209f61767263) | Lee Calcote, Nic Jackson | Cyrine Gamoudi | \r\n| [CNCF - Kyverno: Logging in JSON plus other enhancements](https://mentorship.lfx.linuxfoundation.org/project/e5ef8032-3dd3-44c3-8746-620f4f678d60) | Jim Bugwadia | Damilola Olayinka | \r\n| [CNCF - Thanos: Receive Support for tenant-specific external labels](https://mentorship.lfx.linuxfoundation.org/project/7a13b009-0365-4910-8fbf-9088294870fd) | Bartłomiej Płotka, Filip Petkovski, Saswata Mukherjee | Ha Anh Vu | \r\n| [CNCF - Meshery: User Interface Overhaul: State Management w/Apollo/GraphQL](https://mentorship.lfx.linuxfoundation.org/project/7592d7db-5517-445b-95e8-14144c49e9b1) | Lee Calcote, Nithish Karthik | Harshit Dandriyal | \r\n| [CNCF - WasmEdge: Node API support for WasmEdge QuickJS](https://mentorship.lfx.linuxfoundation.org/project/4853174a-267d-4cd4-a62d-6e68d0c338b1) | Michael Yuan | Keqin Shentu | \r\n| [CNCF - Kyverno: Policy Exceptions](https://mentorship.lfx.linuxfoundation.org/project/0eb98f34-bfd8-4ba1-b9e5-47fc67b6fd41) | Jim Bugwadia | Lijun Yu | \r\n| [CNCF - Volcano: Implement pod filter chain for rescheduling](https://mentorship.lfx.linuxfoundation.org/project/4dc62372-c04f-432f-847c-2cddd2cf786a) | Thor-wl | Lily Pei | \r\n| [CNCF - Meshery: Integration of Open Policy Agent (OPA) and Meshery](https://mentorship.lfx.linuxfoundation.org/project/ea439582-8c63-498d-9066-dc563ce1172e) | Lee Calcote, Ashish Tiwari | Mohd Uzair | \r\n| [CNCF - Kyverno: Enable resource clean-up](https://mentorship.lfx.linuxfoundation.org/project/25e0fa72-8260-4c6f-819b-d87b865e58f2) | Shuting Zhao | Nikhil Sharma | \r\n| [CNCF - Service Mesh Performance: Adaptive Load Controller](https://mentorship.lfx.linuxfoundation.org/project/9959277e-eefc-4c88-83b6-e8c4b011d557) | Lee Calcote, Xin Huang | Nishant Mittal | \r\n| [CNCF - KubeArmor: Add BTF and BPF CO-RE Support to KubeArmor](https://mentorship.lfx.linuxfoundation.org/project/d61e1b05-2a4f-432d-b715-57c818b3e120) | Rahul Jadhav, Ankur Kothiwal, Barun Acharya | Nishanth R | \r\n| [CNCF - WasmEdge: Support serialize and deserialize in WasmEdge](https://mentorship.lfx.linuxfoundation.org/project/da1162c6-2aaf-496f-9f23-a96a3e52c277) | Hung-Ying Tai, Yi-Ying He | Omkar Acharekar | \r\n| [CNCF - WasmEdge: OpenCV SDKs for Wasm in WasmEdge](https://mentorship.lfx.linuxfoundation.org/project/17fc622c-5674-4381-b597-2f49409fda01) | Michael Yuan | Omkar Mohanty | \r\n| [CNCF - WasmEdge: Porting OpenVINO on multiple platforms for the WASI-NN proposal in WasmEdge](https://mentorship.lfx.linuxfoundation.org/project/d01efa41-87a7-4f34-adfe-63c7bab7c1ca) | Hung-Ying Tai, Yi-Ying He | Ran Piao | \r\n| [CNCF - Volcano: Pick out reasonable victim pods for rescheduling plugin](https://mentorship.lfx.linuxfoundation.org/project/9f0d56c0-9781-4912-988f-86443b0dd161) | Thor-wl | Rose Zhen | \r\n| [CNCF - TAG Network and Observability: Kubernetes ontology and subgraph module design](https://mentorship.lfx.linuxfoundation.org/project/df449a23-ac20-4ee9-8a2c-e0e5d08ba727) | Lee Calcote, Matt Young | Ruturaj Mohite | \r\n| [CNCF - Cilium: Improving Security posture of the Cilium/Hubble/Tetragon release process](https://mentorship.lfx.linuxfoundation.org/project/680e32e5-d056-46fa-a94d-4af453d4e81d) | André Martins | Sandipan Panda | \r\n| [CNCF - TAG Contributor Strategy: Mentoring Workspaces](https://mentorship.lfx.linuxfoundation.org/project/2f5582f4-6cfa-41af-88d2-2bfdd8768756) | Hippie Hacker, Caleb Woodbine | Sanskar Bhushan | \r\n| [CNCF - Thanos: Load balancing of API communication in Thanos](https://mentorship.lfx.linuxfoundation.org/project/de2d206e-32cc-45da-bc5a-1fbc7bc1f5c8) | Bartłomiej Płotka, Aditi Ahuja | Uwakmfon Utuk | \r\n| [CNCF - Devfile: Add Compose file support in the spec API II](https://mentorship.lfx.linuxfoundation.org/project/8b4aeab0-f891-4a67-a510-61393ca38520) | Mario Loriedo | Vedant Kakde | \r\n| [CNCF - Kyverno: More support for subresources](https://mentorship.lfx.linuxfoundation.org/project/9ac41a72-62f4-48e9-8630-5f9be261e2bf) | Shuting Zhao | Vyom Yadav | \r\n| [CNCF - Vitess: Improve evaluation engine](https://mentorship.lfx.linuxfoundation.org/project/29ec853c-3ab9-4457-ac91-d273fa073d49) | Vincent Marti | Weijun Huang | \r\n| [CNCF - Karmada: Enable configurable resource interpreter](https://mentorship.lfx.linuxfoundation.org/project/40b17a86-e470-4406-b7f0-731e689a39f4) | Ren Hongcai | Yukun Zhang | \r\n\r\n##### Summer\r\n\r\n| Mentoring Project | Mentor(s) | Mentee |\r\n| --- | --- | --- |\r\n| CNCF - Crossplane: Document and add automated testing for pulling packages from private registries | Daniel Mangum, Jared Watts | Parul Sahoo |\r\n| CNCF - Crossplane: Report breaking changes in CustomResourceDefinition schemas for Pull Requests | Jared Watts,\tMuvaffak Onuş | Ruhika Bulani |\r\n| CNCF - Devfile: Add Compose file support in the spec API | Mario Loriedo | Ishan Shanware |\r\n| CNCF - Devfile: Add some syntax sugar to speficy the components that are deployed at startup | Mario Loriedo | Rajib Mitra |\r\n| CNCF - Karmada: Cluster Resource modeling | Ren Hongcai | Dezhi Yu |\r\n| CNCF - Karmada: Design & Develop FederatedResourceQuota, SearchRegistry & MultiClusterIngress | Ren Hongcai, Chinmay Mehta | Shwet Khatri |\r\n| CNCF - Karmada: Develop Override policy, Resource Binding, Work Page | Ren Hongcai, Chinmay Mehta | Jun Xiang |\r\n| CNCF - Karmada: Develop Propagation policy, Settings, About Pages | Ren Hongcai, Chinmay Mehta | Rupesh Gelal |\r\n| CNCF - KubeArmor: Extend kArmor to include KubeArmor configuration | Rahul Jadhav, Ankur Kothiwal, Barun Acharya | Esther Oluwatomi Adenekan |\r\n| CNCF - KubeArmor: Support for OpenShift | Rahul Jadhav, Ankur Kothiwal, Barun Acharya | Vikas Verma |\r\n| CNCF - Kubernetes: Add GPU support to Cluster API Provider GCP (CAPG) | Richard Case, Carlos Panato, Davanum Srinivas | Aniruddha Basak |\r\n| CNCF - Kubernetes: Cluster API Provider GCP | Richard Case, Carlos Panato, Davanum Srinivas | Subhasmita Swain |\r\n| CNCF - Kyverno: CLI test schema and enhancements | Chip Zoller, Vyankatesh Kudtarkar | Prateek Nandle |\r\n| CNCF - Kyverno: Integrate Kubernetes Pod Security with Kyverno | Shuting Zhao | Hyokil Kim |\r\n| CNCF - Kyverno: Kyverno SLSA 3 | Jim Bugwadia | Zahid Ur Rehman |\r\n| CNCF - Meshery: Cloud Native Playground | Lee Calcote, Aditya Chatterjee | Debopriya Bhattacharjee |\r\n| CNCF - Meshery: Design Configurator | Lee Calcote, Ashish Tiwari | Aritra Sur |\r\n| CNCF - OpenELB: Provide the OpenELB Web UI for managing EIP and IP pool | Feynman Zhou, Changjiang Li, Yunkang Ren | Anurag Pathak |\r\n| CNCF - OpenELB: Support BGP policy in OpenELB | Feynman Zhou, Chauncey Jiang, Yunkang Ren | Amal Thundiyil |\r\n| CNCF - Service Mesh Performance: Implementation of MeshMark | Lee Calcote, Abhishek Kumar | Gaurav Chadha |\r\n| CNCF - Thanos: Implement Unified Endpoint Discovery | Bartlomiej Płotka, Saswata Mukherjee | Srushti Sapkale |\r\n| CNCF - Tremor: Hygenic error handling and validation for pipelines | Heinz Gies, Matthias Wahl | Carol Geng |\r\n| CNCF - Tremor: Pluggable logging | Darach Ennis, Ramona Łuczkiewicz | Rebecca Abli |\r\n| CNCF - Volcano: Official Website Docs Enhancement | Lei Wu, Liang Tang | Jiaojiao Wu |\r\n| CNCF - Volcano: Volcano scalability enhancement | Lei Wu, Liang Tang | Jiahuan Chen |\r\n| CNCF - WasmEdge: Create a Tokio-like async runtime in WasmEdge | Michael Yuan | Heng Zhang |\r\n| CNCF - WasmEdge: Support Durable Objects (DO) in WasmEdge | Michael Yuan | Richard Chien |\r\n\r\n##### Spring\r\n\r\n| Mentoring Project | Mentor(s) | Mentee |\r\n| --- | --- | --- |\r\n| CNCF - Chaos Mesh: Interactive Katacoda Playground for Chaos Experiment Examples | Zhiqiang Zhou | Chengwei Guo |\r\n| CNCF - Karmada: Dashboard development | Hongcai Ren | Chinmay Mehta |\r\n| CNCF - Karmada: Enhancement for controllers scalability | Hongcai Ren | WenQing Dai |\r\n| CNCF - Karmada: Refactor get command to leverage aggregated API | Hongcai Ren | Zhe Cheng |\r\n| CNCF - Karmada: Refactor the scheduler framework | Kevin Wang | Fei Gao |\r\n| CNCF - KubeArmor: Extending kubearmor-cli-tool filtering options | Rahul Jadhav | Sachin Maurya |\r\n| CNCF - KubeArmor: Using mutating webhooks for applying pod/container kubearmor annotations | Rahul Jadhav | Achref BEN SAAD |\r\n| CNCF - KubeEdge: Plans for Node Group Management | Kevin Wang | (zefeng)\tYifei Zhang |\r\n| CNCF - Kubernetes and Elekto: Elections Security Improvements | Josh Berkus | Vedant Raghuwanshi |\r\n| CNCF - Kubernetes SIG ContribEx: Creating Katacoda Scenarios To Help New Contributors | Debabrata Panigrahi | Harshita Verma |\r\n| CNCF - Kubernetes SIG ContribEx: Improvements to Kubernetes maintainers-related automation | Nikhita Raghunath | Raghav Roy |\r\n| CNCF - Kubernetes SIG Network: Documentation assessment | Nick Young | Meha Bhalodyia |\r\n| CNCF - Kubernetes: Automation of AMI build/test/publish pipelines for Cluster API Provider AWS | Sedef Savas | Abhinav Sinha |\r\n| CNCF - Kubernetes: Improving unit test coverage(CAPV) | Geetika Batra | Tushar Malik |\r\n| CNCF - Kubevela: Enhance multi-cluster observability | Jianbo Sun | Kunshuai Zhu |\r\n| CNCF - Kubevela: Management of Terraform state | ZhengXi Zhou | Nan Li |\r\n| CNCF - Kyverno: Automate Performance Testing | Shuting Zhao | Husni Alhamdani |\r\n| CNCF - Kyverno: e2e tests and CLI tests to cover sample policies | Prateek Pandey | Oshi Gupta |\r\n| CNCF - Kyverno: Extend Kyverno CLI test command for Generate policy rules | Prateek Pandey | Shubham Nazare |\r\n| CNCF - Kyverno: OpenTelemetry exporter for Kyverno | Shuting Zhao | Tathagata Paul |\r\n| CNCF - Kyverno: Security enhancements | Jim Bugwadia | Shubham Gupta |\r\n| CNCF - LitmusChaos: Develop new feature and add integration tests for LitmusCTL | Raj Babu Das | Prayag Savsani |\r\n| CNCF - Meshery: Service mesh playground (extended) | Lee Calcote | Aditya Chatterjee |\r\n| CNCF - Meshery: Workflow engine (extended) | Lee Calcote | Aadhitya Amarendiran |\r\n| CNCF - Pixie: Add support for new protocols in protocol tracer | Omid Azizi | Anubhav Choudhary |\r\n| CNCF - Service Mesh Interface: Conformance Program (extended) | Lee Calcote | Pranav Singh |\r\n| CNCF - Service Mesh Performance: Definition of MeshMark (extended) | Lee Calcote | Nikhil Sharma |\r\n| CNCF - Thanos: Run a community Thanos demo instance | Giedrius Statkevičius | Soumya Singh |\r\n| CNCF - Tremor | Heinz Gies | Prashant Mishra |\r\n| CNCF - Tremor: Database Connectors | Matthias Wahl | Sasha Pourcelot |\r\n| CNCF - Updating the kubeedge docs | Fei Xu | Nilisha Jaiswal |\r\n| CNCF - Vitess: Add complete parsing support for MySQL functions | Manan Gupta | Kushal Kumar |\r\n| CNCF - WasmEdge: Enable OpenVINO backend for WASI-NN | Hung-Ying Tai | Jianbai Ye |\r\n| CNCF - WasmEdge: Improving the performance of running miniruby | Hung-Ying Tai | yao bing |\r\n| CNCF - WasmEdge: Improving the performance of running rustpython | Hung-Ying Tai | Yiming WenJ |\r\n" }, { "path": "programs/archive/cross/README.md", "content": "# CROSS Research Experience Program\n\nThe CROSS Research Experiences program provides support for undergraduate and graduate students contributing to CROSS incubator projects. The goal of the program is to seed contributor communities and community infrastructures of existing incubator projects while teaching incubator fellows to effectively lead and delegate.\n\nCNCF is participating in the CROSS program in 2021 for the first time.\n\n## Open Source Research Experience (OSRE) Program Summer 2021\n\nYou can find more details about the program on the [CROSS website](https://cross.ucsc.edu/programs/osre2021.html).\n\n### Mentoring project\n\n- [Write Helm charts for easy deployment of the SkyhookDM, Dask , ServiceX stack on Kubernetes](https://uccross.github.io/projects#write-helm-charts-for-easy-deployment-of-the-skyhookdm-dask--servicex-stack-on-kubernetes)\n" }, { "path": "programs/archive/seasonofdocs/README.md", "content": "# Season of Docs\n\nGoogle [Season of Docs](https://developers.google.com/season-of-docs) gives technical writers an opportunity to work with open source projects.\n\n[GSoD Timeline](https://developers.google.com/season-of-docs/docs/timeline)\n\n## Post 2023\n\nBeyond the 2023 cycle, the [Mentoring WG will no longer host Google Season of Docs](https://github.com/cncf/mentoring/issues/1011) as it's not a mentorship program.\n\nHowever, **GSoD is a great program**, and CNCF projects can still participate!\n\nIf your CNCF project would like help applying to GSoD, writing up a proposal, or would like a second set of eyes on a proposal, please open a [CNCF Service Desk ticket](https://servicedesk.cncf.io) or come find us in the [#techdocs](https://cloud-native.slack.com/archives/CUJ6W5TLM) channel of the CNCF slack.\n" }, { "path": "programs/archive/seasonofdocs/previous-years/2020/README.md", "content": "---\nmaintainers:\n- caniszczyk\n- idvoretskyi\n- zacharysarah\n---\n\n# Season of Docs\n\nGoogle [Season of Docs](https://developers.google.com/season-of-docs) gives technical writers an opportunity to work with open source projects.\n\n:stop_sign: **UPDATE June 4, 2020:** Thank you to everyone who reached out for more information! We've been overwhelmed by interest, and we're no longer reviewing candidate proposals. :stop_sign:\n\n## Contact us\n\nContact the CNCF about Google Season of Docs only through [mentoring@cncf.io](mailto:mentoring@cncf.io). Do not contact project organizers through other platforms.\n\n## 2020 participation\n\nThe CNCF has been [accepted as a mentoring organization](https://opensource.googleblog.com/2020/05/season-of-docs-announces-participating.html) in Season of Docs (GSoD) 2020!\n\n### What's happening now?\n\nAll steps are based on the [GSoD 2020 timeline](https://developers.google.com/season-of-docs/docs/timeline).\n\n#### August 17 - September 13\n\nWe are in the [community bonding period](https://developers.google.com/season-of-docs/docs/timeline):\n\n> Technical writers get to know mentors, get up to speed with the open source organization, and refine their projects in collaboration with mentors\n\n## 2020 project ideas\n\n### Provide a robust collection of example Falco rules\n\n[Falco](https://falco.org/) is a runtime behavior detection and alerting engine for Linux. It enables you to write [rules](https://falco.org/docs/rules) that determine (a) the conditions under which a security notification should be produced and (b) what alert output should be provided. Examples include outputting JSON when a shell is run inside a container and logging to syslog when a sensitive file is read.\n\nBecause Falco rules require users to learn a specific syntax and a specific set of built-in functions, it's vital that those users have access to a comprehensive and use-case-specific \"library\" of example rules that they can draw upon for guidance and inspiration.\n\n#### Project goals\n\nOur goal is to enable Falco users to create more robust detection and alerting systems for their Linux workloads. To that end, the Season of Docs project would involve:\n\n- Creating a library of example rules, organized based on use case\n- Formulating a set of best practices for Falco rules\n- Assembling a \"cheatsheet\" of some of the most important or illustrative rules\n- Providing usability feedback to Falco project maintainers\n\n#### What you'll learn\n\nA writer who takes on this project stands to learn a great deal about:\n\n- The Linux operating system (filesystems, networking, processes)\n- Detection and alerting practices\n- Security concerns in a cloud native context\n\n### Update how the Kubernetes website serves API references\n\nThis is a great project for a writer interested in doc tooling: specifically, publishing API references with the [Hugo](https://gohugo.io).\n\nCurrently, the Kubernetes API references are large HTML documents generated from Swagger specs by scripts hosted outside the docs repository, then added into the website repository.\n\nThe manual build process is cumbersome and fragile. Docs are generated and imported by hand at release time (once per quarter), rather than automated (continuous integration and delivery) like the rest of the docs. The result is an unfriendly UX that isn't integrated with the rest of the site, either in UX or tooling.\n\nTo help improve API reference docs, we're applying Google's [Docsy Hugo theme](https://www.docsy.dev/about/) to the [kubernetes.io](https://kubernetes.io) website.\n\nOne of the features Docsy provides is native Swagger support. We're excited about automating our API reference generation. We need a technical writer to guide our migration from our existing process to a friendlier set of API references that are continuously generated like the rest of our docs.\n\nWe can offer strong, friendly community support and technical guidance and feedback.\nWe recognize that there are many unknowns in this process. It's OK to be scared! We're looking for one or more writers to explore and guide us in the right direction, not for perfection on the first try.\n\n#### Project goals\n\nOur goal is a helpful, consistent, integrated experience for contributing, delivering, and reading API reference docs.\n\n- Using the Docsy theme's [`swaggerui` shortcode](https://www.docsy.dev/docs/adding-content/shortcodes/#swaggerui), transform Kubernetes API Swagger specs in kubernetes/kubernetes into pages in k/website.\n\n This goal requires engaging the Kubernetes developer community and helping achieve community buy-in for a transformed toolchain. You'll get lots of support here from the docs, infrastructure, and contributor special interest groups (SIGs).\n\n- Update the contribution docs on [how to generate API references](https://kubernetes.io/docs/contribute/generate-ref-docs/), hopefully by deleting them.\n\n#### What you'll learn\n\nA writer who takes on this project will learn:\n\n- How to work with stakeholders in open source projects\n- How to render beautiful API docs\n- How to work with tools for website publishing\n\n### Improve docs for Kubernetes services\n\nKubernetes deployments support [services](https://kubernetes.io/docs/concepts/services-networking/service/): a way for other people (and other services) to interact with your application.\n\nCurrently, the documentation that [describes services conceptually](https://kubernetes.io/docs/concepts/services-networking/service/) is long, convoluted, and sometimes unfriendly for people who are learning Kubernetes. We need a writer to clarify what services are, how various Kubernetes components (like [Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress/) and [Endpoint Slices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)) interact with services, and how services [interact with applications](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/).\n\nThis project will grow your ability to explain highly technical concepts to a wide range of learners.\n\n#### Project goals\n\n- Revise and improve the conceptual overview of Kubernetes services\n- Replace outdated architecture images with more resilient tooling, for example, [mermaid](https://mermaid-js.github.io/mermaid/#/).\n- Make it easier for new learners to understand and work with Kubernetes services\n\n#### What you'll learn\n\nA writer who takes on this project will learn:\n\n- How to work with stakeholders in open source projects\n- Kubernetes services architecture\n- How to work with text-based diagrams\n\n### Document more examples for kubectl\n\nThe [`kubectl` cheat sheet](https://kubernetes.io/docs/reference/kubectl/cheatsheet/) is the most visited page on the Kubernetes website. It's clear, friendly, and provides helpful examples of how to use [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), a command line tool with a name that's [easily pronounced](https://www.youtube.com/watch?v=2wgAIvXpJqU).\n\nThe [kubectl command reference](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands) could use more examples like the cheat sheet. The Kubernetes special interest group for command line interfaces ([SIG CLI](https://github.com/kubernetes/community/tree/master/sig-cli)) will work with you to determine which examples readers need most. Your docs mentors will provide guidance on information architecture and how to work in an open source workflow.\n\n#### Project goals\n\n- Work with SIG CLI to create more kubectl examples\n- Add more kubectl examples to the kubectl cheatsheet, or:\n- Refactor kubectl docs for maximum helpfulness\n\n#### What you'll learn\n\n- How to work with stakeholders in open source projects\n- How to write effective code examples\n- Kubectl commands\n\n### Document new interfaces with SIG CLI\n\nThe Kubernetes special interest group (SIG) for command line interfaces (CLI), or [SIG CLI](https://github.com/kubernetes/community/tree/master/sig-cli), is working on new command line tools for Kubernetes. As a technical writer, you'll work with SIG CLI to document new tools, with a goal of reaching an alpha feature state for developers to test and adopt.\n\n#### Project goals\n\n- Document one or more new command line tools\n\n#### What you'll learn\n\n- How to work with stakeholders in open source projects\n- How to document a new tool\n- Bleeding edge command line tools for Kubernetes\n\n\n### Update the Kubernetes Developer Guide\n\nThe [Kubernetes Developer Guide][kdg] serves as the source of truth for contributors to the core Kubernetes project. Along with our [Contributor Guide][kcg], the Developer Guide is the primary means of onboarding new contributors. While the Contributor Guide benefits from several large iterations and improvements, and is useful for new contributors, our developer documentation has fallen behind and isn't in sync with current development practices. This causes a great deal of friction with contributors, especially new and prospective ones. \n\nWe are looking for a technical writer to improve the developer experience for all contributors. The developer documentation can be overwhelming. Its deficiencies aren’t always obvious, even to seasoned contributors. We know the developer guide is large, and aren’t expecting a full overhaul. Our goal is to make iterative improvements.\n\nWe are a friendly, passionate, and supportive [community][kcom] with experienced developers who are available to answer questions and mentor a writer.\n\n#### Project Goals\n\n- Revise, improve and update the [Kubernetes Developer Guide][kdg]\n- Establish new best practices for developers\n- Add well-organized metadata to surface the documentation on the [Kubernetes contributor site][kcs]\n\n#### What you’ll learn\n\n- How to work with a large diverse and distributed team\n- How to manage content with the [Hugo site framework][hugo]\n- How to contribute effectively to the Kubernetes project\n- How to work with open source developers of new APIs and developer features \n\n### Improve documentation of SMI & related service meshes\n\nCurrently, There is no well-structured, hands-on tutorial that walk users through various service meshes & user flows. There is a need of documentation that provides developer playground and test interactions for SMI to users. Also, we need to design and create a complete set of User Guide, Admin Guide, Install & Upgrade Guide, and so on.\n\nWe are looking for a technical writer to improve the developer experience for all contributors at SMI. Your docs mentors will provide guidance on information architecture, user-tutorial detailed guide and how to work in an open source workflow.\n\n#### Project Goals \n\n- Use the [Swaggo][swaggo] Tool to generate the API endpoint documentation\n- Use any open-source training track tool to create tutorial for Linkerd & performance management for service meshes\n- Update the contributors documentation and create an user guide for SMI\n\n#### What you'll learn\n\n- How to work with stakeholders in open-source projects\n- How to work with different open-source tools to create training tutorials\n- How to work with different service meshes and exploring service mesh architecture\n- How to create and render beautiful API docs using [swaggo/swag][swaggo]\n\n\n[swaggo]: https://github.com/swaggo/swag\n[kdg]: https://github.com/kubernetes/community/tree/master/contributors/devel\n[kcg]:https://github.com/kubernetes/community/tree/master/contributors/guide\n[kcom]: https://kubernetes.io/community/\n[kcs]: https://github.com/kubernetes-sigs/contributor-site\n[hugo]: https://gohugo.io/\n\n## Program Cycles and Archive data\n\n| Year | Term | Status | Announcement | Details |\n|------|------|----------|------------------------|----------------------|\n| 2020 | Q2 | Accepted | http://goo.gle/2WOt8xs | [Q2'2020](README.md) |\n" }, { "path": "programs/archive/seasonofdocs/previous-years/2021/README.md", "content": "---\nmaintainers:\n- caniszczyk\n- idvoretskyi\n- zacharysarah\n- celestehorgan\n---\n\n# Google Season of Docs 2021\n\nGoogle [Season of Docs](https://developers.google.com/season-of-docs) (GSoD) gives technical writers an opportunity to work with open source projects.\n\nThe CNCF is applying to participate in GSoD 2021!\n\n## 2021 Timeline\n\nGoogle Season of Docs 2021 makes numerous change to the program from previous years:\n\n1. GSoD 2021 permits only one project proposal per organization. \n\n This marks a significant change from the multiple proposals allowed in previous years. \n\n1. GSoD 2021 starts earlier and runs longer! Projects begin in April/May and run until November.\n\n1. Project proposals include a new requirement for budgeting.\n\n For more information, see the [proposal template](https://developers.google.com/season-of-docs/docs/org-proposal-template).\n\n### What's happening right now?\n\nDate | Activity\n---|---\nMarch 26, 2021 | The CNCF has submitted a [project proposal](#project-proposal) for consideration.\n\nAll steps are based on the [GSoD 2021 timeline](https://developers.google.com/season-of-docs/docs/timeline).\n\n## Project Proposal\n\nReorganize Contour’s documentation\n\n### What's the problem?\n\nThe information architecture for [Contour](https://projectcontour.io) needs help: \n\n- Headings focus on functionality rather than user tasks \n- There’s an abundance of familiar terms overloaded with new definitions\n- Information is organized haphazardly and inconsistently\n- The new user experience is confusing, with artificially high barriers to entry\n\nHelp Project Contour reorganize its documentation around a user's task flow and improve documentation navigability.\n\n### How would we measure success?\n\n- Shorter onramp time for new users\n- Increased support deflections by using docs \n- Docs provide effective 1 to many support, measured in fewer requests for 1:1 support from project team\n- Create a getting started guide for new Contour users\n- Optimize content for actual developer and user workflows\n- Provide consistent presentation: adhere to style guide, headings are consistent, and language is grammatically correct\n\n### What skills does a writer need?\n\nRequired:\n- Familiarity with Git, Markdown and Hugo \n\nNice to have:\n- Distributed systems experience: networking, containers, Kubernetes and Envoy in particular\n\n### Volunteers\n\n- @celestehorgan – Lead for technical writing mentorship; approver for work\n- @jonasrosland – Main point of contact for Contour and approver for work\n- @stevesloka, @krisss, @youngnick – Technical experts and PR approvers\n\n### Budget\n\nTotal budget: $15,000 USD\n\nWriter: $14,350\nVolunteers: 4 @ $100\nStickers: $100\nT-shirts: $150\n\n### Contact info\n\n**Before applying**, please note:\n\n- Email is the only acceptable channel for contact about GSoD. \n- Do not contact admins about GSoD via chat apps or in any other channel.\n- The program page for [Google Season of Docs](https://developers.google.com/season-of-docs/docs) is the best source of information for questions about the program, including [relevant dates](https://developers.google.com/season-of-docs/docs/timeline). \n\nTo apply, send an email to [mentoring@cncf.io](mailto:mentoring@cncf.io). Include links to examples of your technical writing portfolio and résumé/CV.\n\n## Previous years\n\n| Year | Term | Status | Announcement | Details |\n|------|------|----------|------------------------|----------------------|\n| 2020 | Q2 | Accepted | http://goo.gle/2WOt8xs | [Q2'2020](previous-years/2020/README.md) |\n" }, { "path": "programs/archive/seasonofdocs/previous-years/2023/README.md", "content": "\nAccepted CNCF projects for GSOD 2023 are :\n\n| Organization Name | GSOD Page | Budget | Accepted Project Proposal |\n|--------------------------------------------------|-----------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|\n| [Flux](https://github.com/fluxcd) | [Flux GSoD page](https://fluxcd.io/contributing/docs/google-season-of-docs-2023/) | [Flux Budget](https://fluxcd.io/contributing/docs/google-season-of-docs-2023/#project-budget) | [Improving the Flux User Onramp](https://fluxcd.io/contributing/docs/google-season-of-docs-2023/) |\n| [WasmEdge](https://github.com/WasmEdge/WasmEdge) | [WasmEdge GSoD page](https://github.com/WasmEdge/GSoD2023) | [WasmEdge Budget](https://github.com/WasmEdge/GSoD2023#project-budget) | [Reorganize the contributor guide](https://github.com/WasmEdge/GSoD2023) |\n\n" }, { "path": "programs/lfx-mentorship/2019/README.md", "content": "## 2019\n\nIn 2019, CNCF was participating in the Community Bridge, sponsoring three mentees to work on Kubernetes and CoreDNS projects during the foundations’ pilot stage.\n\nSee our blog post here on the [CNCF\nBlog](https://www.cncf.io/blog/2019/08/22/cncf-hosts-three-student-internships-for-kubernetes-and-coredns-projects-through-linux-foundations-communitybridge/).\n\n#### Completed Projects\n\n| CNCF Projects \t| Community Bridge Project \t| Mentor Name(s) \t| Mentee Name \t|\n|---------------\t|-------------------------------------------------------------\t|----------------\t|----------------------------------------------------------------------------------------------\t|\n| Kubernetes \t| Integrating kube-batch with pytorch-operator/mxnet-operator \t| Klaus Ma \t| [Suryavanshi Virendrasingh](https://www.linkedin.com/in/virendrasingh-suryavanshi-47460498/) \t|\n| Kubernetes \t| CSI Driver for Azure Disk \t| Xia Zhang \t| [Priyanshu Khandelwal](https://www.linkedin.com/in/priyanshu-khandelwal-7283b6133/) \t|\n| CoreDNS \t| Support Google Cloud DNS backend \t| Yong Tang \t| [Palash Nigam](https://www.linkedin.com/in/palash25/) \t|\n| Jaeger & Linkerd | Distributed Tracing support for Linkerd | Juraci Paixão & Thomas Grampelberg | [Tarun Pothulapati](https://www.linkedin.com/in/tpothulapati/) |" }, { "path": "programs/lfx-mentorship/2020/q1/README.md", "content": "Q1\n--\n\n*Status: completed*\n\nSee our recent post with the program results on [CNCF Blog](https://www.cncf.io/blog/2020/04/15/seven-cncf-interns-graduate-from-the-2020-linux-foundation-communitybridge-program/).\n\n### Completed Projects\n\n| CNCF Projects | Community Bridge Project | Mentor Name(s) | Mentee Name |\n|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------|-------------------------------------------------------------------------------------------------------|\n| Cortex | Storage Plugins | Goutham Veeramachaneni | [Vineeth Pothulapati](https://people.communitybridge.org/mentee/1027186d-a51f-49cc-a8d8-a8a69b9ceb55) |\n| Fluentd | Extending internal metrics support on Fluent Bit and improving Fluent Bit usability / user-experience | Eduardo Silva and Masoud Koleini | [Atibhi Agarwal](https://people.communitybridge.org/mentee/d42ae6ad-d081-4fd1-8640-6eb11f48f684) |\n| Kubernetes | Integrating the Tenant Operator with the hierarchical namespace controller | Tasha Drew and Fei Guo | [Shivani Singhal](https://people.communitybridge.org/mentee/568f73ab-4787-4a2c-a808-b4b8b878457f) |\n| Kubernetes | Kubernetes working group for CSI driver | Andy Zhang | [Ji'an Liu](https://people.communitybridge.org/mentee/ccf71791-1640-4ccb-85d1-42e2b4d84ea6) |\n| OpenTelemetry | Implementing zPages for OpenTelemetry, integrations registry, libraries compatibility tests, and OpenTelemetry C# integration with Azure, Amazon, and Google Cloud metadata services | Sergey Kanzhelev | [Harnidh Kaur](https://people.communitybridge.org/mentee/5ce1d370-18cf-43e3-a401-a3585cfba2fc) |\n| Prometheus | Various React UI improvements and filtering label values API with matchers | Krasi Georgiev and Julius Volz | [Boyko Lalov](https://people.communitybridge.org/mentee/ee458a52-fdcf-42d1-a00b-87c7e0b956f2) |\n| Thanos | Improving read write coordination for object storage and end to end benchmarking tests on demand through CI | Bartek Plotka and Giedrius Statkevičius | [Khyati Soneji](https://people.communitybridge.org/mentee/0c32f628-42e0-4794-847e-8519cd363b09) |\n\n#### Timeline\n\n-\tDecember 5 2019 - December 15 2019: applications opened;\n\t-\tMentees matching to projects/mentors;\n-\tDecember 16 2019: 5 projects/slots are announced by CNCF;\n\t-\tMentors and mentees may apply via the [Community Bridge platform](https://people.communitybridge.org/), see more details below on how to apply;\n-\tDecember 16 2019 - March 16 2020: mentees matching and coding;\n\t-\tJanuary 31 2020 - intermediate checkpoint. Mentors verify the quality of the completed tasks. First 50% of the stipend is being paid to the mentee if this stage is passed.\n-\tApril 1 (deadline extended) ~~March 20~~ 2020: results announced!\n\t-\tSecond 50% of the stipend is being paid to the mentees.\n\n### Participating projects:\n\n-\t[Kubernetes](https://people.communitybridge.org/project/2d438b9a-c539-46d0-9eed-c6ee4404c88a); [CommunityBridge Funding](https://funding.communitybridge.org/projects/2d438b9a-c539-46d0-9eed-c6ee4404c88a)\n-\t[Prometheus](https://people.communitybridge.org/project/9595fbe7-6a8d-43d4-aebb-a54d57f33fdd); [CommunityBridge Funding](https://funding.communitybridge.org/projects/9595fbe7-6a8d-43d4-aebb-a54d57f33fdd)\n-\t[Fluentd](https://people.communitybridge.org/project/d24ab158-e4e5-4042-91ad-b30ae52941d2); [CommunityBridge Funding](https://funding.communitybridge.org/projects/d24ab158-e4e5-4042-91ad-b30ae52941d2)\n-\t[CoreDNS](https://people.communitybridge.org/project/6705be57-130f-43f5-ba80-11605ffdb1f9); [CommunityBridge Funding](https://funding.communitybridge.org/projects/6705be57-130f-43f5-ba80-11605ffdb1f9)\n-\t[Cortex](https://people.communitybridge.org/project/38bb5e81-2bca-42f5-b31d-3bcd2da732d3); [CommunityBridge Funding](https://funding.communitybridge.org/projects/38bb5e81-2bca-42f5-b31d-3bcd2da732d3)\n-\t[OpenTelemetry](https://people.communitybridge.org/project/f1275c0e-7152-4e09-8d8b-6b14598afbc3); [CommunityBridge Funding](https://funding.communitybridge.org/projects/f1275c0e-7152-4e09-8d8b-6b14598afbc3)\n-\t[Thanos](https://people.communitybridge.org/project/f51284ab-f652-47b1-9819-cd4135e75c00); [CommunityBridge Funding](https://funding.communitybridge.org/projects/f51284ab-f652-47b1-9819-cd4135e75c00)\n" }, { "path": "programs/lfx-mentorship/2020/q1/project_ideas.md", "content": "### Project Ideas:\n\n### Fluentd\n\n#### Extend internal metrics support on Fluent Bit\n\n-\tDescription: [Fluent Bit](https://fluentbit.io) already collect internal metrics from the data pipeline, these metrics are exposed through a HTTP end-point which already provides a Prometheus format for remote consumption. On this project, the student will work in the following tasks:\n\t-\tDig into the internal metrics design, improve the API so other core components can register their own metrics.\n\t-\tImplement a new mechanism to let Fluent Bit ship metrics through current available output plugins.\n\t-\tMinor tasks associated with project metrics, performance benchmarks and documentation.\n-\tRecommended Skills: C, Linux user-space development and basics of system calls\n-\tMentor(s): Eduardo Silva @edsiper\n-\tIssue: https://github.com/fluent/fluent-bit/issues/1811\n\n#### Improve Fluent Bit usability / user-experience\n\n-\tDescription: Nowadays [Fluent Bit](https://fluentbit.io) is a very advanced tool for log processing, so there is some intrinsic complexity and from a usability perspective (end user), it is very easy to make mistakes from a configuration perspective. The team is working on different improvement areas to reduce the number of mistakes and reduce the learning curve, the student aims to help with all these areas. Some related tasks:\n\t-\tHelp to migrate plugins to the new Config Maps mechanism [FLB #1672](https://github.com/fluent/fluent-bit/issues/1672)\n\t-\tImprove error messages handling\n\t-\tExtend internal logging mechanism to support a structure and messages routable mode.\n\t-\tGeneral tasks associated with core API usage and documentation.\n-\tRecommended Skills: C, Linux user-space development ands basics of system calls\n-\tMentor(s): Eduardo Silva @edsiper\n-\tIssue: https://github.com/fluent/fluent-bit/issues/1812\n\n### Kubernetes\n\n#### Kubernetes working group for multi-tenancy: HNC + Tenant Operator\n\n-\tDescription: Integrate the Tenant Operator with the Hierarchical Namespace Controller, per [this design document](https://docs.google.com/document/d/1QAWtYdRZGseSar_KgyfiIisL7JTGMHCfqB_Legfa39w/edit#heading=h.7wst4safj8dx)\n-\tRecommended Skills: golang, some familiarity with the Hierarchical Namespace Controller\n-\tMentor(s): Adrian Ludwin @aludwin, Tasha Drew @tashimi\n-\tIssue: https://github.com/kubernetes-sigs/multi-tenancy/issues/300\n\n#### Kubernetes working group for CSI driver\n\n-\tDescription: Container Storage Interface (CSI) is a standard for exposing storage systems to containerized workloads on Kubernetes without ever having to touch the core Kubernetes code. The idea is to implement a few new CSI features and also e2e tests to cover those features, e.g. inline volume support, volume expansion, windows support, monitoring, etc.\n-\tRecommended Skills: golang, Kubernetes\n-\tMentor(s): Andy Zhang @andyzhangx\n-\tIssue:\n\t-\thttps://github.com/kubernetes-sigs/azuredisk-csi-driver/issues\n\t-\thttps://github.com/kubernetes-sigs/blobfuse-csi-driver/issues\n\n### Prometheus\n\n#### Benchmarks for TSDB\n\n-\tDescription: The TSDB module used in Prometheus doesn’t have proper benchmarks yet, which means we cannot see the potential impact of the changes we are introducing. The idea is to build some automated benchmarking which can be added to the CI pipeline.\n-\tRecommended Skills: CI, Golang, K8s\n-\tRelevant Issues: https://github.com/prometheus/tsdb/issues/235\n-\tPotential Mentors: Krasi Georgiev @krasi-georgiev\n\n#### PromQL/Rule formatting tool\n\n-\tDescription: Like \"gofmt\" for Go, we ought to have a \"promfmt\" for Prometheus since we have a syntax tree. The idea being that the system produces uniform style that minimizes deviation and learning curve. Care should be taken to preserve comments.\n-\tRecommended Skills: Golang\n-\tRelevant Issues: https://github.com/prometheus/prometheus/issues/21\n-\tPotential Mentors: Ganesh Vernekar @codesome\n\n#### Persist retroactive rule evaluations\n\n-\tDescription: We can already reevaluate queries on old data, but we should be able to persist that for a certain window from (Oldest, Now).\n-\tRecommended Skills: Golang\n-\tRelevant Issues: https://github.com/prometheus/prometheus/issues/11\n-\tPotential Mentors: Ganesh Vernekar @codesome, Goutham Veeramachaneni @gouthamve\n\n#### e2e test SD mechanisms\n\n-\tDescription: We're not really excellent in the correctness / bug-free-ness department yet, partially because certain key components either lack tests or you'd have to run them in a real-world scenario for a while to discover certain bugs. I'm especially looking at our under-tested service discovery mechanisms here that require e.g. a Zookeeper or Consul as a dependency to test them for real. It'd be cool to have a test environment that runs a Prometheus release end-to-end (with different SD mechanisms) for a while and checks the results (evaluated expressions, alerts, etc.) for sanity.\n-\tRecommended Skills: Golang\n-\tRelevant Issues: https://github.com/prometheus/prometheus/issues/2935\n-\tPotential Mentors: Gouthamve @gouthamve\n\n#### Various React UI improvements and filtering label values API with matchers.\n\n-\tDescription: Now that Prometheus has a brand new experimental React UI it would need various bug fixes and improvements. It is still missing a few features from the old UI, and as an addition to this we want to add support for showing multiple expressions in one graph.\n-\tRecommended Skills: React, Golang\n-\tRelevant Issues: https://github.com/prometheus/prometheus/issues/6178, https://github.com/prometheus/prometheus/issues/1237, https://github.com/prometheus/prometheus/issues/39\n-\tPotential Mentors: Krasi Georgiev @krasi-georgiev and Julius Volz @juliusv\n\n### Cortex\n\n#### Storage Plugins\n\n-\tDescription: So there are serveral open issues to support new storage types. As adoption increases, there will be new requests coming up. Further, we're re-using cortex in Loki a fair bit and are finding that the storage trade-offs in Loki and Cortex are different and seeing some implementation details for Loki leaking into Cortex. We need a good way to come up with a plugin system that lets the new storage codes live outside the cortex tree. One of the first obvious candidate is the grpc-plugin system from Hashicorp, that has been used to do similar storage plugins for Jaeger.\n-\tRecommended Skills: Golang\n-\tRelevant Issues: https://github.com/cortexproject/cortex/issues/1681\n-\tPotential Mentors: Gouthamve @gouthamve\n\n### OpenTelemetry\n\n#### Implement zPages for OpenTelemetry\n\n-\tDescription: zPages is a great practice many organizations and SRE uses for the last line of defence while troubleshooting application issues. zPages aggregate telemetry in-process in a memory buffer and allow to query this informaiton directly from the app. It will be great to design and implement zPages for the language of your choice. I set C# as a language I maintain, but will be happy to mentor in other languages as well.\n-\tRecommended Skills: C#, basic html/css\n-\tMentor(s): Sergey Kanzhelev (@SergeyKanzhelev)\n-\tIssue: https://github.com/open-telemetry/opentelemetry-dotnet/issues/81\n\n#### OpenTelemetry integrations registry\n\n-\tDescription: The goal of OpenTelemetry is to make robust, portable telemetry a built-in feature of cloud-native software. One step towards this goal is tracking of all integrations implemented or desired. Similar to https://opentracing.io/registry/, but also include automatic status updates and versions.\n-\tRecommended Skills: Go, html/css\n-\tMentor(s): Sergey Kanzhelev (@SergeyKanzhelev)\n-\tIssue: https://github.com/open-telemetry/opentelemetry.io/issues/59\n\n#### OpenTelemetry libraries compatibility tests\n\n-\tDescription: OpenTelemetry project has a unique challange - it implements similar patterns for data collection on many languages. Building a framework and a set of libraries compatibility tests is a great way to ensure the best expirience for end users. Need to know one or more programming languages. Specified C# which I maintain, but happy to mentor on other languages.\n-\tRecommended Skills: C#\n-\tMentor(s): Sergey Kanzhelev (@SergeyKanzhelev)\n-\tIssue: https://github.com/open-telemetry/opentelemetry.io/issues/59\n\n#### OpenTelemetry C# integration with Azure, Amazon, and Google Cloud metadata services\n\n-\tDescription: OpenTelemetry C# SDK can be used on any cloud. All major clouds provide a similar mechanisms to obtain deployment instance information. The task is to obtain those properties from the service like[this](https://docs.microsoft.com/azure/virtual-machines/windows/instance-metadata-service) and associate resulting properties with the telemetry reported by SDK.\n-\tRecommended Skills: C#\n-\tMentor(s): Sergey Kanzhelev (@SergeyKanzhelev)\n\n### Thanos\n\n#### Improved Read Write Coordination for Object Storage\n\n-\tDescription: Thanos is a distributed system that runs different operations on object storage. Components that read from the bucket synchronize files from storage lazilly, implying eventually consistency of file uploads. Additionally, some object storage systems have some form of eventual consistency on a different level, e.g \"read after update\" in AWS or [\"list after write\" for OpenStack Swift](https://docs.openstack.org/swift/latest/overview_architecture.html#updaters). With growing adoption, we need to make sure the Thanos project is fully resilient to those cases, which is why we designed [read write coordination](https://thanos.io/proposals/201901-read-write-operations-bucket.md/). We are happy to mentor candidates to implement this task, which will greatly help the Thanos community and increase the candidate's knowledge in Go and distributed systems.\n-\tRecommended Skills: Golang\n-\tRelevant Issues: https://thanos.io/proposals/201901-read-write-operations-bucket.md/ https://github.com/thanos-io/thanos/issues/1528\n-\tPotential Mentors: Bartek Plotka (@bwplotka)\n\n#### End to End Benchmarking Tests on Demand through CI\n\n-\tDescription: In order to increase confidence in Thanos' performance across releases and major changes, we would like to introduce a way to run reproducible e2e benchmark tests, ideally from the PR and with the use of Kubernetes. This work involves setting up Thanos scenarios and load generators that will run benchmarks for a certain period of time and output resource usage for the given Thanos version.\n-\tRecommended Skills: Golang, Kubernetes\n-\tRelevant Issues: https://github.com/thanos-io/thanos/issues/1707\n-\tPotential Mentors: Giedrius Statkevičius (@GiedriusS)\n\n### CoreDNS\n\n#### Autoscaling CoreDNS Nodes on Kubernetes Clusters Through Exposed Metrics\n\n-\tDescription: [CoreDNS](https://github.com/coredns/coredns) is Kubernetes' default DNS server for service discovery. As service discovery with DNS is the (often overlooked) critical piece for clusters, it is important to maintain enough capacity for serving the cluster-wide service discovery. CoreDNS already have a `metrics` plugin with metrics information exposed. In this project, the student will work on the following tasks:\n\t-\tWrite metrics scraping method to extract the metrics from exposed CoreDNS metrics plugin.\n\t-\tDevelop a method in transforming collected metrics into desired capacity for CoreDNS nodes.\n\t-\tImplement a routine to interact with Kubernetes API to autoscaling CoreDNS node with designed capacity.\n-\tBonus Task: Use machine learning algorithm for transforming metrics to above mentioned designed capacity. We will provide a start algorithm to help student getting started with machine learning, if student is willing to take this bonus task.\n-\tRecommended Skills: Golang and DNS for this project, basic machine learning for bonus task.\n-\tMentor(s): Yong Tang @yongtang\n-\tIssue: https://github.com/coredns/coredns/issues/3541\n" }, { "path": "programs/lfx-mentorship/2020/q2/README.md", "content": "# 2020\n\n## Q2\n\n_Status: completed_\n\n### Timeline\n\n- April 16 - May 1: project applications opened\n - projects are invited to submit their proposals to https://github.com/cncf/mentoring/blob/master/communitybridge/2020/q2/project_ideas.md\n- May 4: selected projects/slots are announced by CNCF;\n- May 5 - May 18: mentees applications opened, projects are selecting mentees;\n- May 20 - mentees are selected by the mentors, coding starts;\n- June 22 - June 28: 1st evaluation;\n - Mentors verify the quality of the completed tasks;\n - First 50% of the stipend is being paid to the mentee if this stage is passed;\n- July 27 - 2nd (final) evaluation checkpoint;\n - Coding ends;\n - The other 50% of the stipend is being paid to the mentees;\n- August 3: results announced!\n\n### Participating Projects\n\n- [Argo](https://people.communitybridge.org/project/5d5d4357-f340-47c9-9ff2-7b0536291576)\n- [CoreDNS](https://people.communitybridge.org/project/6705be57-130f-43f5-ba80-11605ffdb1f9)\n- [Envoy](https://people.communitybridge.org/project/872be524-7465-4639-be88-1b451c581826)\n- [Fluentd](https://people.communitybridge.org/project/d24ab158-e4e5-4042-91ad-b30ae52941d2)\n- [KubeEdge](https://people.communitybridge.org/project/1b931913-44a4-43a7-92ed-d7b2089060b1)\n- [KubeVirt](https://people.communitybridge.org/project/de7ca1c2-2d22-4919-bef8-6cca50a54426)\n- [Kubernetes](https://people.communitybridge.org/project/2d438b9a-c539-46d0-9eed-c6ee4404c88a)\n- [Linkerd](https://people.communitybridge.org/project/65742dc0-7217-4c4a-a609-f5f0fcde5c0a)\n- [OPA](https://people.communitybridge.org/project/12a9270f-8673-4acb-92ec-fd539fc2b567)\n- [OpenEBS](https://people.communitybridge.org/project/40a443f9-cb78-49e6-96ad-26616acb2113)\n- [Prometheus](https://people.communitybridge.org/project/9595fbe7-6a8d-43d4-aebb-a54d57f33fdd)\n- [Service Mesh Interface](https://people.communitybridge.org/project/359dda52-7fb7-4fa8-82cd-a27216757a57)\n- [Thanos](https://people.communitybridge.org/project/f51284ab-f652-47b1-9819-cd4135e75c00)\n- [TiKV](https://people.communitybridge.org/project/c6a0326c-b053-41a3-9bf2-1e7e78481ca6)\n\n### Selected Projects\n\nSelected projects are listed [here](./selected_projects.md)\n\n### Project Ideas\n\nThe proposed project ideas are listed [here](./project_ideas.md).\n" }, { "path": "programs/lfx-mentorship/2020/q2/project_ideas.md", "content": "## Projects ideas\n\nProject maintainers and mentors, please submit the ideas below (under the Proposed Project Ideas section) section using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n### Template\n\n```\n#### CNCF Project Name\n##### Title\n\n-\tDescription:\n-\tRecommended Skills:\n-\tMentor(s):\n-\tUpstream Issue (URL):\n```\n\n### Sample:\n\n#### Prometheus\n##### Refactor the APIs for better readability and less maintenance overhead\n\n- Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n-\tRecommended Skills: golang\n-\tMentor(s): Krasi Georgiev (@krasi-georgiev)\n-\tIssue: https://github.com/prometheus/prometheus/issues/3416\n\n### Proposed Project ideas\n\n### Kubernetes\n\n#### Kubernetes working group for CSI driver\n\n-\tDescription: Container Storage Interface (CSI) is a standard for exposing storage systems to containerized workloads on Kubernetes. The idea is to implement a few new CSI features and also e2e tests to cover those features, e.g. volume expansion, Windows support, inline volume support etc. Also, there are requirements to rewrite some flexvolume drivers(e.g. [smb driver](https://github.com/Azure/kubernetes-volume-drivers/tree/master/flexvolume/smb)) to CSI driver.\n-\tRecommended Skills: golang, Kubernetes\n-\tMentor(s): Andy Zhang @andyzhangx\n-\tIssue:\n\t-\thttps://github.com/kubernetes-sigs/azurefile-csi-driver/issues\n\t-\thttps://github.com/Azure/kubernetes-volume-drivers/issues/48\n\n#### Kubernetes Multi-Tenancy Working Group: Multi-Tenancy Benchmarks\n\n-\tDescription: The Kubernetes Multi-Tenancy Working Group is chartered with exploring and defining multi-tenancy models for Kubernetes. An overview of working group activities can be found in this Kubernetes Multi-Tenancy Working Group . The Multitenancy Benchmarks effort focuses on measuring and validating the desired behaviors for multitenancy. Part of this effort is to automate behavioral and configuration checks on existing clusters, which will be the focus of this project. This automated test suit will help all Kubernetes users validate whether their clusters are setup correctly for multi-tenancy.\n-\tRecommended Skills: Go, Kubernetes\n-\tMentor(s):Tasha Drew (@tashimi), Ryan Bezdicek (@rjbez17), Jim Bugwadia (@JimBugwadia)\n-\tIssue: https://github.com/kubernetes-sigs/multi-tenancy/issues/551\n\n#### Kubernetes Policy Working Group: Policy Violation CRD\n\n- Description: The Kubernetes Policy Working Group is providing an overall architecture that describes both the current policy related implementations as well as future policy related proposals in Kubernetes. As part of this effort, the group is proposing a Kubernetes Custom Resources Definition (CRD) for policy violations and writing adapters to convert from various Kubernetes policy management tools such as OPA, Falco, Kyverno, kube-bench, etc. to report policy violations in a common format. The Policy Violation CRD can then be used by the Dashboard to show violations.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Issue: https://github.com/kubernetes-sigs/wg-policy-prototypes/issues/3\n\n\n### Argo\n\n#### Kruise Deployment Wizard\n\n-\tDescription: The Kruise Wizard is a tool that streamlines the creation of initial deployment manifests for complex Kubernetes applications. Development and traditional Ops teams can now use a wizard-like tool to define application deployments and generate a set of Kustomized based YAML files. These files are committed to a Git repository allowing seamless GitOps adoption. Kustomized based Kubernetes deployments can then be deployed utilizing a variety of CD tools as in our case: ArgoCD.\n-\tRecommended Skills: golang, kubernetes, argoCD, Kustomize\n-\tMentor(s): Ken Owens (@kenowens12)\n-\tUpstream Issue (URL):https://github.com/Mastercard/Kruise-API\n\n\n### OPA\n\n#### OPA Go APIs\n\n-\tDescription: We embed OPA in our applications to implement policy as code. We found that current OPA Go APIs are not designed for API calls. It is mainly for standalone CLI. For example, policy input has to be file via file path. In APIs, policy input could be either string or bytes. We have to write policy data into temp file in order to call OPA APIs. In addition to OPA APIs, we also want to build policy repository to support policy agent\n-\tRecommended Skills: golang, OPA\n-\tMentor(s): Jingnan Zhou (@jingnanzhou)\n-\tUpstream Issue (URL): https://github.com/open-policy-agent/opa/issues/2336\n\n#### OPA - MongoDB query translator\n\n- Description: MongoDB is a general-purpose, document-based, distributed database with a rich query language. OPA features a high-level declarative language called `Rego` purpose-built for expressing policies over complex hierarchical data structures. OPA is often used to enforce policies over incoming API requests, but using OPA's \"partial evaluation\" feature it is also possible to enforce policies when data is accessed inside of document-oriented databases like MongoDB. In this model, callers query OPA to obtain a set of conditions to apply to the database query and then rewrite the database query accordingly. There are existing projects that translate \"partial evaluation\" results to SQL and Elasticsearch. This project would involve designing and implementing a Rego to MongoDB query translator that supports basic relational operations like ==, !=, >, <, etc. This project would hugely benefit the community to perform authorization and data-filtering in MongoDB using OPA.\n- Recommended Skills: Go/Python, MongoDB (not required, but nice to have)\n- Mentor(s): Ash Narkar (@ashutosh-narkar)\n- Issue: https://github.com/open-policy-agent/opa/issues/2059\n\n### Thanos\n\n#### Thanos Query Frontend\n\n- Description: As per [proposal](https://thanos.io/proposals/202004_embedd_cortex_frontend.md/) we plan to embedd Cortex query frontend as new Thanos command. With this project you will have opportunity to work in\nboth Cortex and Thanos codebase to improve both worlds while creating shiny new command in Thanos project for this microservice proxy.\n- Recommended Skills: go, distributed systems, caching\n- Mentor(s): Bartlomiej Plotka (@bwplotka)\n- Issue: https://github.com/thanos-io/thanos/issues/2454\n\n#### Versioned Website Docs\n\n- Description: The Thanos website includes a documentation area that contains per-component docs and configuration built by rendering the markdown files from the tip of master of the Thanos repository. This frequently causes confusion for users, as breaking changes are often merged into master that conflict with the APIs of previous releases. To solve this user-facing issue, we would like to allow the website to show a different set of docs for every Thanos release. This project will involve designing a documentation structure and version picker in the website to select different versions of documents. We will also need to design a workflow for managing docs that integrates with our Git workflow, i.e. updating corresponding docs on pull requests, cherry-picks, etc.\n- Recommended Skills: go, HTML, JavaScript, CSS\n- Mentor(s): Lucas Servén Marín (@squat), Bartlomiej Plotka (@bwplotka)\n- Issue: https://github.com/thanos-io/thanos/issues/2488\n\n#### Per Request Query Tracking and Limiting\n\n- Description: Thanos is at the very high-level: durable and cheap database capable of storing a very large amount of metric data. This means that querying that data can be expensive. Imagine someone queries years of data for millions of series. No matter how fast or efficient our indexing is, even the amount of data being passed through the network can get expensive. This is why users should have control, potentially someday per tenant to tell what query was performed, for how long and how much data it was using, and what happened or error. Users should also be able to limit such large queries.\nRecommended Skills: go, distributed systems, Linux\n- Mentor(s): Bartek Plotka (@bwplotka), Kemal Akkoyun (@kakkoyun)\n- Issue: https://github.com/thanos-io/thanos/issues/1706 and https://github.com/thanos-io/thanos/issues/2527\n\n### Complete Katacoda tutorials\n\n- Description: This is a great project for a writer with some passion for Docker and Kubernetes, interested in doing interactive docs: specifically learning to build [Katacoda Course](https://katacoda.com/scenario-examples/scenarios/create-course). Currently, we have a single [Katacoda](https://katacoda.com/bwplotka/courses/thanos/1-globalview) tutorial, which helps Thanos users to start up quickly and understand the concepts. To help improve the user experience further we have planned five more tutorials. The Katacoda tutorials are written in YAML format and don't require a lot of custom tooling. We have a moderate amount of docs on our website [thanos.io](https://thanos.io/), which should help you to get started quickly. Also, there are many youtube videos explaining the concepts. We can offer friendly community support and technical guidance and feedback.\nWe're looking for one contributor to explore interactive tutorials and learn some technical concepts along the way. We are definitely not looking for perfection on the first try. Writing interactive tutorials: \n * Intro: Downsampling and unlimited metric retention for Prometheus\n * Intro: Global and meta alerts with Thanos\n * Advanced: Connecting remote Prometheuses to Thanos using simple Envoy setup.\n * Advanced: Using Prometheus remote write to stream metrics to Thanos\n * Advanced: Query low tail latency with low cost: Introducing caching to Thanos\nRecommended Skills: Distributed systems, Linux, Kubernetes, Docker\n- Mentor(s): Bartek Plotka (@bwplotka), Povilas Versockas (@povilasv)\n- Issue: https://github.com/thanos-io/thanos/issues/2041\n\n### Prometheus\n\n#### Persist Retroactive Rule Reevaluations\n\n- Description: Right now one of the biggest issues with recording rules is that data is only available since the rule was created. Which means any dashboards that use the recording rule will not have data prior to the recording rules create time. We can already reevaluate queries on old data, but we should be able to persist that for a certain window from [Oldest, Now).\n- Recommended Skills: Golang\n- Mentor(s): Bartlomiej Plotka (@bwplotka), Callum Styan (@cstyan)\n- Issue: https://github.com/prometheus/prometheus/issues/11.\n\n#### Remote Write WAL Pointer + Other Improvements\n\n- Description: Remote write has gone through a rewrite in the last year, but there are still open improvements and feature additions that can be explored. For example, because remote write now sends data via Prometheus' WAL, the pointer for each remote write queue into the WAL should be persisted across restarts. The addition of new record types, or a new remote write specific WAL, so that new data not currently part of the WAL can be remote written coulda also be investigated.\n- Recommended Skills: Golang, database and dist. systems nice to have.\n- Mentor(s): Callum Styan (@cstyan), Chris Marchbanks (@csmarchbanks)\n- Issue: https://github.com/prometheus/prometheus/issues/6333\n\n### Envoy\n\n#### Enrich Envoy stats with header size histogram\n\n- Description: Currently there is lack of visibility into size of request headers that are proxied through Envoy. Adding corresponding histogram would increase observability for Envoy based systems.\n- Recommended Skills: C++\n- Mentor(s): Kateryna Nezdolii (@nezdolik)\n- Issue: https://github.com/envoyproxy/envoy/issues/10308.\n\n### Service Mesh Interface\n\n#### SMI Conformance Testing\n\n- Description: Ensure that a service mesh is properly configured and that its behavior conforms to official SMI specifications. Conformance consists of both capabilities and compliance status as outlined in the [design specification](https://docs.google.com/document/d/1HL8Sk7NSLLj-9PRqoHYVIGyU6fZxUQFotrxbmfFtjwc/edit).\n- Recommended Skills**: Golang (nice to have: Kubernetes, Service Mesh)\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Vinayak Shinde ([@vinushnd](https://twitter.com/vinushnd))\n- Issue: [https://github.com/servicemeshinterface/smi-spec/issues/70](https://github.com/servicemeshinterface/smi-spec/issues/70)\n\n### TiKV\n\n#### Full Chunk-based Computing\n\n- Description: Currently, TiKV uses a simple but inefficient memory layout in computing framework. Using Chunk, a column-based memory layout, could improve memory locality and reduce memory allocation during expression evaluation.\n- Recommended Skills: Rust, Database\n- Mentor(s): Tianyi Zhuang (@TennyZhuang), breeswish (@breeswish)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/7724\n\n\n### OpenEBS\n\n#### A easy to use command-line interface (CLI) for OpenEBS.\n\n- Description: OpenEBS is completely Kubernetes native and is implemented using microservices. OpenEBS can be installed via kubectl or helm chart and managed via custom resources. To improve the usability of OpenEBS, the proposal is to have a easy to use OpenEBS CLI (similar to `kubectl`) to perform operations like:\n - install => Install OpenEBS\n - upgrade => Upgrade OpenEBS components\n - status => Print the readiness of various components, verify prerequisites are met to run openebs pools and volumes.\n - version => Print the OpenEBS version and associated images\n - describe => Describe OpenEBS resources like pools and volumes.\n - create => Create OpenEBS resources\n - delete => Delete OpenEBS resources\n\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Kiran Mova (@kmova)\n- Related Issues:\n - https://github.com/openebs/openebs/issues/2946\n - https://github.com/openebs/openebs/issues/1248\n - https://github.com/openebs/openebs/issues/290\n\n#### Multiarch support for OpenEBS Docker images\n\n- Description: OpenEBS Supports automated builds for amd64 and arm64. It will be good to make use of the \"docker manifest\" command to link different arch images into a single docker repository. This should allow kubernetes nodes to pull in the required container images.\n- Recommended Skills: Docker, Shell, Makefile\n- Mentor(s): Kiran Mova (@kmova)\n- Related Issues:\n - https://github.com/openebs/openebs/issues/3023\n\n#### New storage backend using raw disk images\n\n- Description: OpenEBS Dynamic Local PV with Hostpath are great for use cases with low latency requirements and running on nodes with few attached drives or block devices. Using bare hostpath has the limitation of enforcing the capacity limits requested by PVC. The proposal is to implement a new type of storage, backed by a raw disk image on the host, that is mounted inside the pod. The storage backend should:\n - have near-zero performance overhead, compared to using local disks\n - be thin-provisioned\n - be able to enforce storage size limits\n - be able to expose volume metrics\n\n- Recommended Skills: Kubernetes, Linux, Python, Go\n- Mentor(s): Kiran Mova (@kmova)\n- Related Issues:\n - https://github.com/openebs/openebs/issues/2871\n\n\n### KubeEdge\n\n#### Support metrics-server in cloud\n\n- Description: Now we have integrated cadvisor in edge, and it also needs to integrate metrics-server in the cloud to collect monitoring data of edge nodes.\n- Recommended Skills: Golang\n- Mentor(s): Kevin Wang (@kevin-wangzefeng)\n- Related Issues:\n - https://github.com/kubeedge/kubeedge/issues/1561\n\n#### Add certificate rotation for edge node\n\n- Description: At present, the edge nodes of KubeEdge only apply for certificates when they first started. And we need to automatically generate a new key and request a new certificate from the cloudcore periodically.\n- Recommended Skills: Golang\n- Mentor(s): Fisher Xu (@fisherxu)\n- Related Issues:\n - https://github.com/kubeedge/kubeedge/issues/1630\n\n\n### Fluentd\n##### Fluent Bit Monitoring: Web UI\n\n- Description: Fluent Bit exposes internal metrics from the data processing pipeline through its HTTP interface. This project aims to build a Web UI to show the components of the data pipeline and its continuous metrics with dashboards and further info. The metrics are exposed in JSON format and should be scrapped by the UI. The UI can be deployable on any HTTP server without the need for NodeJS.\n\n\n Please refer to the Upstream Issue link for more details and candidate requirements.\n-\tRecommended Skills: Javascript, VueJS, CSS, HTML & general design skills\n-\tMentor(s): Eduardo Silva (@edsiper)\n-\tUpstream Issue (URL): https://github.com/fluent/fluent-bit/issues/2147\n\n\n### CoreDNS\n\n##### External health check and orchestration of CoreDNS in Kubernetes clusters**\n\n- Description: CoreDNS is the cluster DNS server for Kubernetes and is very much critical for the overall health of the Kubernetes cluster. It is very important to monitoring the health of CoreDNS itself and restarting or repairing any CoreDNS pods that are not behaving correctly. While CoreDNS exposes a health check itself, the health check is not UDP (DNS) based. The existing health check is also launched locally which could be very much different when accessed by other pods remotely.\n This project intends to build an application that checks CoreDNS health through UDP (DNS) externally, and, restart CoreDNS pods by interacting with Kubernetes API through golang. This is an important project that will greatly improve the overall health of Kubernetes clusters through automation.\n- Recommended Skills: Go, DNS, Kubernetes\n- Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)\n- Implementation: The deliverable of this project is a golang program that could be deployed in a Kubernetes cluster independently while at the same time, monitoring CoreDNS pods in the same cluster and interacting Kubernetes API (server) to restart CoreDNS pods as needed.\n- Related Issues:\n - https://github.com/coredns/rfc/issues/7\n\n\n### Linkerd\n\n#### Egress Metrics\n\n-\tDescription: Linkerd provides rich metrics for traffic inside the mesh. As most external services utilize HTTPS, it is unable to provide metrics today. This project intends to provide visibility into the traffic that is leaving clusters and surface metrics for that traffic.\n-\tRecommended Skills: golang, Kubernetes\n-\tMentor(s): Thomas Rampelberg (@grampelberg)\n-\tIssue:\n\t- https://github.com/linkerd/linkerd2/issues/3190\n\n#### Service Topologies\n\n- Description: It is valuable to have metadata related to the topology of a cluster when making load balancing decisions. This metadata can be used to control egress costs between regions or even make advanced routing decisions in multicluster situations. As part of Kubernetes 1.17, [service topology](https://kubernetes.io/docs/concepts/services-networking/service-topology/) landed. This provides extra metadata as part of endpoints for a service to control weighting. Imagine transparently failing over to nodes running in a different zone if the pods locally are no longer running. Linkerd should implement support for this functionality.\n- Recommended Skills: golang, Kubernetes, rust, Tokio\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/4325\n\n#### PCAP-NG Export\n\n- Description: It is difficult to debug what is happening to the network traffic for workloads on Kubernetes. Linkerd provides tap and stat to provide some glimpses into what's happening. Many times, this is enough. Unfortunately, when low level problems and protocol issues crop up, the existing tools are not enough. This causes users to inject the debug container and tcpdump traffic on a pod by pod basis. This project will add PCAP-NG as an export format for tap. This can then be dumped locally or forwarded to Wireshark for analysis and debugging.\n- Recommended Skills: golang, Kubernetes, rust, Tokio\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/4326\n\n#### Granular RBAC for Metrics\n\n- Description: Kubernetes is a multitenant system, many users can interact without seeing what others are working with. Today, Linkerd runs a single control plane per cluster. This results in the metrics collected being stored in a single backend (Prometheus). In some high security environments, this means that the users of the cluster are unable to get the benefit of Linkerd's rich metrics. This project will introduce Kubernetes based, granular RBAC so that cluster operators can control what end users are able to view.\n- Recommended Skills: golang, Kubernetes, Prometheus\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/3312\n\n#### Kafka Proxy Codec\n\n- Description: HTTP based traffic is only one type of modern applications. Many use message queues such as Kafka. Getting the metrics for consumers/producers/messages are just as critical to application health as requests and responses in HTTP. This project will implement a Kafka codec that allows the Linkerd proxy to introspect Kafka's protocol and provide metrics for the communications between consumers and producers. This should show up as a CLI command, dashboard and visualization of the topology between message consumers and HTTP actors.\n- Recommended Skills: golang, Kubernetes, rust, Tokio, Kafka\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/2214\n\n#### JWT Authentication\n\n- Description: Linkerd implements service-service authentication today via. mTLS. This does not yet extend to user based authentication. This project will implement JWT authentication to provide applications using the service mesh a method for implementing authorization on a per-user basis.\n- Recommended Skills: golang, Kubernetes, rust, Tokio\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/3704\n\n#### Network Diagnostics\n\n- Description: It can be challenging to diagnose why things aren't working in a remote cluster. Is there a connectivity issue? What happens when a specific request is sent to a service? How do I work with the data that comes back? Linkerd should make this kind of interaction with a cluster's traffic easy and seamless. This project introduces a new command to the CLI: `exec`. This will wire up the networking locally for a user where local binaries (such as curl or ping) can interact with a Kubernetes cluster natively. It will use local binaries and produce local output to allow users to use their local tools and files to diagnose what's going on with their cluster.\n- Recommended Skills: golang, Kubernetes\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/4327\n\n### KubeVirt\n\n#### Kernel boot\n\n-\tDescription: KubeVirt allows to boot from regular (virtual) disks, an alternative booting method is to directly provide a kernel, initrd, and cmdline to a VM for booting. Such a feature is generally useful for many unikernel projects like the European Project Unicore. This project is about defining the relevant API and adding the necessary kernel boot support to KubeVirt.\n-\tRecommended Skills: golang, Kubernetes, virtualization\n-\tMentor(s): Daniel Belenky (@danielBelenky)\n-\tIssue:\n\t- https://github.com/kubevirt/kubevirt/issues/2741\n\n#### Improve Observability\n-\tDescription: KubeVirt is running VMs on Kubernetes, in order to simplify operations, KubeVirt should expose more metrics about the VMs (workloads) and it's infrastructure components, in order to improve serviceability by integrating with projects like prometheus. This project is about adding a couple of more metrics to different KubeVirt components.\n-\tRecommended Skills: golang, Kubernetes\n-\tMentor(s): Daniel Belenky (@danielBelenky)\n-\tIssue:\n\t- https://github.com/kubevirt/kubevirt/issues/3385\n" }, { "path": "programs/lfx-mentorship/2020/q2/selected_projects.md", "content": "## Selected Projects\n\nProject maintainers and mentors, please submit the selected below (under the Selected Projects section) section using the template below.\n\n### Template\n\n```\n### CNCF Project Name\n#### Title\n\n-\tDescription:\n-\tRecommended Skills:\n-\tMentor(s):\n- Mentee (Communty Bridge URL):\n-\tUpstream Issue (URL):\n- Community Bridge project (URL):\n```\n\n### Sample\n\n#### Prometheus\n\n##### Refactor the APIs for better readability and less maintenance overhead\n\n- Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n- Recommended Skills: golang\n- Mentor(s): Krasi Georgiev (@krasi-georgiev)\n- Mentee: Jane Doe\n- Issue: https://github.com/prometheus/prometheus/issues/3416\n- Community Bridge project (URL): https://people.communitybridge.org/project/9595fbe7-6a8d-43d4-aebb-a54d57f33fdd\n\n## List of Selected Projects\n\n### Service Mesh Interface\n\n#### SMI Conformance with Meshery\n\n- Description: Ensure that a service mesh is properly configured and that its behavior conforms to official SMI specifications. Leverage Meshery as an SMI-integrated tool to provide conformance of both capabilities and compliance status as outlined in the [design specification](https://docs.google.com/document/d/1HL8Sk7NSLLj-9PRqoHYVIGyU6fZxUQFotrxbmfFtjwc/edit).\n- Mentors: Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Vinayak Shinde ([@vinushnd](https://twitter.com/vinushnd)\\)\n- Mentee: [Kanishkar J](https://people.communitybridge.org/mentee/2733c465-9ea8-4889-a3a3-e1b9215393ee,359dda52-7fb7-4fa8-82cd-a27216757a57)\n- Issue: [https://github.com/servicemeshinterface/smi-spec/issues/70](https://github.com/servicemeshinterface/smi-spec/issues/70)\n\n### Kubernetes\n\n#### Kubernetes working group for CSI driver\n\n- Description: Container Storage Interface (CSI) is a standard for exposing storage systems to containerized workloads on Kubernetes. The idea is to implement a few new CSI features and also e2e tests to cover those features, e.g. volume expansion, Windows support, inline volume support etc. Also, there are requirements to rewrite some flexvolume drivers(e.g. [SMB CSI Driver](https://github.com/kubernetes-csi/csi-driver-smb)) to CSI driver.\n- Recommended Skills: golang, Kubernetes\n- Mentor(s): Andy Zhang [@andyzhangx](https://github.com/andyzhangx)\n- Mentee: [Animesh Kumar](https://people.communitybridge.org/mentee/51d3fad8-fac8-49c0-ba18-9c96635b07f1,2d438b9a-c539-46d0-9eed-c6ee4404c88a)\n- Upstream Issue (URL):\n - https://github.com/kubernetes/kubernetes/issues/56005\n - https://github.com/kubernetes-sigs/azurefile-csi-driver/issues\n- Community Bridge project (URL): https://people.communitybridge.org/project/2d438b9a-c539-46d0-9eed-c6ee4404c88a\n\n##### Kubernetes working group for Multi-tenancy: Multi-tenancy benchmark project\n\n- Description: The Kubernetes Multi-Tenancy Working Group is chartered with exploring and defining multi-tenancy models for Kubernetes. An overview of working group activities can be found in this Kubernetes Multi-Tenancy Working Group . The Multitenancy Benchmarks effort focuses on measuring and validating the desired behaviors for multitenancy. Part of this effort is to automate behavioral and configuration checks on existing clusters, which will be the focus of this project. This automated test suit will help all Kubernetes users validate whether their clusters are setup correctly for multi-tenancy.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Tasha Drew [@tashimi](https://github.com/tashimi), Ryan Bezdicek [@rjbez17](https://github.com/rjbez17), Jim Bugwadia [@JimBugwadia](https://github.com/JimBugwadia)\n- Mentee: [Divya Rani](https://people.communitybridge.org/mentee/b65e7f25-a1c7-458a-98d5-e990122c843d,2d438b9a-c539-46d0-9eed-c6ee4404c88a)\n- Upstream Issue (URL):\n - https://github.com/kubernetes-sigs/multi-tenancy/issues/551\n- Community Bridge project: [Kubernetes](https://people.communitybridge.org/project/2d438b9a-c539-46d0-9eed-c6ee4404c88a)\n\n### Linkerd\n\n#### Service Topologies\n\n- Description: It is valuable to have metadata related to the topology of a cluster when making load balancing decisions. This metadata can be used to control egress costs between regions or even make advanced routing decisions in multicluster situations. As part of Kubernetes 1.17, [service topology](https://kubernetes.io/docs/concepts/services-networking/service-topology/) landed. This provides extra metadata as part of endpoints for a service to control weighting. Imagine transparently failing over to nodes running in a different zone if the pods locally are no longer running. Linkerd should implement support for this functionality.\n- Recommended Skills: golang, Kubernetes, rust, Tokio\n- Mentor(s): [Thomas Rampelberg](https://twitter.com/grampelberg) (@grampelberg)\n- Mentee: [Matei David](https://people.communitybridge.org/mentee/17c3eb19-8878-40cc-bc8c-61fa0c97b381,65742dc0-7217-4c4a-a609-f5f0fcde5c0a)\n- Issue:\n - [https://github.com/linkerd/linkerd2/issues/4325](https://github.com/linkerd/linkerd2/issues/4325)\n- Community Bridge project (URL): [https://people.communitybridge.org/project/65742dc0-7217-4c4a-a609-f5f0fcde5c0a](https://people.communitybridge.org/project/65742dc0-7217-4c4a-a609-f5f0fcde5c0a)\n\n### KubeEdge\n\n#### Support metrics-server in cloud\n\n- Description: Now we have integrated cadvisor in edge, and it also needs to integrate metrics-server in the cloud to collect monitoring data of edge nodes.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Kevin Wang (@kevin-wangzefeng)\n- Mentee: [Tiecheng Shen](https://people.communitybridge.org/mentee/b26f53c3-4b47-4bf8-80ff-262aff137722,1b931913-44a4-43a7-92ed-d7b2089060b1)\n- Related Issues:\n - https://github.com/kubeedge/kubeedge/issues/1561\n- Community Bridge project (URL): [https://people.communitybridge.org/project/1b931913-44a4-43a7-92ed-d7b2089060b1](https://people.communitybridge.org/project/1b931913-44a4-43a7-92ed-d7b2089060b1)\n\n#### Add certificate rotation for edge node\n\n- Description: At present, the edge nodes of KubeEdge only apply for certificates when they first started. And we need to automatically generate a new key and request a new certificate from the cloudcore periodically.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Kevin Wang (@kevin-wangzefeng), Fisher Xu (@fisherxu)\n- Mentee: [Jiejie Xu](https://people.communitybridge.org/mentee/571fd9fa-0253-4525-af33-dcab4d2e0454,1b931913-44a4-43a7-92ed-d7b2089060b1)\n- Related Issues:\n - https://github.com/kubeedge/kubeedge/issues/1630\n- Community Bridge project (URL): [https://people.communitybridge.org/project/1b931913-44a4-43a7-92ed-d7b2089060b1](https://people.communitybridge.org/project/1b931913-44a4-43a7-92ed-d7b2089060b1)\n\n### TiKV\n\n#### Full Chunk-based Computing\n\n- Description: Currently, TiKV uses a simple but inefficient memory layout in computing framework. Using Chunk, a column-based memory layout, could improve memory locality and reduce memory allocation during expression evaluation.\n- Recommended Skills: Rust, Database\n- Mentor(s): Tianyi Zhuang ([@TennyZhuang](https://github.com/TennyZhuang)), breeswish ([@breeswish](https://github.com/breeswish))\n- Mentee: [Chi Zhang](https://people.communitybridge.org/mentee/4a9369ba-d561-4849-99cb-3544aff51294,c6a0326c-b053-41a3-9bf2-1e7e78481ca6)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/7724\n- Community Bridge project (URL): [https://people.communitybridge.org/project/c6a0326c-b053-41a3-9bf2-1e7e78481ca6](https://people.communitybridge.org/project/c6a0326c-b053-41a3-9bf2-1e7e78481ca6)\n\n### Envoy\n\n#### Improve Envoy observability for http module\n\n- Description: Currently there are multiple useful metrics missing for http requests that are proxied through Envoy. Adding corresponding metrics would increase observability for Envoy based systems and improve user experience.\n- Recommended Skills: C++\n- Mentor(s): Kateryna Nezdolii ([@nezdolik](https://github.com/nezdolik))\n- Mentee: [Ranjith Kumar Adha](https://people.communitybridge.org/mentee/9654d6c4-1ea5-46d4-b72e-fb78c2326aa6,872be524-7465-4639-be88-1b451c581826)\n- Upstream Issue (URL): https://github.com/envoyproxy/envoy/issues/10308, https://github.com/envoyproxy/envoy/issues/3621\n- Community Bridge project (URL): [https://people.communitybridge.org/project/872be524-7465-4639-be88-1b451c581826](https://people.communitybridge.org/project/872be524-7465-4639-be88-1b451c581826)\n\n### CoreDNS\n\n##### External health check and orchestration of CoreDNS in Kubernetes clusters\\*\\*\n\n- Description: CoreDNS is the cluster DNS server for Kubernetes and is very much critical for the overall health of the Kubernetes cluster. It is very important to monitoring the health of CoreDNS itself and restarting or repairing any CoreDNS pods that are not behaving correctly. While CoreDNS exposes a health check itself, the health check is not UDP (DNS) based. The existing health check is also launched locally which could be very much different when accessed by other pods remotely.\n This project intends to build an application that checks CoreDNS health through UDP (DNS) externally, and, restart CoreDNS pods by interacting with Kubernetes API through golang. This is an important project that will greatly improve the overall health of Kubernetes clusters through automation.\n- Recommended Skills: Go, DNS, Kubernetes\n- Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)\n- Mentee: [Jayesh Sharma](https://people.communitybridge.org/mentee/4ea84460-17c7-4cbb-be95-11ade6195ed3,6705be57-130f-43f5-ba80-11605ffdb1f9)\n- Implementation: The deliverable of this project is a golang program that could be deployed in a Kubernetes cluster independently while at the same time, monitoring CoreDNS pods in the same cluster and interacting Kubernetes API (server) to restart CoreDNS pods as needed.\n- Related Issues:\n - https://github.com/coredns/rfc/issues/7\n\n### OPA\n\n#### OPA - MongoDB query translator\n\n- Description: MongoDB is a general-purpose, document-based, distributed database with a rich query language. OPA features a high-level declarative language called `Rego` purpose-built for expressing policies over complex hierarchical data structures. OPA is often used to enforce policies over incoming API requests, but using OPA's \"partial evaluation\" feature it is also possible to enforce policies when data is accessed inside of document-oriented databases like MongoDB. In this model, callers query OPA to obtain a set of conditions to apply to the database query and then rewrite the database query accordingly. There are existing projects that translate \"partial evaluation\" results to SQL and Elasticsearch. This project would involve designing and implementing a Rego to MongoDB query translator that supports basic relational operations like ==, !=, >, <, etc. This project would hugely benefit the community to perform authorization and data-filtering in MongoDB using OPA.\n- Recommended Skills: Go/Python, MongoDB (not required, but nice to have)\n- Mentor(s): Ash Narkar (@ashutosh-narkar)\n- Mentee: [Vineeth Pothulapati](https://people.communitybridge.org/mentee/1027186d-a51f-49cc-a8d8-a8a69b9ceb55,12a9270f-8673-4acb-92ec-fd539fc2b567)\n- Upstream Issue: https://github.com/open-policy-agent/opa/issues/2059\n- Community Bridge project (URL): [https://people.communitybridge.org/project/12a9270f-8673-4acb-92ec-fd539fc2b567](https://people.communitybridge.org/project/12a9270f-8673-4acb-92ec-fd539fc2b567)\n\n### KubeVirt\n\n#### Kernel boot\n\n- Description: KubeVirt allows to boot from regular (virtual) disks, an alternative booting method is to directly provide a kernel, initrd, and cmdline to a VM for booting. Such a feature is generally useful for many unikernel projects like the European Project Unicore. This project is about defining the relevant API and adding the necessary kernel boot support to KubeVirt.\n- Recommended Skills: golang, Kubernetes, virtualization\n- Mentor(s): Daniel Belenky (@danielBelenky), Daniel Hiller (@dhiller)\n- Mentee: [Hritvi Bhandari](https://people.communitybridge.org/mentee/cb7362a0-d10b-4806-8c43-6ffa4031515b,de7ca1c2-2d22-4919-bef8-6cca50a54426)\n- Issue:\n - https://github.com/kubevirt/kubevirt/issues/2741\n\n#### Improve Observability\n\n- Description: KubeVirt is running VMs on Kubernetes, in order to simplify operations, KubeVirt should expose more metrics about the VMs (workloads) and it's infrastructure components, in order to improve serviceability by integrating with projects like prometheus. This project is about adding a couple of more metrics to different KubeVirt components.\n- Recommended Skills: golang, Kubernetes\n- Mentor(s): Daniel Belenky (@danielBelenky), Daniel Hiller (@dhiller)\n- Mentee: [Arthur Silva Sens](https://people.communitybridge.org/mentee/bd26d0f8-0af5-4032-9fb2-ae6becb621c4,de7ca1c2-2d22-4919-bef8-6cca50a54426)\n- Issue:\n - https://github.com/kubevirt/kubevirt/issues/3385\n\n### OpenEBS\n\n#### A easy to use command-line interface (CLI) for OpenEBS.\n\n- Description: OpenEBS is completely Kubernetes native and is implemented using microservices. OpenEBS can be installed via kubectl or helm chart and managed via custom resources. To improve the usability of OpenEBS, the proposal is to have a easy to use OpenEBS CLI (similar to `kubectl`) to perform operations mentioned below.\n - install => Install OpenEBS\n - upgrade => Upgrade OpenEBS components\n - status => Print the readiness of various components, verify prerequisites are met to run openebs pools and volumes.\n - version => Print the OpenEBS version and associated images\n - describe => Describe OpenEBS resources like pools and volumes.\n - create => Create OpenEBS resources\n - delete => Delete OpenEBS resources\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Kiran Mova (@kmova), Amit Kumar Das (@AmitKumarDas)\n- Mentee(s): [Vani Singh](https://people.communitybridge.org/mentee/fdfc538b-938b-475f-a68b-52cca059386f,40a443f9-cb78-49e6-96ad-26616acb2113), [Harsh Thakur](https://people.communitybridge.org/mentee/b41c735b-64f5-4da4-a26d-b3bd0f867e35,40a443f9-cb78-49e6-96ad-26616acb2113)\n- Related Issues:\n - https://github.com/openebs/openebs/issues/2946\n - https://github.com/openebs/openebs/issues/1248\n - https://github.com/openebs/openebs/issues/290\n\n#### New storage backend using raw disk images\n\n- Description: OpenEBS Dynamic Local PV with Hostpath are great for use cases with low latency requirements and running on nodes with few attached drives or block devices. Using bare hostpath has the limitation of enforcing the capacity limits requested by PVC. The proposal is to implement a new type of storage, backed by a raw disk image on the host, that is mounted inside the pod. The storage backend should:\n - have near-zero performance overhead, compared to using local disks\n - be thin-provisioned\n - be able to enforce storage size limits\n - be able to expose volume metrics\n- Recommended Skills: Kubernetes, Linux, Python, Go\n- Mentor(s): Kiran Mova (@kmova)\n- Mentee: [Mehran Kholdi](https://people.communitybridge.org/mentee/b72c04dc-9650-4e3a-a335-14c5123b8f32,40a443f9-cb78-49e6-96ad-26616acb2113)\n- Related Issues:\n - https://github.com/openebs/openebs/issues/2871\n\n### Prometheus\n\n#### Persist Retroactive Rule Reevaluations\n\n- Description: Right now one of the biggest issues with recording rules is that data is only available since the rule was created. Which means any dashboards that use the recording rule will not have data prior to the recording rules create time. We can already reevaluate queries on old data, but we should be able to persist that for a certain window from `[Oldest, Now)`\n- Recommended Skills: Go\n- Mentor(s): Bartlomiej Plotka (@bwplotka), Callum Styan (@cstyan)\n- Mentee (Communty Bridge URL): [Jessica Grebenschikov](https://people.communitybridge.org/mentee/aceb6a84-ce89-4e4d-8a2d-4a4dd8eb2f46,9595fbe7-6a8d-43d4-aebb-a54d57f33fdd)\n- Upstream Issue (URL): https://github.com/prometheus/prometheus/issues/11\n- Community Bridge project (URL): https://people.communitybridge.org/project/9595fbe7-6a8d-43d4-aebb-a54d57f33fdd\n\n#### Remote Write WAL Pointer + Other Improvements\n\n- Description: Remote write has gone through a rewrite in the last year, but there are still open improvements and feature additions that can be explored. For example, because remote write now sends data via Prometheus' WAL, the pointer for each remote write queue into the WAL should be persisted across restarts. The addition of new record types, or a new remote write specific WAL, so that new data not currently part of the WAL can be remote written coulda also be investigated.\n- Recommended Skills: Go, database and dist. systems nice to have.\n- Mentee (Communty Bridge URL): [Nicole Jingco](https://people.communitybridge.org/mentee/f63d546c-b38b-42fe-9d78-24b077c7a21a,9595fbe7-6a8d-43d4-aebb-a54d57f33fdd)\n- Mentor(s): Callum Styan (@cstyan), Chris Marchbanks (@csmarchbanks)\n- Upstream Issue (URL): https://github.com/prometheus/prometheus/issues/6333\n- Community Bridge project (URL): https://people.communitybridge.org/project/9595fbe7-6a8d-43d4-aebb-a54d57f33fdd\n\n### Thanos\n\n#### Versioned Website Docs\n\n- Description: The Thanos website includes a documentation area that contains per-component docs and configuration built by rendering the markdown files from the tip of master of the Thanos repository. This frequently causes confusion for users, as breaking changes are often merged into master that conflict with the APIs of previous releases. To solve this user-facing issue, we would like to allow the website to show a different set of docs for every Thanos release. This project will involve designing a documentation structure and version picker in the website to select different versions of documents. We will also need to design a workflow for managing docs that integrates with our Git workflow, i.e. updating corresponding docs on pull requests, cherry-picks, etc.\n- Recommended Skills: go, HTML, JavaScript, CSS\n- Mentor(s): Lucas Servén Marín (@squat), Bartlomiej Plotka (@bwplotka)\n- Mentee (Communty Bridge URL): [Uchechukwu Obasi](https://people.communitybridge.org/mentee/365bfa7f-ce76-4300-85ce-f5611ebc74af,f51284ab-f652-47b1-9819-cd4135e75c00)\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/2488\n- Community Bridge project (URL): https://people.communitybridge.org/project/f51284ab-f652-47b1-9819-cd4135e75c00\n\n#### Per Request Query Tracking and Limiting\n\n- Description: Thanos is at the very high-level: durable and cheap database capable of storing a very large amount of metric data. This means that querying that data can be expensive. Imagine someone queries years of data for millions of series. No matter how fast or efficient our indexing is, even the amount of data being passed through the network can get expensive. This is why users should have control, potentially someday per tenant to tell what query was performed, for how long and how much data it was using, and what happened or error. Users should also be able to limit such large queries.\n- Recommended Skills: go, distributed systems, Linux\n- Mentor(s): Bartek Plotka (@bwplotka), Kemal Akkoyun (@kakkoyun)\n- Mentee (Communty Bridge URL):[Yash Sharma](https://people.communitybridge.org/mentee/9deb66ad-7c34-466f-bc1e-c4a177326c6f,f51284ab-f652-47b1-9819-cd4135e75c00)\n- Upstream Issues (URL): https://github.com/thanos-io/thanos/issues/1706 and https://github.com/thanos-io/thanos/issues/2527\n- Community Bridge project (URL): https://people.communitybridge.org/project/f51284ab-f652-47b1-9819-cd4135e75c00\n\n#### Complete Katacoda tutorials\n\n- Description: This is a great project for a writer with some passion for Docker and Kubernetes, interested in doing interactive docs: specifically learning to build Katacoda Course. Currently, we have a single Katacoda tutorial, which helps Thanos users to start up quickly and understand the concepts. To help improve the user experience further we have planned five more tutorials. The Katacoda tutorials are written in YAML format and don't require a lot of custom tooling. We have a moderate amount of docs on our website thanos.io, which should help you to get started quickly. Also, there are many youtube videos explaining the concepts. We can offer friendly community support and technical guidance and feedback. We're looking for one contributor to explore interactive tutorials and learn some technical concepts along the way. We are definitely not looking for perfection on the first try. Writing interactive tutorials:\n - Intro: Downsampling and unlimited metric retention for Prometheus\n - Intro: Global and meta alerts with Thanos\n - Advanced: Connecting remote Prometheuses to Thanos using simple Envoy setup.\n - Advanced: Using Prometheus remote write to stream metrics to Thanos\n - Advanced: Query low tail latency with low cost: Introducing caching to Thanos\n- Recommended Skills: Distributed systems, Linux, Kubernetes, Docker\n- Mentor(s): Bartek Plotka (@bwplotka), Povilas Versockas (@povilasv)\n- Mentee (Communty Bridge URL): [Sonia Singla](https://people.communitybridge.org/mentee/4966d917-9539-47ae-b335-7ef92f59f6c7,f51284ab-f652-47b1-9819-cd4135e75c00)\n- Upstream Issues (URL): https://github.com/thanos-io/thanos/issues/2041\n- Community Bridge project (URL): https://people.communitybridge.org/project/f51284ab-f652-47b1-9819-cd4135e75c00\n\n### Fluentd\n\n#### Fluent Bit Monitoring Web UI\n\n- Description: [Fluent Bit](https://fluentbit.io) exposes internal metrics from the data processing pipeline through its HTTP interface. This project aims to build a Web UI to show the components of the data pipeline and its continuous metrics with dashboards and further info. The metrics are exposed in JSON format and should be scrapped by the UI. The UI can be deployable on any HTTP server **without** the need for **NodeJS**.\n\n- Please refer to the Upstream Issue link for more details and candidate requirements:\n\n - Recommended Skills: Javascript, VueJS, CSS, HTML & general design skills\n - Mentor(s): Eduardo Silva (@edsiper)\n - Upstream Issue (URL): https://github.com/fluent/fluent-bit/issues/2147\n\n- Mentor(s): [Eduardo Silva](https://twitter.com/edsiper) (@edsiper)\n- Mentee: [Shivam Singhal](https://people.communitybridge.org/mentee/9cb20c4a-c637-4453-9cf5-6dd5e7130d60,d24ab158-e4e5-4042-91ad-b30ae52941d2)\n- Issue: [https://github.com/fluent/fluent-bit/issues/2147](https://github.com/fluent/fluent-bit/issues/2147)\n- Community Bridge project (URL): [https://people.communitybridge.org/project/d24ab158-e4e5-4042-91ad-b30ae52941d2](https://people.communitybridge.org/project/d24ab158-e4e5-4042-91ad-b30ae52941d2)\n\n### Argo\n\n#### Enhancing Developer Experience with Open Application Model Delpoyment using Argo CD\n\n- Description: Work with Argo CD community to enhace the declarative application development patterns into cloud native platforms\n- Recommended Skills: Go, Deployment, System Analsis\n- Mentor(s): Ken Owens\n- Mentee (Communty Bridge URL): [Darshan Chaudhary](https://people.communitybridge.org/mentee/5c5cec97-9863-4a44-bb15-31e7f36cb952,5d5d4357-f340-47c9-9ff2-7b0536291576)\n- Upstream Issue (URL): TBD\n- Community Bridge project (URL): https://people.communitybridge.org/project/5d5d4357-f340-47c9-9ff2-7b0536291576\n" }, { "path": "programs/lfx-mentorship/2020/q3-q4/README.md", "content": "2020\n====\n\nQ3-Q4\n-----\n\n*Status: Completed*\n\n### Timeline\n\n-\tSeptember 1 - September 9 (1 week): project applications opened\n\t-\tProjects are invited to submit their proposals\n-\tSeptember 7 - September 21 (2 weeks): CNCF staff selects the projects\n-\tSeptember 21 - selected projects/slots are announced by CNCF;\n-\tSeptember 21 - September 28 (1 week): mentees applications opened\n-\tSeptember 28 - October 5 (1 week) projects are selecting mentees;\n-\tOctober 5 - mentees are selected by the mentors, coding starts;\n-\tOctober 5 - November 2 (4 weeks) - coding (1st stage)\n-\tNovember 2 - November 9 (1 week): 1st evaluation;\n\t-\tMentors verify the quality of the completed tasks;\n-\tFirst 50% of the stipend is being paid to the mentee if this stage is passed;\n-\tNovember 9 - December 7 (4 weeks): (final) evaluation checkpoint;\n\t-\tCoding ends;\n-\tThe remaining 50% of the stipend is being paid to the mentees;\n\t-\tDecember 14 - results announced!\n\n### Participating Projects\n\nSee the announcement at [CNCF Blog](https://www.cncf.io/blog/2020/09/21/calling-all-mentees-cncf-communitybridge-projects-for-the-fall-2020-program/).\n\n### Selected Projects\n\nSelected projects are listed [here](./selected_projects.md).\n\n### Project Ideas\n\nThe proposed project ideas are listed [here](./project_ideas.md).\n" }, { "path": "programs/lfx-mentorship/2020/q3-q4/project_ideas.md", "content": "Projects ideas\n--------------\n\nProject maintainers and mentors, please submit the ideas below (under the Proposed Project Ideas section) section using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n### Template\n\n```\n#### CNCF Project Name\n##### Title\n\n-\tDescription:\n-\tRecommended Skills:\n-\tMentor(s):\n-\tUpstream Issue (URL):\n```\n\n### Sample:\n\n#### Prometheus (sample)\n\n##### Refactor the APIs for better readability and less maintenance overhead\n\n-\tDescription: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n-\tRecommended Skills: golang\n-\tMentor(s): Krasi Georgiev (@krasi-georgiev)\n-\tIssue: https://github.com/prometheus/prometheus/issues/3416\n\n### Proposed Project ideas\n\n#### Kubernetes\n\n##### Create Application for Elections Authenticated by External Oauth\n\n-\tDescription: Create a web-based voting application, with voting logic based on CIVS project, that allows use of external Oauth, such as Github, for voter authentication\n-\tRecommended Skills: Application development, schedule management, programming\n-\tMentor(s): Josh Berkus, Marky Jackson, Jaice Singer DuMars\n-\tUpstream Issue (URL): [Kubernetes community 5096](https://github.com/kubernetes/community/issues/5096)\n\n##### Kubernetes working group for CSI driver\n\n-\tDescription: Container Storage Interface (CSI) is a standard for exposing storage systems to containerized workloads on Kubernetes. This project mainly focus on [SMB CSI driver](https://github.com/kubernetes-csi/csi-driver-smb) and [NFS CSI driver](https://github.com/kubernetes-csi/csi-driver-nfs): set up solid unit tests, test coverage data, e2e test pipeline first and then implement a few new CSI features, e.g. dynamc provisioning support, inline volume support, etc.\n-\tRecommended Skills: golang, Kubernetes\n-\tMentor(s): Andy Zhang [@andyzhangx](https://github.com/andyzhangx)\n-\tUpstream Issue (URL):\n\t-\thttps://github.com/kubernetes-csi/csi-driver-smb/issues\n-\tCommunity Bridge project (URL): https://people.communitybridge.org/project/2d438b9a-c539-46d0-9eed-c6ee4404c88a\n\n#### Chaos Mesh\n\n##### Create a debug information collector for Chaos Mesh\n\n-\tDescription: Create a diagnotic info collector for Chaos Mesh to collect debugging info of a specific chaos experiment, covering chaos-daemon log, tc rules, iptables rules, etc.\n-\tRecommended Skills: Chaos Mesh, Kubernetes, golang\n-\tMentor(s): Keao Yang([@YangKeao](https://github.com/YangKeao)), Cwen Yin([@cwen0](https://github.com/cwen0)\\)\n-\tIssue: https://github.com/chaos-mesh/chaos-mesh/issues/694\n\n##### Support chaos-daemon work independently on a non-k8s node.\n\n-\tDescription: At present, chaos-daemon can only be run as a daemonset service in the Kubernetes environment, but some users want to inject faults into Kubernetes cluster itself, and they cannot use Chaos Mesh to do this. There are also some users who are unable to use Chaos Mesh because their applications are not deployed in the Kubernetes environment. So we need to make the chaos-daemon component run on non-k8s nodes alone, and inject faults directly into this node to solve the problems mentioned above.\n-\tRecommended Skills: Chaos Mesh, Kubernetes, golang\n-\tMentor(s): Keao Yang([@YangKeao](https://github.com/YangKeao)), Cwen Yin([@cwen0](https://github.com/cwen0)\\)\n-\tIssue: https://github.com/chaos-mesh/chaos-mesh/issues/888\n\n#### KubeEdge\n\n##### Support list-watch from edgecore for applications on the edge\n\n-\tDescription: Some applications running on the edge side need to connect to the k8s master through list-watch interface, but on the edge it cannot directly connect to the k8s master. So we need forward the list-watch requests to the k8s master through the cloud-side channel.\n-\tRecommended Skills: KubeEdge, Kubernetes, golang\n-\tMentor(s): Kevin Wang([@kevin-wangzefeng](https://github.com/kevin-wangzefeng)), Fei Xu([@fisherxu](https://github.com/fisherxu)\\)\n-\tIssue: https://github.com/kubeedge/kubeedge/issues/1758\n\n##### Use device API both on cloud and edge\n\n-\tDescription: Now we have defined device API in the cloud side, but the edgeside(edgecore and mapper) still don't use the API, we should refactor edgeside and use same API on cloud and edge to reduce complexity.\n-\tRecommended Skills: KubeEdge, Kubernetes, golang\n-\tMentor(s): Kevin Wang([@kevin-wangzefeng](https://github.com/kevin-wangzefeng)), Fei Xu([@fisherxu](https://github.com/fisherxu)\\)\n-\tIssue: https://github.com/kubeedge/kubeedge/issues/2140\n\n##### Add EdgeGateway as the ingress gateway on Edge\n\n-\tDescription: Add the EdgeGateway as the ingress gateway on Edge to dispatch request to multiple backend pods on the Edge side.\n-\tRecommended Skills: KubeEdge, Kubernetes, golang\n-\tMentor(s): Kevin Wang([@kevin-wangzefeng](https://github.com/kevin-wangzefeng)), Fei Xu([@fisherxu](https://github.com/fisherxu)\\)\n-\tIssue: https://github.com/kubeedge/kubeedge/issues/1432\n\n#### TiKV\n\n##### Support ENUM / SET push down for TiKV Coprocessor\n\n-\tDescription: Coprocessor is a TiKV component to handle predicate push down. This task is to add `ENUM` and `SET` data type to it, so that the performance can be improved in scenarios that involve with these two data types.\n-\tRecommended Skills: Rust, Database\n-\tMentor(s): Chi Zhang (@skyzh)\n-\tUpstream Issue (URL): https://github.com/tikv/tikv/issues/8605\n\n#### Support rbac control for data accessing in TiKV\n\n-\tDescription: This task is to support the authorization and authentication ability by rbac control in TiKV, so that the security of the data accessing in TiKV will become more complete.\n-\tRecommended Skills: Rust, Golang\n-\tMentors(s): Song Gao (@yisaer), Yutong Liang (@rleungx)\n-\tUpstream Issue (URL): https://github.com/tikv/tikv/issues/8621\n\n#### Volcano\n\n##### Implement hierarchy queue to better support fair-share\n\n-\tDescription: Implement hierarchy queue to better support fair-share\n-\tRecommended Skills: Volcano, Scheduling, Golang\n-\tMentor(s): Zhonghu Xu(@hzxuzhonghu), Klaus Ma(@k82cn)\n-\tUpstream Issue (URL): https://github.com/volcano-sh/volcano/issues/1033\n\n##### Customize scheduling algorithms per queue\n\n-\tDescription: Support customized scheduling algorithms per queue\n-\tRecommended Skills: Kubernetes, Scheduling, Golang\n-\tMentor(s): Zhonghu Xu(@hzxuzhonghu), Klaus Ma(@k82cn)\n-\tUpstream Issue (URL): https://github.com/volcano-sh/volcano/issues/1035\n\n##### Implement specific job types to improve usability\n\n-\tDescription: Improve Job API to support specific types of job\n-\tRecommended Skills: Volcano, Job Management, Golang\n-\tMentor(s): Zhonghu Xu(@hzxuzhonghu), Klaus Ma(@k82cn)\n-\tUpstream Issue (URL): https://github.com/volcano-sh/volcano/issues/1034\n\n#### Keptn\n\n##### Keptn CLI to support multiple contexts like KUBECONFIG\n\n-\tDescription: Improve the Keptn CLI to make it easier for users to authenticate to a cluster by just configuring the Kubernetes context. This will enable the user to switch between multiple Keptn installations easily.\n-\tRecommended Skills: Golang, Kubernetes\n-\tMentor(s): Jürgen Etzlstorfer ([@jetzlstorfer](https://github.com/jetzlstorfer)), Christian Kreuzberger ([@christian-kreuzberger-dtx](https://github.com/christian-kreuzberger-dtx)), Andreas Grimmer ([@agrimmer](https://github.com/agrimmer)\\)\n-\tUpstream Issue (URL): https://github.com/keptn/keptn/issues/2300\n\n##### Visualize remediation actions as counteractions for alerts\n\n-\tDescription: Improve the existing UI by adding UI elements for existing (multi-stage) remediation actions for services that are managed by Keptn.\n-\tRecommended Skills: Angular\n-\tMentor(s): Jürgen Etzlstorfer ([@jetzlstorfer](https://github.com/jetzlstorfer)), Johannes Bräuer ([@johannes-b](https://github.com/johannes-b)\\)\n-\tUpstream Issue (URL): https://github.com/keptn/keptn/issues/2299\n\n#### Opentelemetry\n\n##### ETW exporter\n\n-\tDescription: Add exporter for ETW (Event Tracing for Windows) as one of the optional recommended exporters that languages may decide to implement as part of SDK. Initial set of languages to support: C++ and/or C#.\n-\tRecommended Skills: some C++ or C# coding experience. Windows development environment is needed\n-\tMentor(s): @maxgolov\n-\tUpstream Issue (URL): https://github.com/open-telemetry/opentelemetry-cpp/issues/326\n\n##### OpenTelemetry to FluentBit exporter\n\n-\tDescription: Define a data format and create an exporter from OpenTelemetry to FluentBit. This will allow customers to use existing log delivery pipeline to upload telemetry collected by the rich set of various OpenTelemetry SDKs.\n-\tRecommended Skills: one of the languages suported by OpenTelemetry. Ideally C# or Go\n-\tMentor(s): @SergeyKanzhelev\n-\tUpstream Issue (URL): https://github.com/open-telemetry/opentelemetry-dotnet-contrib/issues/31\n\n##### PHP Exporter Development\n\n-\tDescription: Develop some of the exporters for PHP that are found in the ([Spec Compliance Matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/master/spec-compliance-matrix.md#exporters)) that are not yet completed for PHP. There are some really neat exporter implementations that would be excellent candidates.\n-\tRecommended Skills: PHP experience\n-\tMentor(s): @bobstrecansky\n-\tUpstream Issue (URL): https://github.com/open-telemetry/opentelemetry-php/issues/175\n\n#### Thanos\n\n##### Receive: Hashring Update Improvements\n\n-\tDescription: Currently, any change to the hashring configuration file will trigger all Thanos Receive nodes to flush their multi-TSDBs, causing them to enter an unready state until the flush is complete. This unavailability during a flush allows for a clear state transition, however it can result in downtimes on the order of five minutes for every configuration change. We propose modifying how the Thanos Receive component re-configures itself after the hashring configuration file has changed so that the system experiences no downtime.\n-\tRecommended Skills: Thanos, Timeseries database, Golang\n-\tMentor(s): Lucas Servén Marín(@squat), Frederic Branczyk(@brancz)\n-\tUpstream Issue (URL): https://github.com/thanos-io/thanos/issues/3141\n\n##### UI: Enhancements\n\n-\tDescription: The Thanos project has recently migrated its UI to one built on re-usable and shareable components written in React, with the goal of fostering collaboration with the broader Prometheus community. As part of this proposal, we would like create further UI components like status, configuration and discovery pages for better debuggability as well as basic benchmarking and regressions test. Additionally the plan is to collaborate with the Prometheus community to continue building a shared UI component library and to contribute upstream to Prometheus so that it can leverage these components in its UI.\n-\tRecommended Skills: React, JavaScript, Golang\n-\tMentor(s): Kemal Akkoyun(@kakkoyun), Prem Saraswat(@prmsrswt)\n-\tUpstream Issue (URL): https://github.com/thanos-io/thanos/issues/3142\n\n##### UI: Extending BlockViewer\n\n-\tDescription: Thanos BlockViewer UI proven to be essential part of debuggability story for the Thanos proejct. It allows to see exact state of data in Object Storage in an provider agnostic way. This project is about extending this UI with richer features, context and actions to increase observability and control. As part of this proposal, we would like to also contribute the same BlockViewer to Prometheus community to make sure it gives the same value for Prometheus project.\n-\tRecommended Skills: React, JavaScript, Golang, ObjectStorage\n-\tMentor(s): Prem Saraswat(@prmsrswt), Bartek Plotka(@bwplotka)\n-\tUpstream Issue (URL): https://github.com/thanos-io/thanos/issues/3112\n\n#### Open Service Mesh, Kuma and Service Mesh Interface\n\n##### Standards validation for OSM and Kuma\n\n-\tDescription: As two of the service meshes in the CNCF, both Kuma and Open Service Mesh need their implementations of standard specifications validated. This is true for Service Mesh Interface (SMI) and Service Mesh Performance (SMP) specifications. Both API specifications spanning many service meshes. Each service mesh implementing the SMI and SMP specifciation need their conformance validated.\n-\tRecommended Skills: golang\n-\tMentor(s): Lee Calcote (@leecalcote), Abishek Kumar (@kumarabd)\n-\tUpstream Issue (URL): https://github.com/openservicemesh/osm/issues/172\n\n#### Open Service Mesh\n\n##### Support for WebAssembly filters\n\n-\tDescription: Bring OSM on par with other service meshes that support WASM filters in their data plane. OSM's Envoy proxies can be extended at runtime with filters that are running in a WebAssembly sandbox (https://github.com/envoyproxy/envoy-wasm). Provide ability to dynamically load and unload Envoy WASM filters.\n-\tRecommended Skills: golang, rust\n-\tMentor(s): Lee Calcote (@leecalcote), Dev Kalra (@kalradev)\n-\tUpstream Issue (URL): https://github.com/openservicemesh/osm/issues/1671\n\n#### Prometheus\n\n##### Add various post processing steps in query API after PromQL execution\n\n-\tDescription: The results from the `query`/`query_range` are often unordered w.r.t. the label values and sample value. Also, there is no limit on how many series the endpoint can return. In this project, we want to extend those query APIs to include options for post processing the output to do the following:\n\t-\tSupport nested sorting (ascending/descending) of time series based on (1) Label values (2) Sample values for `/query` endpoint.\n\t-\tSupport limiting the number of time series returned by `query`/`query_range` endpoint.\n\t-\tIf time permits, expore how we can do nested sorting of time series for `query_range` API.\n-\tRecommended Skills: golang\n-\tMentor(s): Bartek Plotka(@bwplotka), Ganesh Vernekar (@codesome)\n-\tUpstream Issue (URL): https://github.com/prometheus/prometheus/issues/7947, https://github.com/prometheus/prometheus/issues/7948\n" }, { "path": "programs/lfx-mentorship/2020/q3-q4/selected_projects.md", "content": "## Selected Projects\n\nProject maintainers and mentors, please submit the selected below (under the Selected Projects section) section using the template below.\n\n### Template\n\n```\n### CNCF Project Name\n#### Title\n\n-\tDescription:\n-\tRecommended Skills:\n-\tMentor(s):\n- Mentee (Communty Bridge URL):\n-\tUpstream Issue (URL):\n- Community Bridge project (URL):\n```\n\n### Sample\n\n#### Prometheus (sample)\n\n##### Refactor the APIs for better readability and less maintenance overhead\n\n- Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n- Recommended Skills: golang\n- Mentor(s): Krasi Georgiev (@krasi-georgiev)\n- Mentee: Jane Doe\n- Issue: https://github.com/prometheus/prometheus/issues/3416\n- Community Bridge project (URL): https://people.communitybridge.org/project/9595fbe7-6a8d-43d4-aebb-a54d57f33fdd\n\n## List of Selected Projects\n\n#### OpenTelemetry\n\n##### OpenTelemetry C++ SDK ETW exporter\n\n-\tDescription: Add exporter for ETW (Event Tracing for Windows) as one of the optional recommended exporters that languages may decide to implement as part of SDK. Initial set of languages to support: C++ and/or C#. ETW exporter allows any open source project running on Windows (e.g. Docker) to leverage OpenTelemetry C++ SDK, emitting telemetry events (traces, logs) over ETW channel. Subsequently a listener Agent may forward events to fluent, ELK stack, or other destination. For example, events may be transformed and forwarded OTLP protocol collector. Min-bar is to implement the necessary OT C++ SDK changes (C++) and a test listener (C#). Additional scope may include some concrete examples of instrumentation: Docker ETW logs driver, or an additional out-of-proc forwarder from ETW provider listener to OTLP receiver. Simple projection for node.js (console log to OT C++ SDK - ETW) may also be designed, time-permitting.\n-\tRecommended Skills: some C++ or C# coding experience. Windows development environment is needed.\n-\tMentor(s): Max Golovanov (@maxgolov)\n- Mentee: Mishal Shah (@mishal23)\n-\tIssue: https://github.com/open-telemetry/opentelemetry-cpp/issues/326\n- Community Bridge project (URL): https://people.communitybridge.org/project/f1275c0e-7152-4e09-8d8b-6b14598afbc3\n\n##### OpenTelemetry SDK PHP Exporter\n - Description: Develop some of the exporters for PHP that are found in the ([Spec Compliance Matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/master/spec-compliance-matrix.md#exporters)) that are not yet completed for PHP. There are some really neat exporter implementations that would be excellent candidates for creation / improvements:\n - OTLP (priority)\n - Zipkin\n - Jaeger\n - Prometheus\n- Recommended Skills: PHP\n- Mentor: Bob Strecansky (@bobstrecansky)\n- Mentee: Ritick Gautam ([@riticksingh](https://github.com/riticksingh))\n- Issue: https://github.com/open-telemetry/opentelemetry-php/issues/175\n- Community Bridge Project (URL): https://people.communitybridge.org/project/f1275c0e-7152-4e09-8d8b-6b14598afbc3\n\n##### OpenTelemetry to FluentBit exporter\n\n-\tDescription: Define a data format and create an exporter for traces and metrics from OpenTelemetry to FluentBit. This will allow customers to use existing log delivery pipeline to upload telemetry collected by the rich set of various OpenTelemetry SDKs. Pipeline we want to enalbe is SDK->FluentBit->OpenTelemetry Collector->Jaeger to see traces.\n- Recommended Skills: GoLang\n- Mentor: @SergeyKanzhelev\n- Mentee: Aditya Prajapati (@Syn3rman)\n- Upstream Issue (URL): https://github.com/open-telemetry/opentelemetry-go-contrib/issues/386\n- Community Bridge Project (URL): https://people.communitybridge.org/project/f1275c0e-7152-4e09-8d8b-6b14598afbc3\n\n#### Keptn\n\n##### Keptn CLI to support multiple contexts like KUBECONFIG\n\n-\tDescription: Improve the Keptn CLI to make it easier for users to authenticate to a cluster by just configuring the Kubernetes context. This will enable the user to switch between multiple Keptn installations easily.\n-\tRecommended Skills: Golang, Kubernetes\n-\tMentor(s): Jürgen Etzlstorfer ([@jetzlstorfer](https://github.com/jetzlstorfer)), Christian Kreuzberger ([@christian-kreuzberger-dtx](https://github.com/christian-kreuzberger-dtx))\n- Mentee: Ankit Jain (@ankitjain28may)\n-\tUpstream Issue (URL): https://github.com/keptn/keptn/issues/2300\n- Community Bridge project (URL): https://people.communitybridge.org/project/ba41187f-fa8d-47e1-8046-4040e5b35b73\n\n##### Visualize remediation actions as counteractions for alerts\n\n-\tDescription: Improve the existing UI by adding UI elements for existing (multi-stage) remediation actions for services that are managed by Keptn.\n-\tRecommended Skills: Angular\n-\tMentor(s): Jürgen Etzlstorfer ([@jetzlstorfer](https://github.com/jetzlstorfer)), Johannes Bräuer ([@johannes-b](https://github.com/johannes-b)\\)\n- Mentee: Ayush Nawal (@ayushnawal)\n-\tUpstream Issue (URL): https://github.com/keptn/keptn/issues/2299\n- Community Bridge project (URL): https://people.communitybridge.org/project/ba41187f-fa8d-47e1-8046-4040e5b35b73\n=======\n\n#### TiKV\n\n##### Support ENUM / SET push down for TiKV Coprocessor\n\n- Description: Coprocessor is a TiKV component to handle predicate push down. This task is to add `ENUM` and `SET` data type to it, so that the performance can be improved in scenarios that involve with these two data types.\n- Recommended Skills: Rust, Database\n- Mentor(s): Chi Zhang (@skyzh)\n- Mentee: Hao Ding (@Xuanwo)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/8605\n- Community Bridge Project (URL): https://people.communitybridge.org/project/c6a0326c-b053-41a3-9bf2-1e7e78481ca6\n\n##### Support rbac control for data accessing in TiKV\n\n- Description: This task is to support the authorization and authentication ability by rbac control in TiKV, so that the security of the data accessing in TiKV will become more complete.\n- Recommended Skills: Golang, Rust\n- Mentor(s): Song Gao (@Yisaer)\n- Mentee: Yanning Chen (@PhotonQuantum)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/8621\n- Community Bridge Project (URL): https://people.communitybridge.org/project/c6a0326c-b053-41a3-9bf2-1e7e78481ca6\n\n#### Volcano\n\n##### Implement hierarchy queue to better support fair-share\n\n- Description: Implement hierarchy queue to better support fair-share\n- Recommended Skills: Volcano, Scheduling, Golang\n- Mentor(s): Lei Wu(@Thor-wl)\n- Mentee: wangqian qian(@My-pleasure)\n- Issue: https://github.com/volcano-sh/volcano/issues/1033\n- Community Bridge Project (URL): https://people.communitybridge.org/project/837a970d-64c3-46d1-ade2-5b8b8997a0d4\n\n\n##### Customize scheduling algorithms per queue\n\n- Description: Support customized scheduling algorithms per queue\n- Recommended Skills: Kubernetes, Scheduling, Golang\n- Mentor(s): Leibo Wang(@william-wang)\n- Mentee: Srestha Srivastava(@sresthas)\n- Issue: https://github.com/volcano-sh/volcano/issues/1035\n- Community Bridge Project (URL): https://people.communitybridge.org/project/837a970d-64c3-46d1-ade2-5b8b8997a0d4\n\n\n##### Implement specific job types to improve usability\n\n- Description: Improve Job API to support specific types of job\n- Recommended Skills: Volcano, Job Management, Golang\n- Mentor(s): Leibo Wang(@william-wang)\n- Mentee: Liang Tang(@shinytang6)\n- Issue: https://github.com/volcano-sh/volcano/issues/1034\n- Community Bridge Project (URL): https://people.communitybridge.org/project/837a970d-64c3-46d1-ade2-5b8b8997a0d4\n\n#### Chaos Mesh\n\n##### Create a debug information collector for Chaos Mesh\n\n- Description: Create a diagnotic info collector for Chaos Mesh to collect debugging info of a specific chaos experiment, covering chaos-daemon log, tc rules, iptables rules, etc.\n- Recommended Skills: Chaos Mesh, Kubernetes, golang\n- Mentor(s): Keao Yang([@YangKeao](https://github.com/YangKeao)), Cwen Yin([@cwen0](https://github.com/cwen0)\\)\n- Mentee: [Shuyang Wu](https://people.communitybridge.org/mentee/3a7e3c44-6a0e-4be1-a722-5176d97569ab,12a8bfec-ba3f-496e-bc26-118e9f5eebe6)([@Yiyiyimu](https://github.com/yiyiyimu/))\n- Issue: https://github.com/chaos-mesh/chaos-mesh/issues/694\n- Community Bridge Project (URL): https://people.communitybridge.org/project/12a8bfec-ba3f-496e-bc26-118e9f5eebe6\n\n##### Support chaos-daemon work independently on a non-k8s node.\n\n- Description: At present, chaos-daemon can only be run as a daemonset service in the Kubernetes environment, but some users want to inject faults into Kubernetes cluster itself, and they cannot use Chaos Mesh to do this. There are also some users who are unable to use Chaos Mesh because their applications are not deployed in the Kubernetes environment. So we need to make the chaos-daemon component run on non-k8s nodes alone, and inject faults directly into this node to solve the problems mentioned above.\n- Recommended Skills: Chaos Mesh, Kubernetes, golang\n- Mentor(s): Keao Yang([@YangKeao](https://github.com/YangKeao)), Cwen Yin([@cwen0](https://github.com/cwen0)\\)\n- Mentee: [Manish Dangi](https://people.communitybridge.org/mentee/4778882c-f043-4fc1-a567-dc5e7a4437ed,12a8bfec-ba3f-496e-bc26-118e9f5eebe6)([@manishdangi98](https://github.com/manishdangi98/))\n- Issue: https://github.com/chaos-mesh/chaos-mesh/issues/888\n- Community Bridge Project (URL): https://people.communitybridge.org/project/12a8bfec-ba3f-496e-bc26-118e9f5eebe6\n\n#### Kubernetes\n\n##### Working group for CSI driver\n-\tDescription: Container Storage Interface (CSI) is a standard for exposing storage systems to containerized workloads on Kubernetes. This project mainly focus on [SMB CSI driver](https://github.com/kubernetes-csi/csi-driver-smb) and [NFS CSI driver](https://github.com/kubernetes-csi/csi-driver-nfs): set up solid unit tests, test coverage data, e2e test pipeline first and then implement a few new CSI features, e.g. dynamc provisioning support, inline volume support, etc.\n-\tRecommended Skills: Go, Kubernetes, Python, JavaScript\n-\tMentor(s): Andy Zhang [@andyzhangx](https://github.com/andyzhangx)\n- Mentee: Mayank Shah (@mayankshah1607)\n-\tUpstream Issue (URL):\n\t-\thttps://github.com/kubernetes-csi/csi-driver-smb/issues\n-\tCommunity Bridge project (URL): https://people.communitybridge.org/project/2d438b9a-c539-46d0-9eed-c6ee4404c88a\n\n##### Create Application for Elections Authenticated by External Oauth\n-\tDescription: Create a web-based voting application, with voting logic based on CIVS project, that allows use of external Oauth, such as Github, for voter authentication.\n-\tRecommended Skills: golang, Kubernetes\n-\tMentor(s): Josh Berkus ([@jberkus](https://github.com/jberkus)), Jaice Singer Dumars ([@jdumars](https://github.com/jdumars)), Sergey Kanzhelev ([@SergeyKanzhelev](https://github.com/SergeyKanzhelev/)), Marky Jackson ([@markyjackson-taulia](ttps://github.com/markyjackson-taulia)\\)\n- Mentee: Manish Sahani (@manishsahani999)\n-\tUpstream Issue (URL):\n\t-\thttps://github.com/kubernetes/community/issues/5096\n-\tCommunity Bridge project (URL): https://people.communitybridge.org/project/953e5f12-460b-4bf1-80b3-5171c2044462\n\n#### Thanos\n\n##### Receive: Hashring Update Improvements\n\n- Description: Currently, any change to the hashring configuration file will trigger all Thanos Receive nodes to flush their multi-TSDBs, causing them to enter an unready state until the flush is complete. This unavailability during a flush allows for a clear state transition, however it can result in downtimes on the order of five minutes for every configuration change. We propose modifying how the Thanos Receive component re-configures itself after the hashring configuration file has changed so that the system experiences no downtime.\n- Recommended Skills: Thanos, Timeseries database, Golang\n- Mentor(s): Lucas Servén Marín(@squat), Frederic Branczyk(@brancz)\n- Mentee: [T.S.S. Chandana @Chans321](https://people.communitybridge.org/mentee/402c80c6-c37d-4575-8120-41849ada956e,f51284ab-f652-47b1-9819-cd4135e75c00)\n- Issue: https://github.com/thanos-io/thanos/issues/3141\n- Community Bridge project (URL): https://people.communitybridge.org/project/f51284ab-f652-47b1-9819-cd4135e75c00\n\n##### UI: Enhancements\n\n- Description: The Thanos project has recently migrated its UI to one built on re-usable and shareable components written in React, with the goal of fostering collaboration with the broader Prometheus community. As part of this proposal, we would like create further UI components like status, configuration and discovery pages for better debuggability as well as basic benchmarking and regressions test. Additionally the plan is to collaborate with the Prometheus community to continue building a shared UI component library and to contribute upstream to Prometheus so that it can leverage these components in its UI.\n- Recommended Skills: React, JavaScript, Golang\n- Mentor(s): Kemal Akkoyun(@kakkoyun), Prem Saraswat(@prmsrswt)\n- Mentee: [Raphael Noriode @Oghenebrume50](https://people.communitybridge.org/mentee/194d1349-15b0-41e7-bb4e-db19021765da,f51284ab-f652-47b1-9819-cd4135e75c00)\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/3142\n- Community Bridge project (URL): https://people.communitybridge.org/project/f51284ab-f652-47b1-9819-cd4135e75c00\n\n##### UI: Extending BlockViewer\n\n- Description: Thanos BlockViewer UI proven to be essential part of debuggability story for the Thanos proejct. It allows to see exact state of data in Object Storage in an provider agnostic way. This project is about extending this UI with richer features, context and actions to increase observability and control. As part of this proposal, we would like to also contribute the same BlockViewer to Prometheus community to make sure it gives the same value for Prometheus project.\n- Recommended Skills: React, JavaScript, Golang, ObjectStorage\n- Mentor(s): Prem Saraswat(@prmsrswt), Bartek Plotka(@bwplotka)\n- Mentee: [Kunal Kushwaha @kunal-kushwaha](https://people.communitybridge.org/mentee/13a85bc2-0972-4f90-9f91-5d34bee5c15b,9595fbe7-6a8d-43d4-aebb-a54d57f33fdd)\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/3112\n- Community Bridge project (URL): https://people.communitybridge.org/project/f51284ab-f652-47b1-9819-cd4135e75c00\n\n#### Prometheus\n\n##### Add various post processing steps in query API after PromQL execution\n\n-\tDescription: The results from the query/query_range are often unordered w.r.t. the label values and sample value. Also, there is no limit on how many series the endpoint can return. In this project, we want to extend those query APIs to include options for post processing the output to do the following:\n * Support nested sorting (ascending/descending) of time series based on (1) Label values (2) Sample values for /query endpoint.\n * Support limiting the number of time series returned by query/query_range endpoint.\n * If time permits, expore how we can do nested sorting of time series for query_range API.\n-\tRecommended Skills: Go, PromQL\n-\tMentor(s): Bartek Plotka(@bwplotka), Ganesh Vernekar (@codesome)\n- Mentee (Communty Bridge URL): [Gayathri Venkatesh @GayathriVenkatesh](https://people.communitybridge.org/mentee/9bc4e5a8-41f4-4daa-9982-edaaeb8988b5,9595fbe7-6a8d-43d4-aebb-a54d57f33fdd)\n-\tUpstream Issue (URL): https://github.com/prometheus/prometheus/issues/7947, https://github.com/prometheus/prometheus/issues/7948\n- Community Bridge project (URL): https://people.communitybridge.org/project/9595fbe7-6a8d-43d4-aebb-a54d57f33fdd\n\n#### Open Service Mesh, Kuma and Service Mesh Interface\n\n##### Standards validation for OSM and Kuma\n\n- Description: As two of the service meshes in the CNCF, both Kuma and Open Service Mesh need their implementations of standard specifications validated. This is true for Service Mesh Interface (SMI) and Service Mesh Performance (SMP) specifications. Both API specifications spanning many service meshes. Each service mesh implementing the SMI and SMP specifciation need their conformance validated.\n- Recommended Skills: golang\n- Mentor(s): Lee Calcote (@leecalcote), Abishek Kumar (@kumarabd)\n- Mentee: [Dhruv Patel](https://people.communitybridge.org/mentee/bc370282-64a9-4bab-969f-28e13afca894,359dda52-7fb7-4fa8-82cd-a27216757a57)\n- Upstream Issue (URL): https://github.com/openservicemesh/osm/issues/172\n- Community Bridge project (URL): https://people.communitybridge.org/project/359dda52-7fb7-4fa8-82cd-a27216757a57\n\n#### Open Service Mesh\n\n##### Support for WebAssembly filters\n\n- Description: Bring OSM on par with other service meshes that support WASM filters in their data plane. OSM's Envoy proxies can be extended at runtime with filters that are running in a WebAssembly sandbox (https://github.com/envoyproxy/envoy-wasm). Provide ability to dynamically load and unload Envoy WASM filters.\n- Recommended Skills: golang, rust\n- Mentor(s): Lee Calcote (@leecalcote), Abishek Kumar (@kumarabd)\n- Mentee: [Kush Trivedi](https://people.communitybridge.org/mentee/9a0da751-ed41-442c-ba29-6f148de0d4dd,3918e3c7-c94e-4ff6-86cf-75affba454a1)\n- Upstream Issue (URL): https://github.com/openservicemesh/osm/issues/1671\n- Community Bridge project (URL): https://people.communitybridge.org/project/3918e3c7-c94e-4ff6-86cf-75affba454a1\n\n#### KubeEdge\n\n##### Support list-watch from edgecore for applications on the edge\n\n- Description: Some applications running on the edge side need to connect to the k8s master through list-watch interface, but on the edge it cannot directly connect to the k8s master. So we need forward the list-watch requests to the k8s master through the cloud-side channel.\n- Recommended Skills: KubeEdge, Kubernetes, golang\n- Mentor(s): Kevin Wang([@kevin-wangzefeng](https://github.com/kevin-wangzefeng)), Fei Xu([@fisherxu](https://github.com/fisherxu))\n- Mentee: [Rachel-Shao](https://people.communitybridge.org/mentee/eb993ee8-318f-420a-a076-2c13e1d9dd2f,1b931913-44a4-43a7-92ed-d7b2089060b1)\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/1758\n- Community Bridge project (URL): https://people.communitybridge.org/project/1b931913-44a4-43a7-92ed-d7b2089060b1\n\n##### Use device API both on cloud and edge\n\n- Description: Now we have defined device API in the cloud side, but the edgeside(edgecore and mapper) still don't use the API, we should refactor edgeside and use same API on cloud and edge to reduce complexity.\n- Recommended Skills: KubeEdge, Kubernetes, golang\n- Mentor(s): Kevin Wang([@kevin-wangzefeng](https://github.com/kevin-wangzefeng)), Fei Xu([@fisherxu](https://github.com/fisherxu))\n- Mentee: [Jinyong Mao](https://people.communitybridge.org/mentee/11f7a84a-931a-48ae-bbd2-9f7d8c38200a,1b931913-44a4-43a7-92ed-d7b2089060b1)\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/2140\n- Community Bridge project (URL): https://people.communitybridge.org/project/1b931913-44a4-43a7-92ed-d7b2089060b1\n\n##### Add EdgeGateway as the ingress gateway on Edge\n\n- Description: Add the EdgeGateway as the ingress gateway on Edge to dispatch request to multiple backend pods on the Edge side.\n- Recommended Skills: KubeEdge, Kubernetes, golang\n- Mentor(s): Kevin Wang([@kevin-wangzefeng](https://github.com/kevin-wangzefeng)), Fei Xu([@fisherxu](https://github.com/fisherxu))\n- Mentee: [Zhiling Feng](https://people.communitybridge.org/mentee/3c61a3d2-adfe-469a-8669-471e16c9c580,1b931913-44a4-43a7-92ed-d7b2089060b1)\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/1432\n- Community Bridge project (URL): https://people.communitybridge.org/project/1b931913-44a4-43a7-92ed-d7b2089060b1\n" }, { "path": "programs/lfx-mentorship/2021/01-Spring/README.md", "content": "## Q1\n\n_Status: Completed_\n\n### Timeline\n\n**Spring Term: March 1st - May 31st**\n\n- project applications open: Jan 20th - Jan 31st \\(1.5 weeks\\)\n- mentees applications open: Feb 1st - Feb 12th \\(2 weeks\\)\n- application review by the mentors/admission decisions/HR paperwork: Feb 15th - Feb 26th\n\nMentorship duration - three months \\(12 weeks - full-time schedule\\)\n\n- March 1 (Week 1): Mentorship program begins with the initial work assignments\n- April 12 (End of Week 6): Midterm mentee evaluations and first stipend payments\n- May 31 (End of Week 12): Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals\n\n## Participating Projects\n\n#### Kubernetes\n\n##### SIG Storage\n\n###### [Kubernetes working group for CSI driver](https://mentorship.lfx.linuxfoundation.org/project/51cb21c9-62eb-4e1c-9897-08e554a78b32)\n\n- Description: SContainer Storage Interface (CSI) is a standard for exposing storage systems to containerized workloads on Kubernetes. The idea is to enhance a few CSI features(e.g. NFS, SMB) and also add e2e, sanity tests to cover those features, e.g. inline volume support, Windows support etc.\n- Recommended Skills: golang, Kubernetes\n- Mentors: Andy Zhang (@andyzhangx)\n- Upstream Issue (URL):\n - https://github.com/kubernetes-csi/csi-driver-nfs/issues\n - https://github.com/kubernetes-csi/csi-driver-smb/issues\n\n##### WG Policy\n\n###### [CIS Benchmarks Policy Report](https://mentorship.lfx.linuxfoundation.org/project/0fd19dde-0990-4987-9ab3-2fe9b2ce26b2)\n\n- Description: Execute CIS benchmark checks and produce a Policy Report CRD.\n- Recommended Skills: Golang, CLI, JSON\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/wg-policy-prototypes/issues/29\n\n##### SIG Usability\n\n###### [Jobs-to-Be-Done study](https://mentorship.lfx.linuxfoundation.org/project/a06b291e-6cab-4506-8d32-2d15264e48dc)\n\nQualitative analysis of user interview recordings for Jobs-to-Be-done study\n\n- Description: SIG Usability is conducting a Jobs-to-Be-Done study meant to identify the highest impact areas for improving Kubernetes UX. We are in the process of conducting user interviews and need some help going back through the transcribed recordings to annotate and pull out insights from the conversations. Overall, this is a great opportunity for someone who’s studied or engaged in UX/IA/Usability to get involved in open source.\n- Recommended Skills: User Research, UX, synthesis\n- Mentors: Gaby Moreno (@morengab), Tasha Drew (@tashimi)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/sig-usability/issues/9\n\n##### SIG Architecture\n\n###### [Develop tools for evaluating dependency updates to Kubernetes](https://mentorship.lfx.linuxfoundation.org/project/7c510003-5f52-45c2-b5de-b6664851d3de)\n\n- Description: Implement command line utilities that can help Kubernetes developers evaluate new dependencies by capturing statistics/metrics and estimating cost of adding something new. This will involve diving deep into golang dependency chains (transitive/shared dependencies) and coming up with new metrics to estimate how burdensome something new can be or how much we will save by getting rid of something so we can prioritize work and get more efficient from a developer workflow perspective.\n- Recommended Skills: Golang, CLI\n- Mentor(s): Davanum Srinivas (@dims)\n- Upstream Issue (URL): [code organization meeting notes](https://docs.google.com/document/d/1HtTI0rJEGP_MSf6eO87aCmx_tzpovPAAg7U2Zxwm8FE/edit?ts=5c9d0a4c#heading=h.8phgvuqrxjsg)\n\n##### SIG Cluster Lifecycle\n\n###### [Add support for phases in \"kubeadm upgrade apply\"](https://mentorship.lfx.linuxfoundation.org/project/790f44dd-a690-4149-aad7-c7a5cbd7dc96)\n\n- Description: Implement support for \"phases\" in the \"upgrade apply\" command of kubeadm. Phases act like subcommands and allow granular execution of functiodnality.\n- Recommended Skills: Golang, CLI\n- Mentor(s): Lubomir I. Ivanov (@neolit123)\n- Upstream Issue (URL): https://github.com/kubernetes/kubeadm/issues/1318\n\n#### Keptn\n\n##### [Improve Prometheus integration and exposure of Prometheus metrics](https://mentorship.lfx.linuxfoundation.org/project/54adaade-8537-4150-b4ea-988454615ed7)\n\n- Description: In the current implementation the Prometheus integration in Keptn lacks customisability and configuration options. Also, Keptn core services should be instrumented to expose Prometheus metrics. The goal of this project is to refactor or rewrite the integration and add Prometheus to Keptn core services.\n- Recommended Skills: golang, experience with Prometheus\n- Mentor(s): Jürgen Etzlstorfer (@jetzlstorfer)\n- Upstream Issue (URL): https://github.com/keptn-contrib/prometheus-service/issues/53\n\n##### [Generate service skeleton via CLI](https://mentorship.lfx.linuxfoundation.org/project/630a656a-74ee-4494-9467-b10201ae9b20)\n\n- Description: Provide a CLI command for Keptn CLI that generates a template repository to start developing a Keptn service integration.\n- Recommended Skills: golang, go-templates, Docker\n- Mentor(s): Jürgen Etzlstorfer(@jetzlstorfer)\n- Upstream Issue (URL): https://github.com/keptn/keptn/issues/3034\n\n#### Kyverno\n\n##### [Monitor Kyverno with Prometheus](https://mentorship.lfx.linuxfoundation.org/project/e01ba557-af88-4716-8efe-398ce31a6fb2)\n\n- Description: Publish Kyverno policy execution metrics to Prometheus and Grafana\n- Recommended Skills: Golang, Prometheus\n- Mentor(s): Shuting Zhao (@realshuting)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/256\n\n##### [Integration of Kyverno with Litmus for chaos testing](https://mentorship.lfx.linuxfoundation.org/project/523735c3-9cb9-466f-977b-5719635a5ce7)\n\n- Description: Integrate Litmus Chaos testing with Kyevrno.\n- Recommended Skills: Golang, LitmusChaos\n- Mentor(s): Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/1622\n\n#### OpenTelemetry\n\n##### [Work through OpenTelemetry User Research Documentation and Implement Fixes](https://mentorship.lfx.linuxfoundation.org/project/08b86a82-9603-4b17-89b1-cace6b341c16)\n\n- Description: Implement the fixes suggested in the user research documentation to make this project more consumable for end users.\n- Recommended Skills: PHP\n- Mentor: Bob Strecansky (@bobstrecansky)\n- Upstream Issue (Project URL): https://github.com/open-telemetry/opentelemetry-php/projects/5\n\n#### TiKV\n\n##### [Coprocessor plugin](https://mentorship.lfx.linuxfoundation.org/project/f0bb4ba5-e7e9-4678-8cd1-75f7a7977381)\n\n- Description: Implement a basic coprocessor plugin runtime on top of Wasmer.\n- Recommended Skills: Rust\n- Mentor(s): Andy Lok (@andylokandy), Alex Chi (@skyzh)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/8036\n\n##### [Implement Jepsen test for TiKV](https://mentorship.lfx.linuxfoundation.org/project/1417be44-d2e2-4cdd-8ba7-9de70b87e1a2)\n\n- Description: Build an intergration test framework with Jepsen for TiKV,\n using the TiKV Rust client.\n- Recommended Skills: Rust/Clojure\n- Mentor(s): ZiQian Qin (@ekexium), Andy Lok (@andylokandy)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/9588\n\n##### [Build on Windows](https://mentorship.lfx.linuxfoundation.org/project/0b27faeb-8d89-4f25-aabf-a6e4908c8450)\n\n- Description: Make TiKV build and run on Windows.\n- Recommended Skills: Rust\n- Mentor(s): Andy Lok (@andylokandy)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/9103\n\n#### Tremor\n\n##### [Support for Syslog Protocol](https://mentorship.lfx.linuxfoundation.org/project/8e98bdb5-a131-4298-a195-31962d1a8564)\n\n- Description: Enable Tremor to receive and send Syslog Protocol Messages (https://tools.ietf.org/html/rfc5424) , supporting as much syslog implementations as possible that might deviate from the standard\n- Recommended Skills: Rust Programming (beginner is ok), some experience with syslog (beginner is ok)\n- Mentor(s): Matthias Wahl (@mfelsche), Anup Dhamala (@anupdhml)\n- Upstream Issue (URL): https://github.com/tremor-rs/tremor-runtime/issues/12\n\n##### [Continuous benchmarking and benchmarking infrastructure](https://mentorship.lfx.linuxfoundation.org/project/187dd140-0a0b-44f0-b5b8-23910692c1cf)\n\n- Description: Set up infrastructure for running Tremor benchmarks periodically\n- Recommended Skills: Rust Programming, Github CI, Shell scripting, Linux command line\n- Mentor(s): Anup Dhamala (@anupdhml), Darach Ennis (@darach)\n- Upstream Issue (URL): https://github.com/tremor-rs/tremor-runtime/issues/722\n\n##### [Property based tests for tremor-script](https://mentorship.lfx.linuxfoundation.org/project/04fda726-ab2a-4111-aaf2-3ec7b95771e5)\n\n- Description: Extend property-based testing for tremor script\n- Recommended Skills: Erlang Programming, Rust Programming, Property Based Testing (EQC)\n- Mentor(s): Heinz Gies (@Licenser), Matthias Wahl (@mfelsche)\n- Upstream Issue (URL): https://github.com/tremor-rs/tremor-runtime/issues/721\n\n##### [Google Cloud Connector](https://mentorship.lfx.linuxfoundation.org/project/4e30e06e-1e2e-4f0b-b618-834599446c0c)\n\n- Description: Enhance tremor with connectors for the Google Cloud Platform\n- Recommended Skills: Rust programming ( beginner is ok ), some experience with Google Cloud or other platforms\n- Mentor(s): Darach Ennis (@darach), Heinz Gies (@Licenser)\n- Upstream Issue (URL): https://github.com/tremor-rs/tremor-runtime/issues/724\n\n#### Chaos Mesh\n\n##### [Chaos Engineering as a Service](https://mentorship.lfx.linuxfoundation.org/project/5dd87db8-769b-4647-97c1-2bc4ab571808)\n\n- Description: Chaos Mesh is not like Chaos Engineering as a Service now:\n - Poor observability: the result of chaos experiments are not easy to observe and judge, the users need to check whether the Chaos effects by manual.\n - [Chaosd](https://github.com/chaos-mesh/chaosd)(for physic node) is too simple: only supports command line operation, does not support task scheduling and life cycle management.\n - The costs of learning operation and maintenance are high: the maintenance of Chaos Mesh and Chaosd are not unified.\n - It should be a unified place to manage Chaos experiments for multiple platforms and multiple clusters, and can see the monitoring data of the experiment.\n- Recommended Skills: Golang\n- Mentor(s): Wang Xiang (@[WangXiangUSTC](https://github.com/WangXiangUSTC))\n- Upstream Issue (URL): https://github.com/chaos-mesh/chaos-mesh/issues/1462\n\n##### [Enriching AWS chaos](https://mentorship.lfx.linuxfoundation.org/project/1d49ebad-29fa-430c-8492-44f29ee61cc1)\n\n- Description: We have already made a technical previewing implementation for AWS Chaos, it could inject some simple chaos now, such as stop/restart the EC2. And we want to make it more stable and structured. And there is another direction of AWS chaos: AWS service failure. It might be useful for testing infrastructure automation tools. Basically there are two things that we want to do: - enriching e2e test cases using localstack - more chaos by simulating AWS service failure by hijacking `awscli` request to a modified localstack\n- Recommended Skills: Golang, Python(Optional)\n- Mentor(s): Zhiqiang Zhou(@STRRL)\n- Upstream Issue (URL): https://github.com/chaos-mesh/chaos-mesh/issues/1472\n\n#### KubeEdge\n\n##### [Support multi-instance high availability cloudcore for large-scale cluster](https://mentorship.lfx.linuxfoundation.org/project/083f4362-1046-4939-9db7-fd0553de5875)\n\n- Description:Cloudcore is the core component of kubeegde in cloud, which is responsible for sending resources of cloud to the edge. Now the cloudcore is running in leader/follower mode, only one instance can run at the same time. For the more larger scale cluster, we need to support multi-instance high availability for cloudcore.\n- Recommended Skills: Golang, KubeEdge\n- Mentor(s): Kevin(Zefeng) Wang (@[kevin-wangzefeng](https://github.com/kevin-wangzefeng))\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/2543\n\n##### [Design more tests for specific scenarios of edge computing](https://mentorship.lfx.linuxfoundation.org/project/cf597b73-56fd-45b8-a605-5bb73f6b838d)\n\n- We need to do some designs for adding more tests especially for the specific scenarios of edge computing, eg:\n - Application migration when the network is disconnected\n - System stability when the network is unstable\n - Run large-scale cluster tests periodically\n- Recommended Skills: Golang, KubeEdge\n- Mentor(s): Fisher(Fei) Xu (@[fisherxu](https://github.com/fisherxu))\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/2544\n\n##### [Integration and verification of third-party CNI/CSI based on the edge side list-watch](https://mentorship.lfx.linuxfoundation.org/project/fc674c5f-3429-4591-9cae-8f58d347560f)\n\n- We need to integration and verification of third-party CNI/CSI for the edge applications.\n- Recommended Skills: Golang, KubeEdge\n- Mentor(s): Zhe Gong (@[GsssC](https://github.com/GsssC)), Fisher(Fei) Xu (@[fisherxu](https://github.com/fisherxu))\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/2545\n\n#### Thanos\n\n##### [Multi-Tenant Instrumentation for Thanos operations](https://mentorship.lfx.linuxfoundation.org/project/328fcf60-0dd2-425d-93a4-06046e4166fb)\n\n- Description: Thanos can store and serve the data for multiple tenants at once. However, currently, Thanos does not always provide the needed introspective information about actions related to the tenant (e.g external labels). Allowing admins to obtain tenants’ information on per tenant queries, operations and ingestion would give actionable insight and answer questions such as: What data is used/queried the most for a tenant X? During this mentorship, you will implement logic that will enormously improve the experience of running multi-tenant Thanos on the scale. You will learn more about Go, instrumentation, multitenancy, APIs, and SRE concepts like SLOs.\n- Recommended Skills: Go, Prometheus (basic), Instrumentation (basic)\n- Mentor(s): [@yashrsharma44](https://github.com/yashrsharma44), [@kakkoyun](https://github.com/kakkoyun)\n- Upstream Issue (URL):\n - https://github.com/thanos-io/thanos/issues/3572\n\n##### [Stateless Ruler](https://mentorship.lfx.linuxfoundation.org/project/74a898a5-d741-4c92-87c9-456541214395)\n\n- Description: Thanos Ruler is a critical component in Thanos that is responsible for the alert evaluation and recording rules. However, a few extensive rules can create a significant amount of resulting time-series, limiting the scalability of Thanos Rule, as it uses a single embedded TSDB. Recording/Alerting Rules are a substantial piece of monitoring infrastructure, so we want to ensure users can operate Rulers and scale them in an easy way. There is no way to scale rule evaluation and storage today except functionally sharding rules onto multiple instances of the Thanos Ruler component. Luckily, we have already solved scaling storage of time-series across various processes using Thanos Receiver. To scale rule evaluations and storage, during this mentorship, you will have a chance to implement the proposal that allows the Thanos rule component to have a stateless mode, storing results of queries by sending them to a Thanos receive hash-ring instead of storing them locally. You will learn about Go, Time-series databases, distributed system design, Prometheus, and of course Thanos.\n- Recommended Skills: Go\n- Mentor(s): [@bwplotka](https://github.com/bwplotka), [@squat](https://github.com/squat), [@kakkoyun](https://github.com/kakkoyun)\n- Upstream Issue (URL):\n - https://github.com/thanos-io/thanos/issues/3761\n\n##### [Vertical Block Sharding](https://mentorship.lfx.linuxfoundation.org/project/9920021d-11d2-4c7b-9534-c13e1b5660cc)\n\n- Description: Current Thanos topology is generally horizontally scalable. However, the use cases and approaches of deploying Thanos shifted through time. While initially, Thanos was enabling ingestion through sidecars, now it’s not uncommon to see Thanos receiver usage. This means that the invariant of definite size TSDB block is no longer true. With offline deduplication and arbitrary Receive tenants data can be ingested into huge, often hundreds GB size [TSDB blocks](https://thanos.io/tip/thanos/storage.md/#tsdb-block). This makes it harder to scale compaction and query operation on top of such blocks. The idea of this work is to vertically split larger blocks into smaller ones with the common scaling technique called sharding. As a mentee, we will guide you to make progress towards this goal by teaming up with experienced developers to deliver transparent automation for vertical block sharding! We are looking forward to working with you! During this mentorship, you will learn a lot about programming in Go, distributed Systems, TimeSeries Database, Prometheus, Thanos!\n- Recommended Skills: Go\n- Mentor(s): [@bwplotka](https://github.com/bwplotka), [@kakkoyun](https://github.com/kakkoyun)\n- Upstream Issue (URL):\n - https://github.com/thanos-io/thanos/issues/3068\n\n##### [gRPC Exemplars API](https://mentorship.lfx.linuxfoundation.org/project/7ce99708-8ead-40df-ba12-6ed02f639c04)\n\n- Description: Exemplars are an amazing solution that allows linking metrics to logs, traces, and more! Recently Prometheus added support to Exemplars as defined by OpenMetrics API. In Thanos with our powerful deployment flexibility, we can allow federating Exemplars up to multi-cluster, global level! During this task mentee will develop together with mentors a new gRPC API that allows to access Prometheus exemplars on Thanos level. This is a work item bringing novel and edge technology to the open-source, which will enormously help Thanos users. During this mentorship, you will learn a lot about programming in Go, distributed Systems, gRPC Observability, Prometheus, Thanos!\n- Recommended Skills: Go, gRPC\n- Mentor(s): [@squat](https://github.com/squat), [@prmsrswt](https://github.com/prmsrswt)\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/3435\n\n#### Crossplane\n\n##### [Crisscross - Write controllers in your language of choice](https://mentorship.lfx.linuxfoundation.org/project/55f5e428-bf78-480d-81db-55eef0c4d293)\n\n- Description: Crossplane provides a broad library of Kubernetes custom resources that let you orchestrate systems external to Kubernetes. These include AWS S3 buckets, GCP CloudSQL instances, Azure Cosmos tables, plain old SQL databases, Helm releases, and Dominos pizzas. We call these 'managed resources'. Crossplane's goal is to allow platform teams to build their own custom resources that are in turn composed of these primitives without needing to write Kubernetes controllers in Go. [Crisscross](https://github.com/hasheddan/crisscross) is an experimental project that lets folks add new managed resources to Crossplane without writing Go code. We would love help fleshing out the Crisscross proof of concept. This will likely take the form of writing a web service with endpoints that accept CRUD verbs from Crossplane and uses them to orchstrate an external system - for example CRUDing a DigitalOcean Droplet or an OpenStack Server. Familiarity with Go is a bonus (Crisscross itself is written in Go), but not necessary (Crisscross managed resources can be written in any language).\n- Recommended Skills: Programming REST APIs in any language. Some Go experience, or interest in learning.\n- Mentor(s): @hasheddan, @muvaf, @jbw976\n- Upstream Issue (URL): https://github.com/crossplane/crossplane/issues/2109\n\n##### [Import cloud resources into Crossplane](https://mentorship.lfx.linuxfoundation.org/project/c63704b7-7199-486a-b715-4f17e4cf64ef)\n\n- Description: Crossplane provides a broad library of Kubernetes custom resources that let you orchestrate systems external to Kubernetes. These include AWS S3 buckets, GCP CloudSQL instances, Azure Cosmos tables, plain old SQL databases, Helm releases, and Dominos pizzas. We call these 'managed resources'. Crossplane's goal is to allow platform teams to build their own custom resources that are in turn composed of these primitives without needing to write Kubernetes controllers in Go. Crossplane currently supports 'importing' your existing cloud infrastructure (databases etc) into Crossplane management, but doing so is onerous. You need to write Crossplane YAML that exactly matches the current state of your infrastructure. Ideally Crossplane would provide an import tool that our users could point at an existing RDS instance (for example) in order to generate the Crossplane YAML that represented that instance.\n- Recommended Skills: Ideally Go programming, though we'd consider prototyping this tool in another language.\n- Mentor(s): @muvaf, @hasheddan, @jbw976\n- Upstream Issue (URL): https://github.com/crossplane/crossplane/issues/1243\n\n##### [Automated end-to-end testing infrastructure](https://mentorship.lfx.linuxfoundation.org/project/2e2239cf-2964-434f-a5c9-676b857fc29a)\n\n- Description: Crossplane provides a broad library of Kubernetes custom resources that let you orchestrate systems external to Kubernetes. These include AWS S3 buckets, GCP CloudSQL instances, Azure Cosmos tables, plain old SQL databases, Helm releases, and Dominos pizzas. We call these 'managed resources'. Crossplane's goal is to allow platform teams to build their own custom resources that are in turn composed of these primitives without needing to write Kubernetes controllers in Go. Crossplane currently has extensive unit testing, but not much in the way of automated integration/e2e tests. We have a very broad surface area to test (we have around a hundred controllers that interact with cloud providers) and would like to establish some integration testing best practices so that the community can easily contribute integration tests when they work on Crossplane.\n- Recommended Skills: Go programming, testing best practices.\n- Mentor(s): @hasheddan, @muvaf, @jbw976\n- Upstream Issue (URL): https://github.com/crossplane/crossplane/issues/1033\n\n#### OpenEBS\n\n##### [A easy to use command-line interface (CLI) for OpenEBS](https://mentorship.lfx.linuxfoundation.org/project/ca619db0-1b2d-4fbb-a9a7-d4d24c4340c3)\n\n- Description: OpenEBS is completely Kubernetes native and is implemented using microservices. OpenEBS can be installed via kubectl or helm chart and managed via Kubernetes custom resources. To improve the usability of OpenEBS, the proposal is to have a easy to use OpenEBS CLI (similar to `kubectl`) to perform operations like:\n - upgrade => Upgrade OpenEBS pools and volumes\n - status => Print the readiness of various components, verify prerequisites are met to run openebs pools and volumes.\n - version => Print the OpenEBS version and associated images\n - describe => Describe OpenEBS component status like component/control plane, pools and volumes.\n - create => Create OpenEBS resources\n - delete => Delete OpenEBS resources\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Kiran Mova (@kmova)\n- Upstream Issues (URL): https://github.com/openebs/openebs/issues/2946\n\n##### [Grafana Dashboards for monitoring OpenEBS](https://mentorship.lfx.linuxfoundation.org/project/d797e3e7-a036-4aa1-831a-fd06b00ed316)\n\n- Description: OpenEBS is completely Kubernetes native and is implemented using microservices. OpenEBS can be installed via kubectl or helm chart and managed via Kubernetes custom resources. Each of the OpenEBS components/services expose prometheus metrics. This proposal is to provide Grafana dashboards for monitoring the OpenEBS services.\n- Recommended Skills: Go, Kubernetes, Grafana, Prometheus\n- Mentor(s): Kiran Mova (@kmova)\n- Upstream Issues (URL): https://github.com/openebs/openebs/issues/3333\n\n#### Volcano\n\n##### [Enhanced Support to GPU](https://mentorship.lfx.linuxfoundation.org/project/4d74f4f4-7eb0-4568-8e25-c58a736c08dd)\n\n- Description: Volcano has supported GPU sharing, but not enough. It's a lack of supporting multiple GPUs used for one container in device plugin. Your task is to complete related features about GPU support.\n- Recommended Skills: Go(basic), Kubernetes(basic), Volcano\n- Mentor(s): [@William-Wang](https://github.com/william-wang)\n- Upstream Issue (URL):\n - https://github.com/volcano-sh/devices/issues/12\n\n##### [System Stability Enhancement](https://mentorship.lfx.linuxfoundation.org/project/79b69ae1-0ce4-46a6-affe-6338022ff40a)\n\n- Description: Add more UT/E2E to cover more classical scenarios. Conduct complete stress testing and regression testing, Offer test report, give the improvement plan and put it into practice.\n- Recommended Skills: Go, Test\n- Mentor(s): [@Thor-wl](https://github.com/Thor-wl), [@William-Wang](https://github.com/william-wang)\n- Upstream Issue (URL):\n - https://github.com/volcano-sh/volcano/issues/1284\n\n##### [Reading Materials Update And Supplement](https://mentorship.lfx.linuxfoundation.org/project/3562429e-6650-49e5-bcac-87095cdb0622)\n\n- Description: In order to make volcano easy to use and understand, you task is to improve reading materials.\n- Recommended Skills: English, Volcano\n- Mentor(s): [@Thor-wl](https://github.com/Thor-wl)\n- Upstream Issue (URL):\n - https://github.com/volcano-sh/volcano/issues/1285\n\n#### Project Rekor\n\n##### [CNCF release signing security](https://mentorship.lfx.linuxfoundation.org/project/8ffde3ac-79a5-4715-8d4d-10f2ce952536)\n\n- Description: [Rekor](https://rekor.dev) is a new project that provides a secure supply chain transparency log / ledger. The proposed work is to research how CNCF projects could implement cryptographic signing of releases and store those signatures into rekors transparency log. Following this, simple steps and methods should be outlined for how users can gain security guarantees on releases available for download.\n- Recommended Skills: Scripting, Github, information security (understand basic application of crypto signing, for example GPG).\n- Mentor(s): @lukehinds, @dlorenc, @bobcallaway\n- Upstream Issue (URL): https://github.com/projectrekor/rekor/issues/144\n\n#### LitmusChaos\n\n##### [Add event & alerts infrastructure to the litmus portal](https://mentorship.lfx.linuxfoundation.org/project/d9968740-faa6-4f6a-a943-dc9f427fd81c)\n\n- Description: [LitmusChaos](https://litmuschaos.io) is a Kubernetes native chaos engineering framework that helps SREs & developers find weaknesses in their deployments, with the chaos intent being defined via custom resources. The Litmus portal is a dashboard focused on simplifying the chaos-engineering experience for users and allows execution of complex \"chaos workflows\" that comprise one or more chaos experiments. This portal dashboard needs to be improved to hold more observability information, primarily in the form of an event log & alerts to help users gather important information about the state of the chaos experiments & cluster in general.\n- Recommended Skills: Golang, Typescript\n- Mentor(s): @gdsoumya, @ksatchit\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/2429\n\n#### SPIFFE/SPIRE\n\n##### [Design and implement a health/status subsystem in SPIRE](https://mentorship.lfx.linuxfoundation.org/project/5c4a200d-b81e-4332-bea6-50120fbf28b4)\n\n- Description: [SPIRE](https://spiffe.io), the SPIFFE Runtime Environment, is an extensible system that implements the principles embodied in the SPIFFE standards. SPIRE manages platform and workload attestation, provides an API for controlling attestation policies, and coordinates certificate issuance and rotation. Being a critical system, it is important that operators be able to monitor (and respond to) the current health/state of their SPIRE deployments. To do this, SPIRE needs to grow a full-featured health subsystem that is capable of collecting the status of other subsystems and reporting on it. In this project, you will design and implement this new subsystem with the help and guidance of the SPIRE maintainers.\n- Recommended Skills: Go\n- Mentor(s): Andrew Harding (@azdagron), Evan Gilman (@evan2645)\n- Upstream Issue (URL): https://github.com/spiffe/spire/issues/2047\n\n#### Cloud Native Buildpacks\n\n##### [Design and implement Buildpack Registry Search](https://mentorship.lfx.linuxfoundation.org/project/4b711f9e-90f8-486a-90fc-d832e1c852ca)\n\n- Description: The [Buildpack Registry](https://github.com/buildpacks/rfcs/blob/main/text/0022-client-side-buildpack-registry.md) is a place to publish, store, and discover buildpacks. It will provide a centralized service that platforms can use to resolve a buildpack ID and version into a concrete buildpack that can be downloaded and used. The search service will extend the existing [registry index stored in git](https://github.com/buildpacks/registry-index) in a way that can be consumed on the web as defined in this [RFC](https://github.com/buildpacks/rfcs/blob/main/text/0068-buildpack-registry-search-api.md).\n- Recommended Skills: React, CSS, Ruby, Rails, Github\n- Mentor(s): Joe Kutner (@jkutner), Travis Longoria (@elbandito)\n- Upstream Issue (URL): https://github.com/buildpacks/registry-api/issues/21\n\n" }, { "path": "programs/lfx-mentorship/2021/01-Spring/project_ideas.md", "content": "## Projects ideas\n\nProject maintainers and mentors, please submit the ideas below (under the Proposed Project Ideas section) section using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n### Template\n\n```\n#### CNCF Project Name\n##### Title\n\n-\tDescription:\n-\tRecommended Skills:\n-\tMentor(s):\n-\tUpstream Issue (URL):\n```\n\n### Sample:\n\n#### Prometheus (sample)\n\n##### Refactor the APIs for better readability and less maintenance overhead\n\n- Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n- Recommended Skills: golang\n- Mentor(s): Krasi Georgiev (@krasi-georgiev)\n- Issue: https://github.com/prometheus/prometheus/issues/3416\n\n### Proposed Project ideas\n\n#### Kubernetes\n\n##### WG Policy\n\n###### CIS Benchmarks Policy Report\n\n- Description: Execute CIS benchmark checks and produce a Policy Report CRD.\n- Recommended Skills: Golang, CLI, JSON\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/wg-policy-prototypes/issues/29\n\n##### SIG Usability\n\n###### Jobs-to-Be-Done study\n\nQualitative analysis of user interview recordings for Jobs-to-Be-done study\n\n- Description: SIG Usability is conducting a Jobs-to-Be-Done study meant to identify the highest impact areas for improving Kubernetes UX. We are in the process of conducting user interviews and need some help going back through the transcribed recordings to annotate and pull out insights from the conversations. Overall, this is a great opportunity for someone who’s studied or engaged in UX/IA/Usability to get involved in open source.\n- Recommended Skills: User Research, UX, synthesis\n- Mentors: Gaby Moreno (@morengab), Tasha Drew (@tashimi)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/sig-usability/issues/9\n\n##### SIG Architecture\n\n###### Develop tools for evaluating dependency updates to Kubernetes\n\n- Description: Implement command line utilities that can help Kubernetes developers evaluate new dependencies by capturing statistics/metrics and estimating cost of adding something new. This will\n involve diving deep into golang dependency chains (transitive/shared dependencies) and coming up with new metrics to estimate how burdensome something new can be or how much we will save by getting\n rid of something so we can prioritize work and get more efficient from a developer workflow perspective.\n- Recommended Skills: Golang, CLI\n- Mentor(s): Davanum Srinivas (@dims)\n- Upstream Issue (URL): [code organization meeting notes](https://docs.google.com/document/d/1HtTI0rJEGP_MSf6eO87aCmx_tzpovPAAg7U2Zxwm8FE/edit?ts=5c9d0a4c#heading=h.8phgvuqrxjsg)\n\n##### SIG Cluster Lifecycle\n\n###### Add support for phases in \"kubeadm upgrade apply\"\n\n- Description: Implement support for \"phases\" in the \"upgrade apply\" command of kubeadm. Phases act like subcommands and allow granular execution of functiodnality.\n- Recommended Skills: Golang, CLI\n- Mentor(s): Lubomir I. Ivanov (@neolit123)\n- Upstream Issue (URL): https://github.com/kubernetes/kubeadm/issues/1318\n\n#### Keptn\n\n##### Improve Prometheus integration and exposure of Prometheus metrics\n\n- Description: In the current implementation the Prometheus integration in Keptn lacks customisability and configuration options. Also, Keptn core services should be instrumented to expose Prometheus metrics. The goal of this project is to refactor or rewrite the integration and add Prometheus to Keptn core services.\n- Recommended Skills: golang, experience with Prometheus\n- Mentor(s): Jürgen Etzlstorfer (@jetzlstorfer)\n- Upstream Issue (URL): https://github.com/keptn-contrib/prometheus-service/issues/53\n\n##### Generate service skeleton via CLI\n\n- Description: Provide a CLI command for Keptn CLI that generates a template repository to start developing a Keptn service integration.\n- Recommended Skills: golang, go-templates, Docker\n- Mentor(s): Jürgen Etzlstorfer(@jetzlstorfer)\n- Upstream Issue (URL): https://github.com/keptn/keptn/issues/3034\n\n#### Kyverno\n\n##### Monitor Kyverno with Prometheus\n\n- Description: Publish Kyverno policy execution metrics to Prometheus and Grafana\n- Recommended Skills: Golang, Prometheus\n- Mentor(s): Shuting Zhao (@realshuting)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/256\n\n##### Integration of Kyverno with Litmus for chaos testing\n\n- Description: Integrate Litmus Chaos testing with Kyevrno.\n- Recommended Skills: Golang, LitmusChaos\n- Mentor(s): Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/1622\n\n#### OpenTelemetry\n\n##### Work through OpenTelemetry User Research Documentation and Implement Fixes\n\n- Description: Implement the fixes suggested in the user research documentation to make this project more consumable for end users.\n- Recommended Skills: PHP\n- Mentor: Bob Strecansky (@bobstrecansky)\n- Upstream Issue (Project URL): https://github.com/open-telemetry/opentelemetry-php/projects/5\n\n#### TiKV\n\n##### Coprocessor plugin\n\n- Description: Implement a basic coprocessor plugin runtime on top of Wasmer.\n- Recommended Skills: Rust\n- Mentor(s): Andy Lok (@andylokandy), Alex Chi (@skyzh)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/8036\n\n##### Implement Jepsen test for TiKV\n\n- Description: Build an intergration test framework with Jepsen for TiKV,\n using the TiKV Rust client.\n- Recommended Skills: Rust/Clojure\n- Mentor(s): ZiQian Qin (@ekexium), Andy Lok (@andylokandy)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/9588\n\n##### Build on Windows\n\n- Description: Make TiKV build and run on Windows.\n- Recommended Skills: Rust\n- Mentor(s): Andy Lok (@andylokandy)\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/9103\n\n#### Tremor\n\n##### Support for Syslog Protocol\n\n- Description: Enable Tremor to receive and send Syslog Protocol Messages (https://tools.ietf.org/html/rfc5424) , supporting as much syslog implementations as possible that might deviate from the standard\n- Recommended Skills: Rust Programming (beginner is ok), some experience with syslog (beginner is ok)\n- Mentor(s): Matthias Wahl (@mfelsche), Anup Dhamala (@anupdhml)\n- Upstream Issue (URL): https://github.com/tremor-rs/tremor-runtime/issues/12\n\n##### Continuous benchmarking and benchmarking infrastructure\n\n- Description: Set up infrastructure for running Tremor benchmarks periodically\n- Recommended Skills: Rust Programming, Github CI, Shell scripting, Linux command line\n- Mentor(s): Anup Dhamala (@anupdhml), Darach Ennis (@darach)\n- Upstream Issue (URL): https://github.com/tremor-rs/tremor-runtime/issues/722\n\n##### Property based tests for tremor-script\n\n- Description: Extend property-based testing for tremor script\n- Recommended Skills: Erlang Programming, Rust Programming, Property Based Testing (EQC)\n- Mentor(s): Heinz Gies (@Licenser), Matthias Wahl (@mfelsche)\n- Upstream Issue (URL): https://github.com/tremor-rs/tremor-runtime/issues/721\n\n##### Google Cloud Connector\n\n- Description: Enhance tremor with connectors for the Google Cloud Platform\n- Recommended Skills: Rust programming ( beginner is ok ), some experience with Google Cloud or other platforms\n- Mentor(s): Darach Ennis (@darach), Heinz Gies (@Licenser)\n- Upstream Issue (URL): https://github.com/tremor-rs/tremor-runtime/issues/724\n\n#### Chaos Mesh\n\n##### Chaos Engineering as a Service\n\n- Description: Chaos Mesh is not like Chaos Engineering as a Service now:\n\n - Poor observability: the result of chaos experiments are not easy to observe and judge, the users need to check whether the Chaos effects by manual.\n - [Chaosd](https://github.com/chaos-mesh/chaosd)(for physic node) is too simple: only supports command line operation, does not support task scheduling and life cycle management.\n - The costs of learning operation and maintenance are high: the maintenance of Chaos Mesh and Chaosd are not unified.\n\n It should a unified place to manage Chaos experiments for multiple platforms and multiple clusters, and can see the monitoring data of the experiment.\n\n- Recommended Skills: Golang\n- Mentor(s): Wang Xiang (@[WangXiangUSTC](https://github.com/WangXiangUSTC))\n- Upstream Issue (URL): https://github.com/chaos-mesh/chaos-mesh/issues/1462\n\n##### Enriching AWS chaos\n\n- Description: We have already made a technical previewing implementation for AWS Chaos, it could inject some simple chaos now, such as stop/restart the EC2. And we want to make it more stable and structured. And there is another direction of AWS chaos: AWS service failure. It might be useful for testing infrastructure automation tools. Basically there are two things that we want to do: - enriching e2e test cases using localstack - more chaos by simulating AWS service failure by hijacking `awscli` request to a modified localstack\n- Recommended Skills: Golang, Python(Optional)\n- Mentor(s): Zhiqiang Zhou(@STRRL)\n- Upstream Issue (URL): https://github.com/chaos-mesh/chaos-mesh/issues/1472\n\n#### KubeEdge\n\n##### Support multi-instance high availability cloudcore for large-scale cluster\n\n- Description:Cloudcore is the core component of kubeegde in cloud, which is responsible for sending resources of cloud to the edge. Now the cloudcore is running in leader/follower mode, only one instance can run at the same time. For the more larger scale cluster, we need to support multi-instance high availability for cloudcore.\n- Recommended Skills: Golang, KubeEdge\n- Mentor(s): Kevin(Zefeng) Wang (@[kevin-wangzefeng](https://github.com/kevin-wangzefeng))\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/2543\n\n##### Design more tests for specific scenarios of edge computing\n\n- We need to do some designs for adding more tests especially for the specific scenarios of edge computing, eg:\n - Application migration when the network is disconnected\n - System stability when the network is unstable\n - Run large-scale cluster tests periodically\n- Recommended Skills: Golang, KubeEdge\n- Mentor(s): Fisher(Fei) Xu (@[fisherxu](https://github.com/fisherxu))\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/2544\n\n##### Integration and verification of third-party CNI/CSI based on the edge side list-watch\n\n- We need to integration and verification of third-party CNI/CSI for the edge applications.\n- Recommended Skills: Golang, KubeEdge\n- Mentor(s): Zhe Gong (@[GsssC](https://github.com/GsssC)), Fisher(Fei) Xu (@[fisherxu](https://github.com/fisherxu))\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/2545\n\n#### Thanos\n\n##### Multi-Tenant Instrumentation for Thanos operations\n\n- Description: Thanos can store and serve the data for multiple tenants at once. However, currently, Thanos does not always provide the needed introspective information about actions related to the tenant (e.g external labels). Allowing admins to obtain tenants’ information on per tenant queries, operations and ingestion would give actionable insight and answer questions such as: What data is used/queried the most for a tenant X? During this mentorship, you will implement logic that will enormously improve the experience of running multi-tenant Thanos on the scale. You will learn more about Go, instrumentation, multitenancy, APIs, and SRE concepts like SLOs.\n- Recommended Skills: Go, Prometheus (basic), Instrumentation (basic)\n- Mentor(s): [@yashrsharma44](https://github.com/yashrsharma44), [@kakkoyun](https://github.com/kakkoyun)\n- Upstream Issue (URL):\n - https://github.com/thanos-io/thanos/issues/3572\n\n##### Stateless Ruler\n\n- Description: Thanos Ruler is a critical component in Thanos that is responsible for the alert evaluation and recording rules. However, a few extensive rules can create a significant amount of resulting time-series, limiting the scalability of Thanos Rule, as it uses a single embedded TSDB. Recording/Alerting Rules are a substantial piece of monitoring infrastructure, so we want to ensure users can operate Rulers and scale them in an easy way. There is no way to scale rule evaluation and storage today except functionally sharding rules onto multiple instances of the Thanos Ruler component. Luckily, we have already solved scaling storage of time-series across various processes using Thanos Receiver. To scale rule evaluations and storage, during this mentorship, you will have a chance to implement the proposal that allows the Thanos rule component to have a stateless mode, storing results of queries by sending them to a Thanos receive hash-ring instead of storing them locally. You will learn about Go, Time-series databases, distributed system design, Prometheus, and of course Thanos.\n- Recommended Skills: Go\n- Mentor(s): [@bwplotka](https://github.com/bwplotka), [@squat](https://github.com/squat), [@kakkoyun](https://github.com/kakkoyun)\n- Upstream Issue (URL):\n - https://github.com/thanos-io/thanos/issues/3761\n\n##### Vertical Block Sharding\n\n- Description: Current Thanos topology is generally horizontally scalable. However, the use cases and approaches of deploying Thanos shifted through time. While initially, Thanos was enabling ingestion through sidecars, now it’s not uncommon to see Thanos receiver usage. This means that the invariant of definite size TSDB block is no longer true. With offline deduplication and arbitrary Receive tenants data can be ingested into huge, often hundreds GB size [TSDB blocks](https://thanos.io/tip/thanos/storage.md/#tsdb-block). This makes it harder to scale compaction and query operation on top of such blocks. The idea of this work is to vertically split larger blocks into smaller ones with the common scaling technique called sharding. As a mentee, we will guide you to make progress towards this goal by teaming up with experienced developers to deliver transparent automation for vertical block sharding! We are looking forward to working with you! During this mentorship, you will learn a lot about programming in Go, distributed Systems, TimeSeries Database, Prometheus, Thanos!\n- Recommended Skills: Go\n- Mentor(s): [@bwplotka](https://github.com/bwplotka), [@kakkoyun](https://github.com/kakkoyun)\n- Upstream Issue (URL):\n - https://github.com/thanos-io/thanos/issues/3068\n\n##### gRPC Exemplars API\n\n- Description: Exemplars are an amazing solution that allows linking metrics to logs, traces, and more! Recently Prometheus added support to Exemplars as defined by OpenMetrics API. In Thanos with our powerful deployment flexibility, we can allow federating Exemplars up to multi-cluster, global level! During this task mentee will develop together with mentors a new gRPC API that allows to access Prometheus exemplars on Thanos level. This is a work item bringing novel and edge technology to the open-source, which will enormously help Thanos users. During this mentorship, you will learn a lot about programming in Go, distributed Systems, gRPC Observability, Prometheus, Thanos!\n- Recommended Skills: Go, gRPC\n- Mentor(s): [@squat](https://github.com/squat), [@prmsrswt](https://github.com/prmsrswt)\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/3435\n\n#### OpenEBS\n\n##### A easy to use command-line interface (CLI) for OpenEBS.\n\n- Description: OpenEBS is completely Kubernetes native and is implemented using microservices. OpenEBS can be installed via kubectl or helm chart and managed via Kubernetes custom resources. To improve the usability of OpenEBS, the proposal is to have a easy to use OpenEBS CLI (similar to `kubectl`) to perform operations like:\n\n - upgrade => Upgrade OpenEBS pools and volumes\n - status => Print the readiness of various components, verify prerequisites are met to run openebs pools and volumes.\n - version => Print the OpenEBS version and associated images\n - describe => Describe OpenEBS component status like component/control plane, pools and volumes.\n - create => Create OpenEBS resources\n - delete => Delete OpenEBS resources\n\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Kiran Mova (@kmova)\n- Upstream Issues (URL): https://github.com/openebs/openebs/issues/2946\n\n##### Grafana Dashboards for monitoring OpenEBS.\n\n- Description: OpenEBS is completely Kubernetes native and is implemented using microservices. OpenEBS can be installed via kubectl or helm chart and managed via Kubernetes custom resources. Each of the OpenEBS components/services expose prometheus metrics. This proposal is to provide Grafana dashboards for monitoring the OpenEBS services.\n\n- Recommended Skills: Go, Kubernetes, Grafana, Prometheus\n- Mentor(s): Kiran Mova (@kmova)\n- Upstream Issues (URL): https://github.com/openebs/openebs/issues/3333\n\n#### Volcano\n\n##### Enhanced Support to GPU\n\n- Description: Volcano has supported GPU sharing, but not enough. It's a lack of supporting multiple GPUs used for one container in device plugin. Your task is to complete related features about GPU support.\n- Recommended Skills: Go(basic), Kubernetes(basic), Volcano\n- Mentor(s): [@William-Wang](https://github.com/william-wang)\n- Upstream Issue (URL):\n - https://github.com/volcano-sh/devices/issues/12\n\n##### System Stability Enhancement\n\n- Description: Add more UT/E2E to cover more classical scenarios. Conduct complete stress testing and regression testing, Offer test report, give the improvement plan and put it into practice.\n- Recommended Skills: Go, Test\n- Mentor(s): [@Thor-wl](https://github.com/Thor-wl), [@William-Wang](https://github.com/william-wang)\n- Upstream Issue (URL):\n - https://github.com/volcano-sh/volcano/issues/1284\n\n##### Reading Materials Update And Supplement\n\n- Description: In order to make volcano easy to use and understand, you task is to improve reading materials.\n- Recommended Skills: English, Volcano\n- Mentor(s): [@Thor-wl](https://github.com/Thor-wl)\n- Upstream Issue (URL):\n - https://github.com/volcano-sh/volcano/issues/1285\n\n#### Crossplane\n\n##### Crisscross - Write controllers in your language of choice\n\n- Description: Crossplane provides a broad library of Kubernetes custom resources that let you orchestrate systems external to Kubernetes. These include AWS S3 buckets, GCP CloudSQL instances, Azure Cosmos tables, plain old SQL databases, Helm releases, and Dominos pizzas. We call these 'managed resources'. Crossplane's goal is to allow platform teams to build their own custom resources that are in turn composed of these primitives without needing to write Kubernetes controllers in Go. [Crisscross](https://github.com/hasheddan/crisscross) is an experimental project that lets folks add new managed resources to Crossplane without writing Go code. We would love help fleshing out the Crisscross proof of concept. This will likely take the form of writing a web service with endpoints that accept CRUD verbs from Crossplane and uses them to orchstrate an external system - for example CRUDing a DigitalOcean Droplet or an OpenStack Server. Familiarity with Go is a bonus (Crisscross itself is written in Go), but not necessary (Crisscross managed resources can be written in any language).\n- Recommended Skills: Programming REST APIs in any language. Some Go experience, or interest in learning.\n- Mentor(s): @hasheddan, @negz, @jbw976\n- Upstream Issue (URL): https://github.com/crossplane/crossplane/issues/2109\n\n##### Import cloud resources into Crossplane\n\n- Description: Crossplane provides a broad library of Kubernetes custom resources that let you orchestrate systems external to Kubernetes. These include AWS S3 buckets, GCP CloudSQL instances, Azure Cosmos tables, plain old SQL databases, Helm releases, and Dominos pizzas. We call these 'managed resources'. Crossplane's goal is to allow platform teams to build their own custom resources that are in turn composed of these primitives without needing to write Kubernetes controllers in Go. Crossplane currently supports 'importing' your existing cloud infrastructure (databases etc) into Crossplane management, but doing so is onerous. You need to write Crossplane YAML that exactly matches the current state of your infrastructure. Ideally Crossplane would provide an import tool that our users could point at an existing RDS instance (for example) in order to generate the Crossplane YAML that represented that instance.\n- Recommended Skills: Ideally Go programming, though we'd consider prototyping this tool in another language.\n- Mentor(s): @negz, @hasheddan, @jbw976\n- Upstream Issue (URL): https://github.com/crossplane/crossplane/issues/1243\n\n##### Automated end-to-end testing infrastructure\n\n- Description: Crossplane provides a broad library of Kubernetes custom resources that let you orchestrate systems external to Kubernetes. These include AWS S3 buckets, GCP CloudSQL instances, Azure Cosmos tables, plain old SQL databases, Helm releases, and Dominos pizzas. We call these 'managed resources'. Crossplane's goal is to allow platform teams to build their own custom resources that are in turn composed of these primitives without needing to write Kubernetes controllers in Go. Crossplane currently has extensive unit testing, but not much in the way of automated integration/e2e tests. We have a very broad surface area to test (we have around a hundred controllers that interact with cloud providers) and would like to establish some integration testing best practices so that the community can easily contribute integration tests when they work on Crossplane.\n- Recommended Skills: Go programming, testing best practices.\n- Mentor(s): @hasheddan, @negz, @jbw976\n- Upstream Issue (URL): https://github.com/crossplane/crossplane/issues/1033\n\n#### Project Rekor\n\n##### CNCF release signing security\n\n- Description: [Rekor](https://rekor.dev) is a new project that provides a secure supply chain transparency log / ledger. The proposed work is to research how CNCF projects could implement cryptographic signing of releases and store those signatures into rekors transparency log. Following this, simple steps and methods should be outlined for how users can gain security guarantees on releases available for download.\n- Recommended Skills: Scripting, Github, information security (understand basic application of crypto signing, for example GPG).\n- Mentor(s): @lukehinds, @dlorenc, @bobcallaway\n- Upstream Issue (URL): https://github.com/projectrekor/rekor/issues/144\n\n#### LitmusChaos\n\n##### Add event & alerts infrastructure to the litmus portal\n\n- Description: [LitmusChaos](https://litmuschaos.io) is a Kubernetes native chaos engineering framework that helps SREs & developers find weaknesses in their deployments, with the chaos intent being defined via custom resources. The Litmus portal is a dashboard focused on simplifying the chaos-engineering experience for users and allows execution of complex \"chaos workflows\" that comprise one or more chaos experiments. This portal dashboard needs to be improved to hold more observability information, primarily in the form of an event log & alerts to help users gather important information about the state of the chaos experiments & cluster in general.\n\n- Recommended Skills: Golang, Typescript\n- Mentor(s): @gdsoumya, @ksatchit\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/2429\n\n#### SPIFFE/SPIRE\n\n##### Design and implement a health/status subsystem in SPIRE\n\n- Description: [SPIRE](https://spiffe.io), the SPIFFE Runtime Environment, is an extensible system that implements the principles embodied in the SPIFFE standards. SPIRE manages platform and workload attestation, provides an API for controlling attestation policies, and coordinates certificate issuance and rotation. Being a critical system, it is important that operators be able to monitor (and respond to) the current health/state of their SPIRE deployments. To do this, SPIRE needs to grow a full-featured health subsystem that is capable of collecting the status of other subsystems and reporting on it. In this project, you will design and implement this new subsystem with the help and guidance of the SPIRE maintainers.\n- Recommended Skills: Go\n- Mentor(s): Andrew Harding (@azdagron), Evan Gilman (@evan2645)\n- Upstream Issue (URL): https://github.com/spiffe/spire/issues/2047\n\n#### Cloud Native Buildpacks\n##### Design and implement Buildpack Registry Search\n\n- Description: The [Buildpack Registry](https://github.com/buildpacks/rfcs/blob/main/text/0022-client-side-buildpack-registry.md) is a place to publish, store, and discover buildpacks. It will provide a centralized service that platforms can use to resolve a buildpack ID and version into a concrete buildpack that can be downloaded and used. The search service will extend the existing [registry index stored in git](https://github.com/buildpacks/registry-index) in a way that can be consumed on the web as defined in this [RFC](https://github.com/buildpacks/rfcs/blob/main/text/0068-buildpack-registry-search-api.md).\n- Recommended Skills: React, CSS, Ruby, Rails, Github\n- Mentor(s): Joe Kutner (@jkutner), Travis Longoria (@elbandito)\n- Upstream Issue (URL): https://github.com/buildpacks/registry-api/issues/21\n\n### Envoy\n#### Adaptive Load Control and Distributed Load Testing of Envoy Data Planes\n\n- Description: Users configuring their Envoy-based data planes don't know how to find the optimal Envoy configuration given their workload's resiliency and performance requirements. Nighthawk, Envoy's load generator, supports adaptive load control and horizontally distributed scaling of itself. Using distributed load testing and the creation of a set of adaptive load controllers, Envoy users can be empowered with repeatable tooling to automate identification of an optimal Envoy data plane configuration.\n- Recommended Skill(s): Golang, C++, Rust\n- Issue(s): https://github.com/envoyproxy/envoy-perf/issues/72\n- Mentor(s): Lee Calcote (@lcalcote), Otto van der Schaaf (@oschaaf)\n\n#### Open Service Mesh\n\n##### Support for WebAssembly filters\n\n-\tDescription: Bring OSM on par with other service meshes that support WASM filters in their data plane. OSM's Envoy proxies can be extended at runtime with filters that are running in a WebAssembly sandbox (https://github.com/envoyproxy/envoy-wasm). Provide ability to dynamically load and unload Envoy WASM filters. Provide general purpose filtering of application infrastrcuture logic, tying business logic closer to the mesh.\n-\tRecommended Skills: golang, rust\n-\tMentor(s): Lee Calcote (@leecalcote), Abishek Kumar (@kumarabd)\n-\tUpstream Issue (URL): https://github.com/openservicemesh/osm/issues/1671\n\n#### Service Mesh Interface\n##### Support for Multi-Cluster Operations\n\n- Description: Facilitate federation service mesh deployments across Kubernetes clusters, considering for service catalog federation and \nidentity federation. Account for 1) multiple Kubernetes clusters using the same service mesh, 2) hetrogenius workloads (Kubernetes, VMs, Bare metal) using the same service mesh, 3) multiple Kubernetes clusters using different service meshes (e.g. Istio and Linkerd), 4) heterogeneous workloads using different service meshes (e.g. Istio, Consul).\n-\tRecommended Skills: golang, kubernetes, meshery, smi\n-\tMentor(s): Lee Calcote (@leecalcote), Abishek Kumar (@kumarabd)\n-\tUpstream Issue (URL): https://github.com/servicemeshinterface/smi-spec/issues/212\n" }, { "path": "programs/lfx-mentorship/2021/02-Summer/README.md", "content": "## Q2\n\n_Status: Completed_\n\n- [Q2](#q2)\n - [Timeline](#timeline)\n- [Proposed projects](#proposed-projects)\n- [Participating Projects](#participating-projects)\n - [Buildpacks](#buildpacks)\n - [Embed source metadata in OCI image](#embed-source-metadata-in-oci-image)\n - [CoreDNS](#coredns)\n - [Add ACME protocol support for certificate management with DNS](#add-acme-protocol-support-for-certificate-management-with-dns)\n - [Cortex](#cortex)\n - [Cue support and validation for the Cortex config](#cue-support-and-validation-for-the-cortex-config)\n - [Keptn](#keptn)\n - [Support for generic webhook execution](#support-for-generic-webhook-execution)\n - [Provide a hub for Keptn integrations](#provide-a-hub-for-keptn-integrations)\n - [Racklet](#racklet)\n - [Open source scale-model of Data Centers using commodity compute like Raspberry Pis](#open-source-scale-model-of-data-centers-using-commodity-compute-like-raspberry-pis)\n - [Tremor](#tremor)\n - [Modular sub-queries in tremor-query](#modular-sub-queries-in-tremor-query)\n - [Tremor Web Redesign - Make tremor’s web presence awesome](#tremor-web-redesign---make-tremors-web-presence-awesome)\n - [Kyverno](#kyverno)\n - [Test mutate and generate policies via the Kyverno CLI](#test-mutate-and-generate-policies-via-the-kyverno-cli)\n - [Kubernetes Policy Working Group (WG)](#kubernetes-policy-working-group-wg)\n - [Falco Adapter](#falco-adapter)\n - [Image Scanner Adapter](#image-scanner-adapter)\n - [Vitess](#vitess)\n - [Add testing framework for Django to ensure compatibility with Vitess](#add-testing-framework-for-django-to-ensure-compatibility-with-vitess)\n - [TiKV](#tikv)\n - [Implement Node client](#implement-node-client)\n - [KubeEdge](#kubeedge)\n - [Refactor the cloudStream to pass-through the request instead of parsing the web path](#refactor-the-cloudstream-to-pass-through-the-request-instead-of-parsing-the-web-path)\n - [Improve the KubeEdge website](#improve-the-kubeedge-website)\n - [Thanos](#thanos)\n - [Enhanced Block Viewer UI](#enhanced-block-viewer-ui)\n - [Descriptive API definitions using OpenAPI and Protobuf](#descriptive-api-definitions-using-openapi-and-protobuf)\n - [OpenEBS](#openebs)\n - [Default Kyverno policies for OpenEBS](#default-kyverno-policies-for-openebs)\n - [Enforcing XFS quotas on OpenEBS hostpath Local PV](#enforcing-xfs-quotas-on-openebs-hostpath-local-pv)\n - [Meshery](#meshery)\n - [Service mesh playground](#service-mesh-playground)\n\n### Timeline\n\n**Summer Term: June 1st - August 31st**\n\n- mentorships available on LFX Mentorship: May 3rd, 2021\n- applications open: May 3rd - May 17th (3 weeks)\n- application review/admission decisions/HR paperwork: May 17th - May 31st\n\nMentorship duration - three months \\(12 weeks - full-time schedule\\)\n\n- June 1 (Week 1): Mentorship program begins with the initial work assignments\n- July 11 (End of Week 6): Midterm mentee evaluations and first stipend payments\n- August 31 (End of Week 12): Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals\n\n## Proposed projects\n\nSee the [project ideas](./project_ideas.md) list.\n\n## Participating Projects\n\n#### Buildpacks\n\n##### [Embed source metadata in OCI image](https://mentorship.lfx.linuxfoundation.org/project/25ea21de-7f06-43ae-a4a6-52262ce1193c)\n\n- Description: As a buildpack user using `pack`, I would like to be able to inspect the final app image and determine where the source of the code is located as well as what version (keeping in consideration SCM systems) was used.\n- Recommended Skills: Golang, Docker (Containers)\n- Mentor(s): Javier Romero (@jromero)\n- Issue: \n\n#### CoreDNS\n\n##### [Add ACME protocol support for certificate management with DNS](https://mentorship.lfx.linuxfoundation.org/project/beb3a680-3f78-4716-b072-7f547cf417ab)\n\n- [CoreDNS](https://github.com/coredns/coredns) is a cloud-native DNS server with a focus on service discovery. While best known as the default DNS server for Kubernetes, CoreDNS is capable of handle many other scenarios within or outside of Kubernetes clusters for make easy infrastructure management. One such case is the certificate management. This project is to provide ACME protocol support so that it is possible to have automatic certificate management through CoreDNS. More details and discussions are available in .\n- Recommended Skills: Golang, DNS, TLS, Certificate Management\n- Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)\n- Issue: \n\n#### Cortex\n\n##### [Cue support and validation for the Cortex config](https://mentorship.lfx.linuxfoundation.org/project/faccbbff-f651-4bc5-a825-be0f395315c9)\n\n- Description: [Cortex](https://github.com/cortexproject/cortex) is a\n cloud-native Prometheus compatible monitoring system. It is made up of a set\n of microservices that can be composed into an architecture that fits multiple\n use cases. However, this level of flexibility can lead to complexity in the\n configuration file. One way to handle this complexity is first-class\n validation support for the config. This is where [Cue](https://cuelang.org/)\n comes in. Cue provides data validation as a language feature and has solid\n support for Go. We think enabling Cortex to be configured using Cue and\n creating a Cue specification for the Cortex configuration file and other file\n types specific to Cortex would be a good step forward in improving the\n usability of the project.\n- Recommended Skills: Golang\n- Mentor(s): Jacob Lisi (@jtlisi)\n- Issue: \n\n#### Keptn\n\n##### [Support for generic webhook execution](https://mentorship.lfx.linuxfoundation.org/project/38cafd48-6ffb-44e8-9ed1-5c467bc69fd2)\n\n- Description: As a user, I want to be able to call arbitrary URLs via webhooks that are registered on Keptn events to interact with systems outside of Keptn. Therefore, I would like to use a templating mechanism to define payloads to be able to interact with external systems.\n- Recommended Skills: golang\n- Mentor(s): Jürgen Etzlstorfer (@jetzlstorfer)\n- Issue: \n\n##### [Provide a hub for Keptn integrations](https://mentorship.lfx.linuxfoundation.org/project/e978885c-fe45-48b1-9a67-9cc9ffd68e82)\n\n- Description: Currently, Keptn services and integrations can be found on an overview page at https://keptn.sh/docs/integrations/ While this served fine as a central overview of all currently supported integrations, a more sophisticated \"integrations hub\" is desired. The hub should list all available integrations including their name, status, install numbers/github stars, description, and installation instructions. The project includes a research task of other hubs and how they are built. \n- Recommended Skills: UX/UI, JavaScript, GoLang (a plus but not mandatory) \n- Mentor(s): Jürgen Etzlstorfer (@jetzlstorfer)\n- Issue: \n\n#### Racklet\n\n##### [Open source scale-model of Data Centers using commodity compute like Raspberry Pis](https://mentorship.lfx.linuxfoundation.org/project/622bbf07-b001-470c-8da8-b714bb127183)\n\n- Description:\n “The future is already here - it's just not evenly distributed” - William Gibson\n\n We’d like to introduce an idea for a new open-source project: Racklet. It’s a fully-integrated, Raspberry Pi form-factor\n server rack and software stack that aims to be a scale model of hyperscaler datacenters. All layers of the stack\n are 100% OSS/OSH, and will be developed together with the community. It’s reproducible through open PCB designs,\n 3D printed casing, and commodity, off-the-shelf hardware.\n\n We want to lower the barrier of entry for becoming cloud native. Racklet aims to inspire users to explore how\n modern server architectures work, in a tangible and educational way. Emphasis is put on security, knowledge\n sharing, extensibility, and portability.\n\n The goal is to conceptually map to real environments and provide an accessible and well-documented path to welcome\n future talents to the world of cloud native.\n\n- Recommended Skills: Go, Rust, Kubernetes, Linux, Raspberry Pi, API and library design, Security, Documentation, GitOps, Embedded Systems, Electronics, Continuous Integration, Virtualization\n- Mentor(s): Davanum Srinivas ([@dims](https://github.com/dims))\n- Request For Comments (RFC) Description (URL): \n\n#### Tremor\n\n##### [Modular sub-queries in tremor-query](https://mentorship.lfx.linuxfoundation.org/project/de95a031-903b-4129-b34f-f39611fd176c)\n\n- Description:\n Currently tremor supports composition through composing pipelines together, through function composition and through allowing references to query operator definitions and constants in externalizable modules that can be loaded via a module path.\n It would be excellent if the modularity in tremor extended fully to the query language so that distinct subgraphs could be modularized and consumed by multiple queries to optimise for reuse of flow oriented logic in tremor.\n This would require extending module support in the tremor query language to support sub-graph definitions with parameters that can be declared and used as part of a higher level query.\n Modules in tremor-query in their current state: \n This project idea involves designing the sub-graph module syntax and semantics and implementing changes to the lexer, grammar, optimizers and runtime. It is most suited to candidates who are interested in programming language evolution and design.\n\n- Recommended Skills: Rust, Parsers, Programming Language Design/Implementation (Interest)\n- Mentor(s): Darach Ennis (@darach), Heinz N. Gies (@Licenser), Matthias Wahl (@mfelsche)\n- Upstream Issue (URL): \n\n##### [Tremor Web Redesign - Make tremor’s web presence awesome](https://mentorship.lfx.linuxfoundation.org/project/336820e5-b46e-4184-a7eb-8f0cb4dd18b4)\n\n- Description:\n As an early stage project we’ve biased in favour of documenting the essentials and getting content in place as fast as possible. This has worked well but a side-effect is 3 or 4 different sources of content ( www, docs, rfcs and courseware ).\n In concept with CNCF technical writing and learning best practices use your UX/web design and technical writing expertise for tremor where we as a team are unskilled - make our content awesome and the user experience exceptional.\n These are some improvements we did think of, but these are neither complete nor required, more suggestions are welcome:\n- Unify the different content forms under a single consolidated theme and design\n- Ease of navigation ( breadcrumbs )\n- Preserve markdown for data entry ( we’re programmers ) and keep design separate ( we’re not designers and find this stuff super hard )\n- A clean, easy to navigate theme with a focus on user experience\n- Well integrated with our CI and doc generation tooling ( think gitops for docs and content )\n This task would suit a candidate who is interested in `full stack` engineering and the complete software development lifecycle with a specific focus or interest in engineering documentation, web design and communicating well designed content to others with a good user experience - exploiting principles of good technical writing and web design of content management systems for technical content consumers.\n- Recommended Skills: UX/UI, technical writing, web design, documentation\n- Mentor(s): Darach Ennis (@darach), Heinz N. Gies (@Licenser), Matthias Wahl (@mfelsche)\n- Upstream Issue (URL): \n\n#### Kyverno\n\n##### [Test mutate and generate policies via the Kyverno CLI](https://mentorship.lfx.linuxfoundation.org/project/9ddced83-279c-460d-869a-3f92e9c98c2c)\n\n- Description: Kyverno is a Kubernetes native policy manager that also can be used in a CI/CD pipeline. This project will extend the Kyverno command line tool to support mutate and generate rules and add more E2E/Unit Tests and offer test report based on the results.\n- Recommended Skills: Golang, unit and feature testing.\n- Mentor(s): Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)\n- Issue: https://github.com/kyverno/kyverno/issues/1821\n\n#### Kubernetes Policy Working Group (WG)\n\nThe Kubernetes policy working group focuses on developing tools and solutions that make Kubernetes secure and easiser to use.\n\n##### [Falco Adapter](https://mentorship.lfx.linuxfoundation.org/project/cab6e242-33d5-427d-a408-9adff1a95271)\n\n- Description:\n This project will develop an adapter to run Falco in any Kubernetes cluster and periodically generate or update a [Policy Report custom resource](https://github.com/kubernetes-sigs/wg-policy-prototypes/blob/master/policy-report/README.md). The candidate will learn about Kubernetes controllers and various security topics.\n- Recommended Skills: Linux, Golang, CLI, Kubernetes\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/wg-policy-prototypes/issues/51\n\n##### [Image Scanner Adapter](https://mentorship.lfx.linuxfoundation.org/project/e88fb12c-5943-4c16-becc-83b449b15e9f)\n\n- Description:\n This project will develop an adapter to run an image scanning tool (like Clair or Trivy) in any Kubernetes cluster and periodically generate or update a [Policy Report custom resource](https://github.com/kubernetes-sigs/wg-policy-prototypes/blob/master/policy-report/README.md). The candidate will learn about Kubernetes controllers, image security and management, and Kubernetes custom resources.\n- Recommended Skills: Linux, Golang, CLI, Kubernetes\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/wg-policy-prototypes/issues/54\n\n#### Vitess\n\n##### [Add testing framework for Django to ensure compatibility with Vitess](https://mentorship.lfx.linuxfoundation.org/project/76f2edd5-0f1c-4755-90a1-41ee09fb4d4d)\n\n- Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. To this end, we would like to add a comprehensive test suite to ensure compatibility with [Django](https://www.djangoproject.com/) framework. The mentee would be introduced to the world of distributed databases and how everything comes together without the user realizing the difference. They would learn how to run Vitess and about comprehensive testing techniques.\n- Recommended Skills: python, django, bash\n- Mentor(s): Manan Gupta (@GuptaManan100)\n- Issue: \n\n#### TiKV\n\n##### [Implement Node client](https://mentorship.lfx.linuxfoundation.org/project/eb96b91a-85c5-4ee5-aae4-46c9f10981e0)\n\n- Description: TiKV is a distributed KV database. It support using clients in Rust, Golang, Java, C++ and Python, and the Node client is the last missing piece. This program is going to implement Node client on top of Rust client just like Python client and C++ client.\n- Recommended Skills: JavaScript, TypeScript, Rust\n- Mentor(s): Liming Deng (@iosmanthus), Andy Lok (@andylokandy)\n- Issue: \n\n#### KubeEdge\n\n##### [Refactor the cloudStream to pass-through the request instead of parsing the web path](https://mentorship.lfx.linuxfoundation.org/project/446813c7-f2a6-4d81-ac64-ba407333fabe)\n\n- Description: Edgestream is used to handle the request from apiserver, then forward the request to edged through tunnel. We will find a way to pass-through the request, through the hijack stuff, instead of parsing the web path manually.\n- Recommended Skills: Golang, Kubernetes, KubeEdge\n- Mentor(s): Fei Xu (@fisherxu)\n- Issue: \n\n##### [Improve the KubeEdge website](https://mentorship.lfx.linuxfoundation.org/project/5ad92659-907e-45b6-8cac-e5531c4696bd)\n\n- Description: Improve the design and content of the kubeedge website.\n- Recommended Skills: JavaScript, KubeEdge\n- Mentor(s): Kevin Wang (@kevin-wangzefeng)\n- Issue: \n\n#### Thanos\n\n##### [Enhanced Block Viewer UI](https://mentorship.lfx.linuxfoundation.org/project/3fee59ac-7716-4ad5-9282-ea63ccffea9b)\n\n- Description: The Thanos BlockViewer UI has proven to be an essential part of the debuggability story for the Thanos project. It allows administrators to see the exact state of data in Object Storage in a provider-agnostic way. This project is about extending this UI with richer features, context, and actions to improve observability and increase control.\n- Recommended Skills: React, TypeScript, Golang, ObjectStorage\n- Mentor(s): Prem Saraswat (@onprem), Lucas Servén Marín (@squat)\n- Issue: https://github.com/thanos-io/thanos/issues/3112, https://github.com/thanos-io/thanos/issues/3220, https://github.com/thanos-io/thanos/issues/3221, https://github.com/thanos-io/thanos/issues/3308\n\n##### [Descriptive API definitions using OpenAPI and Protobuf](https://mentorship.lfx.linuxfoundation.org/project/dfccf818-c7f7-4074-9e1b-2805698d9d89)\n\n- Description: In order to improve Thanos usage for users, we would like to define our APIs, both HTTP and gRPC, in protobuf/OpenAPI and expose the automatically generated documentation in the website. We also want to define the configuration of our components in protobuf. This would allow users to use tools for documentation, validation, type checking and even code generation to use our APIs efficiently. During this project we also expect collaboration with the Prometheus project to implement similar improvements on Prometheus' side. https://github.com/cncf/mentoring/blob/master/summerofcode/2021.md#port-the-prometheus-api-to-openapi. Optionally we would like to work on the index page on every Thanos component server that will expose those resources for easier debug.\n- Recommended Skills: Golang, Protocol Buffers, Yaml (:\n- Mentor(s): Bartlomiej Plotka (@bwplotka), Prem Saraswat (@onprem)\n- Issue: https://github.com/thanos-io/thanos/issues/4102\n\n#### OpenEBS\n\n##### [Default Kyverno policies for OpenEBS](https://mentorship.lfx.linuxfoundation.org/project/35b9d57a-fc2c-4b49-a5b3-9a5cf74af66c)\n\n- Description: Kyverno is a Kubernetes native policy manager that can be used in place of PodSecurityPolicies. OpenEBS helm charts currently set up PSPs for many of its Storage engines. This project is to convert PSPs into corresponding Kyverno policies. The OpenEBS storage engines also uses a custom admission webhook validator. The scope of the project can extend to replacing the custom validators with Kyverno policies. \n- Recommended Skills: Golang, unit and feature testing.\n- Mentor(s): Kiran Mova(@kmova), Prateek Pandey (@prateekpandey14)\n- Issue: https://github.com/openebs/openebs/issues/3385\n\n##### [Enforcing XFS quotas on OpenEBS hostpath Local PV](https://mentorship.lfx.linuxfoundation.org/project/7cd6af42-6f86-4a77-a077-304dc7d82134)\n\n- Description: OpenEBS Local PV hostpath is the most simple to use Local PV option available for Kubernetes today. Many of the applications use XFS filesystem to create Local PVs. This project is to implement XFS project quota on the OpenEBS Local PV subdirectory to restrict pods from exceeding the Quota assigned to them via the PVC request. \n- Recommended Skills: Golang, XFS, unit and feature testing.\n- Mentor(s): Kiran Mova(@kmova), Harsh Thakur (@realHarshThakur)\n- Issue: https://github.com/openebs/dynamic-localpv-provisioner/issues/13\n\n#### Meshery\n\n##### [Service mesh playground](https://mentorship.lfx.linuxfoundation.org/project/57571877-84ec-415a-ad0b-b076e20f3ad0)\n\n- Description: Create the world’s service mesh playground. Meshery’s genesis is that of helping teach people about service mesh technology and enabling to operate this type of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission with interactive API documentation connected to a service mesh learning playground (a running instance of Meshery).\n- Recommended Skills: Golang, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Utkarsh Srivastava ([@utkarshdev23](https://twitter.com/utkarshdev23))\n- Issue: \n\n" }, { "path": "programs/lfx-mentorship/2021/02-Summer/project_ideas.md", "content": "## Projects ideas\n\nProject maintainers and mentors, please submit the ideas below (under the Proposed Project Ideas section) section using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n- [Projects ideas](#projects-ideas)\n - [Template](#template)\n - [Sample](#sample)\n - [Prometheus (sample)](#prometheus-sample)\n - [Refactor the APIs for better readability and less maintenance overhead](#refactor-the-apis-for-better-readability-and-less-maintenance-overhead)\n - [Proposed Project ideas](#proposed-project-ideas)\n - [Buildpacks](#buildpacks)\n - [Embed source metadata in OCI image](#embed-source-metadata-in-oci-image)\n - [CoreDNS](#coredns)\n - [Add ACME protocol support for certificate management with DNS](#add-acme-protocol-support-for-certificate-management-with-dns)\n - [Cortex](#cortex)\n - [Cue support and validation for the Cortex config.](#cue-support-and-validation-for-the-cortex-config)\n - [Keptn](#keptn)\n - [Support for generic webhook execution](#support-for-generic-webhook-execution)\n - [Provide a hub for Keptn integrations](#provide-a-hub-for-keptn-integrations)\n - [Meshery](#meshery)\n - [Service mesh playground](#service-mesh-playground)\n - [Racklet](#racklet)\n - [Open source scale-model of Data Centers using commodity compute like Raspberry Pis](#open-source-scale-model-of-data-centers-using-commodity-compute-like-raspberry-pis)\n - [Tremor](#tremor)\n - [Modular sub-queries in tremor-query](#modular-sub-queries-in-tremor-query)\n - [Tremor Web Redesign - Make tremor’s web presence awesome](#tremor-web-redesign---make-tremors-web-presence-awesome)\n - [Kyverno](#kyverno)\n - [Test mutate and generate policies via the Kyverno CLI](#test-mutate-and-generate-policies-via-the-kyverno-cli)\n - [Kubernetes Policy Working Group (WG)](#kubernetes-policy-working-group-wg)\n - [Falco Adapter](#falco-adapter)\n - [Image Scanner Adapter](#image-scanner-adapter)\n - [Vitess](#vitess)\n - [Add testing framework for Django to ensure compatibility with Vitess](#add-testing-framework-for-django-to-ensure-compatibility-with-vitess)\n - [TiKV](#tikv)\n - [Implement Node client](#implement-node-client)\n - [KubeEdge](#kubeedge)\n - [Refactor the cloudStream to pass-through the request instead of parsing the web path](#refactor-the-cloudstream-to-pass-through-the-request-instead-of-parsing-the-web-path)\n - [Improve the KubeEdge website](#improve-the-kubeedge-website)\n\n### Template\n\n```\n#### CNCF Project Name\n##### Title\n\n- Description:\n- Recommended Skills:\n- Mentor(s):\n- Upstream Issue (URL):\n```\n\n### Sample\n\n#### Prometheus (sample)\n\n##### Refactor the APIs for better readability and less maintenance overhead\n\n- Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n- Recommended Skills: golang\n- Mentor(s): Krasi Georgiev (@krasi-georgiev)\n- Issue: \n\n### Proposed Project ideas\n\n#### Buildpacks\n\n##### Embed source metadata in OCI image\n\n- Description: As a buildpack user using `pack`, I would like to be able to inspect the final app image and determine where the source of the code is located as well as what version (keeping in consideration SCM systems) was used.\n- Recommended Skills: Golang, Docker (Containers)\n- Mentor(s): Javier Romero (@jromero)\n- Issue: \n\n#### CoreDNS\n\n##### Add ACME protocol support for certificate management with DNS\n\n- [CoreDNS](https://github.com/coredns/coredns) is a cloud-native DNS server with a focus on service discovery. While best known as the default DNS server for Kubernetes, CoreDNS is capable of handle many other scenarios within or outside of Kubernetes clusters for make easy infrastructure management. One such case is the certificate management. This project is to provide ACME protocol support so that it is possible to have automatic certificate management through CoreDNS. More details and discussions are available in .\n- Recommended Skills: Golang, DNS, TLS, Certificate Management\n- Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)\n- Issue: \n\n#### Cortex\n\n##### Cue support and validation for the Cortex config.\n\n- Description: [Cortex](https://github.com/cortexproject/cortex) is a\n cloud-native Prometheus compatible monitoring system. It is made up of a set\n of microservices that can be composed into an architecture that fits multiple\n use cases. However, this level of flexibility can lead to complexity in the\n configuration file. One way to handle this complexity is first-class\n validation support for the config. This is where [Cue](https://cuelang.org/)\n comes in. Cue provides data validation as a language feature and has solid\n support for Go. We think enabling Cortex to be configured using Cue and\n creating a Cue specification for the Cortex configuration file and other file\n types specific to Cortex would be a good step forward in improving the\n usability of the project.\n- Recommended Skills: Golang\n- Mentor(s): Jacob Lisi (@jtlisi)\n- Issue: \n\n#### Keptn\n\n##### Support for generic webhook execution\n\n- Description: As a user, I want to be able to call arbitrary URLs via webhooks that are registered on Keptn events to interact with systems outside of Keptn. Therefore, I would like to use a templating mechanism to define payloads to be able to interact with external systems.\n- Recommended Skills: golang\n- Mentor(s): Jürgen Etzlstorfer (@jetzlstorfer)\n- Issue: \n\n##### Provide a hub for Keptn integrations\n\n- Description: Currently, Keptn services and integrations can be found on an overview page at https://keptn.sh/docs/integrations/ While this served fine as a central overview of all currently supported integrations, a more sophisticated \"integrations hub\" is desired. The hub should list all available integrations including their name, status, install numbers/github stars, description, and installation instructions. The project includes a research task of other hubs and how they are built.\n- Recommended Skills: UX/UI, JavaScript, GoLang (a plus but not mandatory)\n- Mentor(s): Jürgen Etzlstorfer (@jetzlstorfer)\n- Issue: \n\n#### Meshery\n\n##### Service mesh playground\n\n- Description: Create the world’s service mesh playground. Meshery’s genesis is that of helping teach people about service mesh technology and enabling to operate this type of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission with interactive API documentation connected to a service mesh learning playground (a running instance of Meshery).\n- Recommended Skills: Golang, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Utkarsh Srivastava ([@utkarshdev23](https://twitter.com/utkarshdev23))\n- Issue: \n\n#### Service Mesh Interface\n\n##### Conformance Program\n\n- Description: Ensure that a service mesh is properly configured and that its behavior conforms to official SMI specifications. Advance the definition of conformance tests and the test framework, Meshery (see [design specification](https://docs.google.com/document/d/1HL8Sk7NSLLj-9PRqoHYVIGyU6fZxUQFotrxbmfFtjwc/edit)).\n- Recommended Skills**: Golang, ReactJS, GitHub Actions \n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), \n- Issue: [https://github.com/servicemeshinterface/smi-spec/issues/70](https://github.com/servicemeshinterface/smi-spec/issues/70)\n\n#### Racklet\n\n##### Open source scale-model of Data Centers using commodity compute like Raspberry Pis\n\n- Description:\n\n ```\n “The future is already here - it's just not evenly distributed” - William Gibson\n\n We’d like to introduce an idea for a new open-source project: Racklet. It’s a fully-integrated, Raspberry Pi form-factor\n server rack and software stack that aims to be a scale model of hyperscaler datacenters. All layers of the stack\n are 100% OSS/OSH, and will be developed together with the community. It’s reproducible through open PCB designs,\n 3D printed casing, and commodity, off-the-shelf hardware.\n\n We want to lower the barrier of entry for becoming cloud native. Racklet aims to inspire users to explore how\n modern server architectures work, in a tangible and educational way. Emphasis is put on security, knowledge\n sharing, extensibility, and portability.\n\n The goal is to conceptually map to real environments and provide an accessible and well-documented path to welcome\n future talents to the world of cloud native.\n ```\n\n- Recommended Skills: Go, Rust, Kubernetes, Linux, Raspberry Pi, API and library design, Security, Documentation, GitOps, Embedded Systems, Electronics, Continuous Integration, Virtualization\n- Mentor(s): Davanum Srinivas ([@dims](https://github.com/dims)), Ron Minnich (https://github.com/rminnich)\n- Request For Comments (RFC) Description (URL): \n\n#### Tremor\n\n##### Modular sub-queries in tremor-query\n\n- Description:\n Currently tremor supports composition through composing pipelines together, through function composition and through allowing references to query operator definitions and constants in externalizable modules that can be loaded via a module path.\n\n It would be excellent if the modularity in tremor extended fully to the query language so that distinct subgraphs could be modularized and consumed by multiple queries to optimise for reuse of flow oriented logic in tremor.\n\n This would require extending module support in the tremor query language to support sub-graph definitions with parameters that can be declared and used as part of a higher level query.\n\n Modules in tremor-query in their current state: \n\n This project idea involves designing the sub-graph module syntax and semantics and implementing changes to the lexer, grammar, optimizers and runtime. It is most suited to candidates who are interested in programming language evolution and design.\n\n- Recommended Skills: Rust, Parsers, Programming Language Design/Implementation (Interest)\n- Mentor(s): Darach Ennis (@darach), Heinz N. Gies (@Licenser), Matthias Wahl (@mfelsche)\n- Upstream Issue (URL): \n\n##### Tremor Web Redesign - Make tremor’s web presence awesome\n\n- Description:\n As an early stage project we’ve biased in favour of documenting the essentials and getting content in place as fast as possible. This has worked well but a side-effect is 3 or 4 different sources of content ( www, docs, rfcs and courseware ).\n\n In concert with CNCF technical writing and learning best practices use your UX/web design and technical writing expertise for tremor where we as a team are unskilled - make our content awesome and the user experience exceptional.\n\n These are some improvements we did think of, but these are neither complete nor required, more suggestions are welcome:\n\n- Unify the different content forms under a single consolidated theme and design\n- Ease of navigation ( breadcrumbs )\n- Preserve markdown for data entry ( we’re programmers ) and keep design separate ( we’re not designers and find this stuff super hard )\n- A clean, easy to navigate theme with a focus on user experience\n- Well integrated with our CI and doc generation tooling ( think gitops for docs and content )\n\n This task would suit a candidate who is interested in `full stack` engineering and the complete software development lifecycle with a specific focus or interest in engineering documentation, web design and communicating well designed content to others with a good user experience - exploiting principles of good technical writing and web design of content management systems for technical content consumers.\n\n- Recommended Skills: UX/UI, technical writing, web design, documentation\n- Mentor(s): Darach Ennis (@darach), Heinz N. Gies (@Licenser), Matthias Wahl (@mfelsche)\n- Upstream Issue (URL): \n\n#### Kyverno\n\n##### Test mutate and generate policies via the Kyverno CLI\n\n- Description: Kyverno is a Kubernetes native policy manager that also can be used in a CI/CD pipeline. This project will extend the Kyverno command line tool to support mutate and generate rules and add more E2E/Unit Tests and offer test report based on the results.\n- Recommended Skills: Golang, unit and feature testing.\n- Mentor(s): Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)\n- Issue: https://github.com/kyverno/kyverno/issues/1821\n\n#### Kubernetes\n\n##### Improvements to Cluster API provider for GCP (CAPG)\n\n- Description: The Cluster API is a Kubernetes project to bring declarative, Kubernetes-style APIs to cluster creation, configuration, and management. CAPG provides this Kubernetes-native declarative infrastructure for GCP. The project would start with some help wanted issues around quick start and documentation, this will help with understanding mentee with CAPI/CAPG concepts and current implementation. Then we will move on to some long pending improvements documented in the issues link below.\n- Recommended Skills: Golang, unit and feature testing.\n- Mentor(s): Davanum Srinivas (@dims), Carlos Tadeu Panato Junior (@cpanato)\n- Issue: https://github.com/kubernetes-sigs/cluster-api-provider-gcp/issues\n\n#### Kubernetes Policy Working Group (WG)\n\nThe Kubernetes policy working group focuses on developing tools and solutions that make Kubernetes secure and easiser to use.\n\n##### Falco Adapter\n\n- Description:\n This project will develop an adapter to run Falco in any Kubernetes cluster and periodically generate or update a [Policy Report custom resource](https://github.com/kubernetes-sigs/wg-policy-prototypes/blob/master/policy-report/README.md). The candidate will learn about Kubernetes controllers and various security topics.\n- Recommended Skills: Linux, Golang, CLI, Kubernetes\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/wg-policy-prototypes/issues/51\n\n##### Image Scanner Adapter\n\n- Description:\n This project will develop an adapter to run an image scanning tool (like Clair or Trivy) in any Kubernetes cluster and periodically generate or update a [Policy Report custom resource](https://github.com/kubernetes-sigs/wg-policy-prototypes/blob/master/policy-report/README.md). The candidate will learn about Kubernetes controllers, image security and management, and Kubernetes custom resources.\n- Recommended Skills: Linux, Golang, CLI, Kubernetes\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/wg-policy-prototypes/issues/54\n\n#### Vitess\n\n##### Add testing framework for Django to ensure compatibility with Vitess\n\n- Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. To this end, we would like to add a comprehensive test suite to ensure compatibility with [Django](https://www.djangoproject.com/) framework. The mentee would be introduced to the world of distributed databases and how everything comes together without the user realizing the difference. They would learn how to run Vitess and about comprehensive testing techniques.\n- Recommended Skills: python, django, bash\n- Mentor(s): Manan Gupta (@GuptaManan100)\n- Issue: \n\n#### TiKV\n\n##### Implement Node client\n\n- Description: TiKV is a distributed KV database. It support using clients in Rust, Golang, Java, C++ and Python, and the Node client is the last missing piece. This program is going to implement Node client on top of Rust client just like Python client and C++ client.\n- Recommended Skills: JavaScript, TypeScript, Rust\n- Mentor(s): Liming Deng (@iosmanthus), Andy Lok (@andylokandy)\n- Issue: \n\n#### KubeEdge\n\n##### Refactor the cloudStream to pass-through the request instead of parsing the web path\n\n- Description: Edgestream is used to handle the request from apiserver, then forward the request to edged through tunnel. We will find a way to pass-through the request, through the hijack stuff, instead of parsing the web path manually.\n- Recommended Skills: Golang, Kubernetes, KubeEdge\n- Mentor(s): Fei Xu (@fisherxu)\n- Issue: \n\n##### Improve the KubeEdge website\n\n- Description: Improve the design and content of the kubeedge website.\n- Recommended Skills: JavaScript, KubeEdge\n- Mentor(s): Kevin Wang (@kevin-wangzefeng)\n- Issue: \n\n#### Thanos\n\n##### Enhanced Block Viewer UI\n\n- Description: The Thanos BlockViewer UI has proven to be an essential part of the debuggability story for the Thanos project. It allows administrators to see the exact state of data in Object Storage in a provider-agnostic way. This project is about extending this UI with richer features, context, and actions to improve observability and increase control.\n- Recommended Skills: React, TypeScript, Golang, ObjectStorage\n- Mentor(s): Prem Saraswat (@onprem), Lucas Servén Marín (@squat)\n- Issue: https://github.com/thanos-io/thanos/issues/3112, https://github.com/thanos-io/thanos/issues/3220, https://github.com/thanos-io/thanos/issues/3221, https://github.com/thanos-io/thanos/issues/3308\n\n##### Descriptive API definitions using OpenAPI and Protobuf\n\n- Description: In order to improve Thanos usage for users, we would like to define our APIs, both HTTP and gRPC, in protobuf/OpenAPI and expose the automatically generated documentation in the website. We also want to define the configuration of our components in protobuf. This would allow users to use tools for documentation, validation, type checking and even code generation to use our APIs efficiently. During this project we also expect collaboration with the Prometheus project to implement similar improvements on Prometheus' side. https://github.com/cncf/mentoring/blob/master/summerofcode/2021.md#port-the-prometheus-api-to-openapi. Optionally we would like to work on the index page on every Thanos component server that will expose those resources for easier debug.\n- Recommended Skills: Golang, Protocol Buffers, Yaml (:\n- Mentor(s): Bartlomiej Plotka (@bwplotka), Prem Saraswat (@onprem)\n- Issue: https://github.com/thanos-io/thanos/issues/4102\n\n#### OpenEBS\n\n##### Default Kyverno policies for OpenEBS\n\n- Description: Kyverno is a Kubernetes native policy manager that can be used in place of PodSecurityPolicies. OpenEBS helm charts currently set up PSPs for many of its Storage engines. This project is to convert PSPs into corresponding Kyverno policies. The OpenEBS storage engines also uses a custom admission webhook validator. The scope of the project can extend to replacing the custom validators with Kyverno policies.\n- Recommended Skills: Golang, unit and feature testing.\n- Mentor(s): Kiran Mova(@kmova), Prateek Pandey (@prateekpandey14)\n- Issue: https://github.com/openebs/openebs/issues/3385\n\n##### Enforcing XFS quotas on OpenEBS hostpath Local PV\n\n- Description: OpenEBS Local PV hostpath is the most simple to use Local PV option available for Kubernetes today. Many of the applications use XFS filesystem to create Local PVs. This project is to implement XFS project quota on the OpenEBS Local PV subdirectory to restrict pods from exceeding the Quota assigned to them via the PVC request.\n- Recommended Skills: Golang, XFS, unit and feature testing.\n- Mentor(s): Kiran Mova(@kmova), Harsh Thakur (@realHarshThakur)\n- Issue: https://github.com/openebs/dynamic-localpv-provisioner/issues/13\n" }, { "path": "programs/lfx-mentorship/2021/03-Fall/README.md", "content": "# Q3 - Fall'2021\n\nStatus: Planned\n\n### Timeline\n\nFall Term: September 1st - November 31st\n\n- mentorships available on LFX Mentorship: August 15th, 2021 (by PT EOD)\n- applications open: August 16th - August 22nd\n- application review/admission decisions/HR paperwork: August 23rd - August 31st\n\nMentorship duration - three months \\(12 weeks - full-time schedule\\)\n\n### Project Instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here (), by August 11th.\n\n### Participating Projects\n\n#### Kubernetes\n\n##### Improvements to Cluster API provider for GCP (CAPG)\n\n- Description: The Cluster API is a Kubernetes project to bring declarative, Kubernetes-style APIs to cluster creation, configuration, and management. CAPG provides this Kubernetes-native declarative infrastructure for GCP. The project would start with some help wanted issues around quick start and documentation, this will help with understanding mentee with CAPI/CAPG concepts and current implementation. Then we will move on to some long pending improvements documented in the issues link below.\n- Recommended Skills: Golang, unit and feature testing.\n- Mentor(s): Davanum Srinivas (@dims), Carlos Tadeu Panato Junior (@cpanato)\n- Issue: \n- Apply: \n\n##### Improve SIG-Node testing using Kubetest2\n\n- Description: Kubernetes currently uses Kubetest as the interface for launching and running e2e tests. There is a new [kubetest2](https://github.com/kubernetes-sigs/kubetest2) that is in the process of being developed and will need to be rolled out to various CI harnesses and jobs. As part of this project we will focus on SIG-Node related CI jobs. Here's how we currently test SIG-Node related code - [e2e-node-tests.md](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md). There will be a lot of interesting problems to solve and this work is critical to how we test kubernetes not just in GCP, but also across all the other cloud providers going forward.\n- Recommended Skills: Golang, python, bash, unit and feature testing.\n- Mentor(s): Davanum Srinivas (@dims), Amit Watve (@amwat)\n- Enhancement : \n- Apply: \n\n#### Kubernetes Policy Working Group (WG)\n\nThe Kubernetes policy working group focuses on developing tools and solutions that make Kubernetes secure and easiser to use.\n\n##### KubeArmor support for Policy Report CRD\n\n- Description:\n This project will periodically generate or update a [Policy Report Custom Resource (CR)](https://github.com/kubernetes-sigs/wg-policy-prototypes/blob/master/policy-report/README.md) based on events collected from KubeArmor. This could be implemented as a feature in KubeArmor or developed as an external adapter. The candidate will learn about Kubernetes controllers and various security topics.\n- Recommended Skills: Linux, Golang, CLI, Kubernetes\n- Mentor(s): Jim Bugwadia (@JimBugwadia), Mritunjay Kumar Sharma (@mritunjaysharma394)\n- Upstream Issue (URL): \n- Apply: \n\n#### Vitess\n\n##### Add complete parsing support for MySQL constructs\n\n- Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. Vitess has its own in-built SQL-parser which it uses to understand the query and represent as structs for further processing. As of now, a lot of MySQL constructs are not parsed and result in syntax errors. For example, we do not have complete support to parse [partition constructs](https://dev.mysql.com/doc/refman/5.7/en/partitioning-overview.html). Parsing for a lot of the newer features in MySQL 8.0 is also missing. The task of the mentee would be to add parsing support for such constructs.\n- Recommended Skills: go, SQL, yacc, compilers and lexers\n- Mentor(s): Manan Gupta (@GuptaManan100)\n- Issue: \n- Apply: \n\n##### Add support for comparing strings using collations and character-sets\n\n- Description: Vitess does not yet have support for collations and character-sets. So, to compare varchar strings Vitess needs to rely on [WEIGHT_STRING](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_weight-string) function for now. As per MySQL documentation, WEIGHT_STRING is a debugging function, meant only for internal use. Having the ability to compare strings using collation and character set support we will be able to better implement ORDER BY, GROUP BY, JOIN. It will also allow us to leverage more advanced join techniques than what we currently implement.\n- Recommended Skills: go, SQL\n- Mentor(s): Vicent Marti (@vmg)\n- Issue: \n- Apply: \n\n##### Add support for Upgrade/Downgrade Testing\n\n- Description: Currently Vitess has a rich set of functional tests that are run as part of every commit to catch regressions early. However, they are not sufficient to assess the quality of the product for production rollout. We currently do not test for incompatibilities introduced via upgrade, and ensuring that users can downgrade one level if they need to backout of a failed upgrade. The scenarios will need to be written down, and then tests can be written using GitHub actions:\n - Document Supported Upgrade/Downgrade Scenario\n - Author GitHub actions tests to checkout 2 versions, test scenarios.\n- Recommended Skills: go, GitHub Actions, docker\n- Mentor(s): Harshit Gangal (@harshit-gangal)\n- Issue: \n- Apply: \n\n#### Kyverno\n\n##### Scalability testing for Kyverno\n\n- Description:\n Define and execute scalability tests for Kyverno on large Kubernetes clusters with several namespaces and resources. The candidate has to propose and execute a performance test plan and help optimize resource usage of Kyverno for different loads for large Kubernetes clusters.\n- Recommended Skills: Kubernetes, Golang, Test\n- Mentor(s): Shuting Zhao (@realshuting)\n- Upstream Issue (URL): \n- Apply: \n\n##### Extend Kyverno test command to cover generate policies & improve test coverage\n\n- Description:\n Extend the Kyverno CLI to cover generate policies and improve tests coverage for Kyverno. Based on the test results, the candidate has to add more unit/E2E tests.\n- Recommended Skills: Golang, Test\n- Mentor(s): Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): \n- Apply: \n\n##### Security model and processes for Kyverno\n\n- Description:\n Improve security model and processes for Kyverno. Document security processes, help define a threat model with risks and mitagation, and add best practice processes like publishing signed images.\n- Recommended Skills: Kubernetes, Security, Documentation\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): \n- Apply: \n\n#### Chaos Mesh\n\n##### Monitoring Metrics about Chaos Mesh\n\n- Description: Observability is very important for each application, we want to monitor more things of Chaos Mesh components, enrich the metrics for both logic patterns and performance data. We want to let users could watch the status of Chaos Mesh on grafana dashboard, and developers could using time-series metrics for debugging and profiling.\n- Recommended Skills: golang, prometheus, grafana\n- Mentor(s): [@ZhiqiangZhou](https://github.com/strrl)\n- Issue: \n- Apply: \n\n#### KubeVela\n\n##### Integration with developing time to provide consistent experience\n\n- Description: 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.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Jianbo Sun (@wonderflow)\n- Upstream Issue (URL): \n- Apply: \n\n##### Building An Machine Learning Platform on KubeVela\n\n- Description: 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.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Hongchao Deng (@hongchaodeng)\n- Upstream Issue (URL): \n- Apply: \n\n#### Support remote Terraform HCL (Git repo or ConfigMap) in Terraform Controller\n\n- Description: Currently Terraform Controller supports inline HCL, but community users normally already stored Terraform\n HCLs remotely (in Git repo or ConfigMap). Terraform Controller should support remote HCLs.\n- Recommended Skills: Golang, Terraform\n- Mentor(s): ZhengXi Zhou (@zzxwill)\n- Upstream Issue (URL): \n- Apply: \n\n##### Build Gitops continuous deployment tools on kubevela\n\n- Description: 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.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Jian Li (@leejanee)\n- Upstream Issue (URL): \n- Apply: \n\n#### WasmEdge\n\n##### Support WASI-Crypto proposal\n\n- Description: After WasmEdge provides an experimental API, WASI Socket, for supporting Berkeley Sockets API in Wasm. WasmEdge enabled a new way to open a new socket, listen to an existed socket, and send and receive data. Moreover, it will be nice if we can do more things in the related features such as SSL support. To achieve this feature, one possible way is to compile the OpenSSL library to Wasm and link it as a library. However, the performance may be not good, because all the computation jobs are done at the wasm level. Here is an alternative way, instead of the previous one, we can wrap the OpenSSL library to Wasm external functions. For example, binding `ssl_connect` to `(import \"openssl\" \"ssl_connect\" ... )`. Unfortunately, this is not an easy way to do it. To simply the workload, we decide to implement the WASI-crypto proposal first, and then use this proposal to make the above things happen.\n- Recommended Skills: C++, Rust\n- Mentor(s): Hung-Ying Tai (@hydai), Shen-Ta Hsieh (@ibmibmibm)\n- Upstream Issue (URL): \n- Apply: \n\n##### Support Wasm-Signature proposal\n\n- Description: The wasm-Signature proposal is specifically about embedded digital signatures in WebAssembly modules, not about package/OCI signatures. When distributing WebAssembly modules, it will be nice if we can have a way to verify. To achieve this target, we choose a Wasm-Signature proposal as our implementation standard. With this proposal, WasmEdge can provide `sign` and `verify` features.\n- Recommended Skills: C++, Rust\n- Mentor(s): Hung-Ying Tai (@hydai), Shen-Ta Hsieh (@ibmibmibm)\n- Upstream Issue (URL): \n- Apply: \n\n##### Support WASI-NN proposal\n\n- Description: Machine Learning is a big topic nowadays. WasmEdge already provides [a set of TensorFlow host functions](https://github.com/second-state/wasmedge_tensorflow_interface) to enable the ML inference in WebAssembly. However, these TensorFlow host functions are defined by us and they are just a Wasm function binding from the [TensorFlow C API](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/c/c_api.h). Here comes a standard, the [WASI-NN proposal](https://github.com/WebAssembly/wasi-nn) provides a new way to perform neural network inferencing by using a runtime-provided implementation that can leverage host native optimizations, CPU multi-threading, or powerful hardware devices such as GPUs or TPUs.\n- Recommended Skills: C++, Rust\n- Mentor(s): Hung-Ying Tai (@hydai), Yi-Ying He (@q82419)\n- Upstream Issue (URL): \n- Apply: \n\n##### Support Wasm-C-API proposal\n\n- Description: The wasm-c-api proposal provides the C and C++ API for WASM runtimes. Even though WasmEdge already provided the C API, it's proper to implement the wasm-c-API proposal for the general C/C++ API. In the current status, we've already implemented the non-runtime data structures on the branch. Then, we need to finish the runtime implementation.\n- Recommended Skills: C++\n- Mentor(s): Hung-Ying Tai (@hydai), Yi-Ying He (@q82419)\n- Upstream Issue (URL): \n- Apply: \n\n#### LitmusChaos\n\n##### Develop E2E dashboard with CI/CD pipeline details and enhance litmus e2e website\n\n- Description: This project aims to build an E2E Web dashboard that will display the CI/CD pipeline details of [scheduled](https://litmuschaos.github.io/litmus-e2e/generic-pipeline/pipeline-runs/pod-level-run.html) and [manual](https://github.com/litmuschaos/litmus-e2e/tree/master/.github/workflows) runs. It should contain all the litmus backend and portal pipelines and can be easily switched or add more pipelines. Currently, [these](https://github.com/litmuschaos/litmus-e2e/tree/master/.github/workflows) are the pipeline present in the e2e.\n\n- Recommended Skills: Golang, JavaScript, ReactJS\n- Mentor(s): Udit Gaurav (@uditgaurav), Soumya Ghosh Dastidar (@gdsoumya)\n- Upstream Issue (URL): \n- Apply: \n\n##### Develop/Enhance E2E test-cases for ChaosCenter\n\n- Description: This project aims to develop/enhance the E2E test cases for ChaosCenter. The ChaosCenter is a single source of truth to control all the different Chaos Activities happening around Litmus. From the ChaosCenter you get the freedom to manage every single part of Litmus and shape your workflows exactly the way you want them.\n\n- Recommended Skills: Golang, JavaScript, Kubernetes\n- Mentor(s): Vedant Shrotria (@Jonsy13), Raj Babu Das (@rajdas98)\n- Upstream Issue (URL): \n- Apply: \n\n#### Tremor\n\n##### Solidify and generalize error handling code in the runtime\n\n- Description: The runtimes error handling code stems from ancient times where rust was younger, and we were more naive. As such, it is more grown than designed in many places. With the knowledge of the past three years and stabilization of the codebase, now is a good time to polish it and make errors an exciting user experience.\n- Recommended Skills: rust\n- Mentor(s): [@Matthias Wahl](https://github.com/mfelsche), [@Heinz Gies](https://github.com/Licenser), [@Darach Ennis](https://github.com/darach)\n- Issue: \n- Apply: \n\n##### AWS (S3) connectors\n\n- Description: Tremor supports a number of other systems to connect one, yet one of the most wide spread API's in the cloud world (S3) isn't yet supported. This is a chance to shine and build something many users will enjoy.\n- Recommended Skills: rust\n- Mentor(s): [@Matthias Wahl](https://github.com/mfelsche), [@Heinz Gies](https://github.com/Licenser), [@Darach Ennis](https://github.com/darach)\n- Issue: \n- Apply: \n\n#### Thanos\n\n##### Add groupcache (and improve) backend for the caching bucket in Thanos Store\n\n- Description: This project is about implementing the [groupcache](https://github.com/golang/groupcache) back-end for the caching bucket. Caching bucket is a generic mechanism for caching requests to remote object storage. All of the other caching mechanisms currently suffer from the [cache stampede](https://en.wikipedia.org/wiki/Cache_stampede) problem and it is impossible to \"properly\" solve this problem with them. This is where `groupcache` comes in. Some work has already been [done](https://github.com/GiedriusS/thanos/commit/d269ce25b744b02c6d4d99f0e2e72af812e45f37) so you will have to something work off of. `Groupcache` also needs some improvements with regards to fetching multiple keys at once to improve the performance even more. In the end your work will make not just Thanos faster but also cheaper because less requests will need to be made to the remote object storage.\n- Recommended Skills: Go\n- Mentor(s): Giedrius Statkevičius (@GiedriusS), Prem Saraswat (@onprem)\n- Upstream Issue (URL): \n- Apply: \n\n##### Migrate Thanos to the New Protocol Buffers v2 API\n\n- Description: This project is about updating and optimizing the [protocol buffers](https://developers.google.com/protocol-buffers) implementation used for communication throughout the Thanos project. Thanos relies heavily on gRPC and protocol buffers for communication between its many components, and now with the release of the [new Golang API for protocol buffers](https://blog.golang.org/protobuf-apiv2) and the deprecation of the old API, Thanos should be updated to benefit from the improvements in the ecosystem. As part of this project, the protocol buffers generator used in Thanos will be migrated to one that supports the new API and brings other improvements, such as reducing memory allocations. This project will help make Thanos faster and ensure that we stay up to date with the latest libraries.\n- Recommended Skills: Go, protocol buffers\n- Mentor(s): Lucas Servén Marín (@squat), Kemal Akkoyun (@kakkoyun), Giedrius Statkevičius (@GiedriusS)\n- Upstream Issue (URL): \n- Apply: \n\n##### Add metrics to track the progress for compaction and downsampling\n\n- Description: This project is about improving the observability of the Thanos compactor component to help user track the current progress. Thanos compactor usually has to deal with large TSDB blocks for compaction and downsampling. When the data are large, it takes a long time to finish the compaction or downsampling. Now users have to check the bucket UI manually to see whether the work is done. It would be better to have a more fine-grained way to tell the progress of compaction and downsampling. We can have some metrics to track the work and even integrate the stats into the UI.\n- Recommended Skills: Go\n- Mentor(s): Ben Ye (@yeya24)\n- Upstream Issue (URL):\n - \n - \n- Apply: \n\n#### etcd\n\n##### Etcd.io Docs/SEO Improvement Plan Continuation\n\n- Description:\n This project is the continuation of the [etcd.io website](https://etcd.io) docs improvement work. While the relocation of the primary documentation, SEO, and site look and feel work has already been done, there is still more work to be done to implement the new information architecture that has been proposed. This includes working with the mentors and project maintainers to write new pages, adapt existing ones, and write blog posts.\n- Recommended Skills:\n - Technical writing\n - Documentation\n - English\n - git/GitHub\n - Some web design & coding skills may be helpful, but are not required.\n- Mentor(s):\n - Primary\n - [Nate Waddington](https://github.com/nate-double-u)\n - [Celeste Horgan](https://github.com/celestehorgan)\n - Adjunct\n - [Josh Berkus](https://github.com/jberkus)\n - [Sahdev Zala](https://github.com/spzala)\n- Upstream Issue (URL):\n - [Etcd.io Docs/SEO Improvement Plan](https://github.com/etcd-io/website/issues/65)\n - [New IA implementation](https://github.com/etcd-io/website/issues/267)\n- Apply: \n\n#### Buildpacks\n\n##### Update Builder implementation to 0.1 Builder Spec\n\n- Description: In Cloud Native Buildpacks, [Builders](https://buildpacks.io/docs/concepts/components/builder/) are distributed OCI images that act as the complete context for the building of an application. They came into existance by necessity and have risen to be an essential concept that now needs a specification. As part of this project, you will help us make the necessary changes to [pack](https://github.com/buildpacks/pack) to adhere to the specification as well as _finalize_ the specification itself. This will have to be done with consideration to existing implementations in efforts to prevent unintentionally breaking anyone's existing workflow.\n- Recommended Skills: Go, OCI Containers\n- Mentor(s): Javier Romero (@jromero)\n- Upstream Issue (URL): \n- Apply: \n\n##### Web Redesign of Feature Comparison\n\n- Description: Cloud Native Buildpacks is a specification and set of tools that help you take source code and convert them into OCI images. Sound familiar? Maybe you've heard of Docker, Source-2-Image, Kaniko, etc. Well you are not alone. The goal of this project is to refactor our existing [\"features\" page](https://buildpacks.io/features/#comparison) to provide an easier to comprehend comparison across other similar solutions. Through this project, you'll research each alternative, learn how they compare and aim to provide that information to the users in an easy to digest format. This will include designing and implementing a better format to compare projects and their features side-by-side.\n- Recommended Skills: OCI Containers, JavaScript, CSS, HTML, Design\n- Mentor(s): Javier Romero (@jromero)\n- Upstream Issue (URL): \n- Apply: \n\n#### OpenEBS\n\n##### A Kubernetes operator to remove stale PVs of failed statefulset replicas\n\n- Description: When using StatefulSets with Local Volumes on Ephemeral Nodes - the StatefulSet Pods will get stuck in pending state when the Node is taken out of the cluster. In such cases, manual steps are required to verify that Node is out of the cluster, remove the PV and PVC and delete the failed StatefulSet replica to trigger the re-creation of a new replica with a new PVC/PV on a new node. This enhancement request is to build a generic operator that is driven by a configuration to automate the manual steps.\n- Recommended Skills: Go, Kubernetes, Statefulsets, Local Volumes, OpenEBS\n- Mentor(s): Kiran Mova (@kmova), Amit Kumar Das (@AmitKumarDas)\n- Upstream Issue (URL): \n- Apply: \n\n##### Enhance OpenEBS CLI with a sub-command to upgrade Jiva Volumes\n\n- Description: After upgrading the OpenEBS control plane, user/admin is required to upgrade the Jiva Volumes by launching a Kubernetes Job. This enhancement request is to improve the existing OpenEBS CLI jiva sub-commands that will help users with required information to create Kubernetes Jobs, as well as to add a sub-command that will automatically launch the upgrade jobs.\n- Recommended Skills: Go, Kubernetes, OpenEBS\n- Mentor(s): Kiran Mova (@kmova), Harsh Vardhan (@vharsh)\n- Upstream Issue (URL): \n- Apply: \n\n#### Service Mesh Performance\n\n##### Definition of MeshMark\n\n- Description: Create MeshMark provides a universal performance index to gauge your mesh’s efficiency against deployments in other organizations’ environments. MeshMark functions as a service mesh performance index (a scale) to provide people the ability to weigh the value of their service mesh versus the overhead of their service mesh and assess whether they are getting out of the mesh what they are “paying” for in it. Work with maintainers from Layer5, Intel, Red Hat, and HashiCorp on researching cloud native infrastructure performance. Internship involves: machine learning, adaptive algorithms, running and analyzing performance statistics.\n- Recommended Skills: Analytics, Algorithms, Data Science, (Golang and/or C++ helpful, but not necessary)\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Navendu Pottekkat ([@navendu-pottekkat](https://github.com/navendu-pottekkat))\n- Issue: \n- Apply: \n\n#### Meshery\n\n##### Service mesh playground\n\n- Description: Create the world’s service mesh playground. Meshery’s genesis is that of helping teach people about service mesh technology and enabling to operate this type of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission with interactive API documentation connected to a service mesh learning playground (a running instance of Meshery).\n- Recommended Skills: Golang, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Rudraksh Pareek [@delusionaloptimist](https://github.com/delusionaloptimist)\n- Issue: \n- Apply: \n\n##### Workflow engine\n\n- Description: Integrate a new architectural component into Meshery: a workflow engine. This project involves shifting Meshery off of bitcask and off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.\n- Recommended Skills: Golang, Temporal, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Utkarsh Srivastava ([@utkarshdev23](https://twitter.com/utkarshdev23))\n- Issue: \n- Apply: \n\n#### Service Mesh Interface\n\n##### Conformance Program\n\n- Description: Ensure that a service mesh is properly configured and that its behavior conforms to official SMI specifications. Advance the definition of conformance tests and the test framework, Meshery (see [design specification](https://docs.google.com/document/d/1HL8Sk7NSLLj-9PRqoHYVIGyU6fZxUQFotrxbmfFtjwc/edit)).\n- Recommended Skills\\*\\*: Golang, ReactJS, GitHub Actions\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Navendu Pottekkat [@navendu-pottekkat](https://github.com/navendu-pottekkat)\n- Issue: [https://github.com/servicemeshinterface/smi-spec/issues/70](https://github.com/servicemeshinterface/smi-spec/issues/70)\n- Apply: \n" }, { "path": "programs/lfx-mentorship/2021/03-Fall/project_ideas.md", "content": "## Projects ideas\n\nProject maintainers and mentors, please submit the ideas below (under the Proposed Project Ideas section) section using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n### Template\n\n```\n#### CNCF Project Name\n##### Title\n\n- Description:\n- Recommended Skills:\n- Mentor(s):\n- Upstream Issue (URL):\n```\n\n### Sample\n\n#### Prometheus (sample)\n\n##### Refactor the APIs for better readability and less maintenance overhead\n\n- Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n- Recommended Skills: golang\n- Mentor(s): [@Krasi Georgiev](https://github.com/krasi-georgiev)\n- Issue: \n\n\n## Participating Projects\n\n#### Kubernetes\n\n##### Improvements to Cluster API provider for GCP (CAPG)\n\n- Description: The Cluster API is a Kubernetes project to bring declarative, Kubernetes-style APIs to cluster creation, configuration, and management. CAPG provides this Kubernetes-native declarative infrastructure for GCP. The project would start with some help wanted issues around quick start and documentation, this will help with understanding mentee with CAPI/CAPG concepts and current implementation. Then we will move on to some long pending improvements documented in the issues link below.\n- Recommended Skills: Golang, unit and feature testing.\n- Mentor(s): Davanum Srinivas (@dims), Carlos Tadeu Panato Junior (@cpanato)\n- Issue: https://github.com/kubernetes-sigs/cluster-api-provider-gcp/issues\n\n##### Improve SIG-Node testing using Kubetest2\n\n- Description: Kubernetes currently uses Kubetest as the interface for launching and running e2e tests. There is a new [kubetest2](https://github.com/kubernetes-sigs/kubetest2) that is in the process of being developed and will need to be rolled out to various CI harnesses and jobs. As part of this project we will focus on SIG-Node related CI jobs. Here's how we currently test SIG-Node related code - [e2e-node-tests.md](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md). There will be a lot of interesting problems to solve and this work is critical to how we test kubernetes not just in GCP, but also across all the other cloud providers going forward.\n- Recommended Skills: Golang, python, bash, unit and feature testing.\n- Mentor(s): Davanum Srinivas (@dims), Amit Watve (@amwat)\n- Enhancement : https://github.com/kubernetes/enhancements/tree/master/keps/sig-testing/2464-kubetest2-ci-migration\n\n#### Kubernetes Policy Working Group (WG)\n\nThe Kubernetes policy working group focuses on developing tools and solutions that make Kubernetes secure and easiser to use.\n\n##### KubeArmor support for Policy Report CRD\n\n- Description:\n This project will periodically generate or update a [Policy Report Custom Resource (CR)](https://github.com/kubernetes-sigs/wg-policy-prototypes/blob/master/policy-report/README.md) based on events collected from KubeArmor. This could be implemented as a feature in KubeArmor or developed as an external adapter. The candidate will learn about Kubernetes controllers and various security topics.\n- Recommended Skills: Linux, Golang, CLI, Kubernetes\n- Mentor(s): Jim Bugwadia (@JimBugwadia), Mritunjay Kumar Sharma (@mritunjaysharma394)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/wg-policy-prototypes/issues/59\n\n#### Vitess\n\n##### Add complete parsing support for MySQL constructs\n\n- Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. Vitess has its own in-built SQL-parser which it uses to understand the query and represent as structs for further processing. As of now, a lot of MySQL constructs are not parsed and result in syntax errors. For example, we do not have complete support to parse [partition constructs](https://dev.mysql.com/doc/refman/5.7/en/partitioning-overview.html). Parsing for a lot of the newer features in MySQL 8.0 is also missing. The task of the mentee would be to add parsing support for such constructs. \n- Recommended Skills: go, SQL, yacc, compilers and lexers\n- Mentor(s): Manan Gupta (@GuptaManan100)\n- Issue: \n\n##### Add support for comparing strings using collations and character-sets\n\n- Description: Vitess does not yet have support for collations and character-sets. So, to compare varchar strings Vitess needs to rely on [WEIGHT_STRING](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_weight-string) function for now. As per MySQL documentation, WEIGHT_STRING is a debugging function, meant only for internal use. Having the ability to compare strings using collation and character set support we will be able to better implement ORDER BY, GROUP BY, JOIN. It will also allow us to leverage more advanced join techniques than what we currently implement.\n- Recommended Skills: go, SQL\n- Mentor(s): Vicent Marti (@vmg)\n- Issue: \n\n##### Add support for Upgrade/Downgrade Testing\n\n- Description: Currently Vitess has a rich set of functional tests that are run as part of every commit to catch regressions early. However, they are not sufficient to assess the quality of the product for production rollout. We currently do not test for incompatibilities introduced via upgrade, and ensuring that users can downgrade one level if they need to backout of a failed upgrade. The scenarios will need to be written down, and then tests can be written using GitHub actions:\n - Document Supported Upgrade/Downgrade Scenario\n - Author GitHub actions tests to checkout 2 versions, test scenarios.\n- Recommended Skills: go, GitHub Actions, docker\n- Mentor(s): Harshit Gangal (@harshit-gangal)\n- Issue: \n\n#### Kyverno\n\n##### Scalability testing for Kyverno\n\n- Description:\n Define and execute scalability tests for Kyverno on large Kubernetes clusters with several namespaces and resources. The candidate has to propose and execute a performance test plan and help optimize resource usage of Kyverno for different loads for large Kubernetes clusters.\n- Recommended Skills: Kubernetes, Golang, Test\n- Mentor(s): Shuting Zhao (@realshuting)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/2248\n\n##### Extend Kyverno test command to cover generate policies & improve test coverage\n\n- Description:\n Extend the Kyverno CLI to cover generate policies and improve tests coverage for Kyverno. Based on the test results, the candidate has to add more unit/E2E tests.\n- Recommended Skills: Golang, Test\n- Mentor(s): Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/2249\n\n##### Security model and processes for Kyverno\n\n- Description:\n Improve security model and processes for Kyverno. Document security processes, help define a threat model with risks and mitagation, and add best practice processes like publishing signed images.\n- Recommended Skills: Kubernetes, Security, Documentation\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/2250\n\n\n#### Chaos Mesh\n\n##### Monitoring Metrics about Chaos Mesh\n\n- Description: Observability is very important for each application, we want to monitor more things of Chaos Mesh components, enrich the metrics for both logic patterns and performance data. We want to let users could watch the status of Chaos Mesh on grafana dashboard, and developers could using time-series metrics for debugging and profiling.\n- Recommended Skills: golang, prometheus, grafana\n- Mentor(s): [@ZhiqiangZhou](https://github.com/strrl)\n- Issue: \n\n#### KubeVela\n\n##### Integration with developing time to provide consistent experience\n\n- Description: 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.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Jianbo Sun (@wonderflow)\n- Upstream Issue (URL): https://github.com/oam-dev/kubevela/issues/795\n\n##### Building An Machine Learning Platform on KubeVela\n\n- Description: 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.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Hongchao Deng (@hongchaodeng)\n- Upstream Issue (URL): https://github.com/oam-dev/kubevela/issues/2061\n\n\n#### Support remote Terraform HCL (Git repo or ConfigMap) in Terraform Controller\n\n- Description: Currently Terraform Controller supports inline HCL, but community users normally already stored Terraform\n HCLs remotely (in Git repo or ConfigMap). Terraform Controller should support remote HCLs.\n- Recommended Skills: Golang, Terraform\n- Mentor(s): ZhengXi Zhou (@zzxwill)\n- Upstream Issue (URL): https://github.com/oam-dev/terraform-controller/issues/46\n\n##### Build Gitops continuous deployment tools on kubevela\n\n- Description: 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.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Jian Li (@leejanee)\n- Upstream Issue (URL): https://github.com/oam-dev/kubevela/issues/2062\n\n\n#### WasmEdge\n\n##### Support WASI-Crypto proposal\n\n- Description: After WasmEdge provides an experimental API, WASI Socket, for supporting Berkeley Sockets API in Wasm. WasmEdge enabled a new way to open a new socket, listen to an existed socket, and send and receive data. Moreover, it will be nice if we can do more things in the related features such as SSL support. To achieve this feature, one possible way is to compile the OpenSSL library to Wasm and link it as a library. However, the performance may be not good, because all the computation jobs are done at the wasm level. Here is an alternative way, instead of the previous one, we can wrap the OpenSSL library to Wasm external functions. For example, binding `ssl_connect` to `(import \"openssl\" \"ssl_connect\" ... )`. Unfortunately, this is not an easy way to do it. To simply the workload, we decide to implement the WASI-crypto proposal first, and then use this proposal to make the above things happen.\n- Recommended Skills: C++, Rust\n- Mentor(s): Hung-Ying Tai (@hydai), Shen-Ta Hsieh (@ibmibmibm)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/345\n\n##### Support Wasm-Signature proposal\n\n- Description: The wasm-Signature proposal is specifically about embedded digital signatures in WebAssembly modules, not about package/OCI signatures. When distributing WebAssembly modules, it will be nice if we can have a way to verify. To achieve this target, we choose a Wasm-Signature proposal as our implementation standard. With this proposal, WasmEdge can provide `sign` and `verify` features.\n- Recommended Skills: C++, Rust\n- Mentor(s): Hung-Ying Tai (@hydai), Shen-Ta Hsieh (@ibmibmibm)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/344\n\n##### Support WASI-NN proposal\n\n- Description: Machine Learning is a big topic nowadays. WasmEdge already provides [a set of TensorFlow host functions](https://github.com/second-state/wasmedge_tensorflow_interface) to enable the ML inference in WebAssembly. However, these TensorFlow host functions are defined by us and they are just a Wasm function binding from the [TensorFlow C API](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/c/c_api.h). Here comes a standard, the [WASI-NN proposal](https://github.com/WebAssembly/wasi-nn) provides a new way to perform neural network inferencing by using a runtime-provided implementation that can leverage host native optimizations, CPU multi-threading, or powerful hardware devices such as GPUs or TPUs.\n- Recommended Skills: C++, Rust\n- Mentor(s): Hung-Ying Tai (@hydai), Yi-Ying He (@q82419)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/343\n\n##### Support Wasm-C-API proposal\n\n- Description: The wasm-c-api proposal provides the C and C++ API for WASM runtimes. Even though WasmEdge already provided the C API, it's proper to implement the wasm-c-API proposal for the general C/C++ API. In the current status, we've already implemented the non-runtime data structures on the branch. Then, we need to finish the runtime implementation.\n- Recommended Skills: C++\n- Mentor(s): Hung-Ying Tai (@hydai), Yi-Ying He (@q82419)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/306\n\n#### LitmusChaos\n\n##### Develop E2E dashboard with CI/CD pipeline details and enhance litmus e2e website\n\n- Description: This project aims to build an E2E Web dashboard that will display the CI/CD pipeline details of [scheduled](https://litmuschaos.github.io/litmus-e2e/generic-pipeline/pipeline-runs/pod-level-run.html) and [manual](https://github.com/litmuschaos/litmus-e2e/tree/master/.github/workflows) runs. It should contain all the litmus backend and portal pipelines and can be easily switched or add more pipelines. Currently, [these](https://github.com/litmuschaos/litmus-e2e/tree/master/.github/workflows) are the pipeline present in the e2e.\n\n- Recommended Skills: Golang, JavaScript, ReactJS\n- Mentor(s): Udit Gaurav (@uditgaurav), Soumya Ghosh Dastidar (@gdsoumya)\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/3112\n\n##### Develop/Enhance E2E test-cases for ChaosCenter\n\n- Description: This project aims to develop/enhance the E2E test cases for ChaosCenter. The ChaosCenter is a single source of truth to control all the different Chaos Activities happening around Litmus. From the ChaosCenter you get the freedom to manage every single part of Litmus and shape your workflows exactly the way you want them.\n\n- Recommended Skills: Golang, JavaScript, Kubernetes\n- Mentor(s): Vedant Shrotria (@Jonsy13), Raj Babu Das (@rajdas98)\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/3114\n\n\n#### Tremor\n\n##### Solidify and generalize error handling code in the runtime\n\n- Description: The runtimes error handling code stems from ancient times where rust was younger, and we were more naive. As such, it is more grown than designed in many places. With the knowledge of the past three years and stabilization of the codebase, now is a good time to polish it and make errors an exciting user experience.\n- Recommended Skills: rust\n- Mentor(s): [@Matthias Wahl](https://github.com/mfelsche), [@Heinz Gies](https://github.com/Licenser), [@Darach Ennis](https://github.com/darach)\n- Issue: \n\n##### AWS (s3) connectors\n\n- Description: Tremor supports a number of other systems to connect one, yet one of the most wide spread API's in the cloud world (S3) isn't yet supported. This is a chance to shine and build something many users will enjoy.\n- Recommended Skills: rust\n- Mentor(s): [@Matthias Wahl](https://github.com/mfelsche), [@Heinz Gies](https://github.com/Licenser), [@Darach Ennis](https://github.com/darach)\n- Issue: \n\n#### Thanos\n\n##### Add groupcache (and improve) backend for the caching bucket in Thanos Store\n\n- Description: This project is about implementing the [groupcache](https://github.com/golang/groupcache) back-end for the caching bucket. Caching bucket is a generic mechanism for caching requests to remote object storage. All of the other caching mechanisms currently suffer from the [cache stampede](https://en.wikipedia.org/wiki/Cache_stampede) problem and it is impossible to \"properly\" solve this problem with them. This is where `groupcache` comes in. Some work has already been [done](https://github.com/GiedriusS/thanos/commit/d269ce25b744b02c6d4d99f0e2e72af812e45f37) so you will have to something work off of. `Groupcache` also needs some improvements with regards to fetching multiple keys at once to improve the performance even more. In the end your work will make not just Thanos faster but also cheaper because less requests will need to be made to the remote object storage.\n- Recommended Skills: Go\n- Mentor(s): Giedrius Statkevičius (@GiedriusS), Prem Saraswat (@onprem)\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/2962\n\n##### Migrate Thanos to the New Protocol Buffers v2 API\n\n- Description: This project is about updating and optimizing the [protocol buffers](https://developers.google.com/protocol-buffers) implementation used for communication throughout the Thanos project. Thanos relies heavily on gRPC and protocol buffers for communication between its many components, and now with the release of the [new Golang API for protocol buffers](https://blog.golang.org/protobuf-apiv2) and the deprecation of the old API, Thanos should be updated to benefit from the improvements in the ecosystem. As part of this project, the protocol buffers generator used in Thanos will be migrated to one that supports the new API and brings other improvements, such as reducing memory allocations. This project will help make Thanos faster and ensure that we stay up to date with the latest libraries.\n- Recommended Skills: Go, protocol buffers\n- Mentor(s): Lucas Servén Marín (@squat), Kemal Akkoyun (@kakkoyun), Giedrius Statkevičius (@GiedriusS)\n- Upstream Issue (URL): \n\n##### Add metrics to track the progress for compaction and downsampling \n\n- Description: This project is about improving the observability of the Thanos compactor component to help user track the current progress. Thanos compactor usually has to deal with large TSDB blocks for compaction and downsampling. When the data are large, it takes a long time to finish the compaction or downsampling. Now users have to check the bucket UI manually to see whether the work is done. It would be better to have a more fine-grained way to tell the progress of compaction and downsampling. We can have some metrics to track the work and even integrate the stats into the UI.\n- Recommended Skills: Go\n- Mentor(s): Ben Ye (@yeya24)\n- Upstream Issue (URL): \n - \n - \n\n#### etcd\n\n##### Etcd.io Docs/SEO Improvement Plan Continuation\n\n- Description:\n This project is the continuation of the [etcd.io website](https://etcd.io) docs improvement work. While the relocation of the primary documentation, SEO, and site look and feel work has already been done, there is still more work to be done to implement the new information architecture that has been proposed. This includes working with the mentors and project maintainers to write new pages, adapt existing ones, and write blog posts.\n- Recommended Skills:\n - Technical writing\n - Documentation\n - English\n - git/GitHub\n - Some web design & coding skills may be helpful, but are not required.\n- Mentor(s):\n - Primary\n - [Nate Waddington](https://github.com/nate-double-u)\n - [Celeste Horgan](https://github.com/celestehorgan)\n - Adjunct\n - [Josh Berkus](https://github.com/jberkus)\n - [Sahdev Zala](https://github.com/spzala)\n- Upstream Issue (URL):\n - [Etcd.io Docs/SEO Improvement Plan](https://github.com/etcd-io/website/issues/65)\n - [New IA implementation](https://github.com/etcd-io/website/issues/267)\n\n\n\n#### Buildpacks\n\n##### Update Builder implementation to 0.1 Builder Spec\n\n- Description: In Cloud Native Buildpacks, [Builders](https://buildpacks.io/docs/concepts/components/builder/) are distributed OCI images that act as the complete context for the building of an application. They came into existance by necessity and have risen to be an essential concept that now needs a specification. As part of this project, you will help us make the necessary changes to [pack](https://github.com/buildpacks/pack) to adhere to the specification as well as _finalize_ the specification itself. This will have to be done with consideration to existing implementations in efforts to prevent unintentionally breaking anyone's existing workflow.\n- Recommended Skills: Go, OCI Containers\n- Mentor(s): Javier Romero (@jromero)\n- Upstream Issue (URL): \n\n##### Web Redesign of Feature Comparison\n\n- Description: Cloud Native Buildpacks is a specification and set of tools that help you take source code and convert them into OCI images. Sound familiar? Maybe you've heard of Docker, Source-2-Image, Kaniko, etc. Well you are not alone. The goal of this project is to refactor our existing [\"features\" page](https://buildpacks.io/features/#comparison) to provide an easier to comprehend comparison across other similar solutions. Through this project, you'll research each alternative, learn how they compare and aim to provide that information to the users in an easy to digest format. This will include designing and implementing a better format to compare projects and their features side-by-side.\n- Recommended Skills: OCI Containers, JavaScript, CSS, HTML, Design\n- Mentor(s): Javier Romero (@jromero)\n- Upstream Issue (URL): \n\n#### OpenEBS\n\n##### A Kubernetes operator to remove stale PVs of failed statefulset replicas\n\n- Description: When using StatefulSets with Local Volumes on Ephemeral Nodes - the StatefulSet Pods will get stuck in pending state when the Node is taken out of the cluster. In such cases, manual steps are required to verify that Node is out of the cluster, remove the PV and PVC and delete the failed StatefulSet replica to trigger the re-creation of a new replica with a new PVC/PV on a new node. This enhancement request is to build a generic operator that is driven by a configuration to automate the manual steps. \n- Recommended Skills: Go, Kubernetes, Statefulsets, Local Volumes, OpenEBS\n- Mentor(s): Kiran Mova (@kmova), Amit Kumar Das (@AmitKumarDas)\n- Upstream Issue (URL): \n\n##### Enhance OpenEBS CLI with a sub-command to upgrade Jiva Volumes\n\n- Description: After upgrading the OpenEBS control plane, user/admin is required to upgrade the Jiva Volumes by launching a Kubernetes Job. This enhancement request is to improve the existing OpenEBS CLI jiva sub-commands that will help users with required information to create Kubernetes Jobs, as well as to add a sub-command that will automatically launch the upgrade jobs. \n- Recommended Skills: Go, Kubernetes, OpenEBS\n- Mentor(s): Kiran Mova (@kmova), Harsh Vardhan (@vharsh)\n- Upstream Issue (URL): \n\n#### Service Mesh Performance\n\n##### Definition of MeshMark\n\n- Description: Create MeshMark provides a universal performance index to gauge your mesh’s efficiency against deployments in other organizations’ environments. MeshMark functions as a service mesh performance index (a scale) to provide people the ability to weigh the value of their service mesh versus the overhead of their service mesh and assess whether they are getting out of the mesh what they are “paying” for in it. Work with maintainers from Layer5, Intel, Red Hat, and HashiCorp on researching cloud native infrastructure performance. Internship involves: machine learning, adaptive algorithms, running and analyzing performance statistics.\n- Recommended Skills: Analytics, Algorithms, Data Science, (Golang and/or C++ helpful, but not necessary)\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Navendu Pottekkat ([@navendu-pottekkat](https://github.com/navendu-pottekkat))\n- Issue: \n\n#### Meshery\n\n##### Service mesh playground\n\n- Description: Create the world’s service mesh playground. Meshery’s genesis is that of helping teach people about service mesh technology and enabling to operate this type of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission with interactive API documentation connected to a service mesh learning playground (a running instance of Meshery).\n- Recommended Skills: Golang, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Rudraksh Pareek [@delusionaloptimist](https://github.com/delusionaloptimist)\n- Issue: \n\n##### Workflow engine\n\n- Description: Integrate a new architectural component into Meshery: a workflow engine. This project involves shifting Meshery off of bitcask and off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.\n- Recommended Skills: Golang, Temporal, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Utkarsh Srivastava ([@utkarshdev23](https://twitter.com/utkarshdev23))\n- Issue: \n\n#### Service Mesh Interface\n\n##### Conformance Program\n\n- Description: Ensure that a service mesh is properly configured and that its behavior conforms to official SMI specifications. Advance the definition of conformance tests and the test framework, Meshery (see [design specification](https://docs.google.com/document/d/1HL8Sk7NSLLj-9PRqoHYVIGyU6fZxUQFotrxbmfFtjwc/edit)).\n- Recommended Skills**: Golang, ReactJS, GitHub Actions \n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), Navendu Pottekkat [@navendu-pottekkat](https://github.com/navendu-pottekkat)\n- Issue: [https://github.com/servicemeshinterface/smi-spec/issues/70](https://github.com/servicemeshinterface/smi-spec/issues/70)\n" }, { "path": "programs/lfx-mentorship/2022/01-Spring/README.md", "content": "# Q1\n\nStatus: Complete\n\n- [Q1](#q1)\n - [Timeline](#timeline)\n - [Accepted projects](#accepted-projects)\n - [LitmusChaos](#litmuschaos)\n - [Develop new feature and add integration tests for LitmusCTL](#develop-new-feature-and-add-integration-tests-for-litmusctl)\n - [KubeArmor](#kubearmor)\n - [Extending kubearmor-cli-tool filtering options](#extending-kubearmor-cli-tool-filtering-options)\n - [Chaos Mesh](#chaos-mesh)\n - [Interactive Katacoda Playground for Chaos Experiment Examples](#interactive-katacoda-playground-for-chaos-experiment-examples)\n - [KubeVela](#kubevela)\n - [Enhance multi-cluster observability](#enhance-multi-cluster-observability)\n - [Extend monitoring through VelaQL](#extend-monitoring-through-velaql)\n - [Management of Terraform state](#management-of-terraform-state)\n - [WasmEdge](#wasmedge)\n - [Improving the performance of running miniruby](#improving-the-performance-of-running-miniruby)\n - [Improving the performance of running rustpython](#improving-the-performance-of-running-rustpython)\n - [Enable OpenVINO backend for WASI-NN](#enable-openvino-backend-for-wasi-nn)\n - [Implement typed function references proposal](#implement-typed-function-references-proposal)\n - [Kyverno](#kyverno)\n - [Extend Kyverno CLI test command for Generate policy rules](#extend-kyverno-cli-test-command-for-generate-policy-rules)\n - [e2e tests and CLI tests to cover sample policies](#e2e-tests-and-cli-tests-to-cover-sample-policies)\n - [Automate Performance Testing](#automate-performance-testing)\n - [Security enhancements](#security-enhancements)\n - [OpenTelemetry exporter for Kyverno](#opentelemetry-exporter-for-kyverno)\n - [Kuma](#kuma)\n - [Active monitoring of Cross Zone communication](#active-monitoring-of-cross-zone-communication)\n - [Add status infos in Kubernetes CRDs](#add-status-infos-in-kubernetes-crds)\n - [Karmada](#karmada)\n - [Refactor get command to leverage aggregated API](#refactor-get-command-to-leverage-aggregated-api)\n - [Refactor the scheduler framework](#refactor-the-scheduler-framework)\n - [Enhancement for controllers scalability](#enhancement-for-controllers-scalability)\n - [Dashboard development](#dashboard-development)\n - [Kubernetes](#kubernetes)\n - [Documentation assessment (SIG-Network Gateway API)](#documentation-assessment-sig-network-gateway-api)\n - [Automation of AMI build/test/publish pipelines for Cluster API Provider AWS (CAPA)](#automation-of-ami-buildtestpublish-pipelines-for-cluster-api-provider-aws-capa)\n - [Improvements to Kubernetes maintainers-related automation (SIG Contributor Experience)](#improvements-to-kubernetes-maintainers-related-automation-sig-contributor-experience)\n - [Kubernetes (SIG Contribex: Mentoring Subproject)](#kubernetes-sig-contribex-mentoring-subproject)\n - [Creating Katacoda Scenarios To Help New Contributors](#creating-katacoda-scenarios-to-help-new-contributors)\n - [Kubernetes (SIG Cluster Lifecycle)](#kubernetes-sig-cluster-lifecycle)\n - [Improvising unit test coverage(CAPV)](#improvising-unit-test-coveragecapv)\n - [Elekto and Kubernetes SIG-ContribEx](#elekto-and-kubernetes-sig-contribex)\n - [Elections Security Improvements](#elections-security-improvements)\n - [Vitess](#vitess)\n - [Add complete parsing support for MySQL functions](#add-complete-parsing-support-for-mysql-functions)\n - [Tremor](#tremor)\n - [Database Connectors](#database-connectors)\n - [CI and Release process improvements](#ci-and-release-process-improvements)\n - [KubeEdge](#kubeedge)\n - [Plans for Node Group Management](#plans-for-node-group-management)\n - [Move edge native k8s api interface GA](#move-edge-native-k8s-api-interface-ga)\n - [Design and add more e2e tests especially for edge scenarios](#design-and-add-more-e2e-tests-especially-for-edge-scenarios)\n - [Updating the kubeedge docs](#updating-the-kubeedge-docs)\n - [Thanos](#thanos)\n - [Run a community Thanos demo instance](#run-a-community-thanos-demo-instance)\n - [OpenTelemetry PHP](#opentelemetry-php)\n - [Help drive OpenTelemetry PHP to Beta](#help-drive-opentelemetry-php-to-beta)\n - [Pixie](#pixie)\n - [Add support for new protocols in protocol tracer](#add-support-for-new-protocols-in-protocol-tracer)\n - [Service Mesh Performance](#service-mesh-performance)\n - [Definition of MeshMark](#definition-of-meshmark)\n - [Meshery](#meshery)\n - [Service mesh playground](#service-mesh-playground)\n - [Workflow engine](#workflow-engine)\n - [Service Mesh Interface](#service-mesh-interface)\n - [Conformance Program](#conformance-program)\n\n## Timeline\n\n**Spring Term: March 1st - May 31st**\n\n- project applications open: Jan 26th - Feb 1st \\(1 week\\)\n- mentees applications open: Feb 2nd - Feb 13th \\(2 weeks\\)\n- application review by the mentors/admission decisions/HR paperwork: Feb 15th - Feb 25th\n\nMentorship duration - three months \\(12 weeks - full-time schedule\\)\n\n- March 1 (Week 1): Mentorship program begins with the initial work assignments\n- April 12 (End of Week 6): Midterm mentee evaluations and first stipend payments\n- May 31 (End of Week 12): Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals\n\n## Accepted projects\n\n#### LitmusChaos\n\n##### Develop new feature and add integration tests for LitmusCTL\n\n- Description: [LitmusChaos](https://litmuschaos.io) is an open source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way. This project aims to develop new commands/features for litmusctl along with integration tests for it.\n- Recommended Skills: Golang, Kubernetes, CLI\n- Mentor(s): Raj Babu Das (@rajdas98), Sarthak Jain (@SarthakJain26), Saranya Jena (@Saranya-jena)\n- Upstream Issue (URL): \n- LFX URL: \n\n#### KubeArmor\n\n##### Extending kubearmor-cli-tool filtering options\n\n- Description: [KubeArmor](https://github.com/kubearmor/KubeArmor/) is Cloud Native Runtime Security Enforcement System that restricts the behavior (such as process execution, file access, and networking operation) of containers and nodes at the system level using Linux Kernel LSMs (Linux Security Modules) and eBPF. KubeArmor cli-tool (aka karmor) connects to the kubearmor-relay service to provide command-line telemetry/observability. Karmor cli options could be extended to support various other parameters as described in the given issue.\n- Recommended Skills: golang, k8s\n- Mentor(s): Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)\n- Upstream Issue (URL): \n- LFX URL: \n\n- Description: [KubeArmor](https://github.com/kubearmor/KubeArmor/) is Cloud Native Runtime Security Enforcement System that restricts the behavior of containers and nodes at the system level using Linux Kernel LSMs (Linux Security Modules) and eBPF. KubeArmor applies container/pod annotations to achieve some of the goals. Currently, these annotations are applied using k8s rolling update feature that results in pod getting terminated and recreated. Mutating webhooks could achieve the same functionality in a much cleaner way without having to terminate the pods.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jaehyun Nam (@nam-jaehyun), Rahul Jadhav (@nyrahul), Barun Acharya (@daemon1024)\n- Upstream Issue (URL): \n- LFX URL: \n\n#### Chaos Mesh\n\n##### Interactive Katacoda Playground for Chaos Experiment Examples\n\n- Description: [Chaos Mesh](https://chaos-mesh.org/) is a powerful chaos engineering platform for Kubernetes. There is a Katacoda playground as [interactive tutorial](https://chaos-mesh.org/interactive-tutorial/), and we want to build more Katacoda scenarios as the minimum examples for each certain type of chaos experiment. The basic work would be to create new katacoda scenarios as referred to by , and build small applications (with well-built observability) as the target of chaos experiment if required. This project will not require you to dive deep into the hard-core parts of Chaos Mesh, instead, it would be a tour of learning and exploring Chaos Mesh.\n- Recommended Skills: golang, Kubernetes, Shell scripts\n- Mentor(s): Zhiqiang Zhou (@STRRL)\n- Upstream Issue: \n- LFX URL: \n\n#### KubeVela\n\n##### Enhance multi-cluster observability\n\n- Description: [KubeVela](https://github.com/oam-dev/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.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jianbo Sun (@wonderflow), Da Yin (@somefive)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Extend monitoring through VelaQL\n\n- Description: [KubeVela](https://github.com/oam-dev/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.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jianbo Sun (@wonderflow), Da Yin (@somefive)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Management of Terraform state\n\n- Description: To some extent, Terraform state is the most essential component for cloud resources provisioned by Terraform Controller. We need to better manage the state.\n- Recommended Skills: Golang, Terraform\n- Mentor(s): ZhengXi Zhou (@zzxwill)\n- Upstream Issue (URL): \n- LFX URL: \n\n#### WasmEdge\n\n##### Improving the performance of running miniruby\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is an official sandbox project hosted by the CNCF. WasmEdge is designed for the general purpose wasm runtime. However, when running miniruby, we found the performance is worse than other runtimes such as wasmtime, even after using the ahead-of-time compilation.\n- Recommended Skills: profiling tools, c++\n- Mentor(s): Hung-Ying Tai (@hydai), Shen-Ta Hsieh (@ibmibmibm)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Improving the performance of running rustpython\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is an official sandbox project hosted by the CNCF. WasmEdge is designed for the general purpose wasm runtime. However, when running rustpython, we found the performance is worse than other runtimes such as wasmtime, even after using the ahead-of-time compilation.\n- Recommended Skills: profiling tools, c++\n- Mentor(s): Hung-Ying Tai (@hydai), Shen-Ta Hsieh (@ibmibmibm)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Enable OpenVINO backend for WASI-NN\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is an official sandbox project hosted by the CNCF. WasmEdge has implemented some features of WASI-NN. However, the backend is using ONNX. In this ticket, we would like to have both ONNX and OpenVINO backend.\n- Recommended Skills: c++, OpenVINO\n- Mentor(s): Hung-Ying Tai (@hydai), Yi-Ying He (@q82419)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Implement typed function references proposal\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is an official sandbox project hosted by the CNCF. This proposal is one of the requirements for GC proposal. Typed function references proposal adds function references that are typed and can be called directly.\n- Recommended Skills: c++\n- Mentor(s): Hung-Ying Tai (@hydai), Yi-Ying He (@q82419)\n- Upstream Issue (URL): \n- LFX URL: \n\n#### Kyverno\n\n##### Extend Kyverno CLI test command for Generate policy rules\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project extends the Kyverno CLI to cover generate policies and improve tests coverage for Kyverno, based on the test results. The enhancement will involve extending the test command for generate policy rules, adding more test cases for the samples, and automating execution of tests.\n- **Recommended Skills**: Golang, Kubernetes, Test, Automation\n- **Mentor(s)**: Prateek Pandey (@prateekpandey14)\n- **Upstream Issue (URL)**: \n- LFX URL: \n\n##### e2e tests and CLI tests to cover sample policies\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project will create automated test cases for the samples policies which are missing, and automating execution of tests.The enhancement will involve adding more unit/E2E tests.\n- **Recommended Skills**: Golang, Kubernetes, Test, Automation\n- **Mentor(s)**: Vyankatesh Kudtarkar (@vyankyGH), Prateek Pandey (@prateekpandey14)\n- **Upstream Issue (URL)**: \n- LFX URL: \n\n##### Automate Performance Testing\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project automates scalability tests for Kyverno on large Kubernetes clusters with several namespaces and resources. The candidate has to propose an automation plan to create clusters and resources and help optimize resource usage of Kyverno for different loads for large Kubernetes clusters.\n- **Recommended Skills**: Golang, Kubernetes, Test, Automation\n- **Mentor(s)**: Shuting Zhao (@realshuting)\n- **Upstream Issue (URL)**: \n- LFX URL: \n\n##### Security enhancements\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project improves security posture and processes for Kyverno. Improve OSSF Security Scorecard results, define security processes, and add best practice processes like publishing signed images and build attestations for SLSA compliance.\n- **Recommended Skills**: Security, Golang\n- **Mentor(s)**: Jim Bugwadia (@JimBugwadia)\n- **Upstream Issue (URL)**: \n- LFX URL: \n\n##### OpenTelemetry exporter for Kyverno\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project will instrument Kyverno to export OpenTelemetry data for metrics, logs, flows, and policy reports. The project will include testing with OpenTelemetry collectors and documenting the integration steps.\n- **Recommended Skills**: Observability, Prometheus, OpenTelemetry, Golang\n- **Mentor(s)**: Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)\n- **Upstream Issue (URL)**: \n- LFX URL: \n\n#### Kuma\n\n##### Active monitoring of Cross Zone communication\n\n- Description: [Kuma](https://github.com/kumahq/kuma) is a modern Envoy-based service mesh that can run on every cloud, in a single or multi-zone capacity, across both Kubernetes and VMs. It is currently a CNCF Sandbox project. Because Kuma is heavily built with multi zones in mind it is needed for Kuma to provide a good level of observability of connectivity between these zones. This project aims to provide active monitoring of connections between each zone and create new apis to bubble up this information in the GUI and in our Grafana dashboards. This project goes from design to complete implementation, documentation and demonstration.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jakub Dyszkiewicz (@jakubdyszkiewicz), Bart Smykla (@bartsmykla), Charly Molter (@lahabana)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Add status infos in Kubernetes CRDs\n\n- Description: [Kuma](https://github.com/kumahq/kuma) is a modern Envoy-based service mesh that can run on every cloud, in a single or multi-zone capacity, across both Kubernetes and VMs. It is currently a CNCF Sandbox project. While Kuma currently exposes information about status in its [api](https://kuma.io/docs/1.4.x/documentation/http-api/#mesh-insights) Kubernetes users usualy expect these to be also present in the Status fields of their resources. This project aims in adding status to all Kuma CRD and to improve our controllers to set these as cluster state changes.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jakub Dyszkiewicz (@jakubdyszkiewicz), Bart Smykla (@bartsmykla), Charly Molter (@lahabana)\n- Upstream Issue (URL): \n- LFX URL: \n\n#### Karmada\n\n##### Refactor get command to leverage aggregated API\n\n- Description: Now karmadactl get command retrieves resources by Cluster token stored in Cluster object, we want to refactor it to leverage the Aggregated API.\n- Recommended Skills: golang, k8s\n- Mentor(s): Hongcai Ren (@RainbowMango)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Refactor the scheduler framework\n\n- Description: Refactor the framework of karmada-scheduler to make it easier to extend and adopt more scheduling policies.\n- Recommended Skills: golang, k8s\n- Mentor(s): Kevin Wang (@kevin-wangzefeng)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Enhancement for controllers scalability\n\n- Description: Ensures the controllers are suitable for large-scale deployment in production cases.\n- Recommended Skills: golang, k8s\n- Mentor(s): Hongcai Ren (@RainbowMango)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Dashboard development\n\n- Description: The initial version of karmada-dashboard just getting on board, and more pages waiting for development.\n- Recommended Skills: golang, k8s\n- Mentor(s): Hongcai Ren (@RainbowMango)\n- Upstream Issue (URL): \n- LFX URL: \n\n#### Kubernetes\n\n##### Documentation assessment (SIG-Network Gateway API)\n\n- Description: [Gateway API](https://gateway-api.sigs.k8s.io/) is an evolution of Kubernetes Ingress and Service networking that aims to upgrade and improve these APIs. This project is to have a [docs assessment](https://github.com/cncf/techdocs/blob/main/assessments/howto.md) performed, to help us come with a plan for improving our documentaion. In particular, we're looking for someone to look at the content organization, the clarity of the language and concepts, and to make sure it's as readable as possible for both implementors and end users. You'll be working with the mentors and maintainers of the project, with a stretch goal being to make the changes you produce in the initial assessment.\n- Please provide a writing sample with the application.\n- Recommended Skills:\n - Technical Writing\n - Documentation\n - English\n - git/GitHub\n - Familiarity with Kubernetes and Ingress may also be helpful, but are not required.\n- Mentor(s):\n - Primary: [Nick Young](https://github.com/youngnick)\n - Adjunct: [Nate Waddington](https://github.com/nate-double-u)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Automation of AMI build/test/publish pipelines for Cluster API Provider AWS (CAPA)\n\n- **Description**: Cluster API (CAPI) is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify lifecycle management of Kubernetes clusters. CAPA is the infrastructure provider that extends Cluster API to manage Kubernetes clusters on AWS. As a mentee, you will start with learning CAPI/CAPA concepts and then, will work on the main project which is to automate AMI build, test, and publish workflows using Prow, Github, and other Kubernetes automation tools.\n- **Recommended Skills**: Golang, GitHub, Test, Automation, CI/CD pipelines\n- **Mentor(s)**: Sedef Savas (@sedefsavas)\n- **Upstream Issue (URL)**: \n- LFX URL: \n\n##### Improvements to Kubernetes maintainers-related automation (SIG Contributor Experience)\n\n- **Description**: Kubernetes uses OWNERS files to delegate responsibility over different parts of the codebase. These files are also used in the code review process. Unfortunately, over time, there are lots of OWNERS files which have languished and have stale information. Since the velocity of a project is also determined by the number of people reviewing code, it is essential to keep the OWNERS files up-to-date. To ensure this, the `maintainers` project was created.\n This internship involves improving `maintainers` through adding new features and integrating the tool in suitable automation so that it is actively used by the community to signal out-of-date OWNERS files. A stretch goal would also be to improve similar automation tools used to handle github membership for the community.\n- **Recommended Skills**: golang (required), experience with GitHub APIs (preferred but not required)\n- **Mentor(s)**: Nikhita Raghunath (@nikhita), Nabarun Pal (@palnabarun)\n- **Upstream Issue (URL)**: \n- LFX URL: \n\n##### Kubernetes (SIG Contribex: Mentoring Subproject)\n\n###### Creating Katacoda Scenarios To Help New Contributors\n\n- **Description**: There are various Katacoda scenarios available for diverse aspects of Kubernetes, but they focus on an end-user perspective. There is a need to create interactive tutorials to help folks interested in contributing to the project. As a first step, a Katacoda scenario to set up Kubernetes and run tests locally was created that can be found [here](https://github.com/kubernetes-sigs/contributor-katacoda).\n\nThis internship involves improving the existing Katacoda scenario and adding new scenarios to further include aspects of contributing such as spinning up a `kind` cluster with the changes made and testing those changes out. Through the course of this internship, you will also learn how one can contribute to other projects of the Kubernetes community such as the Kubernetes website, and document these processes as Katacoda scenarios to help new contributors get started in their contribution journey.\n\n- **Recommended Skills**: Technical Writing, Kubernetes, Golang (preferred but not required)\n- **Mentor(s)**: Debabrata Panigrahi (@Debanitrkl), Madhav Jivrajani (@MadhavJivrajani)\n- **Upstream Issue (URL)**: \n- LFX URL: \n\n##### Kubernetes (SIG Cluster Lifecycle)\n\n###### Improvising unit test coverage(CAPV)\n\n- **Description**: Cluster API (CAPI) is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify lifecycle management of Kubernetes clusters. CAPV is the infrastructure provider that extends Cluster API to manage Kubernetes clusters on vSphere. As a mentee, you will start with learning CAPI/CAPV concepts and then, will work on the main project which is to improve unit test coverage. The ideal percentage is 70%. This project aims to either achieve that or come close to it.\n- **Recommended Skills**: Golang, GitHub, Test, Automation, CI/CD pipelines\n- **Mentor(s)**: Ankita Swamy(@Ankitasw),Geetika Batra(@geetikabatra)\n- **Upstream Issue (URL)**: \n- LFX URL: \n\n#### Elekto and Kubernetes SIG-ContribEx\n\n##### Elections Security Improvements\n\n- **Description**: [Elekto](https://elekto.dev) is a project for running preference elections for open source projects hosted by the CNCF. It is used for elections for the Kubernetes and Knative projects, and will soon be used by others. During the 2021 elections, a security audit identified several areas of improvement in both in the security and privacy of Elekto, and in the security of the Kubernetes deployment. The mentee for this project would be implementing those recommendations in order to make Elekto and Kubernetes elections more secure.\n- **Recommended Skills**:\n - Python/Flask programming\n - Understand basic HTML/CSS\n - Moderate knowledge of SQL and database migrations\n - How to use basic cryptographic functions available in existing libraries\n- **Mentor(s)**: Josh Berkus (@jberkus)\n- **Issue**: [Implement Security Recommendations](https://github.com/elekto-io/elekto/issues/51)\n- LFX URL: \n\n#### Vitess\n\n##### Add complete parsing support for MySQL functions\n\n- Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. Vitess has its own in-built SQL-parser which it uses to understand the query and represent as structs for further processing. As of now, a lot of MySQL functions are not parsed correctly and result in syntax errors. Parsing for a lot of the newer features in MySQL 8.0 is also missing. The task of the mentee would be to add parsing support for such functions and features.\n- Recommended Skills: go, SQL, yacc, compilers and lexers\n- Mentor(s): Manan Gupta (@GuptaManan100)\n- Issue: \n- LFX URL: \n\n#### Tremor\n\n##### Database Connectors\n\n- Description: Connectors are tremors interface to the outside world, they allow us to integrate with third-party systems. Currently, tremor only has a limited set of connectors for databases, we support s3 and google cloud storage for object stores, and have a k/v connector that offers a simple integrated key-value store. While this is a good starting point interfacing with more databases will make tremor easier to use for our end users. The primary target will be integrating with Yandex Clickhouse.\n- Recommended Skills: Rust, Databases, Testing\n- Mentor(s): Matthias Wahl, Darach Ennis\n- Upstream Issue (URL):\n- LFX URL: \n\n##### CI and Release process improvements\n\n- Description: Tremor has a lot of headroom when it comes to improving the CI and the build process. Those improvements will make the day-to-day life of contributors better and gives end-users more frequent and up-to-date builds allowing them to be used in a more cloud-native fashion. The goal is to make the general developer and user experience around contributing and releasing better. This project is well suited for someone interested in the DevOps/SRE world but offer stretch goals to reach into other topics.\n- Recommended Skills: Make, Git/GitHub, CI/GitHub Actions, GitOps, DevOps, Packaging\n- Mentor(s): Heinz Gies, Darach Ennis\n- Upstream Issue (URL): \n- LFX URL: \n\n#### KubeEdge\n\n##### Plans for Node Group Management\n\n- Description: In edge computing scenarios, nodes are geographically distributed. The same application may be deployed on nodes at different locations. We have plans for achieving the feature of Pod Scheduling among node groups.\n- Recommended Skills: Kubernetes, KubeEdge\n- Mentor(s): Vincent Lin(@vincentgoat), Kevin Wang(@kevin-wangzefeng)\n- Upstream Issue (URL):\n- LFX URL: \n\n##### Move edge native k8s api interface GA\n\n- Description: Now we have add the edge native k8s api interface, apps like operator running in edgeside can access the apiserver and obtain resources. We still need to fix bug and improve the stability.\n- Recommended Skills: Kubernetes, KubeEdge\n- Mentor(s): Shelley Bao(@Shelley-BaoYue), Fisher Xu(@fisherxu)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Design and add more e2e tests especially for edge scenarios\n\n- Description: We have many features for edge scenarios, as edge autonomy, reliable message transmission, etc. We need to add e2e tests for them.\n- Recommended Skills: Kubernetes, KubeEdge\n- Mentor(s): Wack Xu(@wackxu), Fisher Xu(@fisherxu)\n- Upstream Issue (URL): \n- LFX URL: \n\n##### Updating the kubeedge docs\n\n- Description: Now we have lots of new features, we need add more docs for them.\n- Recommended Skills: Kubernetes, KubeEdge\n- Mentor(s): Fisher Xu(@fisherxu)\n- Upstream Issue (URL): \n- LFX URL: \n\n#### Thanos\n\n##### Run a community Thanos demo instance\n\n- Description: Thanos is a distributed system that has a user interface written in React. Let's create a community instance with continuous integration for easy testing of how Thanos works. Also, it could serve as a testing ground for new React components. A server is provided by CNCF ().\n- Recommended Skills: Linux, Ansible, Python, Shell Scripting\n- Mentor(-s): Giedrius Statkevičius (@GiedriusS), Wiard van Rij (@wiardvanrij)\n- Upstream Issue (URL): \n- LFX URL: \n\n#### OpenTelemetry PHP\n\n##### Help drive OpenTelemetry PHP to Beta\n\n- Description: Help to drive our [project board](https://github.com/open-telemetry/opentelemetry-php/projects/1) for OpenTelemetry PHP. This includes validating spec compliance and writing PHP code to implement some of these features\n- Recommended Skills: PHP\n- Mentor(s): @bobstrecansky, @tidal, @brettmc\n- Upstream Issue (URL): \n- LFX URL: \n\n#### Pixie\n\n##### Add support for new protocols in protocol tracer\n\n- Description: [Pixie](https://github.com/pixie-io/pixie) performs automatic tracing and parsing of various protocols (e.g. HTTP, MySQL, Kafka), but there are many others that still need to be added. You can help add protocol parsers for technologies such as Mongo, AMQP (used by RabbitMQ and other message queues), or another protocol of your choice.\n- Recommended Skills: C++\n- Mentor(s): Omid Azizi (@oazizi000)\n- Upstream Issue (URL): , \n- LFX URL: \n\n#### Service Mesh Performance\n\n##### Definition of MeshMark\n\n- Description: Create MeshMark provides a universal performance index to gauge your mesh’s efficiency against deployments in other organizations’ environments. MeshMark functions as a service mesh performance index (a scale) to provide people the ability to weigh the value of their service mesh versus the overhead of their service mesh and assess whether they are getting out of the mesh what they are “paying” for in it. Work with maintainers from Layer5, Intel, Red Hat, and HashiCorp on researching cloud native infrastructure performance. Internship involves: machine learning, adaptive algorithms, running and analyzing performance statistics.\n- Recommended Skills: Analytics, Algorithms, Data Science, (Golang and/or C++ helpful, but not necessary)\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Aditya Chatterjee](http://github.com/warunicorn19)\n- Issue: \n- LFX URL: \n\n#### Meshery\n\n##### Service mesh playground\n\n- Description: Create the world’s service mesh playground. Meshery’s genesis is that of helping teach people about service mesh technology and enabling to operate this type of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission with interactive API documentation connected to a service mesh learning playground (a running instance of Meshery).\n- Recommended Skills: Golang, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Debopriya Bhattacharjee](https://github.com/debo19)\n- Issue: \n- LFX URL: \n\n##### Workflow engine\n\n- Description: Integrate a new architectural component into Meshery: a workflow engine. This project involves shifting Meshery off of bitcask and off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.\n- Recommended Skills: Golang, Temporal, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Ashish Tiwari](https://github.com/revolyssup)\n- Issue: \n- LFX URL: \n\n#### Service Mesh Interface\n\n##### Conformance Program\n\n- Description: Ensure that a service mesh is properly configured and that its behavior conforms to official SMI specifications. Advance the definition of conformance tests and the test framework, Meshery (see [design specification](https://docs.google.com/document/d/1HL8Sk7NSLLj-9PRqoHYVIGyU6fZxUQFotrxbmfFtjwc/edit)).\n- Recommended Skills\\*\\*: Golang, ReactJS, GitHub Actions\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Abhishek Kumar](https://github.com/Abhishek-kumar09)\n- Issue: [https://github.com/servicemeshinterface/smi-spec/issues/70](https://github.com/servicemeshinterface/smi-spec/issues/70)\n- LFX URL: \n" }, { "path": "programs/lfx-mentorship/2022/01-Spring/project_ideas.md", "content": "# Projects ideas\n\nProject maintainers and mentors, please submit the ideas below (under the Proposed Project Ideas section) section using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n- [Projects ideas](#projects-ideas)\n - [Template](#template)\n - [Sample](#sample)\n - [Prometheus (sample)](#prometheus-sample)\n - [Refactor the APIs for better readability and less maintenance overhead](#refactor-the-apis-for-better-readability-and-less-maintenance-overhead)\n - [Proposed Project ideas](#proposed-project-ideas)\n - [LitmusChaos](#litmuschaos)\n - [Develop new feature and add integration tests for LitmusCTL](#develop-new-feature-and-add-integration-tests-for-litmusctl)\n - [KubeArmor](#kubearmor)\n - [Extending kubearmor-cli-tool filtering options](#extending-kubearmor-cli-tool-filtering-options)\n - [Using mutating webhooks for applying pod/container kubearmor annotations](#using-mutating-webhooks-for-applying-podcontainer-kubearmor-annotations)\n - [Chaos Mesh](#chaos-mesh)\n - [Interactive Katacoda Playground for Chaos Experiment Examples](#interactive-katacoda-playground-for-chaos-experiment-examples)\n - [KubeVela](#kubevela)\n - [Enhance multi-cluster observability](#enhance-multi-cluster-observability)\n - [Extend monitoring through VelaQL](#extend-monitoring-through-velaql)\n - [Management of Terraform state](#management-of-terraform-state)\n - [WasmEdge](#wasmedge)\n - [Improving the performance of running miniruby](#improving-the-performance-of-running-miniruby)\n - [Improving the performance of running rustpython](#improving-the-performance-of-running-rustpython)\n - [Enable OpenVINO backend for WASI-NN](#enable-openvino-backend-for-wasi-nn)\n - [Implement typed function references proposal](#implement-typed-function-references-proposal)\n - [Kyverno](#kyverno)\n - [Extend Kyverno CLI test command for Generate policy rules](#extend-kyverno-cli-test-command-for-generate-policy-rules)\n - [e2e tests and CLI tests to cover sample policies](#e2e-tests-and-cli-tests-to-cover-sample-policies)\n - [Automate Performance Testing](#automate-performance-testing)\n - [Security enhancements](#security-enhancements)\n - [OpenTelemetry exporter for Kyverno](#opentelemetry-exporter-for-kyverno)\n - [Kuma](#kuma)\n - [Active monitoring of Cross Zone communication](#active-monitoring-of-cross-zone-communication)\n - [Add status infos in Kubernetes CRDs](#add-status-infos-in-kubernetes-crds)\n - [Karmada](#karmada)\n - [Refactor get command to leverage aggregated API](#refactor-get-command-to-leverage-aggregated-api)\n - [Refactor the scheduler framework](#refactor-the-scheduler-framework)\n - [Enhancement for controllers scalability](#enhancement-for-controllers-scalability)\n - [Dashboard development](#dashboard-development)\n - [Kubernetes](#kubernetes)\n - [Documentation assessment (SIG-Network Gateway API)](#documentation-assessment-sig-network-gateway-api)\n - [Automation of AMI build/test/publish pipelines for Cluster API Provider AWS (CAPA)](#automation-of-ami-buildtestpublish-pipelines-for-cluster-api-provider-aws-capa)\n - [Improvements to Kubernetes maintainers-related automation (SIG Contributor Experience)](#improvements-to-kubernetes-maintainers-related-automation-sig-contributor-experience)\n - [Kubernetes (SIG Contribex: Mentoring Subproject)](#kubernetes-sig-contribex-mentoring-subproject)\n - [Creating Katacoda Scenarios To Help New Contributors](#creating-katacoda-scenarios-to-help-new-contributors)\n - [Kubernetes (SIG Cluster Lifecycle)](#kubernetes-sig-cluster-lifecycle)\n - [Improvising unit test coverage(CAPV)](#improvising-unit-test-coveragecapv)\n - [Elekto and Kubernetes SIG-ContribEx](#elekto-and-kubernetes-sig-contribex)\n - [Elections Security Improvements](#elections-security-improvements)\n - [Vitess](#vitess)\n - [Add complete parsing support for MySQL functions](#add-complete-parsing-support-for-mysql-functions)\n - [Tremor](#tremor)\n - [Database Connectors](#database-connectors)\n - [CI and Release process improvements](#ci-and-release-process-improvements)\n - [KubeEdge](#kubeedge)\n - [Plans for Node Group Management](#plans-for-node-group-management)\n - [Move edge native k8s api interface GA](#move-edge-native-k8s-api-interface-ga)\n - [Design and add more e2e tests especially for edge scenarios](#design-and-add-more-e2e-tests-especially-for-edge-scenarios)\n - [Updating the kubeedge docs](#updating-the-kubeedge-docs)\n - [Thanos](#thanos)\n - [Run a community Thanos demo instance](#run-a-community-thanos-demo-instance)\n - [OpenTelemetry PHP](#opentelemetry-php)\n - [Help drive OpenTelemetry PHP to Beta](#help-drive-opentelemetry-php-to-beta)\n - [Pixie](#pixie)\n - [Add support for new protocols in protocol tracer](#add-support-for-new-protocols-in-protocol-tracer)\n - [Meshery](#meshery)\n - [Workflow engine](#workflow-engine)\n - [Service mesh playground](#service-mesh-playground)\n - [Service Mesh Performance](#service-mesh-performance)\n - [Definition of MeshMark](#definition-of-meshmark)\n - [Service Mesh Interface](#service-mesh-interface)\n - [Conformance Program](#conformance-program)\n\n## Template\n\n```\n### CNCF Project Name\n#### Title\n\n- Description:\n- Recommended Skills:\n- Mentor(s):\n- Upstream Issue (URL):\n```\n\n## Sample\n\n### Prometheus (sample)\n\n#### Refactor the APIs for better readability and less maintenance overhead\n\n- Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n- Recommended Skills: golang\n- Mentor(s): Krasi Georgiev (@krasi-georgiev)\n- Upstream Issue: \n\n---\n\n## Proposed Project ideas\n\n#### LitmusChaos\n\n##### Develop new feature and add integration tests for LitmusCTL\n\n- Description: [LitmusChaos](\"https://litmuschaos.io\") is an open source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way. This project aims to develop new commands/features for litmusctl along with integration tests for it.\n- Recommended Skills: Golang, Kubernetes, CLI\n- Mentor(s): Raj Babu Das (@rajdas98), Sarthak Jain (@SarthakJain26), Saranya Jena (@Saranya-jena)\n- Upstream Issue (URL): \n\n#### KubeArmor\n\n##### Extending kubearmor-cli-tool filtering options\n\n- Description: [KubeArmor](https://github.com/kubearmor/KubeArmor/) is Cloud Native Runtime Security Enforcement System that restricts the behavior (such as process execution, file access, and networking operation) of containers and nodes at the system level using Linux Kernel LSMs (Linux Security Modules) and eBPF. KubeArmor cli-tool (aka karmor) connects to the kubearmor-relay service to provide command-line telemetry/observability. Karmor cli options could be extended to support various other parameters as described in the given issue.\n- Recommended Skills: golang, k8s\n- Mentor(s): Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)\n- Upstream Issue (URL): \n\n##### Using mutating webhooks for applying pod/container kubearmor annotations\n\n- Description: [KubeArmor](https://github.com/kubearmor/KubeArmor/) is Cloud Native Runtime Security Enforcement System that restricts the behavior of containers and nodes at the system level using Linux Kernel LSMs (Linux Security Modules) and eBPF. KubeArmor applies container/pod annotations to achieve some of the goals. Currently, these annotations are applied using k8s rolling update feature that results in pod getting terminated and recreated. Mutating webhooks could achieve the same functionality in a much cleaner way without having to terminate the pods.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jaehyun Nam (@nam-jaehyun), Rahul Jadhav (@nyrahul), Barun Acharya (@daemon1024)\n- Upstream Issue (URL): \n\n#### Chaos Mesh\n\n##### Interactive Katacoda Playground for Chaos Experiment Examples\n\n- Description: [Chaos Mesh](https://chaos-mesh.org/) is a powerful chaos engineering platform for Kubernetes. There is a Katacoda playground as [interactive tutorial](https://chaos-mesh.org/interactive-tutorial/), and we want to build more Katacoda scenarios as the minimum examples for each certain type of chaos experiment. The basic work would be to create new katacoda scenarios as referred to by , and build small applications (with well-built observability) as the target of chaos experiment if required. This project will not require you to dive deep into the hard-core parts of Chaos Mesh, instead, it would be a tour of learning and exploring Chaos Mesh.\n- Recommended Skills: golang, Kubernetes, Shell scripts\n- Mentor(s): Zhiqiang Zhou (@STRRL)\n- Upstream Issue: \n\n#### KubeVela\n\n##### Enhance multi-cluster observability\n\n- Description: [KubeVela](https://github.com/oam-dev/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.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jianbo Sun (@wonderflow), Da Yin (@somefive)\n- Upstream Issue (URL): \n\n##### Extend monitoring through VelaQL\n\n- Description: [KubeVela](https://github.com/oam-dev/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.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jianbo Sun (@wonderflow), Da Yin (@somefive)\n- Upstream Issue (URL): \n\n##### Management of Terraform state\n\n- Description: To some extent, Terraform state is the most essential component for cloud resources provisioned by Terraform Controller. We need to better manage the state.\n- Recommended Skills: Golang, Terraform\n- Mentor(s): ZhengXi Zhou (@zzxwill)\n- Upstream Issue (URL): \n\n#### WasmEdge\n\n##### Improving the performance of running miniruby\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is an official sandbox project hosted by the CNCF. WasmEdge is designed for the general purpose wasm runtime. However, when running miniruby, we found the performance is worse than other runtimes such as wasmtime, even after using the ahead-of-time compilation.\n- Recommended Skills: profiling tools, c++\n- Mentor(s): Hung-Ying Tai (@hydai), Shen-Ta Hsieh (@ibmibmibm)\n- Upstream Issue (URL): \n\n##### Improving the performance of running rustpython\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is an official sandbox project hosted by the CNCF. WasmEdge is designed for the general purpose wasm runtime. However, when running rustpython, we found the performance is worse than other runtimes such as wasmtime, even after using the ahead-of-time compilation.\n- Recommended Skills: profiling tools, c++\n- Mentor(s): Hung-Ying Tai (@hydai), Shen-Ta Hsieh (@ibmibmibm)\n- Upstream Issue (URL): \n\n##### Enable OpenVINO backend for WASI-NN\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is an official sandbox project hosted by the CNCF. WasmEdge has implemented some features of WASI-NN. However, the backend is using ONNX. In this ticket, we would like to have both ONNX and OpenVINO backend.\n- Recommended Skills: c++, OpenVINO\n- Mentor(s): Hung-Ying Tai (@hydai), Yi-Ying He (@q82419)\n- Upstream Issue (URL): \n\n##### Implement typed function references proposal\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is an official sandbox project hosted by the CNCF. This proposal is one of the requirements for GC proposal. Typed function references proposal adds function references that are typed and can be called directly.\n- Recommended Skills: c++\n- Mentor(s): Hung-Ying Tai (@hydai), Yi-Ying He (@q82419)\n- Upstream Issue (URL): \n\n#### Kyverno\n\n##### Extend Kyverno CLI test command for Generate policy rules\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project extends the Kyverno CLI to cover generate policies and improve tests coverage for Kyverno, based on the test results. The enhancement will involve extending the test command for generate policy rules, adding more test cases for the samples, and automating execution of tests.\n- **Recommended Skills**: Golang, Kubernetes, Test, Automation\n- **Mentor(s)**: Prateek Pandey (@prateekpandey14)\n- **Upstream Issue (URL)**: \n\n##### e2e tests and CLI tests to cover sample policies\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project will create automated test cases for the samples policies which are missing, and automating execution of tests.The enhancement will involve adding more unit/E2E tests.\n- **Recommended Skills**: Golang, Kubernetes, Test, Automation\n- **Mentor(s)**: Vyankatesh Kudtarkar (@vyankyGH), Prateek Pandey (@prateekpandey14)\n- **Upstream Issue (URL)**: \n\n##### Automate Performance Testing\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project automates scalability tests for Kyverno on large Kubernetes clusters with several namespaces and resources. The candidate has to propose an automation plan to create clusters and resources and help optimize resource usage of Kyverno for different loads for large Kubernetes clusters.\n- **Recommended Skills**: Golang, Kubernetes, Test, Automation\n- **Mentor(s)**: Shuting Zhao (@realshuting)\n- **Upstream Issue (URL)**: \n\n##### Security enhancements\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project improves security posture and processes for Kyverno. Improve OSSF Security Scorecard results, define security processes, and add best practice processes like publishing signed images and build attestations for SLSA compliance.\n- **Recommended Skills**: Security, Golang\n- **Mentor(s)**: Jim Bugwadia (@JimBugwadia)\n- **Upstream Issue (URL)**: \n\n##### OpenTelemetry exporter for Kyverno\n\n- **Description**: [Kyverno](https://kyverno.io) is a Kubernetes native policy engine that secures and automates Kubernetes configurations. This project will instrument Kyverno to export OpenTelemetry data for metrics, logs, flows, and policy reports. The project will include testing with OpenTelemetry collectors and documenting the integration steps.\n- **Recommended Skills**: Observability, Prometheus, OpenTelemetry, Golang\n- **Mentor(s)**: Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)\n- **Upstream Issue (URL)**: \n\n#### Kuma\n\n##### Active monitoring of Cross Zone communication\n\n- Description: [Kuma](https://github.com/kumahq/kuma) is a modern Envoy-based service mesh that can run on every cloud, in a single or multi-zone capacity, across both Kubernetes and VMs. It is currently a CNCF Sandbox project. Because Kuma is heavily built with multi zones in mind it is needed for Kuma to provide a good level of observability of connectivity between these zones. This project aims to provide active monitoring of connections between each zone and create new apis to bubble up this information in the GUI and in our Grafana dashboards. This project goes from design to complete implementation, documentation and demonstration.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jakub Dyszkiewicz (@jakubdyszkiewicz), Bart Smykla (@bartsmykla), Charly Molter (@lahabana)\n- Upstream Issue (URL): \n\n##### Add status infos in Kubernetes CRDs\n\n- Description: [Kuma](https://github.com/kumahq/kuma) is a modern Envoy-based service mesh that can run on every cloud, in a single or multi-zone capacity, across both Kubernetes and VMs. It is currently a CNCF Sandbox project. While Kuma currently exposes information about status in its [api](https://kuma.io/docs/1.4.x/documentation/http-api/#mesh-insights) Kubernetes users usualy expect these to be also present in the Status fields of their resources. This project aims in adding status to all Kuma CRD and to improve our controllers to set these as cluster state changes.\n- Recommended Skills: golang, k8s\n- Mentor(s): Jakub Dyszkiewicz (@jakubdyszkiewicz), Bart Smykla (@bartsmykla), Charly Molter (@lahabana)\n- Upstream Issue (URL): \n\n#### Karmada\n\n##### Refactor get command to leverage aggregated API\n\n- Description: Now karmadactl get command retrieves resources by Cluster token stored in Cluster object, we want to refactor it to leverage the Aggregated API.\n- Recommended Skills: golang, k8s\n- Mentor(s): Hongcai Ren (@RainbowMango)\n- Upstream Issue (URL): \n\n##### Refactor the scheduler framework\n\n- Description: Refactor the framework of karmada-scheduler to make it easier to extend and adopt more scheduling policies.\n- Recommended Skills: golang, k8s\n- Mentor(s): Kevin Wang (@kevin-wangzefeng)\n- Upstream Issue (URL): \n\n##### Enhancement for controllers scalability\n\n- Description: Ensures the controllers are suitable for large-scale deployment in production cases.\n- Recommended Skills: golang, k8s\n- Mentor(s): Hongcai Ren (@RainbowMango)\n- Upstream Issue (URL): \n\n##### Dashboard development\n\n- Description: The initial version of karmada-dashboard just getting on board, and more pages waiting for development.\n- Recommended Skills: golang, k8s\n- Mentor(s): Hongcai Ren (@RainbowMango)\n- Upstream Issue (URL): \n\n#### Kubernetes\n\n##### Documentation assessment (SIG-Network Gateway API)\n\n- Description: [Gateway API](https://gateway-api.sigs.k8s.io/) is an evolution of Kubernetes Ingress and Service networking that aims to upgrade and improve these APIs. This project is to have a [docs assessment](https://github.com/cncf/techdocs/blob/main/assessments/howto.md) performed, to help us come with a plan for improving our documentaion. In particular, we're looking for someone to look at the content organization, the clarity of the language and concepts, and to make sure it's as readable as possible for both implementors and end users. You'll be working with the mentors and maintainers of the project, with a stretch goal being to make the changes you produce in the initial assessment.\n- Please provide a writing sample with the application.\n- Recommended Skills:\n - Technical Writing\n - Documentation\n - English\n - git/GitHub\n - Familiarity with Kubernetes and Ingress may also be helpful, but are not required.\n- Mentor(s):\n - Primary: [Nick Young](https://github.com/youngnick)\n - Adjunct: [Nate Waddington](https://github.com/nate-double-u)\n- Upstream Issue (URL): \n\n##### Automation of AMI build/test/publish pipelines for Cluster API Provider AWS (CAPA)\n\n- **Description**: Cluster API (CAPI) is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify lifecycle management of Kubernetes clusters. CAPA is the infrastructure provider that extends Cluster API to manage Kubernetes clusters on AWS. As a mentee, you will start with learning CAPI/CAPA concepts and then, will work on the main project which is to automate AMI build, test, and publish workflows using Prow, Github, and other Kubernetes automation tools.\n- **Recommended Skills**: Golang, GitHub, Test, Automation, CI/CD pipelines\n- **Mentor(s)**: Sedef Savas (@sedefsavas)\n- **Upstream Issue (URL)**: \n\n##### Improvements to Kubernetes maintainers-related automation (SIG Contributor Experience)\n\n- **Description**: Kubernetes uses OWNERS files to delegate responsibility over different parts of the codebase. These files are also used in the code review process. Unfortunately, over time, there are lots of OWNERS files which have languished and have stale information. Since the velocity of a project is also determined by the number of people reviewing code, it is essential to keep the OWNERS files up-to-date. To ensure this, the `maintainers` project was created.\n This internship involves improving `maintainers` through adding new features and integrating the tool in suitable automation so that it is actively used by the community to signal out-of-date OWNERS files. A stretch goal would also be to improve similar automation tools used to handle github membership for the community.\n\n- **Recommended Skills**: golang (required), experience with GitHub APIs (preferred but not required)\n- **Mentor(s)**: Nikhita Raghunath (@nikhita), Nabarun Pal (@palnabarun)\n- **Upstream Issue (URL)**: \n\n##### Kubernetes (SIG Contribex: Mentoring Subproject)\n\n###### Creating Katacoda Scenarios To Help New Contributors\n\n- **Description**: There are various Katacoda scenarios available for diverse aspects of Kubernetes, but they focus on an end-user perspective. There is a need to create interactive tutorials to help folks interested in contributing to the project. As a first step, a Katacoda scenario to set up Kubernetes and run tests locally was created that can be found [here](https://github.com/kubernetes-sigs/contributor-katacoda).\n\nThis internship involves improving the existing Katacoda scenario and adding new scenarios to further include aspects of contributing such as spinning up a `kind` cluster with the changes made and testing those changes out. Through the course of this internship, you will also learn how one can contribute to other projects of the Kubernetes community such as the Kubernetes website, and document these processes as Katacoda scenarios to help new contributors get started in their contribution journey.\n\n- **Recommended Skills**: Technical Writing, Kubernetes, Golang (preferred but not required)\n- **Mentor(s)**: Debabrata Panigrahi (@Debanitrkl), Madhav Jivrajani (@MadhavJivrajani)\n- **Upstream Issue (URL)**: \n\n##### Kubernetes (SIG Cluster Lifecycle)\n\n###### Improving unit test coverage(CAPV)\n\n- **Description**: Cluster API (CAPI) is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify lifecycle management of Kubernetes clusters. CAPV is the infrastructure provider that extends Cluster API to manage Kubernetes clusters on vSphere. As a mentee, you will start with learning CAPI/CAPV concepts and then, will work on the main project which is to improve unit test coverage.\n- **Recommended Skills**: Golang, GitHub, Test, Automation, CI/CD pipelines\n- **Mentor(s)**: Ankita Swamy(@Ankitasw),Geetika Batra(@geetikabatra)\n- **Upstream Issue (URL)**: \n\n#### Elekto and Kubernetes SIG-ContribEx\n\n##### Elections Security Improvements\n\n- **Description**: [Elekto](https://elekto.dev) is a project for running preference elections for open source projects hosted by the CNCF. It is used for elections for the Kubernetes and Knative projects, and will soon be used by others. During the 2021 elections, a security audit identified several areas of improvement in both in the security and privacy of Elekto, and in the security of the Kubernetes deployment. The mentee for this project would be implementing those recommendations in order to make Elekto and Kubernetes elections more secure.\n- **Recommended Skills**:\n - Python/Flask programming\n - Understand basic HTML/CSS\n - Moderate knowledge of SQL and database migrations\n - How to use basic cryptographic functions available in existing libraries\n- **Mentor(s)**: Josh Berkus (@jberkus)\n- **Issue**: [Implement Security Recommendations](https://github.com/elekto-io/elekto/issues/51)\n\n#### Vitess\n\n##### Add complete parsing support for MySQL functions\n\n- Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. Vitess has its own in-built SQL-parser which it uses to understand the query and represent as structs for further processing. As of now, a lot of MySQL functions are not parsed correctly and result in syntax errors. Parsing for a lot of the newer features in MySQL 8.0 is also missing. The task of the mentee would be to add parsing support for such functions and features.\n- Recommended Skills: go, SQL, yacc, compilers and lexers\n- Mentor(s): Manan Gupta (@GuptaManan100)\n- Issue: \n\n#### Tremor\n\n##### Database Connectors\n\n- Description: Connectors are tremors interface to the outside world, they allow us to integrate with third-party systems. Currently, tremor only has a limited set of connectors for databases, we support s3 and google cloud storage for object stores, and have a k/v connector that offers a simple integrated key-value store. While this is a good starting point interfacing with more databases will make tremor easier to use for our end users. The primary target will be integrating with Yandex Clickhouse.\n- Recommended Skills: Rust, Databases, Testing\n- Mentor(s): Matthias Wahl, Darach Ennis\n- Upstream Issue (URL):\n\n##### CI and Release process improvements\n\n- Description: Tremor has a lot of headroom when it comes to improving the CI and the build process. Those improvements will make the day-to-day life of contributors better and gives end-users more frequent and up-to-date builds allowing them to be used in a more cloud-native fashion. The goal is to make the general developer and user experience around contributing and releasing better. This project is well suited for someone interested in the DevOps/SRE world but offer stretch goals to reach into other topics.\n- Recommended Skills: Make, Git/GitHub, CI/GitHub Actions, GitOps, DevOps, Packaging\n- Mentor(s): Heinz Gies, Darach Ennis\n- Upstream Issue (URL): \n\n#### KubeEdge\n\n##### Plans for Node Group Management\n\n- Description: In edge computing scenarios, nodes are geographically distributed. The same application may be deployed on nodes at different locations. We have plans for achieving the feature of Pod Scheduling among node groups.\n- Recommended Skills: Kubernetes, KubeEdge\n- Mentor(s): Vincent Lin(@vincentgoat), Kevin Wang(@kevin-wangzefeng)\n- Upstream Issue (URL):\n\n##### Move edge native k8s api interface GA\n\n- Description: Now we have add the edge native k8s api interface, apps like operator running in edgeside can access the apiserver and obtain resources. We still need to fix bug and improve the stability.\n- Recommended Skills: Kubernetes, KubeEdge\n- Mentor(s): Shelley Bao(@Shelley-BaoYue), Fisher Xu(@fisherxu)\n- Upstream Issue (URL): \n\n##### Design and add more e2e tests especially for edge scenarios\n\n- Description: We have many features for edge scenarios, as edge autonomy, reliable message transmission, etc. We need to add e2e tests for them.\n- Recommended Skills: Kubernetes, KubeEdge\n- Mentor(s): Wack Xu(@wackxu), Fisher Xu(@fisherxu)\n- Upstream Issue (URL): \n\n##### Updating the kubeedge docs\n\n- Description: Now we have lots of new features, we need add more docs for them.\n- Recommended Skills: Kubernetes, KubeEdge\n- Mentor(s): Fisher Xu(@fisherxu)\n- Upstream Issue (URL): \n\n#### Thanos\n\n##### Run a community Thanos demo instance\n\n- Description: Thanos is a distributed system that has a user interface written in React. Let's create a community instance with continuous integration for easy testing of how Thanos works. Also, it could serve as a testing ground for new React components. A server is provided by CNCF ().\n- Recommended Skills: Linux, Ansible, Python, Shell Scripting\n- Mentor(-s): Giedrius Statkevičius (@GiedriusS)\n- Upstream Issue (URL): \n\n#### OpenTelemetry PHP\n\n##### Help drive OpenTelemetry PHP to Beta\n\n- Description: Help to drive our [project board](https://github.com/open-telemetry/opentelemetry-php/projects/1) for OpenTelemetry PHP. This includes validating spec compliance and writing PHP code to implement some of these features\n- Recommended Skills: PHP\n- Mentor(s): @bobstrecansky, @tidal, @brettmc\n- Upstream Issue (URL): \n\n#### Pixie\n\n##### Add support for new protocols in protocol tracer\n\n- Description: [Pixie](https://github.com/pixie-io/pixie) performs automatic tracing and parsing of various protocols (e.g. HTTP, MySQL, Kafka), but there are many others that still need to be added. You can help add protocol parsers for technologies such as Mongo, AMQP (used by RabbitMQ and other message queues), or another protocol of your choice.\n- Recommended Skills: C++\n- Mentor(s): Omid Azizi (@oazizi000)\n- Upstream Issue (URL): , \n\n#### Service Mesh Performance\n\n##### Definition of MeshMark\n\n- Description: Create MeshMark provides a universal performance index to gauge your mesh’s efficiency against deployments in other organizations’ environments. MeshMark functions as a service mesh performance index (a scale) to provide people the ability to weigh the value of their service mesh versus the overhead of their service mesh and assess whether they are getting out of the mesh what they are “paying” for in it. Work with maintainers from Layer5, Intel, Red Hat, and HashiCorp on researching cloud native infrastructure performance. Internship involves: machine learning, adaptive algorithms, running and analyzing performance statistics.\n- Recommended Skills: Analytics, Algorithms, Data Science, (Golang and/or C++ helpful, but not necessary)\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Aditya Chatterjee](http://github.com/warunicorn19)\n- Issue: \n\n#### Meshery\n\n##### Service mesh playground\n\n- Description: Create the world’s service mesh playground. Meshery’s genesis is that of helping teach people about service mesh technology and enabling to operate this type of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission with interactive API documentation connected to a service mesh learning playground (a running instance of Meshery).\n- Recommended Skills: Golang, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Debopriya Bhattacharjee](https://github.com/debo19)\n- Issue: \n\n##### Workflow engine\n\n- Description: Integrate a new architectural component into Meshery: a workflow engine. This project involves shifting Meshery off of bitcask and off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.\n- Recommended Skills: Golang, Temporal, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Ashish Tiwari](https://github.com/revolyssup)\n- Issue: \n\n#### Service Mesh Interface\n\n##### Conformance Program\n\n- Description: Ensure that a service mesh is properly configured and that its behavior conforms to official SMI specifications. Advance the definition of conformance tests and the test framework, Meshery (see [design specification](https://docs.google.com/document/d/1HL8Sk7NSLLj-9PRqoHYVIGyU6fZxUQFotrxbmfFtjwc/edit)).\n- Recommended Skills**: Golang, ReactJS, GitHub Actions \n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Abhishek Kumar](https://github.com/Abhishek-kumar09)\n- Issue: [https://github.com/servicemeshinterface/smi-spec/issues/70](https://github.com/servicemeshinterface/smi-spec/issues/70)\n" }, { "path": "programs/lfx-mentorship/2022/02-Summer/README.md", "content": "Status: Completed\n\n# Table of contents\n\n- [Table of contents](#table-of-contents)\n- [Q2](#q2)\n - [Timeline](#timeline)\n - [Summer Term: June 6th - August 31st](#summer-term-june-6th---august-31st)\n - [Mentorship duration - three months (**11 weeks** - full-time schedule)](#mentorship-duration---three-months-11-weeks---full-time-schedule)\n - [Accepted Projects](#accepted-projects)\n - [Crossplane](#crossplane)\n - [Report breaking changes in CustomResourceDefinition schemas for Pull Requests](#report-breaking-changes-in-customresourcedefinition-schemas-for-pull-requests)\n - [Document and add automated testing for pulling packages from private registries](#document-and-add-automated-testing-for-pulling-packages-from-private-registries)\n - [Karmada](#karmada)\n - [Cluster Resource modeling](#cluster-resource-modeling)\n - [Develop Override policy, Resource Binding, Work Page](#develop-override-policy-resource-binding-work-page)\n - [Develop Propagation policy, Settings, About Pages](#develop-propagation-policy-settings-about-pages)\n - [Design & Develop FederatedResourceQuota, SearchRegistry & MultiClusterIngress page](#design--develop-federatedresourcequota-searchregistry--multiclusteringress-page)\n - [Tremor](#tremor)\n - [Pluggable logging](#pluggable-logging)\n - [Hygenic error handling and validation for pipelines](#hygenic-error-handling-and-validation-for-pipelines)\n - [Volcano](#volcano)\n - [Official Website Docs Enhancement](#official-website-docs-enhancement)\n - [Volcano scalability enhancement](#volcano-scalability-enhancement)\n - [KubeArmor](#kubearmor)\n - [Supporting KubeArmor on ARM platforms](#supporting-kubearmor-on-arm-platforms)\n - [Support for OpenShift](#support-for-openshift)\n - [Extend kArmor to include KubeArmor configuration](#extend-karmor-to-include-kubearmor-configuration)\n - [Thanos](#thanos)\n - [Implement Unified Endpoint Discovery](#implement-unified-endpoint-discovery)\n - [WasmEdge](#wasmedge)\n - [Create a Tokio-like async runtime in WasmEdge](#create-a-tokio-like-async-runtime-in-wasmedge)\n - [Provide a wasm-compatible Rust TLS implementation](#provide-a-wasm-compatible-rust-tls-implementation)\n - [Support Durable Objects (DO) in WasmEdge](#support-durable-objects-do-in-wasmedge)\n - [Implement component-model proposal in WasmEdge](#implement-component-model-proposal-in-wasmedge)\n - [Kyverno](#kyverno)\n - [Integrate Kubernetes Pod Security with Kyverno](#integrate-kubernetes-pod-security-with-kyverno)\n - [Kyverno SLSA 3](#kyverno-slsa-3)\n - [CLI test schema and enhancements](#cli-test-schema-and-enhancements)\n - [OpenFunction](#openfunction)\n - [Support and update the Python Functions Framework](#support-and-update-the-python-functions-framework)\n - [OpenELB](#openelb)\n - [Support BGP policy in OpenELB](#support-bgp-policy-in-openelb)\n - [Provide the OpenELB Web UI for managing EIP and IP pool](#provide-the-openelb-web-ui-for-managing-eip-and-ip-pool)\n - [Meshery](#meshery)\n - [Cloud Native Playground](#cloud-native-playground)\n - [Design Configurator](#design-configurator)\n - [Service Mesh Performance](#service-mesh-performance)\n - [Implementation of MeshMark](#implementation-of-meshmark)\n - [Devfile](#devfile)\n - [Add Compose file support in the spec API](#add-compose-file-support-in-the-spec-api)\n - [Add some syntax sugar to speficy the components that are deployed at startup and those that are not](#add-some-syntax-sugar-to-speficy-the-components-that-are-deployed-at-startup-and-those-that-are-not)\n - [Cluster API Provider GCP](#cluster-api-provider-gcp)\n - [Add GPU Support](#add-gpu-support)\n - [Vitess](#vitess)\n - [Add complete parsing support for Spatial MySQL functions](#add-complete-parsing-support-for-spatial-mysql-functions)\n\n# Q2\n\nStatus: Accepting applications\n\n## Timeline\n\n**Note, this has been updated**\n\n### Summer Term: June 6th - August 31st\n\n- mentorships available on LFX Mentorship: May 8th, 2021 (no change, existing proposals still available for application)\n- **proposals cutoff May 24th**\n- applications open: May 9th - **May 29th**\n- application review/admission decisions/HR paperwork: **May 31st - June 3rd**\n\n### Mentorship duration - three months (**11 weeks** - full-time schedule)\n\n- **June 6 (Week 1)**: Mentorship program begins with the initial work assignments\n- July 15 (**End of Week 5**): Midterm mentee evaluations and first stipend payments\n- August 31 (**End of Week 11**): Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals\n\n---\n\n## Accepted Projects\n\n### Crossplane\n\n#### Report breaking changes in CustomResourceDefinition schemas for Pull Requests\n\n- Description: As Crossplane ecosystem expands, it's not unusual anymore to have 100s of `CustomResourceDefinition`s in a provider. A big part of this is thanks to code generation tooling we've been building. However, the changes we make with those tools may result in thousands of lines of changes and it's hard to tell whether there is a breaking change in given `CustomResourceDefinition` in those PRs. Today, we're checking manually to see if there is a breaking change and mark the PR as such so that the notice ends up in the release notes. We can have a GH Action that processes diff in `package/crds` folder and report breaking changes in the OpenAPI v3 Schemas of CRDs. It'd comment on the PR and automatically label it with `breaking-change`. This tool would be useful for the whole Kubernetes community that works to extend Kubernetes with `CustomResourceDefinition`s. We should document the variety of ways to pull packages from popular private registries, and also have testing in place to ensure we don't break any of the mechanisms from release to release.\n- Recommended Skills: golang\n- Mentor(s): Muvaffak Onus (@muvaf), Jared Watts (@jbw976)\n- Upstream Issue (URL): https://github.com/crossplane/crossplane/issues/2863\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/06fe8a5b-c3b9-4d12-975f-19f5ec49d006\n\n#### Document and add automated testing for pulling packages from private registries\n\n- Description: Crossplane supports pulling packages from private registries through a variety of mechanisms, including [IRSA](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), [Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity), and [`packagePullSecrets`](https://doc.crds.dev/github.com/crossplane/crossplane/pkg.crossplane.io/Provider/v1@v1.6.3#spec-packagePullSecrets). There are a wide variety of environments in which a user is pulling a private package, which can lead to confusion about which to use, the precedence with which each is invoked, etc. This can lead to issues such as https://github.com/crossplane/crossplane/issues/2876, where I suspect that we are resolving to [Application Default Credentials](https://cloud.google.com/docs/authentication/production#auth-cloud-implicit-go), when we actually want to be using the provided `packagePullSecret`.\n- Recommended Skills: golang\n- Mentor(s): Daniel Mangum (@hasheddan), Jared Watts (@jbw976)\n- Upstream Issue (URL): https://github.com/crossplane/crossplane/issues/2913\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c6e63427-09d9-42e5-b2af-c9c66e57881a\n\n### Karmada\n\n#### Cluster Resource modeling\n\n- Description: In the scheduling progress, the `karmada-scheduler` makes decisions as per a bunch of factors, one of the factors is the resource details of the cluster. We don't want to collect and store each node's resources in detail(That's a burden for Karmada to maintain the information), but we want to build a resource model for each cluster.\n- Recommended Skills: golang, k8s, algorithm\n- Mentor(s): Hongcai Ren (@RainbowMango)\n- Upstream Issue (URL): https://github.com/karmada-io/karmada/issues/772\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2b3edea5-1f6a-4f6b-a80a-38f5be4ec339\n\n#### Develop Override policy, Resource Binding, Work Page\n\n- Description: These pages on the web dashboard will help to perform different operations for Override policies, Resource Binding in karmada.\n- Recommended Skills: Front-end development, Reactjs, Redux, Figma\n- Mentor(s): Hongcai Ren (@RainbowMango), Chinmay Mehta (@chinmaym07)\n- Upstream Issue (URL): https://github.com/karmada-io/dashboard/issues/15\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bcccd290-87c5-4ad1-9360-e6041d51521c\n\n#### Develop Propagation policy, Settings, About Pages\n\n- Description: Propogation Policy page on the web dashboard will help to perform different operations for Propagation policies in karmada, Settings page will help the user to modify the dashboard according to their needs.\n- Recommended Skills: Front-end development, Reactjs, Redux, Figma\n- Mentor(s): Hongcai Ren (@RainbowMango), Chinmay Mehta (@chinmaym07)\n- Upstream Issue (URL): https://github.com/karmada-io/dashboard/issues/16\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/25122df1-5e92-4d63-9ccc-b0c068237e00\n\n#### Design & Develop FederatedResourceQuota, SearchRegistry & MultiClusterIngress page\n\n- Description:\nMore pages need to be designed & added to the dashboard which are required to make great use of the functionalities of the karmada project using the web ui client.\n- Recommended Skills: Front-end development, Reactjs, Redux, Figma\n- Mentor(s): Hongcai Ren (@RainbowMango), Chinmay Mehta (@chinmaym07)\n- Upstream Issue (URL): https://github.com/karmada-io/dashboard/issues/17\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4c4ccc69-8a71-4f5e-913f-c3c79f9af9a4\n\n### Tremor\n\n#### Pluggable logging\n- Description: Tremor is an event processing system that can - among other things - process logs and metrics. Currently, Tremor uses log4rs to handle its own logging. We would like tremor to have a facility to handle its logs through its own pipelines (similar to the pluggable metrics experience). A starting point could be a sink for log4rs, which could then be replaced completely, making log4rs an optional output.\n- Recommended Skills: Rust, Testing\n- Mentor(s): Ramona Łuczkiewicz (@agares), Darach Ennis (@darach)\n- Upstream Issue: https://github.com/tremor-rs/tremor-runtime/issues/1621\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1218d516-45af-46a3-977b-e5a9de818cec\n\n#### Hygenic error handling and validation for pipelines\n- Description: Tremor uses its own language for pluggable user defined functionality. The language interconnects internal operators via the `connect` statement and the `select` statement. Currently, neither `select` nor `connect` verifies that the operator port of the receiving or the sending part is correct ( exists, and is an expected type ) - this can lead to silent or confusing errors. User experience is super important to tremor, so that is a solution state we’re not happy with. The goal of this mentorship is to add validation and provide targeted hygienic errors to users that are trivial to diagnose and resolve as this will massively improve user experience.\n- Recommended Skills: Rust, Programming Language Design\n- Mentor(s): Matthias Wahl (@mfelsche), Heinz N. Gies (@Licenser)\n- Upstream Issue: https://github.com/tremor-rs/tremor-runtime/issues/1358\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b503dac3-3b2f-49c5-be17-1d95404ef0a9\n\n### Volcano\n\n#### Official Website Docs Enhancement\n\n- Description: Official website docs has not been updated for a long time including technology docs, talks, best practice and so on, which bothers users and developers a lot.\n- Recommended Skills: Kubernetes, golang, technical writing, English, Chinese\n- Mentor(s): Lei Wu (@Thor-wl)\n- Upstream Issue: \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d5a09dfc-c4cc-4733-8c4c-ff3aab2e3688\n\n#### Volcano scalability enhancement\n\n- Description: In order to have a better support of other AI/HPC platforms and GPU, it is necessary to enhance the integration with third-party operators and GPU support.\n- Recommended Skills: Kubernetes, golang\n- Mentor(s): Liang Tang (@shinytang6)\n- Upstream Issue: \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8d1c8ff1-24da-4839-9072-3a6070eeb482\n\n\n### KubeArmor\n\n#### Supporting KubeArmor on ARM platforms\n\n- Description: KubeArmor has garnered interests from edge computing platforms (such as LF Edge OpenHorizon) that leverages k8s control plane for workload orchestration. The primary requirement is to support ARM platforms that are prevalent on the edge devices (especially Raspberry PI). KubeArmor leverages eBPF for observability and Linux Security Modules (such as AppArmor) for policy enforcement. One of the challenges is to check if the eBPF primitives such as observing kprobe, kretprobe, tracepoints that are typically available on the x86 platform are also available on the ARM platform and check if the parameter list fulfills the requirement. Post this analysis, the KubeArmor code might have to be changed to accommodate any differences in the eBPF behavior.\n- Recommended Skills: golang, raspberry-pi, ebpf, k8s\n- Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)\n- Upstream Issue (URL):[ kubearmor/KubeArmor#614](https://github.com/kubearmor/KubeArmor/issues/614)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a91eab39-88b3-4a42-82bf-2bd963772acb\n\n#### Support for OpenShift\n\n- Description: KubeArmor is a cloud-native runtime security enforcement system that restricts the behavior (such as process execution, file access, and networking operation) of containers and nodes (VMs) at the system level.\nThis project aims to support KubeArmor on OpenShift. The work will include compatibility analysis of KubeArmor on OpenShift, finding limitations (if any), and eventually testing it on OpenShift.\n- Recommended Skills: OpenShift, k8s\n- Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)\n- Upstream Issue (URL): [kubearmor/KubeArmor/#221](https://github.com/kubearmor/KubeArmor/issues/221)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/af03f76c-6253-4efc-b26b-17c522794813\n\n#### Extend kArmor to include KubeArmor configuration\n\n- Description: KubeArmor is a cloud-native runtime security enforcement system that restricts the behavior (such as process execution, file access, and networking operation) of containers and nodes (VMs) at the system level. kArmor is a KubeArmor CLI tool that connects to the kubearmor-relay service to provide command-line telemetry and observability data.\nThe project aims to extend KubeArmor CLI-tool kArmor to check KubeArmor configurations in the running environment. This feature will provide various information about KubeArmor like the current running mode (audit or enforcement), the enforcer used by KubeArmor (SELinux or AppArmor or BPF-LSM), whether it's running in systemd mode or on k8s, etc.\n- Recommended Skills: go, k8s\n- Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)\n- Upstream Issue (URL): [kubearmor/kubearmor-client/#19](https://github.com/kubearmor/kubearmor-client/issues/19#issue-1048413733)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/65cabd48-6a5a-4eb6-9e80-4420c152da6a\n\n### Thanos\n\n#### Implement Unified Endpoint Discovery\n\nDescription: Thanos Querier microservice is one of the core component of the Thanos system responsible for asking relevent data stores for metrics, labels, metadata, exemplars, targets, alerts and more and merging their results. One of the key challenges to Querier configuration is telling which endpoints it should talk to and what APIs it should expect. For this we proposed the [Unified Endoint Discovery](https://thanos.io/tip/proposals-accepted/202101-endpoint-discovery.md/) idea, which allows consistency and easy to use configuration across all APIs. This project is meant to continue the implementation of this proposal and make sure it works well for all the edge cases using our e2e testing framework.\nRecommended Skills: Go, DNS\nMentor(s): Bartlomiej Plotka (@bwplotka), Saswata Mukherjee (@saswatamcode)\nUpstream Issue: https://github.com/thanos-io/thanos/issues/5340\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0afef0c2-6ad0-41f1-8c56-10a52afe87b7\n\n### WasmEdge\n\n#### Create a Tokio-like async runtime in WasmEdge\n\n- Description: One of the most important features of WasmEdge is its support for [non-blocking network sockets](https://wasmedge.org/book/en/dev/rust/networking-nonblocking.html). However, the current WasmEdge API for async networking is still cumbersome. Rust developers would prefer to use a Tokio-like async / await API for such tasks. But Tokio is multi-threaded and cannot run correctly in standard single-threaded WebAssembly. Yet, it is possible to [provide a single-threaded Tokio runtime](https://stackoverflow.com/questions/61763072/is-there-a-way-to-use-tokiomain-with-a-single-threaded-runtime-in-tokio-0-2). Our goal is to create a WebAssembly compatible Tokio scheduler.\n- Recommended Skills: Rust, tokio, wasm\n- Mentor(s): juntao(@juntao)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/1429\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/666271e6-7bdf-4050-a2a2-3adaac5a7c13\n\n#### Provide a wasm-compatible Rust TLS implementation\n\n- Description: The WasmEdge networking socket API provides support for TCP and HTTP connections. But many web services today require HTTPS connections. That means we need to support TLS in WasmEdge. The [Rustls](https://github.com/rustls/rustls) crate is the most popular TLS implementation in Rust. However, Rustls is based on the Ring library, which cannot be compiled into WebAssembly. In WasmEdge, we now [support](https://github.com/WasmEdge/WasmEdge/issues/345) the [wasi-crypto spec](https://github.com/WebAssembly/wasi-crypto). That allows us to compile the [rust-crypto](https://crates.io/crates/crypto) library into WebAssembly and run on WasmEdge. The goal of this project is to create a Rust TLS implementation based on rust-crypto.\n- Recommended Skills: Rust, wasm, crypto\n- Mentor(s): juntao(@juntao), WenShuo Yang(@sonder-joker)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/1430\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fca1338f-5be0-41e6-a499-b44e2e722096\n\n#### Support Durable Objects (DO) in WasmEdge\n\n- Description: Durable Objects (DO) are persistent data objects available to applications at runtime. They can be stored in a persistent KV store or a data cache. [DOs are important for stateful serverless functions](https://blog.cloudflare.com/introducing-workers-durable-objects/). The [Anna KVS](https://github.com/hydro-project/anna) project developed by UC Berkeley is an autoscaling KVS ideally suited for edge nodes. It is a good match for WasmEdge to support stateful serverless functions on the edge cloud. The goal of this task is to create Rust and JavaScript clients for Anna KVS using the WasmEdge socket API. It allows Rust-based WasmEdge applications to connect to Anna KVS, and store or retrieve DOs in the KVS. _Note_: A new Rust-based version of Anna KVS is going to be released soon. We will likely use the new version for this task. The network socket API for accessing the KVS will remain largely unchanged from the old version.\n- Recommended Skills: Anna KVS, Rust, wasm, JavaScript, Database\n- Mentor(s): juntao(@juntao)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/1431\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/232a19f2-40de-4dfa-8966-2c1586bc6ecc\n\n#### Implement component-model proposal in WasmEdge\n\n- Description: The [component-model](https://github.com/WebAssembly/component-model) proposal merges and supersedes the [Module Linking](https://github.com/WebAssembly/module-linking/) and [Interface Types](https://github.com/WebAssembly/interface-types) proposals. With this feature, WasmEdge can execute multiple modules wasm with Module Linking and and more flexible types with Interface Type.\n- Recommended Skills: C++, wasm\n- Mentor(s): Hung-Ying Tai(@hydai), Yi-Ying He (@q82419)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/1433\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5def28a6-3ec2-4ba3-b56f-403a03a2b9ef\n\n### Kyverno\n\n#### Integrate Kubernetes Pod Security with Kyverno\n\n- Description: Integrate Kubernetes Pod Security with Kyverno for finer grained controls.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Shuting Zhao (@realshuting)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/3830\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d145fd38-b533-49a8-9b02-60220f9f618c\n\n#### Kyverno SLSA 3\n\n- Description: Implement software supply chain security best practices to achieve SLSA Level 3 compliance (https://slsa.dev/). This includes generation of build provenance data for Kyverno. [Kyverno - SLSA](https://docs.google.com/presentation/d/1jWbSVyQkMn1VdXfg7kW1dYmk8fgcvzBfZ-4ZCAaVOLs/edit#slide=id.g35f391192_00).\n- Recommended Skills: Security, CI/CD, Golang\n- Mentor(s): Jim Bugwadia\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/3119\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/457cabc9-90d3-4519-bfad-92966501dbd4\n\n#### CLI test schema and enhancements\n\n- Description: The Kyverno CLI does not have a formalized schema with proper validation for its `test` command. Create a formal schema which is documented allowing for full validation and related other capabilities which enhance its usage.\n- Recommended Skills: Golang\n- Mentor(s): Vyankatesh Kudtarkar, Chip Zoller,\n- Upstream Issue (URL):\n - https://github.com/kyverno/kyverno/issues/2323\n - https://github.com/kyverno/kyverno/issues/2315\n - https://github.com/kyverno/kyverno/issues/2302\n - https://github.com/kyverno/kyverno/issues/2857\n - https://github.com/kyverno/kyverno/issues/2945\n - https://github.com/kyverno/kyverno/issues/3271\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0e385057-2c8f-48b2-8ff9-b4244870c10c\n\n### OpenFunction\n\n#### Support and update the Python Functions Framework\n\n- Description: [OpenFunction](https://github.com/OpenFunction/OpenFunction) is a cloud-native open source FaaS (Function as a Service) platform. [OpenFunction 0.6.0](https://openfunction.dev/blog/2022/03/25/announcing-openfunction-0.6.0-faas-observability-http-trigger-and-more/) brings notable features including function plugin, distributed tracing for functions, control autoscaling behavior, HTTP trigger to async function, etc. Meanwhile, the asynchronous runtime definition has also been refactored. The core API has been upgraded from `v1alpha1` to `v1beta1`. So far, the Go Function Framework fully supports the latest features of OpenFunction 0.6.0. We hope the Python Functions Framework could also be applicable in OpenFunction 0.6.0.\n- Recommended Skills: Python, Kubernetes, OpenFunction\n- Mentor(s): [Kehui Li](https://github.com/kehuili), [Haili Zhang](https://github.com/webup), [Feynman Zhou](https://github.com/feynmanzhou)\n- Upstream Issue: https://github.com/OpenFunction/functions-framework/issues/18\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0c5cecb1-3de8-435a-acdf-7adfcbd759d3\n\n### OpenELB\n\n#### Support BGP policy in OpenELB\n\n- Description: OpenELB is an open-source load balancer implementation designed for exposing the LoadBalancer type of Kubernetes services in bare metal, edge, and virtualization environments. Currently, OpenELB supports the BGP protocol. However, the BGP policy is not fully supported in OpenELB. Therefore, based on the BGP protocol, OpenELB is supposed to support the BGP policy to enable leveraging the GoBGP policy feature for controlling the route advertisement.\n- Recommended Skills: Golang, Kubernetes, Helm, Docker\n- Mentor(s): [Chauncey Jiang](https://github.com/chaunceyjiang/)，[Yunkang Ren](https://github.com/renyunkang), [Feynman Zhou](https://github.com/feynmanzhou)\n- Upstream Issue: https://github.com/openelb/openelb/issues/267\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b97a815b-6900-4a3e-a4af-7460551f933c\n\n#### Provide the OpenELB Web UI for managing EIP and IP pool\n\n- Description: OpenELB is an open-source load balancer implementation designed for exposing the LoadBalancer type of Kubernetes services in bare metal, edge, and virtualization environments. Currently, Currently, the allocation of OpenELB EIP pool and EIP can only be viewed and managed using command in the terminal. We hope to provide a simple web console to make OpenELB much developer-friendly. Users could manage EIP pool and EIP resources using web UI.\n- Recommended Skills: Javascript, HTML, Docker, Kubernetes\n- Mentor(s): [Yunkang Ren](https://github.com/renyunkang), [Changjiang Li](https://github.com/weili520), [Feynman Zhou](https://github.com/feynmanzhou)\n- Upstream Issue: https://github.com/openelb/openelb/issues/244\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/947885e1-6b32-4b3c-85cb-955cb617237e\n\n### Meshery\n\n#### Cloud Native Playground\n\n- Description: Hosted at play.meshery.io, build a unique learning environment for learning modern application networking through Meshery's support of every service mesh, orchestration of Kubernetes, and integration with many other CNCF projects. Meshery's genesis is that of helping teach people about service mesh technology and enabling to operate this type of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission with interactive API documentation connected to a cloud native playground (a running instance of Meshery).\n- Recommended Skills: Golang, ReactJS\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Aditya Chatterjee](https://github.com/warunicorn19)\n- Issue: \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bb6cf95e-bbdc-4b50-8446-45507c9e5a6a\n\n#### Design Configurator\n\n- Description: Integrate a new user experience into Meshery: a cloud native design configurator. This project involves presentation of Kuberenetes core resources and any custom resource (CRD) as a configurable component in a React-based user interface in which users design (in great detail) and deploy their cloud native infrastructure. Interns will familiarize with concepts of content lifecycle management.\n- Recommended Skills: ReactJS, OpenAPI, JSON Schema.\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Ashish Tiwari](https://github.com/revolyssup)\n- Issue: \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cf4de999-41a9-4769-a298-d7d4b208ab3d\n\n### Service Mesh Performance\n\n#### Implementation of MeshMark\n\n- Description: MeshMark functions as a service mesh performance index (a scale) to provide people the ability to weigh the value of their service mesh versus the overhead of their service mesh and assess whether they are getting out of the mesh what they are “paying” for in it. Implementation of this new performance index involves integration with Meshery, Prometheus, and more.\n- Recommended Skills\\*\\*: Golang, ReactJS, GitHub Actions\n- Mentor(s): Lee Calcote ([@lcalcote](https://twitter.com/lcalcote)), [Abhishek Kumar](https://github.com/Abhishek-kumar09)\n- Issue: https://github.com/service-mesh-performance/service-mesh-performance/issues/325\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cf992af8-6102-4c2d-8394-c3462112e39f\n\n### Devfile\n\n#### Add Compose file support in the spec API\n\n- Description: Devfiles are YAML files that define development environment running in the cloud. The main part of a Devfile is the components section and specify the containers required to code, build and test an application. The Devfile can either include those containers defintions or reference external files such as Dockerfiles or Kubernetes manifests. [The Compose file](https://github.com/compose-spec/compose-spec/blob/master/spec.md) is a popular format in open source development projects to define runtime environments for testing the application but those cannot be referenced by a Devfile yet. The goal is to update the API specification to allow referencing a Compose file from a Devfile and to implement the support in the Devfile library.\n- Expected outcome: Create a PR against https://github.com/devfile/api to update the spec with the support for Compose files and a PR against https://github.com/devfile/libary to implement it using (the use of an external library such as [kompose](https://github.com/kubernetes/kompose) is recommended). As a stretch goal, implement Compose file support for the DevWorkspace Kubernetes operator too.\n- Expected size of the project: 350h\n- Difficulty rating: Medium\n- Recommended Skills: Golang, Compose, Kubernetes\n- Mentor(s): Mario Loriedo (@l0rd)\n- Upstream Issue (URL): https://github.com/devfile/api/issues/501\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ef552046-cf54-4fe1-ac31-0a1014210e15\n\n#### Add some syntax sugar to speficy the components that are deployed at startup and those that are not\n\n- Description: Devfiles are YAML files that define development environment running in the cloud. The main part of a Devfile is the components section and specify the containers required to code, build and test an application. Some components, such as those to code and build the application, need to be deployed as soon as development environment is provisioned. Others instead are supposed to be started later, usually when a command is triggered by the developer to test the applicaiton she is working on (a database for example). The current definition of the latter type of coponents is complicated and not self explanatory. The goal of this project is to add a new component field to specify if the component should be included at startup or not.\n- Expected outcome: Create a PR against https://github.com/devfile/api to update the component spec and a PR against https://github.com/devfile/library to implement it using. As a stretch goal, implement the support for the new field for the DevWorkspace Kubernetes operator too.\n- Expected size of the project: 350h\n- Difficulty rating: Medium\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Mario Loriedo (@l0rd)\n- Upstream Issue (URL): https://github.com/devfile/api/issues/852\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3feec75a-3d80-476a-83ab-89ee90f48aad\n\n### Cluster API Provider GCP\n\n#### Add GPU Support\n\n- Description: Cluster API Provider GCP (a.k.a. CAPG) enables the creation of Kubernetes clusters in GCP with Cluster API. Currently the clusters it creates do not support running workloads in them that take advantage of GPUs and so this rules out things like highly performant machine learning and computational heavy work workloads. We want to enhance CAPG so that it supports GPUs so that users can run these type of workloads. This will require creating a proposal for the change (i.e. design work) and then implementing the propsal which may include changes to the api/controllers, base images and driver installation.\n- Expected outcome: This work will enable CAPG to support the creation of Kubernetes clusters where workfloads can take advantage of GPUs.\n- Difficulty rating: Medium\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Carlos Panato (@cpanato), Davanum Srinivas (@dims), Richard Case (@richardcase)\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/cluster-api-provider-gcp/issues/289\n- LFX URL: [https://mentorship.lfx.linuxfoundation.org/project/e799bb33-a695-420b-af32-e596938c6960](https://mentorship.lfx.linuxfoundation.org/project/e799bb33-a695-420b-af32-e596938c6960)\n\n### Vitess\n\n#### Add complete parsing support for Spatial MySQL functions\n\n- Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. Vitess has its own in-built SQL-parser which it uses to understand the query and represent as structs for further processing. As of now, a lot of spatial MySQL functions are not parsed correctly and result in syntax errors. The task of the mentee would be to add parsing support for such functions and features which can be found at https://dev.mysql.com/doc/refman/8.0/en/spatial-analysis-functions.html\n- Recommended Skills: go, SQL, yacc, compilers and lexers\n- Mentor(s): Manan Gupta (@GuptaManan100)\n- Issue: \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/75533c12-1487-40b0-858c-42babeabf782\n" }, { "path": "programs/lfx-mentorship/2022/02-Summer/project_ideas.md", "content": "# Projects ideas\n\nProject maintainers and mentors, please submit the ideas below (under the Proposed Project Ideas section) section using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n## Template\n\n```\n### CNCF Project Name\n#### Title\n\n- Description:\n- Recommended Skills:\n- Mentor(s):\n- Upstream Issue (URL):\n```\n\n## Sample\n\n### Prometheus (sample)\n\n#### Refactor the APIs for better readability and less maintenance overhead\n\n- Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n- Recommended Skills: golang\n- Mentor(s): Krasi Georgiev (@krasi-georgiev)\n- Upstream Issue: \n\n---\n\n## Proposed Project ideas\n\nAccepted ideas have been moved to [README.md](README.md) \n\n" }, { "path": "programs/lfx-mentorship/2022/03-Sept-Nov/README.md", "content": "# Term 03 - 2022 September - November \n\nStatus: Completed\n\n## Table of Contents\n\n - [Timeline](#timeline)\n - [Term 3 September 5th November 30th](#term-3-september-5th-november-30th)\n - [Project Instructions](#project-instructions)\n - [Application instructions](#application-instructions)\n - [Accepted Projects](#accepted-projects)\n - [Cilium](#cilium)\n - [Improving Security posture of the Cilium/Hubble/Tetragon release process](#improving-security-posture-of-the-ciliumhubbletetragon-release-process)\n - [CNCF TAG Contributor Strategy](#cncf-tag-contributor-strategy)\n - [Mentoring Workspaces - GITHUBUSER.PROJECT.cncf.io (w/ VSCode)](#mentoring-workspaces---githubuserprojectcncfio-w-vscode)\n - [CNCF TAG Network and Observability](#cncf-tag-network-and-observability)\n - [Kubernetes ontology and subgraph module design](#kubernetes-ontology-and-subgraph-module-design)\n - [Devfile](#devfile)\n - [Add Compose file support in the spec API II](#add-compose-file-support-in-the-spec-api-ii)\n - [Karmada](#karmada)\n - [Enable configurable resource interpreter](#enable-configurable-resource-interpreter)\n - [KubeArmor](#kubearmor)\n - [Add BTF and BPF CO-RE Support to KubeArmor](#add-btf-and-bpf-co-re-support-to-kubearmor)\n - [Use non-privileged containers for KubeArmor daemonset](#use-non-privileged-containers-for-kubearmor-daemonset)\n - [Kyverno](#kyverno)\n - [Policy Exceptions](#policy-exceptions)\n - [Enable resource clean-up](#enable-resource-clean-up)\n - [Implement new custom JMESPath filters](#implement-new-custom-jmespath-filters)\n - [Logging in JSON plus other enhancements](#logging-in-json-plus-other-enhancements)\n - [More support for subresources](#more-support-for-subresources)\n - [Meshery](#meshery)\n - [Integration of Open Policy Agent (OPA) and Meshery](#integration-of-open-policy-agent-opa-and-meshery)\n - [User Interface Overhaul: State Management w/Apollo/GraphQL](#user-interface-overhaul-state-management-wapollographql)\n - [Service Mesh Performance](#service-mesh-performance)\n - [Adaptive Load Controller](#adaptive-load-controller)\n - [Convergence of Network and Graph topologies](#convergence-of-network-and-graph-topologies)\n - [Thanos](#thanos)\n - [Receive: Support for tenant-specific external labels](#receive-support-for-tenant-specific-external-labels)\n - [Load balancing of API communication in Thanos](#load-balancing-of-api-communication-in-thanos)\n - [Vitess](#vitess)\n - [Add complete parsing support for Spatial MySQL functions II](#add-complete-parsing-support-for-spatial-mysql-functions-ii)\n - [Improve evaluation engine](#improve-evaluation-engine)\n - [Volcano](#volcano)\n - [Pick out reasonable victim pods for rescheduling plugin](#pick-out-reasonable-victim-pods-for-rescheduling-plugin)\n - [Implement pod filter chain for rescheduling](#implement-pod-filter-chain-for-rescheduling)\n - [Avoid hot node in dynamic scheduling based on real workload](#avoid-hot-node-in-dynamic-scheduling-based-on-real-workload)\n - [Integrate Volcano with Ray](#integrate-volcano-with-ray)\n - [Support hot update daemon log level](#support-hot-update-daemon-log-level)\n - [WasmEdge](#wasmedge)\n - [Support serialize and deserialize in WasmEdge](#support-serialize-and-deserialize-in-wasmedge)\n - [Porting OpenVINO on multiple platforms for the WASI-NN proposal in WasmEdge](#porting-openvino-on-multiple-platforms-for-the-wasi-nn-proposal-in-wasmedge)\n - [Node API support for WasmEdge QuickJS](#node-api-support-for-wasmedge-quickjs)\n - [OpenCV SDKs for Wasm in WasmEdge](#opencv-sdks-for-wasm-in-wasmedge)\n\n\n### Timeline\n\n#### Term 3: September 5th - November 30th\n\nMentorship duration - three months (12 weeks - full-time schedule)\n\n| activity | date |\n| --- | --- | \n| project proposals | August 1 - August 12, 5:00 PM PDT |\n| mentee applications open | August 15 - August 24, 5:00 PM PDT |\n| application review/admission decisions/HR paperwork | August 25 - September 1, 5:00 PM PDT |\n| Mentorship program begins with the initial work assignments | September 5 (Week 1) | \n| Midterm mentee evaluations and first stipend payments | October 6 (End of Week 5) |\n| Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals | November 16, 5:00 PM PST (End of Week 11) |\n| Last day of term | November 30 |\n\n\n### Project Instructions\n\nProject proposals open August 1st, 2022.\n\nOnce opened, Project maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/lfx-mentorship/2022/03-Sept-Nov/project_ideas.md, by August 12th, 2022.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/lfx-mentorship/README.md#program-guidelines) page.\n\n\n## Accepted Projects\n\n### Cilium\n\n#### Improving Security posture of the Cilium/Hubble/Tetragon release process\n\n- Description: To be able to improve the Security posture of the Cilium family’s open source projects (Cilium, Hubble, Tetragon), we would need to create signed SBOMs, signed release artifacts for each open source project and automate all of these steps.\n\n- Recommended Skills: Golang, GitHub Actions, Kubernetes, Docker, Security\n- Mentor(s): [André Martins](https://github.com/aanm) [Natália Réka Ivánkó](https://github.com/sharlns) [Jed Salazar](https://github.com/jedsalazar)\n- Issues: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/680e32e5-d056-46fa-a94d-4af453d4e81d\n\n\n### CNCF TAG Contributor Strategy\n\n#### Mentoring Workspaces - GITHUBUSER.PROJECT.cncf.io (w/ VSCode)\n\n- Description: pair.sharing.io is a mentoring / pair environment used by ii.nz that brings up clusters to co-learn and co-author via tmate+emacs and a live cluster with many features useful to cloud native development. However, while many folks find the ideas useful, it would be good to reach a wider audience by bringing up workspaces w/ VSCode as an alternative to emacs. The request is for a PoC deploying coder.com to CNCF Infrastructure (likely Packet) and bringing over some of the methods of collaboration learned by ii on pair to a wider audience.\n \"If you want to go fast, go by yourself. If you want to go far, go together.\" African Proverb – Martha Goedert\n- Recommended Skills: shell, terminals, VSCode, k8s, System Administration\n- Mentor(s): Hippie Hacker (@hh), Caleb Woodbine (@BobyMCBobs)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/2f5582f4-6cfa-41af-88d2-2bfdd8768756\n\n### CNCF TAG Network and Observability\n\n#### Kubernetes ontology and subgraph module design\n\n- Description: Network topologies and graph databases go hand-in-hand. The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph. Deliverables (among other items):\n\n\n\n- a Kubernetes ontology using OWL as a popular (and mature) way of doing this.\n- a cuelang-based component generator\n\n- Recommended Skills: cuelang, golang, neo4j\n- Mentor(s): [Lee Calcote](https://github.com/leecalcote), [Matt Young](https://github.com/halcyondude)\n- Issue: https://github.com/cncf/tag-network/issues/21\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/df449a23-ac20-4ee9-8a2c-e0e5d08ba727\n\n\n### Devfile\n\n#### Add Compose file support in the spec API II\n\n- Description: Devfiles are YAML files that define remote development environments. The main part of a Devfile is the `components` section and that's where the containers required to code, build and test an application are specified. The Devfile can either include those containers defintions or reference external files such as Dockerfiles or Kubernetes manifests. [The Compose file](https://github.com/compose-spec/compose-spec/blob/master/spec.md) is a popular format in open source development projects to define runtime environments for testing the application but those cannot be referenced by a Devfile yet. The goal is to continue the work that has been started a couple of months ago to allow referencing a Compose file from a Devfile. The expected outcome is to create a PoC written in go that parses a Compose file such as [this one](https://github.com/microservices-demo/microservices-demo/blob/master/deploy/docker-compose/docker-compose.yml) using [kompose](https://github.com/kubernetes/kompose) (as a library, not as an executable) and that creates the objects corresponding to the Compose file services in a Kubernetes cluster.\n- Recommended Skills: Golang, Compose, Kubernetes\n- Mentor(s): Mario Loriedo (@l0rd)\n- Upstream Issue (URL): https://github.com/devfile/api/issues/501\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/8b4aeab0-f891-4a67-a510-61393ca38520\n\n\n### Karmada\n\n#### Enable configurable resource interpreter\n\n- Description: Now Resource Interpreter framework enabled both built-in and customized interpreter, we are going to provide a way for people customize the interpreter by applying a configuration.\n- Recommended Skills: golang, k8s, lua\n- Mentor(s): Hongcai Ren (@RainbowMango)\n- Upstream Issue (URL): \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/40b17a86-e470-4406-b7f0-731e689a39f4\n\n\n### KubeArmor\n\n#### Add BTF and BPF CO-RE Support to KubeArmor\n\n- Description: Currently KubeArmor depends on kernel headers to use various kernel structures. This creates difficulty in having portability.\nLinux Kernel versions with BTF (BPF Type Format) information available allows us to write portable BPF CO-RE (or Compile Once - Run Everywhere) applications that can run on multiple kernel versions and configurations without any modification or runtime compilation on the target machine. \nBut there is a restriction that CO-RE requires to have the BTF information of the target kernel, which is provided by the kernel itself when it's compiled with CONFIG_DEBUG_INFO_BTF=y. This option was introduced in Linux 5.2. \nFor kernels < 5.2 we can use BTFGen to ship BTF information with KubeArmor code or use pahole to generate BTF information from the vmlinux image (with DWARF information) at runtime. \nThe project aims to make KubeArmor truly portable across all kernel versions by reducing host environment dependencies.\n\n- Recommended Skills: Kernel, go, C \n- Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/d61e1b05-2a4f-432d-b715-57c818b3e120\n\n#### Use non-privileged containers for KubeArmor daemonset\n\n- Description: KubeArmor currently uses privileged mode for its daemonset containers. But it is not a good practice. Privileged containers are usually frowned upon. In many cases, specific admission controllers are deployed to not allow containers to be installed in privileged mode.\nIt is best to not use privileged mode but to define specific capabilities for KubeArmor. \nThe aim of the project is to analyse and reduce the system privileges required by KubeArmor, thereby reducing the potential attack surface.\n\n- Recommended Skills: go, Kernel, k8s\n- Mentor(s): Ankur Kothiwal (@Ankurk99), Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/3cc962b4-cd8b-46ea-9c77-83304145fd51\n\n\n### Kyverno\n\n#### Policy Exceptions\n\n- Description: Enable flexible management of policy exceptions without requiring changes to the policy definitions.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Jim Bugwadia\n- Upstream Issue (URL):\n - https://github.com/kyverno/kyverno/issues/2627 \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/0eb98f34-bfd8-4ba1-b9e5-47fc67b6fd41\n\n#### Enable resource clean-up\n\n- Description: Support a new type of Kyverno rule to delete resources based on various criterias, such as the type, age, metadata and status.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Shuting Zhao (@realshuting)\n- Upstream Issue (URL):\n - https://github.com/kyverno/kyverno/issues/3483\n - https://github.com/kyverno/KDP/pull/25 \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/25e0fa72-8260-4c6f-819b-d87b865e58f2\n\n#### Implement new custom JMESPath filters\n\n- Description: Kyverno uses JMESPath to perform filtering and selection of JSON content in a flexible and advanced way. Many custom filters have been implemented specifically for Kyverno to date. Implement two more filters which fill needed gaps in Kyverno today: a grouping filter and an index locator.\n- Recommended Skills: Golang\n- Mentor(s): Chip Zoller, Shuting Zhao\n- Upstream Issue (URL):\n - https://github.com/kyverno/kyverno/issues/3981 \n - https://github.com/kyverno/kyverno/issues/4336\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/bb0ff695-3d54-4ce2-b93c-3ab92842b3ee\n\n#### Logging in JSON plus other enhancements\n\n- Description: Add an ability allowing a user to tell Kyverno to log in JSON format rather than klog.\n- Recommended Skills: Golang\n- Mentor(s): Jim Bugwadia\n- Upstream Issue (URL): \n - https://github.com/kyverno/kyverno/issues/3411\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/e5ef8032-3dd3-44c3-8746-620f4f678d60\n\n#### More support for subresources\n\n- Description: Kyverno lacks the ability to operate on some important subresources like /scale and /status in areas such as validation and mutation.\n- Recommended Skills: Golang\n- Mentor(s): Shuting Zhao\n- Upstream Issue (URL): \n - https://github.com/kyverno/kyverno/issues/3118\n - https://github.com/kyverno/kyverno/issues/2843\n - https://github.com/kyverno/kyverno/issues/4313 \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/9ac41a72-62f4-48e9-8630-5f9be261e2bf\n\n\n### Meshery\n\n#### Integration of Open Policy Agent (OPA) and Meshery\n\n- Description: As a golang library integrate OPA into Meshery Server, enabling users to define policies to dictate the manner in which their cloud native infrastructure is to both run and be configured. Design an extensible policy framework in which rules may be augmented and dynamically supplied at runtime. \n- Recommended Skills: golang, rego, reactjs\n- Mentor(s): [Lee Calcote](https://github.com/leecalcote), [Ashish Tiwari](https://github.com/revolyssup)\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/544\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/ea439582-8c63-498d-9066-dc563ce1172e\n\n#### User Interface Overhaul: State Management w/Apollo/GraphQL\n\n- Description: Overcome current architectural issues of:\n1) No Caching - In Meshery UI, List of adapters is a state that is being used in multiple components i.e Settings , Dashboard , Connection Wizard and Performance. Refetching the data on every mount of each of these components degrades the user experience. The same goes for all the other data that are being used across multiple components.\n2) Multiple Sources of Truth - There is no single source of truth in Meshery UI as all react components manage their own state. Since Meshery UI has to deal with data that frequently changes, like Control Plane Data, Meshsync data etc. it will become hard to keep them in sync if they all manage their own copy of them in their local state.\n\n- Recommended Skills: reactjs, apollo, graphql, redux\n- Mentor(s): [Lee Calcote](https://github.com/leecalcote), [Nithish Karthik](https://github.com/sudo-NithishKarthik)\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/5094\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/7592d7db-5517-445b-95e8-14144c49e9b1\n\n\n### Service Mesh Performance\n\n#### Adaptive Load Controller\n\n- Description: The adaptive load controller is to execute optimization routines recursivley to determine the maximum load a system can sustain. The maximum load is usually defined by the maximum requests per second (rps) the system can handle. The metrics (CPU usage, latency etc) collected from the system under test are the constraints we provide to judge whether a system under test (SUT) is sustaining the load.\n\nA use-case that fits very well is be the ability to use it to run performance tests on a schedule and track the maximum load a system can handle over time. This could give insights to performance improvements or degradations.\n\n- Recommended Skills: golang, grpc, docker, kubernetes\n- Mentor(s): [Lee Calcote](https://github.com/leecalcote), [Xin Huang](https://github.com/gyohuangxin)\n- Upstream Issue (URL): https://github.com/service-mesh-performance/service-mesh-performance/issues/350\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/9959277e-eefc-4c88-83b6-e8c4b011d557\n\n#### Convergence of Network and Graph topologies\n\n- Description: Use Neo4j's ability to create graph projections, which copy a subgraph to RAM so that algorithms can be efficiently run. This opens the door to leveraging algorithms in the areas of Centrality, Community Detection, Pathfinding, Topological Link Prediction, etc. Bringing to bear advances made in Machine Learning / AI / recommendation systems, fraud detection could really help to derive meaning and comprehension for future tools. Another example is how ML + graph approaches are used to find and determine the optimal molecular structure of atoms such that desired physical properties are targeted. This approach could be applied to the problem of workload sizing and estimation for service mesh operators and would-be adopters.\n- Recommended Skills: cuelang, golang, neo4j\n- Mentor(s): [Lee Calcote](https://github.com/leecalcote), [Nic Jackson](https://github.com/nicholasjackson)\n- Upstream Issue (URL): https://github.com/service-mesh-performance/service-mesh-performance/issues/351\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/2c4510d6-7b73-4082-a3f4-209f61767263\n\n\n### Thanos\n\n#### Receive: Support for tenant-specific external labels\n\n- Description: Tenants in Thanos Receivers currently get one external label which indicates their tenant ID. We would like to implement attaching arbitrary external labels to each Thanos Tenant. This functionality is useful for various different use cases, such as improving performance when querying data for tenants which share the same labels.\n- Recommended Skills: Golang\n- Mentor(s): [Filip Petkovski](https://github.com/fpetkovski), [Saswata Mukherjee](https://github.com/saswatamcode)\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/5434\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/7a13b009-0365-4910-8fbf-9088294870fd\n\n#### Load balancing of API communication in Thanos \n\n- Description: Thanos uses gRPC for the majority of network communication. It performs fanouts and sharding of different queries to multiple nodes in a distributed system. Unfortunately, due to the nature of the gRPC, a conventional TCP-based load balancer (e.g. K8s Service) is not enough to distribute requests equally to multiple replicas of the same stateless node. As a result, there is a need to figure out the pragmatic way for Thanos users to load balance requests to multiple backends either by gRPC client load balancing or by guides and integration with popular load balancing proxies like nginx, caddy or envoy.\n- Recommended Skills: Golang, HTTP, gRPC\n- Mentor(s): [Bartłomiej Plotka](https://github.com/bwplotka), [Aditi Ahuja](https://github.com/metonymic-smokey)\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/3016 + https://github.com/thanos-io/thanos/issues/1083\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/de2d206e-32cc-45da-bc5a-1fbc7bc1f5c8\n\n\n### Vitess\n\n#### Add complete parsing support for Spatial MySQL functions II\n\n- Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. Vitess has its own in-built SQL-parser which it uses to understand the query and represent as structs for further processing. As of now, a lot of spatial MySQL functions are not parsed correctly and result in syntax errors. The task of the mentee would be to add parsing support for such functions and features which can be found at https://dev.mysql.com/doc/refman/8.0/en/spatial-analysis-functions.html\n- Recommended Skills: go, SQL, yacc, compilers and lexers\n- Mentor(s): [Manan Gupta](https://github.com/GuptaManan100)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/845ccf34-d7aa-45cf-abc2-1b3064e96af1\n\n#### Improve evaluation engine\n\n- Description: Improve the compatbility of Vitess' evaluation engine against MySQL by adding support for more built-in SQL functions.\n- Detailed description: The evaluation engine in Vitess is one of the most critical parts of our query serving infrastructure. This engine is capable of evaluating arbitrary SQL expressions directly inside Vitess' process, without reaching out to a live MySQL instance, and this allows us to plan and execute complex user queries (e.g. queries that contain WHERE and similar filter clauses) between Vitess shards much more efficiently. If you're interested in this GSoC project, your task for the summer will involve continuing the work on this evaluation engine by implementing support for as many built-in SQL functions as possible, using the behavior of MySQL as a reference.\n- Expected outcomes: We expect the Evaluation Engine in Vitess to be close to 100% compatible with MySQL after all the leftover SQL built-ins have been implemented.\n- Recommended Skills: Golang, MySQL\n- Mentor(s): Vicent Marti (@vmg)\n- Expected size of the project: 350h\n- Difficulty rating: Medium\n- Upstream Issue (URL): https://github.com/vitessio/vitess/issues/9647\n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/29ec853c-3ab9-4457-ac91-d273fa073d49\n\n\n### Volcano\n\n#### Pick out reasonable victim pods for rescheduling plugin\n\n- Description: Currently, rescheduling is a little rough to evict victim pods without difference. It should distinguish pods with more consideration such as pod priority, namespace and so on. Your task is to take a full consideration about all the scenarios, provide a design documentation, implement your idea and give a full test.\n- Recommended Skills: golang, Volcano\n- Mentor(s): [Thor-wl](https://github.com/Thor-wl)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/9f0d56c0-9781-4912-988f-86443b0dd161\n\n#### Implement pod filter chain for rescheduling\n\n- Description: Currently, Volcano will regard all pods as potential victims in rescheduling, which is not so reasonable in some scenarios. Your task is to implement a pod filter chain to support custom configurations.\n- Recommended Skills: golang, Volcano\n- Mentor(s): [Thor-wl](https://github.com/Thor-wl)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/4dc62372-c04f-432f-847c-2cddd2cf786a\n\n#### Avoid hot node in dynamic scheduling based on real workload\n\n- Description: In v1.6.0, Volcano has supported dynamic scheduling based on real workload. However, the scheduler cannot be aware of hot nodes which may receive too many bound pods. Your task is to design an algorithm to avoid hot nodes and balance node pressure.\n- Recommended Skills: golang, Volcano\n- Mentor(s): [william-wang](https://github.com/william-wang)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/2ceeee35-a85d-4768-9f22-d22838e27cd5\n\n#### Integrate Volcano with Ray\n\n- Description: Volcano has supported a lot of mainstream computing platforms such as Spark and TensorFlow. As [Ray](https://github.com/ray-project/ray) is a new and popular computing platform, Volcano should integrate with it.\n- Mentor(s): [william-wang](https://github.com/william-wang)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/c6dff087-9b4d-4ff5-865d-abd876974534\n\n#### Support hot update daemon log level\n\n- Description: Users have no ways to update log level of Volcano components now, which is difficult to track bugs especially in the production environment. Your task is to achieve it.\n- Mentor(s): [william-wang](https://github.com/william-wang)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/02972292-469d-431a-96be-149a04ea2746\n\n\n### WasmEdge\n\n#### Support serialize and deserialize in WasmEdge\n\n- Description: WasmEdge can load the WASM binary and instantiate into WASM module instances for execution. In an use case, we need to serialize the loaded WASM data structure back into the encoded WASM binary, or deserialize the serialized one into the WASM data structure in WasmEdge. With the serializing mechanism, WasmEdge can control the WASM binary wisely such as caching or snapshotting.\n\n- Recommended Skills: C++, WebAssembly\n- Mentor(s): [Hung-Ying Tai](https://github.com/hydai) (hydai[at]secondstate.io), [Yi-Ying He](https://github.com/q82419) (yiying[at]secondstate.io)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/da1162c6-2aaf-496f-9f23-a96a3e52c277\n\n#### Porting OpenVINO on multiple platforms for the WASI-NN proposal in WasmEdge\n\n- Description: The [OpenVINO](https://www.intel.com/content/www/us/en/developer/tools/openvino-toolkit/download.html) official release supports various platforms. WasmEdge supports the WASI-NN proposal with OpenVINO backend now, but only in Ubuntu 20.04. In this project, we want to porting and integrating the OpenVINO installation for the multiple platforms such as MacOS, Windows, or manylinux with the WasmEdge WASI-NN plugin.\n\n- Recommended Skills: C++, WebAssembly\n- Mentor(s): [Hung-Ying Tai](https://github.com/hydai) (hydai[at]secondstate.io), [Yi-Ying He](https://github.com/q82419) (yiying[at]secondstate.io)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/d01efa41-87a7-4f34-adfe-63c7bab7c1ca\n\n#### Node API support for WasmEdge QuickJS\n\n- Description: The [WasmEdge QuickJS runtime](https://wasmedge.org/book/en/dev/js.html) is a secure, fast, and lightweight JavaScript runtime for cloud-native applications. Compared with more established JavaScript runtimes like Nodejs and Deno, the WasmEdge QuickJS runtime provides runtime isolation and security at a very low overhead. In order for WasmEdge QuickJS to be more widely adopted, it needs to support [nodejs](https://wasmedge.org/book/en/dev/js/nodejs.html) applications. WasmEdge QuickJS already supports [NPM and CJS modules](https://wasmedge.org/book/en/dev/js/npm.html).\n\n- Recommended Skills: Javascript, Rust\n- Mentor(s): [Michael Yuan](https://github.com/juntao) (michael@secondstate.io)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/4853174a-267d-4cd4-a62d-6e68d0c338b1\n\n#### OpenCV SDKs for Wasm in WasmEdge\n\n- Description: WasmEdge is a leading WebAssembly runtime for AI inference. It supports AI frameworks such as Tensorflow, OpenVINO and PyTorch. A compelling use case is computer vision applications on the edge. Computer vision applications need to pre-process images and videos into tensor formats before applying the AI model. They then often need to overlay the tensor results onto the original image. In our existing demos, we use the Rust [image crate](https://crates.io/crates/image) to process images. However, the crate only has limited features and is inadequate for many computer vision applications. In the Python-based computer vision applications, the image pre-processing is often done with the Python wrapper for OpenCV library. The OpenCV library itself is written in C and can be compiled into WebAssembly. We would like to create an OpenCV SDK that allows WebAssembly applications to call OpenCV functions.\n\n- Recommended Skills: C++, WebAssembly, Rust\n- Mentor(s): [Michael Yuan](https://github.com/juntao) (michael@secondstate.io)\n- Issue: \n\n- **LFX URL**: https://mentorship.lfx.linuxfoundation.org/project/17fc622c-5674-4381-b597-2f49409fda01\n\n" }, { "path": "programs/lfx-mentorship/2022/03-Sept-Nov/project_ideas.md", "content": "# Projects ideas\n\nProject maintainers and mentors, please submit the ideas below (under the Proposed Project Ideas section) section using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n### Template\n\n```\n#### CNCF Project Name\n##### Title\n\n- Description:\n- Recommended Skills:\n- Mentor(s): (please include email info, either here, or contact @nate-double-u on the CNCF slack)\n- Upstream Issue (URL):\n```\n\n" }, { "path": "programs/lfx-mentorship/2023/01-Mar-May/README.md", "content": "# Term 01 - 2023 March - May\n\nStatus: Complete\n\nMentorship duration - three months (12 weeks - full-time schedule)\n\n| activity | date |\n| --- | --- | \n| project proposals | January 16 - 31, 5:00 PM PDT |\n| mentee applications open | February 1 - 21, 5:00 PM PDT |\n| application review/admission decisions/HR paperwork | February 22 - March 7, 5:00 PM PDT |\n| Mentorship program begins with the initial work assignments | March 8 (Week 1) | \n| Midterm mentee evaluations and first stipend payments | April 12 (Week 6) |\n| Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals | May 24, 5:00 PM PST (Week 12) |\n| Last day of term | May 31 |\n\n\n### Project Instructions\n\nProject proposals open Jan 16th, 2023.\n\nOnce opened, Project maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/lfx-mentorship/2023/01-Mar-May/project_ideas.md, by January 31, 2023.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n- [Accepted Projects](#accepted-projects)\n - [Cilium](#cilium)\n - [Website Use Cases pages](#website-use-cases-pages)\n - [Cloud Native Buildpacks](#cloud-native-buildpacks)\n - [Pack Performance enhancements](#pack-performance-enhancements)\n - [Multi-Architecture Builds Support](#multi-architecture-builds-support)\n - [CNCF Landscape](#cncf-landscape)\n - [UX UI improvement](#ux-ui-improvement)\n - [CNCF Tag Contributor Strategy](#cncf-tag-contributor-strategy---ii)\n - [Mentoring Workspaces - GITHUBUSER.PROJECT.cncf.io (w/ VSCode)](#mentoring-workspaces---githubuserprojectcncfio-w-vscode)\n - [CNCF TAG Network](#cncf-tag-network)\n - [Representing Kubernetes ontology in MeshModel](#representing-kubernetes-ontology-in-meshmodel)\n - [Cortex](#cortex)\n - [Experimental Auth Gateway](#experimental-auth-gateway)\n - [API to import Prometheus \\& Thanos blocks](#api-to-import-prometheus--thanos-blocks)\n - [Switch Cortex Ruler to query Query Frontend](#switch-cortex-ruler-to-query-query-frontend)\n - [Automated nightly benchmarks](#automated-nightly-benchmarks)\n - [Harbor](#harbor)\n - [Regex replication rules](#regex-replication-rules)\n - [An official Golang API client and CLI for Harbor](#an-official-golang-api-client-and-cli-for-harbor)\n - [Implement per project and/or for the whole instance vulnerability overview](#implement-per-project-andor-for-the-whole-instance-vulnerability-overview)\n - [Harbor Robot accounts with full Harbor API access](#harbor-robot-accounts-with-full-harbor-api-access)\n - [Kubernetes](#kubernetes)\n - [Cluster API Provider GCP (CAPG)](#cluster-api-provider-gcp-capg)\n - [Add telemetry and profiling support](#add-telemetry-and-profiling-support)\n - [Cluster API Provider AWS (CAPA)](#cluster-api-provider-aws-capa)\n - [Reimagining how we handle AWS account preparation](#reimagining-how-we-handle-aws-account-preparation)\n - [Kubescape](#kubescape)\n - [Implement security controls based on penetration testing best practices](#implement-security-controls-based-on-penetration-testing-best-practices)\n - [Build debugging capabilities for Helm](#build-debugging-capabilities-for-helm)\n - [Release engineering: add Kubescape to commonly-requested package managers](#release-engineering-add-kubescape-to-commonly-requested-package-managers)\n - [KubeVela](#kubevela)\n - [Extend the capability of KubeVela by making several useful addons](#extend-the-capability-of-kubevela-by-making-several-useful-addons)\n - [Support auto generation of CUE schema and docs from Go struct](#support-auto-generation-of-cue-schema-and-docs-from-go-struct)\n - [Support auto generation of multiple languages SDK from CUE](#support-auto-generation-of-multiple-languages-sdk-from-cue)\n - [Kyverno](#kyverno)\n - [Pod Security Admission Integrations](#pod-security-admission-integrations)\n - [Kubernetes Validating Admission Policy Support](#kubernetes-validating-admission-policy-support)\n - [OCI references support](#oci-references-support)\n - [Artifact Hub listing of Kyverno Policy Library](#artifact-hub-listing-of-kyverno-policy-library)\n - [Karmada](#karmada)\n - [Provide interactive environments for Karmada users](#provide-interactive-environments-for-karmada-users)\n - [Enhance Karmada testing coverage](#enhance-karmada-testing-coverage)\n - [Bundle third-party resources into the Resource Interpreter framework](#bundle-third-party-resources-into-the-resource-interpreter-framework)\n - [Konveyor](#konveyor)\n - [Move2Kube: Allow customizations be added as remote git repo path](#move2kube-allow-customizations-be-added-as-remote-git-repo-path)\n - [Move2Kube: Implement a test suite](#move2kube-implement-a-test-suite)\n - [Move2Kube: Consume Move2Kube through a plugin on Eclipse](#move2kube-consume-move2kube-through-a-plugin-on-eclipse)\n - [Move2Kube: Consume Move2Kube through a plugin on VSCode](#move2kube-consume-move2kube-through-a-plugin-on-vscode)\n - [KubeArmor](#kubearmor)\n - [KubeArmor Telemetry Monitoring and Dashboards](#kubearmor-telemetry-monitoring-and-dashboards)\n - [Adding OpenTelemetry Support](#adding-opentelemetry-support)\n - [Rancher Plugin Integration](#rancher-plugin-integration)\n - [Kubewarden](#kubewarden)\n - [Kubewarden SDKs feature parity](#kubewarden-sdks-feature-parity)\n - [Kubewarden policies enhancements](#kubewarden-policies-enhancements)\n - [KubeEdge](#kubeedge)\n - [Design and implement the KubeEdge Dashboard](#design-and-implement-the-kubeedge-dashboard)\n - [Re-design and implement the KubeEdge website](#re-design-and-implement-the-kubeedge-website)\n - [Cloud-Robotic AI Benchmarking for Edge-cloud Collaborative Lifelong Learning](#cloud-robotic-ai-benchmarking-for-edge-cloud-collaborative-lifelong-learning)\n - [Meshery](#meshery)\n - [Distributed workflow engine](#distributed-workflow-engine)\n - [Multi-user cloud native playground](#multi-user-cloud-native-playground)\n - [Distributed client-side policy evaluation in WASM and Rego](#distributed-client-side-policy-evaluation-in-wasm-and-rego)\n - [Linkerd](#linkerd)\n - [Linkerd Dashboard Improvements](#linkerd-dashboard-improvements)\n - [Add dynamic profiling to Linkerd Rust controllers](#add-dynamic-profiling-to-linkerd-rust-controllers)\n - [Prototype multi-cluster service discovery and operations](#prototype-multi-cluster-service-discovery-and-operations)\n - [LitmusChaos](#litmuschaos)\n - [Improve code quality and add unit tests of litmus chaos components](#improve-code-quality-and-add-unit-tests-of-litmus-chaos-components)\n - [NATS](#nats)\n - [End-to-end example of a multiplayer game using NATS in Unity](#end-to-end-example-of-a-multiplayer-game-using-nats-in-unity)\n - [Notary](#notary)\n - [HashiCorp Vault plugin for Notary](#hashicorp-vault-plugin-for-notary)\n - [OpenKruise](#openkruise)\n - [Bring progressive delivery to daemon workload](#bring-progressive-delivery-to-daemon-workload)\n - [Support customize arbitary fields of workload subset in UnitedDeployment](#support-customize-arbitary-fields-of-workload-subset-in-uniteddeployment)\n - [ORAS](#oras)\n - [Develop .NET SDK for ORAS](#develop-net-sdk-for-oras)\n - [Develop ORAS Website](#develop-oras-website)\n - [Service Mesh Performance](#service-mesh-performance)\n - [Adaptive Load Controller](#adaptive-load-controller)\n - [TestGrid](#testgrid)\n - [Frontend development inside Lit Component Framework](#frontend-development-inside-lit-component-framework)\n - [Thanos](#thanos)\n - [Add query observability for new promql engine](#add-query-observability-for-new-promql-engine)\n - [Series Cardinality API](#series-cardinality-api)\n - [Querying Apache Parquet files with PromQL](#querying-apache-parquet-files-with-promql)\n - [Vitess](#vitess)\n - [Implement a benchmarking and load testing framework for the VReplication module in Vitess](#implement-a-benchmarking-and-load-testing-framework-for-the-vreplication-module-in-vitess)\n - [Add complete parsing support for Spatial MySQL functions](#add-complete-parsing-support-for-spatial-mysql-functions)\n - [WasmEdge](#wasmedge)\n - [Streaming data processing with WasmEdge](#streaming-data-processing-with-wasmedge)\n - [A Rust library crate for mediapipe models for WasmEdge NN](#a-rust-library-crate-for-mediapipe-models-for-wasmedge-nn)\n - [Unified WasmEdge tools](#unified-wasmedge-tools)\n - [WasmEdge C++ SDK](#wasmedge-c-sdk)\n\n---\n\n## Accepted Projects\n\n### Cilium\n\n#### Website Use Cases pages\n\n- Description: Cilium would like to have use case pages built out on its website to make it easy for people to find the information and relevant content to the problems they are trying to solve with Cilium.\n- Expected Outcome: The mentee will read through relevant docs, blogs, case studies, user stories, and labs to understand the use cases which will drive the content for each of the pages being built. The finished product will be a new use cases section on the Cilium website.\n- Recommended Skills: Content Writing, Javascript, CSS\n- Mentor(s): Bill Mulligan (@xmulligan, bill@isovalent.com) \n- Upstream Issue: https://github.com/cilium/cilium.io/issues/226\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/81a0e506-1c05-45fa-90c4-6bde8bdc0e61\n\n### Cloud Native Buildpacks\n\n#### Pack Performance enhancements\n\n- Description: Pack is the reference implementation of a Cloud Native Buildpacks platform used to build application images in multiple organizations. Because all developers want their code to build and deploy as quickly as possible, small speedups in pack can have significant benefits, and slow-downs in pack are undesirable. Today, pack has no benchmark suite that would safe-guard against regressions in execution speed.\n- Expected Outcome: The mentee will create a benchmark suite around some critical path sections identified with help from maintainers. The mentee will be supported in applying profiling tools to identify possible speedups, hopefully leading to at least one user-facing performance improvement.\n- Recommended Skills: Golang, git, software development. (Mentee does not need prior experience in profiling or performance tuning)\n- Mentor(s): Natalie Arellano (@natalieparellano, narellano@vmware.com); Joe Kimmel (@joe-kimmel-vmw, jkimmel@vmware.com) \n- Upstream Issue: https://github.com/buildpacks/pack/issues/1610\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/33e0747c-4ab8-4074-aa90-3b908b3a588e\n\n#### Multi-Architecture Builds Support\n\n- Description: The rise of ARM processors has created new binary targets for pre-compiled executables. Additionally, there are tales of widespread use of operating systems that aren't linux? In the ideal case a `pack` user could create a build for an abritrary architecture and operating system, regardless of the host system they used to run the command.\n- Expected outcome: Improved multi-architecture (including ARM) and multi-os \"cross-compilation\" support in [pack](https://github.com/buildpacks/pack/)\n- Recommended Skills: Golang, software development literacy. Familiarity with buildpacks will be helpful.\n- Mentor(s): Aidan Delaney (@AidanDelaney); Jerico Pena (@jpena-r7); Juan Bustamante (jbustamante@vmware.com, @jjbustamante)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/buildpacks/pack/issues/1459 and https://github.com/buildpacks/pack/issues/1460\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ee387e1b-de4e-4c1e-9bef-0239a2e9ca40\n\n### CNCF Landscape\n\n#### UX UI improvement\n- Description: In an effort to better the user experience, the CNCF Landscape is actively seeking ways to improve and enhance its features.\n- The aim is for the mentee to carry out a User Research to validate existing user personas, gain a deeper understanding of user needs, and conduct a thorough heuristic evaluation to gain insights into user experiences. Using the results, the mentee will establish a solid foundation to start an iterative process of ideation, prototyping, and testing possible solutions. The ultimate goal is to initiate a continuous cycle of improvement and further development of features that enhance the user experience of the CNCF Landscape.\n- Recommended skills: Design Thinking, UX research methodology. \nIn this stage of the project, we are seeking candidates with a background and/or training in user research. Supporting materials, such as the following recommended deliverables, that demonstrate your understanding and experience in this area are ideal:\n\n1. Proto-Personas\n2. Validated Personas with Supporting Findings\n3. Brief Explanation of the Difference between Proto-Personas and Validated Personas\n4. List of UX Research Techniques for Kickstarting the Discovery of Landscape Users\n5. Figma and Visual Design are a plus.\n\n- Mentors: Andrea Velázquez andrea@buoyant.io, Nate W. @nate-double-u natew@cncf.io, Chris Aniszczyk @caniszczyk caniszczyk@linuxfoundation.org \n- Upstream issue: https://github.com/cncf/landscape/issues/2467\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/df011bb8-8ce1-4092-bfc6-1e92ce40a17d\n\n### CNCF Tag Contributor Strategy - ii\n\n#### Mentoring Workspaces - GITHUBUSER.PROJECT.cncf.io (w/ VSCode)\n\n- Description: pair.sharing.io is a mentoring / pair environment used by ii.nz that brings up clusters to co-learn and co-author via tmate+emacs and a live cluster with many features useful to cloud native development. However, while many folks find the ideas useful, it would be good to reach a wider audience by bringing up workspaces w/ VSCode as an alternative to emacs. The request is for a PoC deploying coder.com to CNCF Infrastructure (likely Packet) and bringing over some of the methods of collaboration learned by ii on pair to a wider audience.\n \"If you want to go fast, go by yourself. If you want to go far, go together.\" African Proverb – Martha Goedert\n- Recommended Skills: shell, terminals, VSCode, k8s, System Administration\n- Mentor: Hippie Hacker (@hh, hh@cncf.io)\n- Issue: https://github.com/sharingio/pair/issues/173\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/632ab03f-a970-44ce-b451-fac0a7349f71\n\n### CNCF TAG Network\n\n#### Representing Kubernetes ontology in MeshModel\n\n- Description: Network topologies and graph databases go hand-in-hand. The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph. Deliverables (among other items):\n\n- MeshModel capabilities browser\n- Import/export of MeshModel models and components as OCI images\n- augmentation of cuelang-based component generator\n\n- Recommended Skills: cuelang, golang, OCI\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com)\n- Issue: https://github.com/cncf/tag-network/issues/24\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/96080e3d-83e2-46ed-928c-b6e7f3154bf3\n\n### Cortex\n\n#### Experimental Auth Gateway\n- Description: Cortex server has a simple authentication mechanism (X-Scope-OrgId) but users can’t use the multi tenancy features out of the box without complicated proxy configuration. It’s hard to support all the different authentication mechanisms used by different companies but plan to have a simple but opinionated auth-gateway that provides value out of the box.\n- Expected Outcome: A new experimental cortex component called auth-gateway that validates tenants requests and proxies valid requests to distributors and query-frontend.\n- Recommended Skills: Golang, HTTP proxies\n- Mentor: Friedrich Gonzalez (@friedrichg, friedrichg@gmail.com)\n- Upstream Issue: https://github.com/cortexproject/cortex/issues/5106\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/820f9269-ddef-44e9-bf77-95a8d2444c1e\n\n#### API to import Prometheus & Thanos blocks\n- Description: For users who want to migrate from Prometheus to Cortex, currently it is supported via a tool called [Thanosconvert](https://cortexmetrics.io/docs/blocks-storage/migrate-storage-from-thanos-and-prometheus/#when-migrating-from-prometheus). However, having this feature as part of the tool is limited in some usecase like SaaS because users usually don’t have permissions to access their storage layer directly. It would be nice to extend this feature into an API so that users can import their Prometheus TSDB compatible blocks for easier migration.\n- Expected Outcome: An API that imports Prometheus blocks into Cortex.\n- Recommended Skills: Golang, Prometheus, Thanos\n- Mentor: Alan Protasio (@alanprot, alanprot@gmail.com), Daniel Blando (@danielblando, daniel@blando.com.br)\n- Upstream Issue: https://github.com/cortexproject/cortex/issues/4956\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/184ccb3e-6abe-4bf9-9659-b42b5c07c5a5\n\n#### Switch Cortex Ruler to query Query Frontend\n- Description: Cortex Ruler queries ingester directly for rule evaluation. This is okay but if Cortex Ruler could query Query Frontend instead for rule evaluation, it can benefit from more features in the Query Frontend like vertical sharding. This also simplifies the Cortex ruler to not embed a querier and uses less resources. For this project, we would like to switch Cortex Ruler to query Query Frontend. You are expected to work with a microservice architecture and write unit tests and end to end tests to make sure the feature works correctly.\n- Expected Outcome: Cortex Ruler talks to Query Frontend for rules evaluation.\n- Recommended Skills: Golang, distributed systems\n- Mentor: Alvin Lin (@alvinlin123, alvinlin123@gmail.com), Yijie Qin (@qinxx108, qinyijie1994@gmail.com)\n- Upstream Issue: https://github.com/cortexproject/cortex/issues/5105\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fe5c060e-420b-4c0f-90ae-389d893c50b6\n\n#### Automated nightly benchmarks\n- Description: In order to make sure Cortex doesn’t introduce performance regressions across releases and major changes, we would like to introduce an automated way to run some nightly macro/micro benchmarks for Cortex clusters. This project could potentially involve setting up Kubernetes clusters, Cortex components, and load generators. We’d love to keep track of performance metrics for each test run and visualize them through a UI.\n- Expected Outcome: An automated workflow that runs performance macro/micro benchmarks everyday or on demand and performance metrics can be visualized through a UI.\n- Recommended Skills: Golang, Kubernetes\n- Mentor: Ben Ye (@yeya24, yb532204897@gmail.com)\n- Upstream Issue: https://github.com/cortexproject/cortex/issues/5107\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0071e2ff-f538-4817-978b-07b267cfcd6a\n\n### Harbor\n\n#### Regex replication rules\n\n- Description: Add more versatile replication filters\n- Expected Outcome: Implement regex capability when defining relication rules, update documentation and present the functionality\n- Recommended Skills: Angular, JavaScript, Golang\n- Mentor(s): vb@container-registry.com@Vad1mo @wy65701436 @OrlinVasilev\n- Mentor(s): @Vad1mo - Vadim Bauer, vb@container-registry.com); @wy65701436 - Yan Wang(wangyan@vmware.com); @OrlinVasilev Orlin Vasilev (ovasilev@vmware.com)\n- Upstream Issue (URL): https://github.com/goharbor/harbor/issues/8614 \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/49749be9-5a67-4b2b-9312-7def13ae98b8\n\n#### An official Golang API client and CLI for Harbor\n\n- Description: Design, plan and implement an Golang API client for Harbor\n- Expected Outcome: Working golang harbor API client which can be used in the CI/CD implementations which compliments the Web UI, well documented and with the coresponding architectural diagrams under the Harbor org(not necessary to be complete functionality)\n- Recommended Skills: Golang, spf13/cobra\n- Mentor(s): Vadim Bauer, vb@container-registry.com); @wy65701436 - Yan Wang(wangyan@vmware.com);\n- Upstream Issue (URL): https://github.com/search?q=Harbor%20CLI&type=repositories\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7e8cb88a-5b37-471c-8db8-e11907b5a661\n\n#### Implement per project and/or for the whole instance vulnerability overview\n \n- Description: Design, plan and implement an and UI and backend to be able to visualize per project and/or for the registry vulnerability overview which will allow better security audits and vulenrability mitigation \n- Expected Outcome: Addition to the Web UI which can be used to represent in full for the whole Harbor instance or per project the vulnerability status of the images, which will allow Harbor admin or project admin to get an overview of the existing vulnerabilities on in the images, also to provide capability to export the data via the CVE exporter so it can be consumed in 3rd party tools(not necessary to be complete functionality)\n- Recommended Skills: Angular, JavaScript, Golang, UI/UX, Clarity \n- Mentor(s): Vadim Bauer, vb@container-registry.com); @wy65701436 - Yan Wang(wangyan@vmware.com);\n- Upstream Issue (URL): https://github.com/goharbor/harbor/issues/16680 https://github.com/goharbor/harbor/issues/10496 https://dso.docker.com/explore?search=pkgs\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7ea4c506-c830-4a15-be4a-600d2dfe3f44\n\n#### Harbor Robot accounts with full Harbor API access\n\n- Description: Robot accounts should be allowed to access the full Harbor API (more of a UI thing)\n- Expected Outcome: Implement a way to configure and fully documented with examples usecase how to setup Harbor Robot accounts with full or managed access to Harbor\n- Recommended Skills: Angular, JavaScript, Golang, UI/UX, Clarity \n- Mentor(s): @wy65701436 - Yan Wang(wangyan@vmware.com); Vadim Bauer, vb@container-registry.com);\n- Upstream Issue (URL): https://github.com/goharbor/harbor/issues/8723\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4a96c735-6480-4464-8b33-4f9c58ba1005\n\n### Kubernetes\n\n#### Cluster API Provider GCP (CAPG)\n\n##### Add telemetry and profiling support\n\n- Description: Cluster API Provider GCP (CAPG) enables the creation of Kubernetes clusters in GCP with Cluster API. With increasing adoption of Cluster API (CAPI) in general and of CAPG we want to improve the supportability of CAPG, especially for production environments. The first part of this is to add telemetry/tracing using OpenTelemetry so that we can understand and visualize the flow of reconciliation within the provider. The next part is to add a **pprof** endpoint that can be optionally enabled to enable operations/support users to collect profiling information from a running instances of CAPG.\n- Expected Outcome: This work will enable tracing and profiling of a running instance of CAPG (along with supporting docs) to supports operations/support engineers.\n- Recommend Skills: Golang, Kubernetes\n- Mentors(s): Carlos Panato (@cpanato ctadeu@gmail.com), Richard Case (@richardcase richmcase@gmail.com)\n- Upstream Issue: https://github.com/kubernetes-sigs/cluster-api-provider-gcp/issues/810\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/55469b74-0c98-44f1-b8e1-4244a736bf82\n\n#### Cluster API Provider AWS (CAPA)\n\n##### Reimagining how we handle AWS account preparation\n\n- Description: Cluster API Provider AWS (CAPA) can create and manage the lifecycle of Kubernetes clusters in AWS (with the help of Cluster API in general). For each target AWS account where a user wants to create clusters it must be prepared for usage first. This is currently done using [clusterawsadm](https://cluster-api-aws.sigs.k8s.io/topics/using-clusterawsadm-to-fulfill-prerequisites.html) which creates/updates a CloudFormation stack that in turn creates/updates IAM resources. This approach has caused issues as CloudFormation is region specific but IAM is global and users often run the tool in different regions which results in failed stacks that cannot easily be deleted. As a project we want to move away from using CloudFormation and instead use API calls (like the rest of CAPA). We also want to make the process idempotent so it doesn't matter if you run it against different regions. This account preparation is key to CAPA and with out it CAPA cannot run.\n- Expected Outcome: A new approach to handling the prerequisites required for CAPA. We need to continue to support the cli based approach (so clusterawsadm will be updated) but we can also explore a declarative approach with an operator.\n- Recommend Skills: Golang, Kubernetes\n- Mentors(s): Richard Case (@richardcase richmcase@gmail.com)\n- Upstream Issue: https://github.com/kubernetes-sigs/cluster-api-provider-aws/issues/3715\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2d76dbe6-43eb-465e-a852-64b2e48f2c68\n\n### Kubescape\n\n#### Implement security controls based on penetration testing best practices\n\n- Description: Kubescape covers different hardening guidelines around Kubernetes: NSA-CISA, MITRE and CIS. Detection capabilities of potential security issues could be even more enriched by researching pen-testing tools and practices regarding Kubernetes and implementing these as controls. An example pen-test writeup is https://hacktricks.boitatech.com.br/pentesting/pentesting-kubernetes. This and others could help define a set of “offensive” controls to complement the “defensive” controls we have today.\n- Expected Outcome: ~10 controls for detecting challenges that would commonly be found in a cluster penetration test. Documentation on how they were selected and how to use them.\n- Recommended Skills: Cybersecurity, Rego \n- Mentor(s): Ben Hirschberg (@slashben, ben@armosec.io)\n- Upstream Issue: https://github.com/kubescape/kubescape/issues/1072\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/db63c23a-2b41-40e0-a833-cf0e2c33c739\n\n#### Build debugging capabilities for Helm\n\n- Description: The Go standard templating package (`text/template`) is the base on which Helm templates are built. We wish to be able to backtrack lines and fields in objects after rendering Helm charts. This would help users of Helm to be able to understand quickly where different security issues in the final object are coming from in the source. To do this, the `text/template` package should be extended to include debug markers that point from the output lines to the input lines. \n- Expected Outcome: Propose and implement an extension to the Go package which solves this.\n- Recommended Skills: Go\n- Mentor(s): Ben Hirschberg (@slashben, ben@armosec.io)\n- Upstream Issue: https://github.com/helm/helm/issues/11552\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/570b1bba-206d-47ac-9667-22268ff7a6d9\n\n#### Release engineering: add Kubescape to commonly-requested package managers\n\n- Description: The Kubescape client binary is built from GitHub using standard patterns. Support for homebrew and krew exists, but users have requested RPM and DEB packages. In this project you will stabilize the delivery of new builds to existing package managers, and implement support for RPM and DEB packages using GitHub Actions.\n- Expected Outcome: When a new Kubescape version is released, it is available in homebrew, krew, RPM and DEB repositories.\n- Recommended Skills: Release management, scripting\n- Mentor(s): Craig Box (@craigbox, craigb@armosec.io)\n- Upstream Issue: https://github.com/kubescape/kubescape/issues/400\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/138e9cac-ec86-43cb-a04f-c2980e3c2865\n\n\n### KubeVela\n\n#### Extend the capability of KubeVela by making several useful addons\n\n- Description: 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.\n- Expected Outcome: 10+ eperimetal addons, clear documentation should be provided for enabling and using these addons, including examples of useful use-cases.\n- Recommended Skills: golang, kubernetes, cueLang\n- Mentor(s): Jianbo Sun (@wonderflow, wonderflow.sun@gmail.com), Wong Yike (@wangyikewxgm, wangyike_wyk@163.com) \n- Upstream Issue: https://github.com/kubevela/kubevela/issues/5358\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/51398c19-87c2-4b50-9dd3-760fbd820688\n\n#### Support auto generation of CUE schema and docs from Go struct\n\n- Description: 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.\n- Expected Outcome: Auto-generators of CUE schemas and docs from Go structs, the capabilities should be wrapped in vela cli command.\n- Recommended Skills: Go, CUE\n- Mentor(s): Fog Dong (@FogDong, wuwuglu19@gmail.com), Da Yin(@Somefive, yd219913@alibaba-inc.com)\n- Upstream Issue: https://github.com/kubevela/kubevela/issues/5364\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/85f61cae-02d7-4931-8d87-d3da3128060e\n\n#### Support auto generation of multiple languages SDK from CUE\n\n- Description: 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.\n- Expected Outcome: Support auto generation of multiple languages SDK from CUE, including Golang, Java, Python, etc. The capabilities should be wrapped in vela cli command.\n- Recommended Skills: Go, Kubernetes, CUE\n- Mentor(s): Qiao Zhongpei (@chivalryq, chivalry.pp@gmail.com) Zeng Qingguo (@barnettZQG, barnett.zqg@gmail.com)\n- Upstream Issue: https://github.com/kubevela/kubevela/issues/5365\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2981c1de-49af-4bd8-b87d-02e455a96ee1\n\n### Kyverno\n\n#### Pod Security Admission Integrations\n\n- Description: Integrate Kubernetes Pod Security with Kyverno - Part II\n- Expected Outcome: PR sent to kubernetes/kubernetes containing necessary changes to implement the behavior on the Kyverno side.\n- Recommended Skills: Golang, Kubernetes, Pod Security\n- Mentor(s): Shuting Zhao (@realshuting, shuting@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/6144\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/59afc794-c33e-4930-a5b8-eb3abd8d9896\n\n#### Kubernetes Validating Admission Policy Support\n\n- Description: Kubernetes Validating Admission Policy Support\n- Expected Outcome: Kyverno support for ValidatingAdmissionPolicy in one of the identified proposals.\n- Recommended Skills: Golang, Kubernetes, Admission Controls\n- Mentor(s): Jim Bugwadia (@jimbugwadia, jim@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/5441\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a00294be-06a0-4e66-a2a5-6e2dfb3a097c\n\n#### OCI references support\n\n- Description: Use OCI References in image verification\n- Expected Outcome: PR sent to kyverno/kyverno implementing support for OCI references in verifyImages rules\n- Recommended Skills: Golang, Kubernetes, OCI images\n- Mentor(s): Jim Bugwadia (@jimbugwadia, jim@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/6142\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e5da551f-8a3d-42ec-8c00-e9ae10a86aa2\n\n#### Artifact Hub listing of Kyverno Policy Library\n\n- Description: Develop a system to reflect all Kyverno Policies in the community library on Artifact Hub\n- Expected Outcome: All Kyverno policies searchable on Artifact Hub with an extensible system for future use\n- Recommended Skills: Golang, Artifact Hub, DevOps Automation, GitHub Actions\n- Mentor(s): Chip Zoller (@chipzoller, chipzoller@gmail.com)\n- Upstream Issue: https://github.com/kyverno/policies/issues/491\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f502b839-a804-4a6c-8da5-3985ce25883e\n\n\n### Karmada\n\n#### Provide interactive environments for Karmada users\n- Description: Using interactive environments(like killercoda) for users to get started quickly.\n- Expected Outcome: Implement 2 Karmada examples in killercoda, including a CLI installation example and script installation example, both contains installation and deploying workload to multi-clusters steps.\n- Recommended Skills: Kubernetes, Karmada\n- Mentor(s): Wei Jiang (@jwcesign, jiangwei115@huawei.com), Hongcai Ren(@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/3085\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6a6e8093-660a-4b6e-8d29-24b8ef70e4f0\n\n#### Enhance Karmada testing coverage\n\n- Description: Karmada would like to improve the UT coverage of the code to better maintain the quality of the code and reduce the introduction of defects.\n- Expected Outcome: Increase the UT coverage rate to 65% (currently, the UT coverage rate is [43%](https://app.codecov.io/gh/karmada-io/karmada) ), increase the code coverage rate by about 20%.\n- Recommended Skills: Golang, Git\n- Mentor(s): Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com), Hongcai Ren(@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/3086\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1b2c5ff4-d6ea-4ca5-b138-75fce03407b4\n\n#### Bundle third-party resources into the Resource Interpreter framework\n\n- Description: Karmada's Resource Interpreter Framework is designed for interpreting resource structure. It consists of built-in and customized interpreters. Karmada could bundle some popular and open-sourced resources so that users can save the effort to customize them.\n- Expected Outcome: The resources from projects, including Argo Workflow/Flux CD/Kyverno/OpenKurise, could be bundled in Karmada, and the corresponding documentation should also be supplemented.\n- Recommended Skills: Go, Cloud Native\n- Mentor(s): Tiecheng Shen (@Poor12, shentiecheng@huawei.com), Hongcai Ren(@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/3087\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/891b4b92-0a78-409e-8b90-dcd58d126225\n\n### Konveyor\n\n#### Move2Kube: Allow customizations be added as remote git repo path\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has inbuilt support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. Currently, in the CLI we can use the -c flag to point to the folder containing customizations and in UI we could upload a zip file containing the customizatoins. It would be better to consume customizations when specified as a git repo path. The use case can also be extended to take source code input taken directory from a remote git repository.\n- Expected Outcome: Move2Kube should be able to consume git repo path as input.\n- Recommended Skills: Golang\n- Mentor(s): Mehant Kammakomati (@kmehant, mehant.kammakomati2@ibm.com), Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/604\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fc06da19-fadd-499f-ae71-3da2caba5aea\n\n#### Move2Kube: Implement a test suite\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has inbuilt support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. The project is actively developed with new features and bug fixes being added and it is being actively used by many users. There is a need for a concrete test suite to test various components of Move2Kube and integrate it to the existing CI/CD pipeline.\n- Expected Outcome: A test suite for Move2Kube\n- Recommended Skills: Golang, testing package, jest and/ react testing library.\n- Mentor(s): Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com), Mehant Kammakomati (@kmehant, mehant.kammakomati2@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/957\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6d457c37-68cb-4d52-b9d6-798b09350255\n\n#### Move2Kube: Consume Move2Kube through a plugin on Eclipse\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has inbuilt support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. Users currently have to use move2kube command line tool or UI to access move2kube and use it in their replatforming workflows. Allow Move2Kube to be accessible from Eclipse as a plugin. It can start with simple functionality like right clicking on a docker-compose file, and generating all Kubernetes artifacts. An eclipse plugin for Move2kube will promote fast integration in replatforming workflows.\n- Expected Outcome: An end to end working eclipse plugin with a demo video showcasing the functionality.\n- Recommended Skills: Eclipse, Java, Golang.\n- Mentor(s): Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com), Mehant Kammakomati (@kmehant, mehant.kammakomati2@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/396\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9976a49b-0aa4-49db-ae71-6180f85218ef\n\n#### Move2Kube: Consume Move2Kube through a plugin on VSCode\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has inbuilt support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. Users currently have to use move2kube command line tool or UI to access move2kube. Allow Move2Kube to be accessible from VSCode as a plugin. It can start with simple functionality like right clicking on a docker-compose file, and generating all Kubernetes artifacts. A VSCode plugin for Move2kube will promote fast integration in replatforming workflows.\n- Expected Outcome: An end to end working VSCode plugin with a demo video showcasing the functionality.\n- Recommended Skills: VSCode plugins, TypeScript, Golang.\n- Mentor(s): Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com), Mehant Kammakomati (@kmehant, mehant.kammakomati2@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/395\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d8a7022f-8c62-4776-9e7c-4cc12f306177\n\n### KubeArmor\n\n#### KubeArmor Telemetry Monitoring and Dashboards\n\n- Description: KubeArmor generates a large amount of data through logs and alerts, but interpreting this data can be difficult. To make it easier to understand, it is necessary to parse the telemetry, create meaningful metrics, enable data filtering, and create visualizations such as graphs to display on a dashboard.\n- Expected Outcome: Create a telemetry dashboard, write setup documentation and usage guide.\n- Recommended Skills: ELK stack (Elasticsearch, Logstash & Kibana), Fluentd, Loki and Grafana\n- Mentors: Anurag Kumar (@kranurag7, contact.anurag7@gmail.com), Ankur Kothiwal (@Ankurk99, ankur.kothiwal99@gmail.com), Barun Acharya (@daemon1024, barun1024@gmail.com), Rahul Jadhav (@nyrahul, nyrahul@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/836\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a0696db8-509e-44ff-ae61-82a3442853c1\n\n#### Adding OpenTelemetry Support\n\n- Description: To integrate KubeArmor with OpenTelemetry, an adapter needs to be created. OpenTelemetry is a standard for telemetry data, including distributed tracing, metrics, and logs, and has an SDK and a collector component that can run on Kubernetes. Applications can directly expose OpenTelemetry data through in-app instrumentation using the OpenTelemetry SDK. The collector can then gather data from multiple applications in a cluster and send it to various backends for storage and visualization, such as Jaeger.\n- Expected Outcome: The mentee's task is to develop an OpenTelemetry adapter for KubeArmor that can receive logs, alerts, and telemetry from the kubearmor-relay-service and convert it into the OpenTelemetry format. They are also expected to create documentation and usage guides that describe how to set up and use the adapter, as well as demonstrate the integration with a backend that supports OpenTelemetry.\n- Recommended Skills: OpenTelemetry, Go\n- Mentor(s): Anurag Kumar (@kranurag7, contact.anurag7@gmail.com), Ankur Kothiwal (@Ankurk99, ankur.kothiwal99@gmail.com), Barun Acharya (@daemon1024, barun1024@gmail.com), Rahul Jadhav (@nyrahul, nyrahul@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/894\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/369f081d-398e-4ce8-b645-e9605b62326a\n\n#### Rancher Plugin Integration\n\n- Description: The goal is to create an extension for Rancher, a Kubernetes management platform, which will enable interaction with KubeArmor. The extension will have the capability to install KubeArmor, allow for the management of security policies, and provide monitoring of workload behavior through alerts and telemetry.\n- Expected Outcome: Rancher plugin address the following points: Install KubeArmor within Rancher, document and demonstrate the usage.\nNote: This item is a work in progress. The selected mentee is expected to continue the same work.\n- Recommended Skills: Rancher, Grafana stack, Javascript\n- Mentor(s): Anurag Kumar (@kranurag7, contact.anurag7@gmail.com), Ankur Kothiwal (@Ankurk99, ankur.kothiwal99@gmail.com), Barun Acharya (@daemon1024, barun1024@gmail.com), Rahul Jadhav (@nyrahul, nyrahul@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/992\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b7accea9-22bc-44e7-bac0-2f7b986fa626\n\n\n### Kubewarden\n\n#### Kubewarden SDKs feature parity\n\n- Description: Kubewarden currently allow policy writers to use 4 different programming languages. Therefore, there are 4 SDKs to be maintained. However, they lack feature parity. In other words, some SDK have feature that have features not available in other SDKs. It's necessary to map what are the features missing between the Go and Rust SDKs and implement some of them. For that, it is necessary to read and understand what is done in the Rust SDK and implement the equivalent in the Go SDK.\n- Expected Outcome: Map all the features missing between the Go and Rust SKDs and implement some of the missing features\n- Recommended Skills: Rust, Go, Kubernetes\n- Mentor(s): José Guilherme Vanz (@jvanz), Victor Cuadrado Juan (@viccuad)\n- Upstream Issue: https://github.com/kubewarden/kubewarden-controller/issues/392\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ddc368b7-1e24-42ed-9e30-02abdf6fcd33\n\n#### Kubewarden policies enhancements\n\n- Description: Kubewarden has many policies to validate and mutate Kubernetes resources. Therefore, there are many enhancements to be made on them. However, these improvements are still to be made. Thus, it's necessary to fix the open issues in the policies repositories and implement new policies to add more value to the Kubewarden users. \n- Expected Outcome: Fix as many open issues in the Kubewarden policies as possible and create new policies requested by the community\n- Recommended Skills: Rust, Go, Kubernetes\n- Mentor(s): José Guilherme Vanz (@jvanz), Victor Cuadrado Juan (@viccuad)\n- Upstream Issue: https://github.com/kubewarden/kubewarden-controller/issues/393\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9b8a3840-1355-4301-894b-7271c597f0cf\n\n### KubeEdge\n\n#### Design and implement the KubeEdge Dashboard\n\n- Description: Users now can use K8s API or Kubectl to talk to KubeEdge, in this project we will design and implement the KubeEdge dashboard, so users can talk to KubeEdge cluster through UI.\n- Expected Outcome: Create the KubeEdge dashboard, users can view and operate the resource through UI.\n- Recommended Skills: JS, Kubernetes, KubeEdge, Html\n- Mentors: Vincent Lin (@vincentgoat, linguohui1@huawei.com), Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/dashboard/issues/1\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4d9d8e17-8484-4c3e-9210-bb911633f57c\n\n\n#### Re-design and implement the KubeEdge website\n\n- Description: KubeEdge's website has been running for a few years, and now we have more customer cases and more developer courses, so this project will update KubeEdge's website, with more readable documents on the homepage, covering user cases, developer courses, etc.\n- Expected Outcome: The website has more readable documentation, covering user cases, developer courses, etc.\n- Recommended Skills: JS, KubeEdge, Html\n- Mentor(s): Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com), Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/website/issues/292\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a50fec46-7bc6-4fa0-ba84-848f0c136b5c\n\n#### Cloud-Robotic AI Benchmarking for Edge-cloud Collaborative Lifelong Learning\n\n- Description: Based on real-world datasets provided by industry members of KubeEdge SIG AI, the issue aims to build a lifelong learning benchmarking on KubeEdge-Ianvs. Namely, it aims to help all Edge AI application developers to validate and select the best-matched algorithm of lifelong learning.\n- Expected Outcome: The benchmark includes: 1) Work together to release a new dataset to the public! 2) Implement critical algorithm or system metrics, e.g., BWT, FWT and thoughput; 3) (Optional) Develop a baseline algorithm for this benchmark.\n- Recommended Skills: TensorFlow/Pytorch, Python, Kubernetes\n- Mentor(s): Siqi Luo (@luosiqi, luosiqi2@huawei.com), Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/48\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/50cdbd65-e0cd-4c0f-8c63-6bd5c603ba89\n\n#### Meshery\n\n##### Distributed workflow engine\n\n- Description: Integrate a new architectural component into Meshery: a workflow engine. This project involves shifting Meshery off of bitcask and off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.\n- Recommended Skills: Golang, Temporal, ReactJS\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Ashish Tiwari (ashishjaitiwari15112000@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/3934\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/73202d21-d4ca-4435-9a73-f326c9b3e796\n \n##### Multi-user cloud native playground\n\n- Description: Advance the cloud native playground in which any CNCF project can be explored. Meshery’s genesis is that of helping teach people about cloud native technology and enabling to operate various types of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission by infusing multi-user collaboration as a pervasisve feature so that users can learn together in a running instance of Meshery.\n- Recommended Skills: ReactJS, CSS, Golang (nice-to-have)\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Abhishek Kumar (@abhishek-kumar09, abhimait1909@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/7020\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2ee7a912-e26e-4602-9dfc-4febe3842df3\n\n#### Distributed client-side policy evaluation in WASM and Rego\n\n- Description: Meshery's highly dynamic infrastructure configuration capabilities require real-time evaluation of complex policies. Policies of various types and with a high number of parameters need to be evaluted client-side. With policies expressed in Rego, the goal of this project is to incorporate use of the https://github.com/open-policy-agent/golang-opa-wasm project into Meshery UI, so that a powerful, real-time user experience is possible.\n- Recommended Skills: Golang, Open Policy Agent, WebAssembly\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Ashish Tiwari (ashishjaitiwari15112000@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/7019\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7e3382be-5d82-443e-b0bc-4dcd2194705d\n\n### Linkerd\n\n#### Linkerd Dashboard Improvements\n\n- Description: Improve the Linkerd web dashboard with improved topology visualization, support for Linkerd conformance to the Gateway API project, and improved multi-cluster support.\n- Expected Outcome: A period of focused investment in the Linkerd viz dashboard experience will greatly improve the experience for Linkerd users. \n- Recommended Skills: React/JavaScript, Kubernetes\n- Mentor(s): Oliver Gould (@olixOr, ver@buoyant.io), Alex Leong (@adleong, alex@buoyant.io) \n- Upstream Issue: https://github.com/linkerd/linkerd2/issues/7865, https://github.com/linkerd/linkerd2/issues/9243, https://github.com/linkerd/linkerd2/issues/9554\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0dd36ed5-4c92-4fb3-b809-bb614261a199\n\n#### Add dynamic profiling to Linkerd Rust controllers\n- Description: The Linkerd control plane includes controllers that are written in Rust. Enable users to dynamically profile the running application can aid significantly in debugging and diagnostics. \n- Expected Outcome: In an upcoming release of Linkerd the policy controller would expose endpoints (leveraging [pprof](https://github.com/tikv/pprof-rs/blob/master/README.md) or another tool) for profiling controller resource consumption.\n- Recommended Skills: Rust, Kubernetes\n- Mentor(s): Oliver Gould (@olixOr, ver@buoyant.io), Alex Leong (@adleong, alex@buoyant.io) \n- Upstream Issue: https://github.com/linkerd/linkerd2/issues/10227\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e1ff5120-32e4-44a8-a1be-4e0717ef9ad6\n\n#### Prototype multi-cluster service discovery and operations\n- Description: When deploying a multi-cluster resource one has to perform certain contortions such as providing a list of other clusters to each cluster. This places a dependency ordering on spinning up new clusters and a requirement for application operators to coordinate with cluster operators.\n- Expected Outcome: Develop a prototype where each cluster only needs to reference a common service definition to discover peers without knowledge of the names or even number of other clusters.\n- Recommended Skills: Go, Rust, Kubernetes\n- Mentor(s): Oliver Gould (@olixOr, ver@buoyant.io), Matei David (@mateiidavid, matei@buoyant.io) \n- Upstream Issue: https://github.com/linkerd/linkerd2/issues/7566\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ce8883ce-9e32-4337-8fe0-5c51fed758e4\n\n\n### LitmusChaos\n\n#### Improve code quality and add unit tests of litmus chaos components\n- Description: [LitmusChaos](https://litmuschaos.io) is an open-source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way. This project aims to improve the code quality of the golang components of litmus chaos and refactor the codebase for adding the unit test cases.\n- Expected Outcome: This will help the project to improve code quality, enhance the unit test suite, and identification of weaknesses\n- Recommended Skills: Golang, Kubernetes\n- Mentor: Amit Kumar Das (@amityt, amit.das@harness.io) Sayan Mondal (@S-ayanide, sayan.mondal@harness.io)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/3892\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a222f58a-08ee-4727-80c8-41c4d6f5a2a9\n\n### NATS\n\n#### End-to-end example of a multiplayer game using NATS in Unity\n\n- Description: This project consists of developing an example Unity setup of a multiplayer game using the latest version of the NATS Server.\n- Expected Outcome: A well documented repository under the `nats-io` GitHub organization that contains the artifacts and sample code of the setup using the .NET NATS Client (https://github.com/nats-io/nats.net)\n- Recommended Skills: .NET, C#, Unity, NATS\n- Mentor(s): Waldemar Quevedo (@wallyqs)\n- Upstream Issue: https://github.com/nats-io/dot-net-nats-examples/issues/1\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/127da817-037b-4225-83a6-3a3eeea8b421\n\n\n### Notary\n\n#### HashiCorp Vault plugin for Notary\n\n- Description: Notary is a CNCF incubating project that aims to provide signing and verification capabilities to ensure delivery integrity and security. It supports creating and storing signatures for container images, SBOM, vulnerability scanning results, etc. to ensure the artifacts someone produced have not been tampered by others. Notary only has an Azure Key Vault plugin for storing keys in Azure Key Vault, which is used to sign and verify artifacts in the OCI registry. [HashiCorp Vault](https://github.com/hashicorp/vault) is a popular KMS and we see more and more users rely on it in the on-premise environment.\n- Expected Outcome: Develop a Key Management System (KMS) plugin with [HashiCorp Vault](https://github.com/hashicorp/vault) for Notary CLI (Notation), which can be used to store the keys for Notation signing and verification.\n- Recommended Skills: Golang programming language, Notary knowledge.\n- Mentor(s): Patrick Zheng (@patrickzheng200, patrickzheng@microsoft.com), Shiwei Zhang (@shizhMSFT, shiwei.zhang@microsoft.com)\n- Upstream Issue: https://github.com/notaryproject/notation/issues/521\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9710c834-913d-487d-9ebf-8205cdf48ab4\n\n### OpenKruise\n\n#### Bring progressive delivery to daemon workload\n\n- Description: Kruise Rollout enable progressive delivery of various workload ranging from stateless workload such as Deployment to stateful workload such as StatefulSet or customized operators. This project aims to bring progress delivery capability to daemon workload, which is run on each node of a k8s cluster. The project involves implementing common API of progressive delivery for OpenKruise Advance DaemonSet, and integrate with the Kruise Rollout framework. \n- Expected Outcome: Support progressive delivery for OpenKruise Advance DaemonSet(along with supporting test cases and docs) , that is, update new version of daemon pods in batches with user defined pause strategy. Traffic scheduling is not required for this project. \n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Zhang Zhen (@furykerry, furykerry@gmail.com), Zhang Lei(@resouer, resouer@gmail.com)\n- Upstream Issue: https://github.com/openkruise/rollouts/issues/69\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d3a1507a-b132-4c7c-aead-dfe78fd34eb8\n\n#### Support customize arbitary fields of workload subset in UnitedDeployment\n\n- Description: UnitedDeployment in OpenKruise enable users to manage a set of k8s workloads in whole while be able to customize the topology and replicas of each workload. This project extends the customization capability to arbitary workload fields by adding common patch fields, so that \neach subset of UnitedDeployment can have different metadata, container configuration etc. \n- Expected Outcome: Support generate patches for new creating pods of each subset workload while the users can rollout and scale the UnitedDeployment in whole. \n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Zhang Zhen (@furykerry, furykerry@gmail.com), Zhang Lei(@resouer, resouer@gmail.com)\n- Upstream Issue: https://github.com/openkruise/kruise/issues/811\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9e0f01ab-615f-44ed-b65b-0f1296037a48\n\n\n### ORAS\n\n#### Develop .NET SDK for ORAS\n\n- Description: [ORAS](https://oras.land/) is a tool for working with OCI artifacts and OCI registries. It allows users to distribute OCI artifacts across OCI Registries. Users seeking a generic registry client can benefit from the ORAS CLI, while developers can build their own clients on top of one of the ORAS client libraries. ORAS has Python and Golang SDK that allow developers to build their own clients on top of one of the library. Similarly, developing a .NET SDK will enable .Net developers to use ORAS API and enhance the ORAS ecosystem. \n- Expected Outcome: Develop a .NET SDK in a new repository and write the examples and API document on GoDoc. Write unit test for this SDK and make sure the testing coverage is qualified.\n- Recommended Skills: C#/.NET, ORAS conceptual knowledge.\n- Mentor(s): Sylvia Lei (@Wwwsylvia, lixia.lei@microsoft.com), Shiwei Zhang (@shizhMSFT, shiwei.zhang@microsoft.com)\n- Upstream Issue: https://github.com/oras-project/oras/issues/774\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5d331c88-fc2d-4635-a92c-5d25fb42f47d\n\n#### Develop ORAS Website\n\n- Description: [ORAS](https://oras.land/) is a tool for working with OCI artifacts and OCI registries. It allows users to distribute OCI artifacts across OCI Registries. ORAS only has a documentation site so far, the project goal is to develop a new website using Hugo framework based on the Figma layout design.\n- Expected Outcome: Develop a new website using the [Hugo framework](https://gohugo.io/) based on the Figma layout design. It will replace the existing [ORAS documentation website](https://oras.land/) and provide a better user experience with interactive design.\n- Recommended Skills: HTML, Javascript, CSS, Hugo.\n- Mentor(s): Feynman Zhou (@FeynmanZhou, feynmanzhou@microsoft.com), \n- Upstream Issue: https://github.com/oras-project/oras-www/issues/82\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7f633ade-64f5-477c-bcbe-7b6693329c63\n\n### Service Mesh Performance\n\n#### Adaptive Load Controller II\n\n- Description: The adaptive load controller is to execute optimization routines recursivley to determine the maximum load a system can sustain. The maximum load is usually defined by the maximum requests per second (rps) the system can handle. The metrics (CPU usage, latency etc) collected from the system under test are the constraints we provide to judge whether a system under test (SUT) is sustaining the load.\n\nA use-case that fits very well is be the ability to use it to run performance tests on a schedule and track the maximum load a system can handle over time. This could give insights to performance improvements or degradations.\n\n- Recommended Skills: golang, grpc, docker, kubernetes\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Xin Huang (@gyohuangxin, xin1.huang@intel.com)\n- Upstream Issue (URL): https://github.com/service-mesh-performance/service-mesh-performance/issues/350\nLFX URL: https://mentorship.lfx.linuxfoundation.org/project/2597fc3d-eb2c-411f-b02d-940c8347328d\n\n### TestGrid\n\n#### Frontend development inside Lit Component Framework\n\n- Description: [TestGrid](http://testgrid.k8s.io) is the test visualization tool attached to Prow to\n collate and display historical test results for the k8s and k8s-adjacent\n communities. The UI is in the process of being rewritten.\n- Expected Outcome: Create Lit-based view components for TestGrid (summary, index, etc.) that display data from the API. Implement Jasmine and Storybook testing for these components.\n- Recommended Skills: TypeScript, CSS, Golang\n- Mentor(s): Sean Chase (@chases2, slchase@google.com)\n- Upstream Issue: https://github.com/GoogleCloudPlatform/testgrid/issues/1005\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ca622980-cc8c-4f18-8a74-b9a7b4b49e3a\n\n### Thanos\n\n#### Add query observability for new promql engine\n- Description: The new [Thanos Promql Engine](https://github.com/thanos-community/promql-engine) lacks observability down to operator level and we don't have a way to track each operator's performance. This project aims to extend the `Explain` method of each operator, and return an operator tree with time taken recorded. Then Thanos Query UI could then visualize the operator trace.\n- Expected Outcome: Add a button in Query UI that when enabled will show query tree + how much time has been spent in each operator\n- Recommended Skills: Golang, React\n- Mentor: Giedrius Statkevičius (@GiedriusS, giedriuswork@gmail.com), Saswata Mukherjee (@saswatamcode, saswataminsta@yahoo.com)\n- Upstream Issue: https://github.com/thanos-community/promql-engine/issues/106\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a0958ddf-1fd6-4c8e-887f-adb28639a9f4\n\n#### Series Cardinality API\n- Description: Prometheus has a TSDB stats API https://prometheus.io/docs/prometheus/latest/querying/api/#tsdb-stats which contains information about series cardinality and the API is supported by Thanos. However, it can only return 10 results per stats, which is not flexible to track the arbitrary metrics. This project aims to design and implement APIs that expose cardinalities. Stretch goal can be to add cardinality explorer page to Thanos UI.\n- Expected Outcome: New Thanos APIs to expose series cardinality.\n- Recommended Skills: Golang, React\n- Mentor: Ben Ye (@yeya24, yb532204897@gmail.com)\n- Upstream Issue: https://github.com/thanos-io/thanos/issues/6007\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/dbce5279-d029-46f3-b117-9e9dd7f84bd6\n\n#### Querying Apache Parquet files with PromQL\n- Description: The new [Thanos PromQL Engine](https://github.com/thanos-community/promql-engine) has a sufficient separation between the syntax tree and the execution plan to allow us to query arbitrary data sources. In this project we would like to explore ways to query data stored in Apache Parquet files.\n- Expected Outcome: The Thanos PromQL engine can query timeseries data from Apache Parquet files.\n- Recommended Skills: Golang\n- Mentor: Filip Petkovski (@fpetkovski, filip.petkovsky@gmail.com), Prem Saraswat (@onprem, prmsrswt@gmail.com)\n- Upstream Issue: https://github.com/thanos-community/promql-engine/issues/167\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a04cfbe4-4dde-4c7e-8b70-9570639b48a7\n\n### Vitess\n\n#### Implement a benchmarking and load testing framework for the VReplication module in Vitess\n- Description: Vitess is a distributed database system built around MySQL. VReplication is core technology built into Vitess that is used to enable many features like vertical and horizontal sharding, change data capture and materialized views. The project involves designing and implementing a customizable framework that enables us to test different VReplication workflows at scale and to obtain benchmarks that can be used to monitor performance improvements and regression from code changes. The framework will consist of a custom DSL (Domain Specific Language) which will be used to define each test case and a driver which will read the DSLs and execute the tests. The DSL will be based on the Hashicorp Configuration Language (https://github.com/hashicorp/hcl). The driver will be written in Golang and target AWS using Terraform for provisioning and Ansible for automation. The results and benchmarks will be stored in PlanetScale (https://planetscale.com/) in the existing vitess benchmark database.\n- Expected Outcome: The test framework with at least one working test and stored benchmark metrics for a MoveTables workflow.\n- Recommended Skills: golang\n- Mentor: Rohit Nayak (@rohit-nayak-ps, rohit@planetscale.com) \n- Upstream Issue: https://github.com/vitessio/vitess/issues/12136\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b903d812-c3ff-47bf-8626-0b9274fec742\n\n#### Add complete parsing support for Spatial MySQL functions\n- Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. Vitess has its own in-built SQL-parser which it uses to understand the query and represent as structs for further processing. As of now, a lot of spatial MySQL functions are not parsed correctly and result in syntax errors. The task of the mentee would be to add parsing support for such functions and features which can be found at https://dev.mysql.com/doc/refman/8.0/en/spatial-analysis-functions.html\n- Recommended Skills: go, SQL, yacc, compilers and lexers\n- Mentor(s): [Manan Gupta](https://github.com/GuptaManan100) (manan@planetscale.com)\n- Upstraeam Issue: https://github.com/vitessio/vitess/issues/8604\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d338ee93-e767-4f44-a0ea-02dbf803a55a\n\n### WasmEdge\n\n#### Streaming data processing with WasmEdge\n\n- Description: WasmEdge would like to integrate WasmEdge as an alternative runtime for Fluvio. We would like to create a compile-time feature for the [fluvio-smartengine](https://github.com/infinyon/fluvio/tree/master/crates/fluvio-smartengine) crate. Once this feature is turned on, the compiler will choose to embed WasmEdge into the binary build using the [WasmEdge Rust SDK](https://wasmedge.org/book/en/sdk/rust.html).\n- Expected Outcome: A complete PR and a demo app that uses WasmEdge to process streaming data using a Tensorflow or Pytorch model\n- Recommended Skills: working knowledge of the Rust language and WebAssembly Rust SDK\n- Mentor(s): Michael Yuan (@juntao, michael@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2231\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/484542b0-84d6-43e3-b3fe-16fb2624f1b2\n\n#### A Rust library crate for mediapipe models for WasmEdge NN\n\n- Description: WasmEdge would like to build a Rust library crate that enables easy integration of Mediapipe models in WasmEdge applications. Each Mediapipe model has [a description page](https://google.github.io/mediapipe/solutions/face_detection.html) that describes its input and output tensors. The [models](https://google.github.io/mediapipe/solutions/models.html) are available in Tensorflow Lite format, which is supported by the WasmEdge Tensorflow Lite plugin.\n- Expected Outcome: We need at least one set of library functions for each model in Mediapipe. Each library function takes in a media object and returns the inference result.\n- Recommended Skills: basic knowledge of Rust and experience in working with AI models and image processing.\n- Mentor(s): Michael Yuan (@juntao, michael@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2229\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e4e6d486-e6df-475d-8074-a363d0361076\n\n#### Unified WasmEdge tools\n\n- Description: WasmEdge provides two tools in the release assets: `wasmedgec` and `wasmedge`. However, providing multiple tools will make it too complicated to use. That's why we want a simple entry point, `wasmedge`. As its subcommands, all the tools above should be collected into this new tool.\n- Expected Outcome: A document to explain the new WasmEdge tools, a test suite covers the implementation details, and implement `wasmedge run` and `wasmedge compile` featues.\n- Recommended Skills: C++ programming language, WebAssembly knowledge.\n- Mentor(s): Hung-ying Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2226\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2ebb39fd-3497-44f3-90d7-e95b444b2bc8\n\n\n#### WasmEdge C++ SDK\n\n- Description: WasmEdge provides C SDK as the based library and uses this to implement other languages SDK such as Golang, Rust, Java, and Python(developing). We would like to provide C++ SDK in this task.\n- Expected Outcome: A document to explain the C++ SDK, a test suite cover the implementation details, and the implementation of WasmEdge Basics and VM sections in the C SDK.\n- Recommended Skills: C++ programming language, WebAssembly knowledge.\n- Mentor(s): Yiying He (@q82419, yiying@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2241\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1d5d1fcd-b671-4367-b6db-13ef263aece1\n\n\n" }, { "path": "programs/lfx-mentorship/2023/01-Mar-May/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description: \n- Expected Outcome:\n- Recommended Skills: \n- Mentor(s): Mentor Name (@mentor_github, mentor@email.addy) \n- Upstream Issue: \n\n---\n\n## Proposed Project ideas\n\n" }, { "path": "programs/lfx-mentorship/2023/02-Jun-Aug/README.md", "content": "# Term 02 - 2023 June - August\n\nStatus: Complete\n\nMentorship duration - three months (12 weeks - full-time schedule)\n\n### Timeline\n\n| activity | date |\n| --- | --- | \n| project proposals due | Tue, May 9, 5:00 PM PDT |\n| mentee applications open | Wed May 10 - Tue May 23, 5:00 PM PDT |\n| application review/admission decisions | Wed May 24 - Mon May 29, 5:00 PM PDT |\n| Mentorship program begins with the initial work assignments | Thur June 1 (Week 1) | \n| Midterm mentee evaluations and first stipend payments | Wed July 12 (Week 6) |\n| Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals | Wed Aug 23, 5:00 PM PST (Week 12) |\n| Last day of term | Thur Aug 31 |\n\n### Project Instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2023/02-Jun-Aug/project_ideas.md, by Tuesday, May 9, 2023.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\nTable of Contents\n\n- [Armada](#armada)\n - [Build interfaces around Postgres for Armada](#build-interfaces-around-postgres-for-armada)\n- [Cilium/Tetragon](#ciliumtetragon)\n - [Implement a Kubernetes operator to maintain pod IP to pod metadata mapping](#implement-a-kubernetes-operator-to-maintain-pod-ip-to-pod-metadata-mapping)\n- [CNCF Landscape ](#cncf-landscape)\n - [UX / UI Improvements II](#ux--ui-improvements-ii)\n- [CoreDNS](#coredns)\n - [Add DNS-over-QUIC (DoQ) and/or DNS-over-HTTP/3 (DoH3) support](#add-dns-over-quic-doq-andor-dns-over-http3-doh3-support)\n- [Jaeger](#jaeger)\n - [Upgrade Jaeger's internal telemetry to OpenTelemetry](#upgrade-jaegers-internal-telemetry-to-opentelemetry)\n - [Implement Critical Path analysis](#implement-critical-path-analysis)\n- [Knative](#knative)\n - [Self-Balancing Knative Kafka Broker partitions](#self-balancing-knative-kafka-broker-partitions)\n - [Porting Knative Serving to Microshift](#porting-knative-serving-to-microshift)\n- [Konveyor](#konveyor)\n - [Add Integration test suite and components testing to Konveyor](#add-integration-test-suite-and-components-testing-to-konveyor)\n- [KubeArmor](#kubearmor)\n - [Implement DNS visibility with KubeArmor](#implement-dns-visibility-with-kubearmor)\n - [Manage KubeArmor policies using OCI registry and use OCI hooks for container events](#manage-kubearmor-policies-using-oci-registry-and-use-oci-hooks-for-container-events)\n- [Kubescape](#kubescape)\n - [Store Kubescape configuration scan results as CRs](#store-kubescape-configuration-scan-results-as-crs)\n - [Prometheus exporter for image vulnerabilities](#prometheus-exporter-for-image-vulnerabilities)\n - [Vulnerability-based Dockerfile generator](#vulnerability-based-dockerfile-generator)\n- [KubeVela](#kubevela)\n - [Expand multiple database drivers for the API server](#expand-multiple-database-drivers-for-the-api-server)\n - [Auto-generate the TypeScript and Java languages API SDK](#auto-generate-the-typescript-and-java-languages-api-sdk)\n- [Kyverno](#kyverno)\n - [Kuttl tests for the Kyverno policy library](#kuttl-tests-for-the-kyverno-policy-library)\n - [Sigstore Cosign Updates](#sigstore-cosign-updates)\n - [ValidatingAdmissionPolicy support, Phase 2](#validatingadmissionpolicy-support-phase-2)\n - [Cleanup Policies, Phase 2](#cleanup-policies-phase-2)\n- [LitmusChaos](#litmuschaos)\n - [Migrate chaos workflow api from graphql to rest and improve chaos center code base](#migrate-chaos-workflow-api-from-graphql-to-rest-and-improve-chaos-center-code-base)\n - [Enhance/Upgrade chaos operator and chaos exporter module](#enhanceupgrade-chaos-operator-and-chaos-exporter-module)\n- [Meshery](#meshery)\n - [Meshery UI Permissions Framework](#meshery-ui-permissions-framework)\n - [OPA policy evaluation in-browser using WebAssembly and Rego](#opa-policy-evaluation-in-browser-using-webassembly-and-rego)\n - [Adopt OCI as the packaging and distribution format for Meshery MeshModels](#adopt-oci-as-the-packaging-and-distribution-format-for-meshery-meshmodels)\n - [OCI compatible Kubernetes ontology](#oci-compatible-kubernetes-ontology)\n- [Notary](#notary)\n - [Design and implement the new Notary website](#design-and-implement-the-new-notary-website)\n - [Develop content for Notary documentation and blogs](#develop-content-for-notary-documentation-and-blogs)\n- [ORAS](#oras)\n - [Design and implement Artifact Explore web portal](#design-and-implement-artifact-explore-web-portal)\n - [Refactor the ORAS documentation structure and write new user guides](#refactor-the-oras-documentation-structure-and-write-new-user-guides)\n- [Service Mesh Performance](#service-mesh-performance)\n - [Service Mesh Performance IDE Plugin](#service-mesh-performance-ide-plugin)\n- [Strimzi](#strimzi)\n - [Proof of Concept of an MQTT to Apache Kafka bridge for producing messages](#proof-of-concept-of-an-mqtt-to-apache-kafka-bridge-for-producing-messages)\n- [Thanos](#thanos)\n - [Continuation of add query observability for the new engine](#continuation-of-add-query-observability-for-the-new-engine)\n- [Vitess](#vitess)\n - [Rework the frontend UI of Vitess’ benchmarking tools](#rework-the-frontend-ui-of-vitess-benchmarking-tools)\n- [WasmEdge](#wasmedge)\n - [Serialization Completion](#serialization-completion)\n - [zlib Plugin Support](#zlib-plugin-support)\n - [Support Tensorflow and PyTorch in WasmEdge’s Python runtime](#support-tensorflow-and-pytorch-in-wasmedges-python-runtime)\n - [A stream log processing framework for WasmEdge](#a-stream-log-processing-framework-for-wasmedge)\n\n---\n\n## Accepted projects\n\n### Armada\n\n#### Build interfaces around Postgres for Armada\n\n- Description: Open source projects should not be hard coded to a particular Database. Armada currently only allows users to use Postgres. This project is to build interfaces around our connections to Postgres so we can allow other databases.\n- Expected outcomes:\n - A interface is created that allows Armada to interact with any SQL database without exposing implementation details of postgres\n - increase Test coverage\n- Recommend Skills: Go, SQL\n- Mentor(s):\n - Geoffrey Wilson, @suprjinx, geoff@gr-oss.io\n - Kevin Hannon, @kannon92, kevin@gr-oss.io\n- Upstream Issue (URL): https://github.com/armadaproject/armada/issues/2121\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/73d90321-62b3-498e-bf37-d899ec99df9e\n\n### Cilium/Tetragon\n\n#### Implement a Kubernetes operator to maintain pod IP to pod metadata mapping\n\n- Description:\n\n Tetragon currently depends on Cilium to look up pod information by their IP\n addresses. The goal of this project is to remove this Cilium dependency by\n implementing a Kubernetes operator that provides this information. The idea\n is for this operator to maintain a new custom resource that provide a mapping\n from IPs to the small subset of pod information that Tetragon needs.\n\n- Expected Outcome:\n - A Kubernetes operator that maintains IP to pod info mapping used by Tetragon.\n - The operator should be installable via Helm as a Kubernetes deployment.\n - Replace Cilium dependency in the code base with this new custom resource.\n - Some performance benchmarks in a high pod churn environment.\n- Recommended Skills:\n - Goassign\n - Kubernetes\n- Mentor(s):\n - Kornilios Kourtis (@kkourt, kornilios@isovalent.com)\n - Michi Mutsuzaki (@michi-covalent, michi@isovalent.com)\n- Upstream Issue:\n - https://github.com/cilium/tetragon/issues/794\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/659fe584-68e6-46bf-bd13-12653ef60268\n\n### CNCF Landscape \n\n#### UX / UI Improvements II\n\n- Description: With your collaboration, we aim to analyze findings and meaningful information (quantitative and qualitative data) and run a series of ideation rounds. We will create user personas, empathy maps, and other UX deliverables that will be the foundation to lay out a set of solutions to improve the current way to search, navigate and find relevant information on the Landscape.\n- Expected Outcome: Creation user personas, empathy maps, and other UX deliverables.\n- Recommended Skills: UX reaserach, desighn thinking, Figma and prototyping. \n- Mentors: Andrea Velázquez @andreuxxxx andrea@buoyant.io, Nate W. @nate-double-u natew@cncf.io, Chris Aniszczyk @caniszczyk caniszczyk@linuxfoundation.org\n- Upstream Issue: https://github.com/cncf/landscape/issues/2467\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c45cc842-278f-4663-9ff4-deecc3fc040d\n\n### CoreDNS\n\n#### Add DNS-over-QUIC (DoQ) and/or DNS-over-HTTP/3 (DoH3) support\n\n- Description: DNS-over-QUIC (DoQ) and DNS-over-HTTP/3 (DoH3) are relatively new protocols for transmitting DNS queries with security and privacy. Additionally, DoQ and DoH3 also offers other benefits such as improved latency and better error detection. The goal of this proposal is to add DoQ and/or DoH3 support to CoreDNS.\n- Expected Outcome: An implementation of DoQ or DoH3 for CoreDNS. A stretch goal of adding both DoQ and DoH3 is also within scope.\n- Recommended Skills: Golang, DNS.\n- Mentor(s): Yong Tang @yongtang (yong.tang.github@outlook.com); Chris O'Haver @chrisohaver (cohaver@infoblox.com)\n- Upstream Issue (URL): https://github.com/coredns/coredns/issues/5583, https://github.com/coredns/coredns/issues/5539\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/dd10bf62-53d1-4a96-bea2-65bbb78bd10e\n\n### Jaeger\n\n#### Upgrade Jaeger's internal telemetry to OpenTelemetry\n\n- Description: historically, the Jaeger backend used the OpenTracing API, with Jaeger's own Go SDK `jaeger-client-go`, for instrumenting its own internals for distributed tracing. Since Jaeger's SDKs have been deprecated, we want to upgrade the Jaeger backend to use the OpenTelemetry tracing API and SDK directly.\n- Expected Outcome:\n - Replace the use of OpenTracing API with OpenTelemetry\n - Remove `jaeger-client-go` and `jaeger-lib` as dependencies\n - Remove `opentracing-go` and `opentracing-contrib/*` as dependencies\n - Switch to standard instrumentation libraries where available (e.g. for HTTP, gRPC)\n - Rethink/rework `crossdock` integration tests to test end-to-end flow with OpenTelemetry data\n - Publish a blog post on medium.com/jaegertracing documenting the experience\n- Recommended Skills: Go\n- Mentor(s): Yuri Shkuro (@yurishkuro, github@ysh.us); Albert Teoh (@albertteoh, see.kwang.teoh@gmail.com)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/3381\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b8009398-1252-4f63-82fe-363846ccc11d\n\n#### Implement Critical Path analysis\n\n- Description: Jaeger (https://jaegertracing.io) is a popular platform for distributed tracing. Critical path analysis is an important tool in the latency investigations. This project aims to add support for critical path analysis to Jaeger UI.\n- Expected outcomes:\n - Implement critical path determination algorithm (maybe in the backend)\n - Enhance Trace Timeline view to overlay critical path on top of the trace.\n - Add relevant documentation to the Jaeger website\n - Author a blog post on Jaeger blog explaining the new feature\n- Stretch goals:\n - Add critical path visualization to other trace views (graph, table, flamechart)\n- Recommended Skills: Javascript, Typescript, Go\n- Mentor(s): Yuri Shkuro (@yurishkuro, github@ysh.us), Yash Sharma (yashrsharma44@meta.com)\n- Upstream Issue (URL): https://github.com/jaegertracing/jaeger-ui/issues/1288\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0fc6c44b-5ddf-467f-8016-72cc35b4e3ff\n\n### Knative\n\n#### Self-Balancing Knative Kafka Broker partitions\n\n- Description: Creating a Knative Kafka Broker requires developers to specify the number of partitions the backing Kafka topic should have, however, this is not an easy decision to make and it requires planning based on the expected load the Knative Broker could receive. This project aims to remove this configuration setting by having an autoscaler that is responsible to add or remove partitions based on the effective load the Knative Kafka Broker receives while preserving [ordered and unordered delivery features](https://knative.dev/docs/eventing/brokers/broker-types/kafka-broker/#configuring-the-order-of-delivered-events) for Triggers.\n- Expected outcome: A Knative Kafka Broker can be created without setting the number of partitions and the number of partitions for a topic backing the Knative Kafka Broker increases or decreases based on the observed load received.\n- Recommended Skills: Kubernetes, Apache Kafka, Go, Java\n- Mentor(s): Pierangelo Di Pilato @pierDipi (pierdipi AT redhat DOT com), Ali Ok @aliok (aliok AT redhat DOT com)\n- Upstream Issue (URL): https://github.com/knative-sandbox/eventing-kafka-broker/issues/2917\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ac483209-2b08-4f74-aaa5-4ab3203b0677\n\n#### Porting Knative Serving to Microshift\n\n- Description: More and more workload is moving towards running on the edge. We saw experiments running Kubernetes on vehicles, fighter jets, 5G antenna and various far edge, near edge and fat edge environments. We would like to see what the challenges are when Knative is run in a resource limited environment. While there are multiple edge-friendly Kubernetes distributions, we would like to see [Microshift](https://github.com/openshift/microshift) used as the base platform. Knative consists of Serving and Eventing modules but focusing on Knative Serving as a first step should be more approachable. The project consists of 2 stages. First one is to run Knative on Microshift with minimal resources. This requires finding out problems here, solving them. A stretch goal is to find out what happens with architectures other than x86_64.\n- Expected outcome: Having Knative Serving with an ingress layer running on top of Microshift. Having a Hello-World Knative Service running on top. Finding issues blocking the edge setup, and possibly fixing them.\n- Recommended Skills: Golang, Kubernetes, Knative, good understanding of networking, good understanding of CI/CD\n- Mentor(s): Reto Lehmann @ReToCode (rlehmann AT redhat DOT com), Stavros Kontopoulos @skonto (skontopo AT redhat DOT com)\n- Upstream Issue (URL): https://github.com/knative/serving/issues/12718\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/830eb064-cf8a-4a8e-bba3-97d429a6ca79\n\n### Konveyor\n\n#### Add Integration test suite and components testing to Konveyor\n\n- Description:\nThe Konveyor project helps modernize applications by providing open source tools to rehost, replatform, and refactor applications to Kubernetes and cloud-native technologies.We’re looking for help on building integration tests on application level as well as work on missing parts of Konveyor component tests.There is open testing work to better applications analysis, tasks coverage, more detailed Hub API tests and Hub integration with addons. All of those use the Hub API that is covered with basic tests already. Based on existing Hub API tests, it is expected to continue work to cover more Konveyor functionality with tests.\nThe development environment is based on golang and Kubernetes. A minikube instance will work well for local development on Linux or Mac systems.\n- Expected Outcome:\n - Integration test suite and components testing added to existing Konveyor upstream automated test suite\n- Recommended Skills:\n - Go\n - Basic software development skills (command line, git)\n- Mentor(s):\n - Marek Aufart (@aufi, maufart@redhat.com)\n - David Zager (@djzager, dzager@redhat.com)\n- Upstream Issue:\n - https://github.com/konveyor/tackle2-operator/issues/220\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/78852896-9785-4156-bb9b-bc3c5cb6ed17\n\n### KubeArmor\n\n#### Implement DNS visibility with KubeArmor\n\n* Description: The project aims to provide better visibility into the domains accessed from pods, with a focus on identifying and containing attacks that use techniques like Domain Generation Algorithms (DGA) to connect to remote command and control (C&C) servers. By gathering information on which domains are being accessed and applying network rules to allow only specific domains, the project aims to empower security operations (secops) teams to better prevent and respond to such attacks.\n* Expected Outcome: \n * KubeArmor to emit telemetry events for any DNS lookups from any pods.\n * Ability to see egress DNS lookups done from any pods using karmor summary.\n * Documentation\n* Recommended Skills: Go, K8s, familiarity with network security and a basic understanding of KubeArmor is a plus.\n* Mentors:\n * Anurag Kumar (@kranurag7, contact.anurag7@gmail.com)\n * Barun Acharya (@daemon1024, barun1024@gmail.com)\n * Ankur Kothiwal (@Ankurk99, ankur.kothiwal99@gmail.com)\n* Upstream Issue: [Issue #1219](https://github.com/kubearmor/KubeArmor/issues/1219)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cfa22331-36f3-4d20-abf0-667a31fd2ba8\n\n#### Manage KubeArmor policies using OCI registry and use OCI hooks for container events\n\n* Description: The feature aims to manage KubeArmor policies using OCI registry and use OCI hooks to get container events. Currently, KubeArmor uses a UNIX domain socket file to watch for container events, but the proposed feature aims to use OCI hooks instead.\n* Expected Outcome: To provide a more secure and efficient way of managing KubeArmor policies by leveraging OCI registry. Storing policies in OCI registries will make it easier to distribute policies across multiple clusters and environments. Using OCI hooks will also reduce the overhead of monitoring container events and make it easier to integrate KubeArmor with other container runtimes.\n* Recommended Skills: Go, K8s, understanding of the Open Container Initiative (OCI) and container runtimes.\n* Mentors:\n * Anurag Kumar (@kranurag7, contact.anurag7@gmail.com)\n * Barun Acharya (@daemon1024, barun1024@gmail.com)\n * Ankur Kothiwal (@Ankurk99, ankur.kothiwal99@gmail.com)\n* Upstream Issue: [Issue #1130](https://github.com/kubearmor/KubeArmor/issues/1130)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/08d245cb-001f-4292-90eb-e8895189c77a\n\n### Kubescape\n\n#### Store Kubescape configuration scan results as CRs\n\n- Description: [Kubescape](http://kubescape.io/) is a utility that can scan a Kubernetes cluster and report on its security posture. There is an \"operator\" which can be installed in the cluster to perform scheduled scans scan, but this is largely used to send the data to an external service. In this project, you will implement a mechanism in the Kubescape operator to save scan results locally in a custom resource (CR), as well as a watch so that scans can be performed on cluster state changes.\n- Expected Outcome: Having the ability to scan a cluster when it changes, and have the results saved inside the cluster. This will allow users and automations to judge the security posture of changes that are made to the cluster (for example, deployments or rollouts.)\n- Recommended Skills: Go\n- Mentors:\n - Ben Hirschberg (@slashben, ben AT armosec.io)\n - Craig Box (@craigbox, craigb AT armosec.io)\n - David Wertenteil (@dwertent, dwertent AT armosec.io)\n - Upstream Issue: https://github.com/kubescape/kubescape/issues/1225\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1a6a7aaf-7436-431b-9131-9422e4b2fb71\n\n#### Prometheus exporter for image vulnerabilities\n\n- Description: Kubescape has a component that runs in-cluster which performs image scanning on all the container images deployed to a cluster. This function is largely used to send the data to an external service. In this projet, you will develop a Prometheus exporter for the image vulnerability information produced by Kubescape. This will allow users to access the data from within the cluster, as well as use it for alerting.\n- Expected Outcome: Access to cluster vulnerability data through Prometheus. For example, you should have the ability to alert on number or percentage of \"Critical\" level vulnerabilities in containers running in the cluster.\n- Recommended Skills: Go, Prometheus\n- Mentors:\n - Ben Hirschberg (@slashben, ben AT armosec.io)\n - Craig Box (@craigbox, craigb AT armosec.io)\n - David Wertenteil (@dwertent, dwertent AT armosec.io)\n- Upstream Issue: https://github.com/kubescape/kubescape/issues/1226\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8c701687-7cde-42fc-8195-08d35fdb5ee8\n\n#### Vulnerability-based Dockerfile generator\n\n- Description: Kubescape can detect vulnerabilities in a container image. Some can automatically be remediated by changing the base image version (or other package information) inside the Dockerfile which created the image. This project is to automate this remediation.\n- Expected Outcome: An enhancement to Kubescape to generate a Dockerfile that proposes fixes for vulnerabilities found in a container image. This may be by integration with existing open source tools or developing something new.\n- Recommended Skills: Go\n- Mentors:\n - Ben Hirschberg (@slashben, ben AT armosec.io)\n - Craig Box (@craigbox, craigb AT armosec.io)\n - David Wertenteil (@dwertent, dwertent AT armosec.io)\n- Upstream Issue: https://github.com/kubescape/kubescape/issues/1227\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fbaf3d52-77ee-469c-8eb4-3e0378896159\n\n\n### KubeVela\n\n#### Expand multiple database drivers for the API server\n- Description: 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. \n- Expected Outcome: The outcome of this project will be expand two more database driver for KubeVela VelaUX API server:\n - Mysql\n - PostgreSQL\n- Recommended Skills:\n - Golang\n - Kubernetes\n - Backend APIs Development\n- Mentor(s):\n - Qiao Zhongpei (@chivalryq, chivalry.pp@gmail.com)\n - Zeng Qingguo (@barnettZQG, barnett.zqg@gmail.com)\n- Upstream Issue (URL): https://github.com/kubevela/kubevela/issues/5426\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/21c95d53-dd75-4a2f-a8fd-92374c54940d\n\n#### Auto-generate the TypeScript and Java languages API SDK\n- Description: 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](https://openapi-generator.tech/) could help to generate most codes. But there are still some special cases like:\n - Dynamic component/trait/policy/workflowsteps properties need to be generated according to CUE.\n - Automatically handles the user authentication process, including automatically refreshing tokens.\n - The API definition may be incomplete accuracy, we should check it to generate high-quality code.\n- Expected Outcome: The outcome of this project will be expand two more database driver for KubeVela VelaUX API server:\n - VelaUX APIServer TypeScript SDK\n - VelaUX APIServer Java SDK\n- Recommended Skills:\n - Golang\n - Kubernetes\n - Backend APIs Development\n - OpenAPI schema\n - CUE\n- Mentor(s):\n - Qiao Zhongpei (@chivalryq, chivalry.pp@gmail.com)\n - Yin Da (@somefive, Somefive@foxmail.com)\n- Upstream Issue (URL): https://github.com/kubevela/kubevela/issues/5428\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b97b2f2d-4dbd-45f5-9121-0e865aa6dfd9\n\n### Kyverno\n\n#### Kuttl tests for the Kyverno policy library\n\n- Description: Kyverno has the largest policy library of any policy tool for Kubernetes. Ensuring that policies work effectively across releases of both Kyverno and Kubernetes is important for users. Additionally, these tests can be leveraged in the CI processes ensuring that changes to the Kyverno codebase do not cause regressions which impact areas relevant to these policies. In this mentorship, you will learn how the `kuttl` tool works and write test cases using `kuttl` to cover all policies in the official Kyverno policy library.\n- Expected outcome: All policies have corresponding tests using the `kuttl` tool.\n- Recommended Skills: Kubernetes, Kyverno\n- Mentor(s): Chip Zoller @chipzoller (chipzoller AT gmail DOT com)\n- Upstream Issue (URL): https://github.com/kyverno/policies/issues/546\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/85ebe560-e9ee-42fe-9dff-f8dc6a11ef27\n\n#### Sigstore Cosign Updates\n\n- Description: Kyverno supports image signature and attestation verification using the Sigstore Cosign tooling. Re-implement the Kyverno Sigstore Cosign module to use OCI artifacts and references and remove dependencies to the Cosign CLI packages.\n- Expected outcome: Kyverno can use OCI artifacts to verify container images that are in Cosign format.\n- Recommended Skills: Golang, Kubernetes, Kyverno\n- Mentor(s):\n - Shuting Zhao @realshuting (shuting AT nirmata DOT com)\n - Vishal Choudhary @Vishal-Chdhry (contactvishaltech AT gmail DOT com)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/7087\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cabb007c-5669-4b16-8778-36d995a71591\n\n#### ValidatingAdmissionPolicy support, Phase 2\n\n- Description: Kyverno is working towards support of ValidatingAdmissionPolicy (CEL admission). Extend this support for other items such as CLI, reporting, and auto-generating ValidatingAdmissionPolicies from Kyverno policies.\n- Expected outcome: Extended support and integration with ValidatingAdmissionPolicies\n- Recommended Skills: Golang, Kubernetes, Kyverno\n- Mentor(s):\n - Jim Bugwadia @jimbugwadia (jim AT nirmata DOT com)\n - Mariam Fahmy @MariamFahmy98 (mariamfahmy66 AT gmail DOT com)\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/7088\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e4be265d-fa05-46b7-8fad-2585b6a76082\n\n#### Cleanup Policies, Phase 2\n\n- Description: Kyverno has a policy type called Cleanup Policies which allow removal of resources defined in a policy. In this second phase, we would like to extend this ability to cleanup resources based upon defining a label for even more fine-grained control.\n- Expected outcome: Extend Cleanup Policies feature by allowing per-resource removal based upon label assignment\n- Recommended Skills: Golang, Kubernetes, Kyverno\n- Mentor(s): Charles-Edouard Brétéché @eddycharly (charled.breteche AT gmail DOT com)\n- Upstream Issue (URL):\n - https://github.com/kyverno/kyverno/issues/5748\n - https://github.com/kyverno/KDP/blob/main/proposals/cleanup.md#proposal\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4689c5fa-165e-4015-ad21-951d9babcb7e\n\n### LitmusChaos\n\n#### Enhance/improve chaos center code base and redesign chaos workflow apis\n- Description: This project focuses on enhancing and improving the Chaos Center code base, specifically redesigning the Chaos Workflow APIs to provide an enhanced user experience. The main objectives include refining the functionality of the Chaos Workflow and Workflow Run APIs, modularizing the chaos-workflow package into separate packages, and addressing security vulnerabilities and golangci-lint issues in the Chaos Center backend components. The project aims to deliver a more robust and secure Chaos Center platform, offering improved usability and performance for users.\n- Expected outcome: The outcome of this project will be improved functionality, security, and usability of the chaos workflow APIs and chaos-center backend components through the implementation of new features, refactoring of existing code, and addressing of security vulnerabilities.\n- Recommended Skills:\n - Golang\n - Kubernetes\n - Backend APIs Development\n- Mentor(s):\n - Amit Kumar Das (@amityt, amit.das@harness.io)\n - Arkajyoti Mukherjee (@arkajyotiMukherjee, arkajyoti.mukherjee@harness.io)\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/3970\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/983193ea-9cca-405f-baa5-e6ade4df1ba2\n\n#### Enhance/Upgrade chaos operator and chaos exporter module\n\n- Description: LitmusChaos is an open source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way. This project idea involves upgrading the Chaos Operator and Chaos Exporter repositories by updating their dependencies, addressing security vulnerabilities, and adding new functionality. Specifically, the project aims to upgrade the operator-sdk and Prometheus exporter versions, add new Prometheus metrics to the Chaos Exporter, and fix security vulnerabilities pointed out by trivy and golangci-lint. Furthermore, the project seeks to add unit test cases to both repositories to ensure that their functionality is robust and reliable. Overall, this project aims to improve the stability, security, and functionality of the Chaos Operator and Chaos Exporter repositories, making them better suited for use in production environments.\n- Expected outcome: The outcome of this project will be improved stability, security, and functionality of the Chaos Operator and Chaos Exporter modules through the upgrade of dependencies, addition of new metrics, and implementation of unit tests.\n- Recommended Skills:\n - Golang\n - Kubernetes and k8s golang client\n - Prometheus\n- Mentor(s):\n - Shubham Chaudhary (@ispeakc0de, shubham.chaudhary@harness.io)\n - Vansh Bhatia (@vanshBhatia-A4k9, vansh.bhatia@harness.io)\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/3969\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bd6e875a-a64c-4405-af1c-677d8c45014b\n\n### Meshery\n\n#### Meshery UI Permissions Framework\n\n- Description: Meshery UI lacks a permissions framework. The existing internal implementation is simple, fragile and must be completely rewritten. The approach to implemention a permmissions framework includes using React.js and CASL.js. Meshery UI's approach needs to be extensible given that this framework will be an extension point for Remote Providers to supply their own permissions.\n- Expected outcome: Definition of permissions and their enforcement in Meshery with an aim for deep granularity and extensibility with each user interface input component carrying a unique permission key id. Each key is then put into a group of keys in a keychain, keychains assigned to user roles, in turn, roles assigned to users. With users having the ability to create own custom roles, the framework will be dynamic based on the associated server-side permissions for the currently auth’ed user.\n- Recommended Skills: React.js, CASL.js\n- Mentor(s): Lee Calcote @leecalcote (leecalcote@gmail.com), Abhishek Kumar @Abhishek-kumar09 (abhimait1909@gmail.com)\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/7436, https://github.com/meshery/meshery/issues/7382\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f4a9804f-2e46-42a4-b2ae-ad3ea7b29734\n\n#### OPA policy evaluation in-browser using WebAssembly and Rego\n\n- Description: Meshery's highly dynamic infrastructure configuration capabilities require real-time evaluation of complex policies. Policies of various types and with a high number of parameters need to be evaluted client-side. With policies expressed in Rego, the goal of this project is to incorporate use of the https://github.com/open-policy-agent/golang-opa-wasm project into Meshery UI.\n- Expected outcome: a powerful real-time multi-user collaboration experience.\n- Recommended Skills: Golang, Open Policy Agent, WASM\n- Mentor(s): Lee Calcote @leecalcote (leecalcote@gmail.com), Abhishek Kumar @Abhishek-kumar09 (abhimait1909@gmail.com)\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/7019\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/005db8db-7efe-4433-9605-91d14174c72c\n\n#### Adopt OCI as the packaging and distribution format for Meshery MeshModels\n\n- Description: Meshery MeshModels represent a schema-based description of cloud native infratructure. MeshModels need to be portable between Meshery deployments as well as easily versionable in external repositories.\n- Expected outcome:\n - Meshery clients (mesheryctl and Meshery UI) should be able to import/export MeshModels as OCI images.\n - Meshery clients (mesheryctl and Meshery UI) should be able to push/pull from OCI-compatible registries.\n - Stretch Goal: OCI image signing; Verify the authenticity of MeshModels using [cosign](https://github.com/sigstore/cosign).\n - Target registries: Meshery Catalog (https://meshery.io/catalog), Artifact Hub.\n- Recommended Skills: Reactjs, Golang, GraphQL\n- Mentor(s): Lee Calcote @leecalcote (leecalcote@gmail.com)\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/6447\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/26377c30-9ffd-41e3-bfea-839bf126f8f6\n\n#### OCI compatible Kubernetes ontology\n\n- Description: Network topologies and graph databases go hand-in-hand. The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph. Deliverables (among other items):\n\n- MeshModel capabilities browser\n- Import/export of MeshModel models and components as OCI images\n- augmentation of cuelang-based component generator\n\n- Recommended Skills: cuelang, golang, OCI\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com)\n- Issue: https://github.com/cncf/tag-network/issues/24\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bb8ddf84-31d7-4a89-9e4b-e6aa9601c0db\n\n### Notary\n\n#### Design and implement the new Notary website\n\n- Description: Design the new Notary website using the Figma tool and develop it based on the design layout. We redesigned the Notary website and finished the first phase development work with CNCF employee @thisisobate in [#PR 139](https://github.com/notaryproject/notaryproject.dev/pull/139). This project is to continue to design and implement the new Notary website and ensure deliver a developer-friendly experience.\n- Expected Outcome: \n - Design and implement the Adopters page\n - Redesign a Community page\n - Improve the landing page design; add an installation section with a terminal effect design\n - Support mobile responsive design\n - Add a pop-up window on the landing page to tell users how to join the community\n - Add Algolia search for the website\n - Design and implement a video page to list Youtube videos\n - Refine the content on the website\n - Add Broken link check to Netlify CI\n- Recommended Skills: Figma design, HTML, CSS, JavaScript, Hugo\n- Mentor(s): Feynman Zhou (@FeynmanZhou , feynmanzhou@microsoft.com)\n- Upstream Issue (URL): https://github.com/notaryproject/notaryproject.dev/issues/194\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/06774504-da91-469e-89f9-14fb18b6e0d8\n\n#### Develop content for Notary documentation and blogs\n\n- Description: Develop content for Notary documentation and write blog posts to educate users about the Notary use cases. Write user guides, contributing guides, and developer guides for every new Notary release and keep those content up-to-date.\n- Expected Outcome: \n - Write user guides with end-to-end scenarios based on given doc structure and requirement\n - Write contributing guides and developer guides, ensure new developers can easily build and start contributing to Notary subprojects \n - Write blog posts to educate users to use Notation with cloud-native ecosystem tools\n- Recommended Skills: OCI, Docker, Kubernetes, Notary, Git, Markdown, Technical writing experience\n- Mentor(s): Mentor(s): Yi Zha, @yizha1 (yizha1@microsoft.com)\n- Upstream Issue (URL): https://github.com/notaryproject/notaryproject.dev/issues/195\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/007ca3e9-c121-4428-8e63-57bc0418e98a\n\n### ORAS\n\n#### Design and implement Artifact Explore web portal\n\n- Description: This project goal is to improve the efficiency of the image developers and users through the artifact explorer tool with ORAS under the hood. This tool helps users to explore and search the content of an artifact or a registry. This doc is to gather ideas for early brainstorming purposes. For users, this tool reduces CLI learning cost and improve efficiency for developers. They don’t need to memorize and type the CLI commands to explore the content of an OCI artifact and registry.\n\n- Expected Outcome:\n - Provides a web portal to view the content of OCI artifacts from any public registries\n - Users can drill down into the detailed content of an image manifest or a layer\n - Users can view the artifact reference graph from the web portal\n - Users can view and download the supply chain artifacts like the signature, SBOM, attestation \n - Provides search capabilities to allow users to search container images or OCI artifacts on a central web portal. We can combine it with Artifact [Search API capabilities](https://docs.google.com/document/d/1rcQROZP31q7BOjoZ977Ok7pt28z_UXfW0vAK3xC0wdI/edit#heading=h.rx512bvufn5q).\n - Explore the image’s file system of layer (tentative)\n \n- Recommended Skills: Figma design, HTML, CSS, JavaScript, Hugo, Docker\n- Mentor(s): Feynman Zhou (@FeynmanZhou , feynmanzhou@microsoft.com), Billy Zha (@qweeah , jinzha1@microsoft.com), Asmit Malakannawar (@asmitbm , asmitbm2952002@gmail.com) \n- Upstream issue: https://github.com/oras-project/oras-www/issues/158\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9749bc0a-04c9-498d-a16c-e66c0930e819\n\n#### Refactor the ORAS documentation structure and write new user guides\n\n- Description: Refactor the ORAS documentation structure and write new user guides based on the latest version of ORAS. The detailed ORAS documentation structure and content should be refactored according to the proposal in the [upstream issue](https://github.com/oras-project/oras-www/issues/65). \n- Expected Outcome: Deliver a developer-friendly documentation structure for ORAS and write new user guides according to the proposed documentation structure. Publish all content at https://oras.land/\n- Recommended Skills: OCI, Docker, ORAS, Markdown\n- Mentor(s): Terry Howe (@TerryHowe , terrylhowe@gmail.com), Asmit Malakannawar (@asmitbm , asmitbm2952002@gmail.com), Feynman Zhou (@FeynmanZhou , feynmanzhou@microsoft.com)\n- Upstream issue: https://github.com/oras-project/oras-www/issues/65\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2314fcc1-f09b-4dab-90fb-d0ef092b6c0e\n\n### Service Mesh Performance\n\n#### Service Mesh Performance IDE Plugin\n\n- Description: The objective of this project is to develop IDE plugins that can enhance the developer experience while working with Service Mesh Performance Performance Profiles. The proposed plugins will leverage technologies such as golang and cuelang to provide features such as syntax highlighting, auto-completion, validation, and rendering previews for Service Mesh Performance profile and model definitions.\n- Expected outcome:\n- 1. Release VS Code Extension\n- 2. Syntax Highlighting and Auto-completion: The plugin can fetch SMP Model definitions such as cloud-native components and their relationships. This information can be used to provide syntax highlighting and auto-completion for these definitions in the JSON files, making it easier for developers to write error-free code.\n- 3. Validation and Reference: For Meshery MeshModel definitions such as cloud-native components and their relationships, the plugin can use the CUE language to provide validation for the CUE input and preview the rendering result. The plugin can also fetch the SMP Model schemas and display them in the IDE for reference.\n- Recommended Skills: Cuelang\n- Mentor(s): Lee Calcote @leecalcote (leecalcote@gmail.com), Xin Huang @gyohuangxin (xin1.huang@intel.com)\n- Upstream Issue (URL): https://github.com/service-mesh-performance/service-mesh-performance/issues/379\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4735d0fa-229f-43e7-9415-dff9220bf687\n\n### Strimzi\n\n#### Proof of Concept of an MQTT to Apache Kafka bridge for producing messages\n\n- Description: A really common use case we have been seeing is about enabling an IoT scenario with MQTT based devices and using an Apache Kafka cluster as the events and storage platform running on Kubernetes via Strimzi. In order to do that, there is the need to map the MQTT protocol to the custom Apache Kafka one and bridge from one to the other. This project idea is about designing such a mapping and developing a pure [Netty](https://github.com/netty/netty/tree/4.1/codec-mqtt/src/main/java/io/netty/handler/codec/mqtt) based MQTT server component (not a full MQTT broker) able to accept MQTT client connections and handling the corresponding communication based on the [MQTT 3.1.1 specification](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html). Finally, developing the Kafka producer part to get messages from MQTT clients and sending them to an Apache Kafka cluster.\n- Expected outcome: POC source code for an MQTT to Apache Kafka bridge\n- Recommended Skills:\n - Java\n - Apache Kafka (not mandatory but to be learned)\n - MQTT protocol (not mandatory but to be learned)\n- Mentor(s):\n - Paolo Patierno (@ppatierno, ppatiern@redhat.com)\n - Kyle Liberti (@kyguy, kliberti@redhat.com)\n- Upstream Issue (URL): https://github.com/strimzi/strimzi-kafka-operator/issues/8030\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8d301adf-94d8-4e5d-821d-f904ed15c3f9\n\n### Thanos\n\n#### Continuation of add query observability for the new engine\n\n- Description: We have added solid foundation for query observability in the new engine during the previous LFX mentorship term. Let's continue the awesome work by Pradyumna by implementing other features.\n- Expected outcome: other query observability visualizations are implemented; extra observability data has been added\n- Recommended skills: Golang, React\n- Mentor(s): @saswatamcode, Saswata Mukherjee saswataminsta@yahoo.com, @GiedriusS Giedrius Statkevičius giedriuswork@gmail.com\n- Difficulty: Medium\n- Upstream issue (URL): https://github.com/thanos-community/promql-engine/issues/106\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1953e512-fa8c-4f0e-9b24-0e6c81a7cd39\n\n### Vitess\n\n#### Rework the frontend UI of Vitess’ benchmarking tools\n\n- Description: Vitess uses a couple of tools to benchmark its codebase and to make sure that new code doesn’t introduce performance regressions. These tools are: arewefastyet and the VReplication Benchmarking Framework. We currently have an old frontend UI that serves arewefastyet. However, this UI is slow, not optimized and not easily extensible. It uses the built-in Golang template system to serve pages. We would like to create a common frontend UI that will be used by both benchmarking tools and that will replace the current arewefastyet’s UI. The mentee will have the responsibility of creating the UI using (most likely) React/Vite on Vercel. The frontend component will connect to our already-existing backend components: a MySQL database and arewefastyet’s REST API.\n- Expected Outcome: The expected outcome is to have a working frontend UI that integrates well with our different backends (databases and benchmarking tools’ APIs).\n- Recommended Skills: React, Vercel, Vite, REST API, (Optional writing APIs in Golang)\n\n- Mentor(s):\n - @fouioui Florent Poinsard frouioui@planetscale.com\n - Rohit Nayak @rohit-nayak-ps rohit@planetscale.com\n- Upstream Issue (URL): https://github.com/vitessio/arewefastyet/issues/328 \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8299d27a-9e36-4de6-abbc-c9282634ee03\n\n### WasmEdge\n\n#### Serialization Completion\n\n- Description: WasmEdge is a WebAssembly runtime in both interpreter and ahead-of-time mode. However, WasmEdge only supports the binary format for the input WebAssembly file. To help the text format WebAssembly loader feature in the future, the implementation of serializing a WebAssembly module is necessary. In this mentorship, we hope the mentee should complete the serialization functions already in [the `dev/serialize` branch](https://github.com/WasmEdge/WasmEdge/tree/dev/serialize) of the `WasmEdge` repo.\n- Expected outcome: Complete the serialization functions of WebAssembly modules, such as the element segment and data segment encoding. Complete the WebAssembly instructions encoding. Generate the unit test data and pass the unit tests. >80% of code coverage for serialization.\n- Recommended Skills: C/C++, WebAssembly\n- Mentor(s): Yi-Ying He @q82419 (yiying at secondstate dot io), Hung-Ying Tai @hydai (hydai at secondstate dot io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2262\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4a8a4f26-0ca9-4517-8cce-582c92092e33\n\n#### zlib Plugin Support\n\n- Description: The zlib is required for compiling and running many existing C / C++ / Rust apps in Wasm. Most noticeably, it is [needed in the Python port to Wasm](https://github.com/python/cpython/issues/93819). The VMWare Wasm Labs team is using a zlib port from [Singlestore](https://github.com/singlestore-labs/python-wasi) in [their Python Wasm runtime](https://wasmlabs.dev/articles/python-wasm32-wasi/). In WasmEdge, we could support the zlib host functions through our [plugin system](https://wasmedge.org/book/en/plugin.html). This way, any existing zlib apps can be compiled to Wasm and runs inside WasmEdge.\n- Expected outcome: Create a new [WasmEdge plugin](https://wasmedge.org/book/en/plugin.html) that exports all public functions in `zlib`. Implement SDK (in C/Rust) that uses the C ABI to generate corresponding headers for the above plugin. Generate the unit tests and pass the unit tests. >80% of code coverage for verification.\n- Recommended Skills: C/C++, Rust, WebAssembly\n- Mentor(s): Yi-Ying He @q82419 (yiying at secondstate dot io), Hung-Ying Tai @hydai (hydai at secondstate dot io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2244\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/74cecdf7-e886-4830-8bb0-7814f0d1aa2d\n\n#### Support Tensorflow and PyTorch in WasmEdge’s Python runtime\n\n- Description: In this project, you will incorporate WasmEdge’s NN (Neural Network) extensions into the Python interpreter. WasmEdge provides C and Rust APIs for guest applications to access host functions in the underlying Tensorflow and PyTorch libraries. You will make those functions accessible from the CPython-based interpreter as Python wrappers. This way, Python applications can do lightweight AI inference on the WasmEdge container.\n- Expected outcome:\n * Investigate and list all C-based host function APIs for Tensorflow and PyTorch inference in WasmEdge NN.\n * Create CPython wrappers for those host functions.\n * Create high-level Python wrapper functions that are ergonomic for Python developers.\n * Create CI and demo apps to validate the Python wrapper API.\n * Create detailed documentation and tutorials.\n- Recommended Skills: Proficient in C programming including creating dynamic libraries; Proficient in Python and machine learning programming. Basic understanding of WebAssembly and WasmEdge.\n- Mentor(s): Michael Yuan @juntao (michael at secondstate dot io), Asen Alexandrov @adalexandrov (alexandrov at vmware dot com)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2471\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/884ff3f2-3ea3-4010-8928-ca27bbae219a\n\n#### A stream log processing framework for WasmEdge\n\n- Description: In this project, we aim to build a Rust-based log processing framework. Applications built on this framework will be compiled into WebAssembly and run in WasmEdge containers side by side with Linux containers and apps. The WasmEdge app collects logs from other containerized apps and then sends them to a streaming database or processing pipeline.\n- Expected outcome:\n * Create a Rust framework with 3 traits similar to the [`Transformer`](https://github.com/second-state/MEGA/blob/main/mega_etl/src/lib.rs#L99) trait in the [MEGA framework](https://github.com/second-state/MEGA).\n * The `Collector` trait abstracts operations needed for a log collector.\n * The `Transformer` trait abstracts the transformation algorithms that can be applied to the logs.\n * The `Destination` trait abstracts operations needed to send transformed to a streaming data pipeline or database.\n * Implement at least two `Collector`s. One for MySQL database binlog and the other for a generic log file in a Linux container in the same Kubernetes pod.\n * Implement at least two `Transformer` algorithms supported by [FileBeat](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-overview.html).\n * Implement at least three `Destination`s. One for a Kafka queue, one for a Redis database, and the other for ElasticSearch.\n * Provide CI and demo test cases.\n * Provide documentation and tutorials.\n- Recommended Skills: Proficient in the Rust programming language; Familiarity with MySQL, Kafka, ElasticSearch, and FileBeat; Familiarity with Kubernetes and related container management tools; Basic understanding of WebAssembly and WasmEdge\n- Mentor(s): Michael Yuan @juntao (michael at secondstate dot io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2470\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/55c226fe-d119-4b2c-aba0-e7415867f6e5\n\n" }, { "path": "programs/lfx-mentorship/2023/02-Jun-Aug/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s): Mentor Name (@mentor_github, mentor@email.addy)\n- Upstream Issue:\n\n```\n\n---\n\n## Proposed Project ideas\n\n---\n" }, { "path": "programs/lfx-mentorship/2023/03-Sep-Nov/README.md", "content": "# Term 03 - 2023 September - November\n\nStatus: Completed\n\nMentorship duration - three months (12 weeks - full-time schedule)\n\n### Timeline\n\n| activity | date |\n| --- | --- | \n| project proposals | Thur July 27, 5:00 PM PDT |\n| mentee applications open | Wed Aug 2 - Tues 15, 5:00 PM PDT |\n| application review/admission decisions | Wed Aug 16 - Tues Aug 29, 5:00 PM PDT |\n| Mentorship program begins with the initial work assignments | Mon Sept 4 (Week 1) | \n| Midterm mentee evaluations and first stipend payments | Wed Oct 11 (Week 6) |\n| Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals | Wed Nov 22, 5:00 PM PST (Week 12) |\n| Last day of term | Thur Nov 30 |\n\n### Project Instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2023/03-Sep-Nov/project_ideas.md, by Thursday, July 27, 2023.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n## Table of Contents\n\n- [Carvel](#carvel)\n * [kctrl to support exporting package repository as tar](#kctrl-to-support-exporting-package-repository-as-tar)\n- [CRI-O](#cri-o)\n * [Add additional log drivers to conmon-rs](#add-additional-log-drivers-to-conmon-rs)\n * [CRI stats KEP](#cri-stats-kep)\n- [Istio](#istio)\n * [Implement performance testing](#implement-performance-testing)\n * [Documentation for Ambient Mesh](#documentation-for-ambient-mesh)\n- [Jaeger](#jaeger)\n * [Upgrade Jaeger UI to the latest version of React.js](#upgrade-jaeger-ui-to-the-latest-version-of-reactjs)\n * [Combine three distinct graph views in Jaeger UI into one](#combine-three-distinct-graph-views-in-jaeger-ui-into-one)\n * [Build official support in Jaeger for Elasticsearch 8](#build-official-support-in-jaeger-for-elasticsearch-8)\n- [Karmada](#karmada)\n * [Karmada supports promote dependent resources automatically](#karmada-supports-promote-dependent-resources-automatically)\n * [Add Karmada API documentation on the website](#add-karmada-api-documentation-on-the-website)\n- [Konveyor](#konveyor)\n * [Extend use-case of detecting deprecated Kubernetes API usage](#extend-use-case-of-detecting-deprecated-kubernetes-api-usage)\n * [Move2Kube: Compile Move2Kube to WASM/WASI and run it in the browser](#move2kube--compile-move2kube-to-wasm-wasi-and-run-it-in-the-browser)\n * [Move2Kube: WASM Transformers](#move2kube--wasm-transformers)\n * [Move2Kube: Advanced Resources support - ArgoCD, Tekton, Stateful Set, etc.](#move2kube--advanced-resources-support---argocd--tekton--stateful-set--etc)\n- [KubeArmor](#kubearmor)\n * [Implement DNS visibility with KubeArmor II](#implement-dns-visibility-with-kubearmor-ii)\n * [Extend Support Matrix and Document Usecases](#extend-support-matrix-and-document-usecases)\n- [KubeEdge](#kubeedge)\n * [Add case study center in website](#add-case-study-center-in-website)\n * [Support latest version in keink and run demo on keink](#support-latest-version-in-keink-and-run-demo-on-keink)\n * [Support latest version installation demo in killercoda](#support-latest-version-installation-demo-in-killercoda)\n- [Kubernetes](#kubernetes)\n * [Build a Go library and CLI for interacting with OpenBuildService](#build-a-go-library-and-cli-for-interacting-with-openbuildservice)\n- [Kubescape](#kubescape)\n * [Build an admission controller for Kubescape](#build-an-admission-controller-for-kubescape)\n * [Upgrade the documentation publishing pipeline for Kubescape controls](#upgrade-the-documentation-publishing-pipeline-for-kubescape-controls)\n- [KubeVela](#kubevela)\n * [Support auto generation of multiple languages SDK from CUE II](#support-auto-generation-of-multiple-languages-sdk-from-cue-ii)\n- [Kyverno](#kyverno)\n * [Pod Security Admission Integrations II](#pod-security-admission-integrations-ii)\n * [Policy Exceptions 2.0](#policy-exceptions-20)\n * [Kyverno Kuttl Enhancements](#kyverno-kuttl-enhancements)\n- [LitmusChaos](#litmuschaos)\n * [Improve litmusctl UX and codebase and add new functionalities to litmusctl](#improve-litmusctl-ux-and-codebase-and-add-new-functionalities-to-litmusctl)\n * [Improve Chaoscenter Web and Authentication Server: Add Unit Test Cases, Enhance GQL APIs, Update API Documentation](#improve-chaoscenter-web-and-authentication-server--add-unit-test-cases--enhance-gql-apis--update-api-documentation)\n- [Meshery](#meshery)\n * [Overhaul UX Design System](#overhaul-ux-design-system)\n * [Package Meshery Catalog Artifacts as OCI Images](#package-meshery-catalog-artifact-as-oci-images)\n * [WASM-based OPA policy evaluation with Rego](#wasm-based-opa-policy-evaluation-with-rego)\n- [Thanos](#thanos)\n * [Implement fan-out query observability in Thanos](#implement-fan-out-query-observability-in-thanos)\n * [Release the distributed query engine in Thanos](#release-the-distributed-query-engine-in-thanos)\n- [Vitess](#vitess)\n * [Continue the migration to React and enhance existing frontend UI](#continue-the-migration-to-react-and-enhance-existing-frontend-ui)\n- [OpenKruise](#openkruise)\n * [Integrate Openkruise workload with ArgoCD and Helm](#integrate-openkruise-workload-with-argocd-and-helm)\n- [Volcano](#volcano)\n * [Support NPU accelerator scheduling in Volcano](#support-npu-accelerator-scheduling-in-volcano)\n * [Build a new elastic resource quota mechinism in Volcano](#build-a-new-elastic-resource-quota-mechinism-in-volcano)\n * [Add user guidance for jobflow](#add-user-guidance-for-jobflow)\n * [Fix bugs for jobflow to enhance its stability](#fix-bugs-for-jobflow-to-enhance-its-stability)\n- [WasmEdge](#wasmedge)\n * [Add matrix operations for OpenCVMini-Wasm-Plugin](#add-matrix-operations-for-opencvmini-wasm-plugin)\n * [Support AOT mode in proxy-wasm](#support-aot-mode-in-proxy-wasm)\n * [Create a Rust crate for YOLO model](#create-a-rust-crate-for-yolo-model)\n * [Create a ffmpeg plugin](#create-a-ffmpeg-plugin)\n\n---\n\n## Accepted projects\n\n### Carvel\n\n#### kctrl to support exporting package repository as tar\n\n- Description: While generating Package Repository kctrl to create the tar version of the Package Repository instead of pushing the OCI Image to a registry. \n- Expected Outcome: \n - Proposal containing design discussions and options considered.\n - Function Implementation to support a flag which allows to export the package repo to tar\n - Documentation changes as required \n- Recommended Skills: Golang\n- Mentor(s): \n - Soumik Majumder (@100mik, soumik712@gmail.com)\n - Renu Yarday (@renuy, ryarday@vmware.com)\n- Upstream Issue (URL): https://github.com/carvel-dev/kapp-controller/issues/1277\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/91398424-f095-4b85-bb0f-e7c56e777ea0\n\n### CRI-O\n\n#### Add additional log drivers to conmon-rs\n\n- Description: conmon-rs is a container monitor written in Rust, used by CRI-O to monitor a container's lifecycle. Part of its responsibilities is log forwarding--taking the output of the container and writing that output to various places. Currently, conmon-rs supports one format: the one required by the Kubernetes CRI. The goal of this proposal is to add new log formats from the list of standardized ones, like JSON, Splunk, Journald.\n- Expected outcome: A JSON log driver and Journald log driver are added to conmon-rs. A stretch goal of adding a Splunk log driver is also within scope.\n- Recommended Skills: Rust, familiarity with containers\n- Mentor(s):\n - Peter Hunt, haircommander, pehunt@redhat.com\n - Sascha Grunert, saschagrunert, mail@saschagrunert.de\n- Upstream Issue (URL): https://github.com/containers/conmon-rs/issues/1126\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/99274b1a-694b-4af5-b7ca-39311f38a646\n\n#### CRI stats KEP\n\n- Description: [CRI stats KEP](https://github.com/kubernetes/enhancements/issues/2371) is an effort to take the container stats and metrics collection from cAdvisor and move it to the CRI implementations. CRI-O will soon have support for stats and metrics collected through CRI, but work needs to be done to verify and validate these fields, and make sure their collection is performant as possible.\n- Expected outcome: A test suite verifying the correctness of CRI-O's stats and metrics collection, as well as data verifying performance regressions are minimal at worst.\n- Recommended Skills: Golang, familiarity with containers\n- Mentor(s):\n - Peter Hunt, haircommander, pehunt@redhat.com\n - Sohan Kunkerkar, sohankunkerkar, skunkerk@redhat.com\n- Upstream Issue (URL): https://github.com/cri-o/cri-o/issues/7175\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cb189d71-3943-450a-9d5f-d71bd66d73c9\n\n### Istio\n\n#### Implement performance testing\n\n- Description: Up until version 1.16, [Istio](https://istio.io/) published [performance and scale testing results](https://istio.io/v1.16/docs/ops/deployment/performance-and-scalability/). These should be returned to service, and updated to support ambient mesh. Third-party benchmarking tools should be updated to support testing the performance of ambient mesh.\n- Expected Outcome: Performance testing pages are returned to istio.io, and include both sidecar and ambient mesh results.\n- Recommended Skills:\n - Python\n - Networking\n- Mentors:\n - Lin Sun (@linsun, lin.sun@solo.io)\n - Andrea Y Ma\t(@andream12345,\tayma@us.ibm.com)\n- Upstream Issue: https://github.com/istio/istio/issues/44009\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bbebd511-1a3e-4c4f-b106-2f09690825c5\n\n#### Documentation for Ambient Mesh\n\n- Description: [Istio](https://istio.io/) is working on [a new operating mode called ambient mesh](https://istio.io/latest/blog/2022/introducing-ambient-mesh/). As this moves from experimental to the recommended method of operating a service mesh, we will need to revise our documentation to discuss the new model, explain the tradeoffs, and tell users how to choose.\n- Expected Outcome: Revisions to Istio's documentation to reflect the availability of ambient mesh. These will be maintained in a parallel branch of istio.io that can be pulled from when Ambient is in Beta or GA.\n- Recommended Skills: \n - Technical writing\n - Developer advocacy\n- Mentors:\n - Lin Sun (lin.sun@solo.io)\n- Upstream Issue: https://github.com/istio/istio.io/issues/13481\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/89ee4357-dd58-4e15-a601-c411742a587c\n\n### Jaeger\n\n#### Upgrade Jaeger UI to the latest version of React.js\n\n- Description: Jaeger UI is built on React. While we are seemingly already on v18.x of React, the upgrade was not done across the board and some other dependencies are still lagging behind, e.g. `\"@types/react\": \"16.8.7\"`. It's also blocking upgrades of other dependencies. This project is likely to involve a substantial amount of code contribution, as certain upgrade require fixing the code to use the new APIs, and sometimes we may run into dependencies that are EOL and need to be replaced altogether.\n- Expected Outcome: Ideal outcome is to have _all_ dependencies upgraded to the latest versions (with the help of @dependabot) and fix all deprecation warnings during the build. But incremental progress towards that goal is also acceptable.\n- Recommended Skills: Javascript, Typescript, NPM, Yarn, Vite.js\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n- Upstream Issue: https://github.com/jaegertracing/jaeger-ui/issues/998\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/83cc55fe-b97a-4195-8dd2-cc9aed7e509c\n\n#### Combine three distinct graph views in Jaeger UI into one\n\n- Description: Jaeger UI provides several views to visualize service dependencies, also known as service topology maps. However, these views are using different drawing libraries, resulting in very different look & feel and inconsistent experience. One of the views is using a `plexus` library that was purposely built as part of Jaeger UI that provides rich capabilities for displaying graphs, which may be a good candidate for the other views.\n- Expected Outcomes:\n - Remove the dependency on react-vis library (https://github.com/jaegertracing/jaeger-ui/issues/1597).\n - Use a single library for graph visualizations.\n - Provide consistent look and feel of different graph views.\n- Recommended Skills: Javascript, Typescript, NPM, Yarn, Vite.js, web worker\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Yash Sharma (yashrsharma44@meta.com)\n- Upstream Issue: https://github.com/jaegertracing/jaeger-ui/issues/1466\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1e67c90b-de3e-4c4e-a2be-a5583a948864\n\n#### Build official support in Jaeger for Elasticsearch 8\n\n- Description: Jaeger has always supported Elasticsearch (ES) as an official backend. Unfortunately, the Go driver we are using, `olivere/elastic`, does not support ESv8 and not planning to release any new versions. Despite the licensing changes, Elasticsearch remains a popular choice and v8 support question often comes up. In this project we want to add official support for ESv8. However, we also want to take this opportunity to do a better alignment with the OpenTelemetry Collector, which already has an [ESv8 exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/elasticsearchexporter), perhaps we can use it directly and minimize the amount of code.\n- Expected Outcomes:\n - Use OTEL ESv8 exporter from Jaeger, if possible, otherwise build internal implementation\n - Stretch goal: use ES data as the source for Jaeger SPM views\n- Recommended Skills: Go, Elasticsearch\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/4600\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/37cf2714-668d-4014-ac44-953f70f9dc8e\n\n### Karmada\n\n#### Karmada supports promote dependent resources automatically\n\n- Description: Provide an automatic promotion mechanism for dependent resources in karmadactl. When promoting a resource, all the resources that it depends on will be automatically promoted as well. For example, promoting the Secret that is dependent by a Deployment.\n- Expected Outcome:\n - Technical Documentation: design description and analysis\n - Function Implementation: support promote the dependent resources automatically\n - Test coverage: add test cases to cover new functions\n- Recommended Skills:\n - Go\n - Cloud Native\n- Mentor(s):\n - Wei Jiang (@jwcesign, jiangwei115@huawei.com)\n - Hongcai Ren(@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/3842\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/60b43efd-79e0-457e-989f-d4d59d55d8a6\n\n#### Add Karmada API documentation on the website\n\n- Description: Add the Karmada API documentation on the [website](https://github.com/karmada-io/website),and complete the script for automatic document generation.\n- Expected Outcome:\n - Technical Documentation: design description and analysis\n - Script Complete: automatic document generation\n - Maintaining Documentation: add maintaining document on the website\n- Recommended Skills:\n - Go\n - Cloud Native\n- Mentor(s):\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n - Hongcai Ren(@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/3843\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/54940f04-54b8-41ee-94bf-153f977b31e7\n\n### Konveyor\n\n#### Extend use-case of detecting deprecated Kubernetes API usage\n\n- Description: [Konveyor](https://www.konveyor.io/) provides a [unified experience](https://github.com/konveyor/enhancements/tree/master/enhancements/unified_experience) of tools to help organizations modernize their applications at scale to Kubernetes and cloud-native technologies. We are looking for help on extending a use-case of detecting usage of [deprecated and removed Kubernetes APIs](https://kubernetes.io/docs/reference/using-api/deprecation-guide/) in applications. This work will involve determining what API resources have been deprecated or removed in each version of Kubernetes and then building [Analyzer Rules](https://github.com/konveyor/analyzer-lsp/blob/main/docs/rules.md) to be contributed to our [Rulesets repository](https://github.com/konveyor/rulesets), curation or development of sample applications in Golang, Java, and YAML to aid test scenarios, and documentation to help show a guided walkthrough of this capability. You can see the beginning of this use-case being addressed with a [sample rule](https://github.com/konveyor/analyzer-lsp/blob/main/rule-example.yaml#L42-L45) in this [demo of analyzer-lsp](https://github.com/konveyor/analyzer-lsp/tree/main#quick-demo). The development environment is based on Golang and Kubernetes. A minikube instance will work well for local development on Linux or Mac systems.\n- Expected Outcome:\n - [Rules](https://github.com/konveyor/analyzer-lsp/blob/main/docs/rules.md) contributed to [konveyor/rulesets](https://github.com/konveyor/rulesets) to detect usage of deprecated or removed Kubernetes APIs. Coverage for YAML, Golang, and Java source code, addition of this scenario into the project's automated test suite, and documentation of a guided scenario showing usage of these rules via a curated set of application source code examples.\n- Recommended Skills:\n - Go\n - Basic understanding of interaction with Kubernetes via kubectl\n - Basic software development skills (command line, git)\n- Mentor(s):\n - Emily McMullan (@eemcmullan, eemcmullan92@gmail.com)\n - Jonah Sussman (@JonahSussman, jsussman@redhat.com)\n - John Matthews (@jwmatthews, jwmatthews@gmail.com)\n- Upstream Issue:\n - https://github.com/konveyor/operator/issues/251\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/989d0ad3-976a-4514-b2fc-34e9e6081567\n\n#### Move2Kube: Compile Move2Kube to WASM/WASI and run it in the browser\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has inbuilt support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. We want to compile targetting WASM/WASI and run the resulting WASM module in the browser. This will help up showcase Move2Kube for demos and allow users to quickly try out Move2Kube without having to install it or any of its dependencies.\n- Expected Outcome:\n - Run Move2Kube CLI in the browser using WebAssembly.\n- Recommended Skills:\n - Golang\n - WASM\n- Mentor(s):\n - Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com)\n - Mehant Kammakomati (@kmehant, mehant.kammakomati2@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/1062\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c2b5f721-2666-4d9e-85d6-7bedae27e144\n\n#### Move2Kube: WASM Transformers\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has inbuilt support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. Move2Kube has a very plugin friendly architecture, users can write custom logic in the form of \"Transformers\" that Move2Kube can integrate seamlessly into its transformation pipeline. So far we have support for both Starlark and container image based transformers. We would like to support writing transformers as WASM modules that Move2Kube can run. WASM provides extensive sandboxing for security, it allows writing transformers in different language stacks like Rust, C/C++, etc. other than Golang, and WASM is just as lightweight and fast as Starlark.\n- Expected Outcome:\n - Implement a feature in Move2Kube CLI to allow running WASM modules as custom transformers.\n- Recommended Skills:\n - Golang\n - WASM\n- Mentor(s):\n - Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com)\n - Mehant Kammakomati (@kmehant, mehant.kammakomati2@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/1061\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ec286a9e-e48d-4c83-a991-9c79a4ec213a\n\n#### Move2Kube: Advanced Resources support - ArgoCD, Tekton, Stateful Set, etc.\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has inbuilt support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. Currently we have rudimentary support for resources such as ArgoCD, Tekton, etc. We need to enhance this to make it useful. Example: https://github.com/konveyor/move2kube/issues/930\n- Expected Outcome:\n - More comprehensive support for advanced K8s resources so as to support real world use cases.\n- Recommended Skills:\n - Golang\n - K8s\n - ArgoCD\n - Tekton\n- Mentor(s):\n - Akash Nayak (@Akash-Nayak, akash.nayak1@ibm.com)\n - Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/1063\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b9aad4e2-d9c7-405e-8482-5aced0a4ecdb\n\n### KubeArmor\n\n#### Implement DNS visibility with KubeArmor II\n\n- Description: The project aims to provide better visibility into the domains accessed from pods, with a focus on identifying and containing attacks that use techniques like Domain Generation Algorithms (DGA) to connect to remote command and control (C&C) servers. By gathering information on which domains are being accessed and applying network rules to allow only specific domains, the project aims to empower security operations (secops) teams to better prevent and respond to such attacks.\n- Expected Outcome: \n - KubeArmor to emit telemetry events for any DNS lookups from any pods.\n - Ability to see egress DNS lookups done from any pods using karmor summary.\n - Documentation\n- Recommended Skills: Go, K8s, eBPF. familiarity with network security and a basic understanding of KubeArmor is a plus.\n- Mentors:\n - Anurag Kumar (@kranurag7, contact.anurag7@gmail.com)\n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Ankur Kothiwal (@Ankurk99, ankur.kothiwal99@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1219\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/53d7c0da-f066-486a-a9cb-c2da55e42375\n\n#### Extend Support Matrix and Document Usecases\n\n- Description: The project aims to extend KubeArmor support and document how KubeArmor is relevant for securing Kubernetes on Edge in addition to generic Kubernetes based Application deployments\n- Expected Outcome: \n - Try KubeArmor on Different Kubernetes Platforms\n - Microshift, k0s\n - Make fixes to deployments to make them work if needed\n - Document Usecases on these platforms\n - Document Usecases at a broader level for EDGE and Container Security\n - Produce Blogs about extended support and additional usecases\n- Recommended Skills: K8s, Basic understanding of KubeArmor, Content Writing is a plus.\n- Mentors:\n - Anurag Kumar (@kranurag7, contact.anurag7@gmail.com)\n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Ankur Kothiwal (@Ankurk99, ankur.kothiwal99@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1334\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/eba8fbf7-848b-4d69-8b0e-b6852acc7755\n\n### KubeEdge\n\n#### Add case study center in website\n\n- Description: Now we have had many user cases in the community. However, the KubeEdge website does not have a page to display user cases. Many users lack ways to understand and learn KubeEdge implementation cases., we hope to build a case center to display them, so that more users can consult and learn. \n- Expected Outcome: Add user case study center to display all KubeEdge user cases. Users can upload their own cases. Also users and learners can also manage and view cases by industry tag.\n- Recommended Skills: JS , HTML, KubeEdge\n- Mentor(s): \n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n - Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/website/issues/347\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/12dda5ae-a123-4e2a-985c-13d33f8a25f0\n\n#### Support latest version in keink and run demo on keink\n\n- Description: keink (KubeEdge IN kind) is a project for running local KubeEdge clusters using Docker container \"nodes\", so developers can install a multi-node\n edge cluster in one node. Now we need to support the latest version installation in keink. \n- Expected Outcome: keink can install the latest version of KubeEdge and developers can quickly use keink to run kubeedge, and then develop applications on KubeEdge.\n- Recommended Skills: Kubernetes, KubeEdge, Golang\n- Mentor(s):\n - Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/keink/issues/8\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8c7c6769-edea-4ecd-8fb4-53aa1dacb070\n\n#### Support latest version installation demo in killercoda\n\n- Description: We have created a tutorial in the interactive learning platform killercoda for KubeEdge deployment. This can give a hands-on experience of KubeEdge deployment. Now we need to support the latest version of KubeEdge and integrate example for developers.\n- Expected Outcome: It can install the latest version of KubeEdge example, developers can experience these cloud native edge-computing demos online.\n- Recommended Skills: Kubernetes, KubeEdge, Golang\n- Mentor(s):\n - Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/killercoda-scenarios/issues/8\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/36bfe273-9059-47e0-88f7-afb38b2d9ebb\n\n### Kubernetes\n\n#### Build a Go library and CLI for interacting with OpenBuildService\n\n- Description: Kubernetes is set to start using [OpenBuildService](http://openbuildservice.org) as a platform for building, publishing, and hosting Kubernetes system (Debian and RPM) packages. The current integration with the OpenBuildService platform assumes a lot of manual tasks and depending on `osc` command-line tool written in Python. At SIG Release, we're striving to automate as many tasks as possible. We want to build a library and CLI written in Go for interacting with the OpenBuildService APIs and platform that can be integrated with our existing [release tooling (`krel`)](http://github.com/kubernetes/release).\n- Expected Outcome: Library and CLI tool for interacting with OpenBuildService platform via their publicly available APIs. Both library and CLI tool should be properly tested via unit, integration, and end-to-end tests, and properly documented.\n- Recommended Skills: Golang, working with APIs\n- Mentor(s):\n - Carlos Panato (@cpanato, ctadeu@gmail.com)\n - Marko Mudrinić (@xmudrii, mudrinic.mare@gmail.com)\n- Upstream Issue: https://github.com/kubernetes/sig-release/issues/2295\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/47f53d22-ff5c-4479-b701-3ca3dbc7df0a\n\n### Kubescape\n\n#### Build an admission controller for Kubescape\n\n- Description: [Kubescape](http://kubescape.io/) is a utility that can scan a Kubernetes cluster and report on its security posture. It can also scan individual workloads (e.g. YAML files) before they are applied. By creating a Kubescape admission controller, we will be able to combine the two, denying workloads into a cluster where it would reduce the security posture.\n- Expected Outcome: The Kubescape application will be extended and packaged to operate as an admission controller inside a cluster. The controller will be well documented, safe to install, and instrumented with logging and telemetry data to be able to diagnose problems.\n- Recommended Skills:\n - Go\n - Experience using Kubernetes and understanding of its concepts\n- Mentors:\n - Craig Box (@craigbox, craigb AT armosec.io)\n - Ben Hirschberg (@slashben, ben AT armosec.io)\n- Upstream Issue: https://github.com/kubescape/kubescape/issues/1301\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/271852c6-3348-4ec7-bf09-035913b1c86e\n\n#### Upgrade the documentation publishing pipeline for Kubescape controls\n\n- Description: [Kubescape's control library](https://github.com/kubescape/regolibrary) includes more than 200 controls, tests that codify Kubernetes best practices derived from the most prevalent security frameworks in the industry. Metadata in the controls is used to generate documentation pages in the ARMO website. This project will update this automation to make this control documentation available on kubescape.io.\n- Expected Outcome: A full set of documentation for Kubescape controls on kubescape.io. Stretch goals include better README-style documentation inside the repository, and documentation pages on how the controls, frameworks and tests relate.\n- Recommended Skills: \n - Python\n - Technical writing\n - Rego\n- Mentors:\n - Ben Hirschberg (@slashben, ben AT armosec.io)\n - Craig Box (@craigbox, craigb AT armosec.io)\n- Upstream Issue: https://github.com/kubescape/kubescape/issues/1302\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ccd3fc5f-a0a9-441f-bd4c-5caae8ab6509\n\n### KubeVela\n\n#### Support auto generation of multiple languages SDK from CUE II\n\n- Description: In KubeVela, we use [CUElang](https://cuelang.org/) 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.\n- Expected Outcome: Support auto generation of multiple languages SDK from CUE, including Java, Typescript ,Python. This capability should be part of vela CLI command.\n- Recommended Skills: Java, Typescript ,Python, Kubernetes, CUE\n- Mentor(s): \n - Qiao Zhongpei (@chivalryq, chivalry.pp@gmail.com) \n - Wang YiKe (@wangyikewxgm, wangyike.wyk@gmail.com)\n- Upstream Issue: [kubevela/kubevela#5365](https://github.com/kubevela/kubevela/issues/5365)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e8c0d16a-c263-4a6c-bce7-0b896c925a52\n\n### Kyverno\n\n#### Pod Security Admission Integrations II\n\n- Description: Integrate Kubernetes Pod Security with Kyverno - Part Ⅲ\n- Expected Outcome: Kyverno's podSecurity \"subrule\" has the ability to exclude based on specific field paths and not just the control level.\n- Recommended Skills: Golang, Kubernetes, Pod Security\n- Mentor(s):\n - Shuting Zhao (@realshuting, shuting@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/6144\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a7f754b4-5c8c-48a3-8f5f-b3ff6307b0f4\n\n#### Policy Exceptions 2.0\n\n- Description: Enhancements for Kyverno Policy Exceptions including support for images and conditions.\n- Expected Outcome: A future version of Kyverno has enhanced support for its Policy Exception resource.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s):\n - Jim Bugwadia (@jimbugwadia, jim@nirmata.com)\n - Mariam Fahmy (@MariamFahmy98, mariam.fahmy@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/7907\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7ffb0f63-e1e4-477b-ab0c-a69cb681f112\n\n#### Kyverno Kuttl Enhancements\n\n- Description: Add new features to the kuttl application used by the Kyverno project to aid in its end-to-end testing process.\n- Expected Outcome: Kyverno's fork of kuttl has these enhancements allowing more and better test cases to be written.\n- Recommended Skills: Golang\n- Mentor(s):\n - Charles-Edouard Brétéché (@eddycharly, charles.edouard@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kuttl/issues/18\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/919e8b57-8fc1-4f61-8bc8-3c8b06dd5e7a\n\n### LitmusChaos\n\n#### Improve litmusctl UX and codebase and add new functionalities to litmusctl\n- Description: [LitmusChaos](https://litmuschaos.io) is an open-source chaos engineering platform for Kubernetes, enabling users to test and improve the resilience of their cloud-native applications. The project focuses on improving litmusctl by enhancing its interactive mode with promptui, and refactoring code to Go interfaces for better unit testing and code quality. Additionally, it aims to replace kubectl with client-go for more efficient Kubernetes operations, resulting in a more user-friendly and reliable command-line tool for chaos engineering and workload management.\n- Expected outcome: The expected outcome of the project includes an improved litmusctl tool with a user-friendly promptui-based interactive mode, enhanced code quality through Go interfaces, and a robust test suite. The migration to client-go for Kubernetes operations will ensure better performance and reduced external dependencies, providing users with a reliable and efficient command-line utility for chaos engineering and Kubernetes management tasks.\n- Recommended Skills:\n - Golang\n - Kubernetes (Basic understanding of interaction with Kubernetes via kubectl)\n- Mentor(s):\n - Saranya Jena (@Saranya-jena, saranya.jena@harness.io)\n - Sayan Mondal (@S-ayanide, sayan.mondal@harness.io)\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/4101\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fde90e7f-0410-4b84-ad9c-99f7139267ed\n\n#### Improve Chaoscenter Web and Authentication Server: Add Unit Test Cases, Enhance GQL APIs, Update API Documentation\n\n- Description: [LitmusChaos](https://litmuschaos.io) is an open-source chaos engineering platform for Kubernetes, enabling users to test and improve the resilience of their cloud-native applications. The task is add unit tests for Chaoscenter Web and test cases for the Authentication Server. The GraphQL API documentation will be updated with the latest APIs, while the GraphQL server's APIs and handler functions will be optimized to reduce code duplicacy. Additionally, comprehensive documentation and video tutorials will be created for local development setup, promoting easier onboarding and collaboration.\n- Expected outcome: The expected outcome of this issue is an improved Chaoscenter Web and Authentication Server with added unit tests, updated GraphQL API documentation, and optimized APIs and handler functions. The enhancements will result in a more reliable, efficient, and user-friendly chaos engineering platform, promoting better collaboration within the community.\n- Recommended Skills:\n - Golang\n - TypeScript\n- Mentor(s):\n - Sarthak Jain (@SarthakJain26, sarthak.jain@harness.io)\n - Neelanjan Manna (@neelanjan00, neelanjan.manna@harness.io)\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/4102\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/237b7300-d749-4f14-bd4c-9375e5ec39b6\n\n### Meshery\n\n#### Overhaul UX Design System\n\n- Description: [Meshery](https://meshery.io) is a self-service engineering platform, Meshery enables collaborative design and operation of cloud native infrastructure. The Meshery Design System is a flexible, scalable design system built on the foundations of accessibility, beautiful design, and consistent user experience.\n- Expected outcome: Rebuild the Meshery Design System so that it provides the open source building blocks to design and implement consistent, accessible, and delightful product experiences.\n- Recommended Skills:\n - Figma\n - User-centered Design\n - Visual Design\n- Mentor(s):\n - Lee Calcote (@leecalcote, leecalcote@gmail.com)\n - Ritik Saxena (@ritiksaxena124, ritiksaxena124@gmail.com)\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/8347\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a61f6cdb-98b4-43c9-8ca2-ea9bb5d5c470\n\n#### Package Meshery Catalog Artifacts as OCI Images\n\n- Description: [Meshery](https://meshery.io) is a self-service engineering platform, Meshery enables collaborative design and operation of cloud native infrastructure. [Meshery Catalog](https://meshery.io/catalog) content represents a schema-based description of cloud native infrastructure. Catalog content need to be portable between Meshery deployments as well as easily version-able in external repositories.\n- Expected outcome: Rebuild the Meshery Design System so that it provides the open source building blocks to design and implement consistent, accessible, and delightful product experiences.\n- Recommended Skills:\n - Golang, GraphQL, Reactjs\n - OCI Registries\n- Mentor(s):\n - Lee Calcote (@leecalcote, leecalcote@gmail.com)\n - Uzair Shaikh (@MUzairS15, muzair.shaikh810@gmail.com)\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/8348\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/aff716df-c257-4ead-8b48-39a3f9272b7f\n\n#### WASM-based OPA policy evaluation with Rego\n\n- Description: Meshery's highly dynamic infrastructure configuration capabilities require real-time evaluation of complex policies. Policies of various types and with a high number of parameters need to be evaluted client-side. With policies expressed in Rego, the goal of this project is to incorporate use of the https://github.com/open-policy-agent/golang-opa-wasm project into Meshery UI.\n- Expected outcome: a powerful real-time multi-user collaboration experience.\n- Recommended Skills:\n - Golang\n - Open Policy Agent, Rego\n - WASM\n- Mentor(s):\n - Lee Calcote (@leecalcote, leecalcote@gmail.com)\n - Abhishek Kumar (@Abhishek-kumar09, abhimait1909@gmail.com)\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/7019\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9faff011-1027-49c0-aa37-8d5be7208d6f\n\n### Thanos\n\n#### Implement fan-out query observability in Thanos\n\n- Description:\n In the previous mentorship sessions we added the foundation required for query observability in Thanos's new [promql-engine](https://github.com/thanos-io/promql-engine) and hooked it up in the UI. We now have the foundation to record telemetry from our query engine as well such as time consumed per operator.\n This project aims to expand on this and add more metadata to the query execution, both on the promql-engine operator tree level and Thanos Query `Select()` calls for fan-out query observability.\n Once we have this metadata, we would like to visualize it in the Query UI.\n- Expected Outcome:\n The end goal is to have a query execution tree decorated with the metadata, collected during execution (ideally even visualized in the Thanos UI). This will help users to understand the performance implications of their PromQL queries and the bottlenecks in their Thanos Query setups.\n- Recommended Skills:\n - Golang\n - React.js with TypeScript\n - Git + GitHub\n - Any Prometheus/PromQL/Thanos understanding is a plus\n- Mentor(s):\n - Giedrius Statkevičius (@GiedriusS, giedriuswork@gmail.com)\n - Saswata Mukherjee (@saswatamcode, saswataminsta@yahoo.com)\n- Upstream Issue: https://github.com/thanos-io/thanos/issues/6517, https://github.com/thanos-community/promql-engine/issues/106\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5a96f43c-d858-40c2-b556-2770ba6b03d4\n\n#### Release the distributed query engine in Thanos\n\n- Description:\n The Thanos engine is capable of executing queries in a distributed manner, by pushing down aggregations to other querier nodes. This querying mode is not yet integrated well in the UI and is not exposed to users.\n The goal of this project is to add the needed integrations to the Thanos UI and officially release the feature to end users.\n- Expected Outcome:\n The expected outcome of the project is to have a fully integrated distributed querying capability through the Thanos UI.\n- Recommended Skills:\n - Golang\n - React.js with TypeScript\n - Git + GitHub\n - Any Prometheus/PromQL/Thanos understanding is a plus\n- Mentor(s):\n - Filip Petkovski (@fpetkovski, filip.petkovsky@gmail.com)\n- Upstream Issue: https://github.com/thanos-io/thanos/issues/6124\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3d6d3534-24e9-4261-9b91-7de3d78554f7\n\n### Vitess\n\n#### Continue the migration to React and enhance existing frontend UI\n\n- Description: Vitess uses arewefastyet to automatically benchmark its codebase and ensure no performance regression is introduced. The mentee will have the responsibility of continuing the UI that was previously created using React/Vite.\n- Expected Outcome: The expected outcome is to continue working on the Frontend UI that was developed during the 2023-summer term, that includes adding an admin UI, adding a feature to ensure the consistency of the results, improving the overall UX of the website, and add new pages to improve the scope of arewefastyet. The full list of expected work can be found in the issue linked below.\n- Recommended Skills: React +++, Docker ++, Vite +, REST API +++, Golang ++\n\n- Mentor(s):\n - Florent Poinsard @fouioui florent@planetscale.com\n- Upstream Issue (URL): https://github.com/vitessio/arewefastyet/issues/415\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/10d70edd-60ec-409b-8801-0fb752501b12\n\n\n### OpenKruise\n\n#### Integrate Openkruise workload with ArgoCD and Helm\n\n- Description: ArgoCD and Helm are popular tools to delivery k8s workload, yet currently only the k8s built-in workload are supported out-of-box for ArgoCD and Helm. OpenKruise provide advanced worklood that resemble with the built-in workload, users can use OpenKruise workload with ArgoCD and Helm, yet they cannot tell ArgoCD and Helm whether Openkruise workload is ready or not. \n- Expected Outcome:\n - Improve ArgoCD integration by writing custom lua script to tell whether OpenKruise workload is healthy. The lua script can be submited to the Argo-CD repository.\n - Improve Helm intergration by building a job container that can check whether OpenKruise workload is healthy during helm install/upgrade process. \n- Recommended Skills: Lua ,Docker, Kubernetes\n- Mentor(s):\n - Zhang zhen (@furykerry, furykerry@gmail.com)\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n- Upstream Issue: https://github.com/openkruise/kruise/issues/1345\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f603a2e7-9af2-40b2-a74f-109cad843de1\n\n### Volcano\n\n#### Support NPU accelerator scheduling in Volcano\n\n- Description: design and implement NPU accelerator scheduling in Volcano including the vitrualized NPU resource scheduling, job controller enhancement for NPU distributed training, NPU topology scheduling and so on.\n- Expected Outcome: \n - design doc and feature user guide\n - implement NPU topology scheduling\n - implement job controller enhancement\n - vitrualized NPU resource scheduling\n- Recommend Skills: Go, Kubernetes, Volcano\n- Mentor(s):\n william wang(@william-wang, wang.platform@gmail.com)\n wang yang(@wangyang0616, wangyang8126@gmail.com)\n- Upstream Issue (URL): https://github.com/volcano-sh/volcano/issues/3019\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2d07fac8-9206-4299-a9fe-a55f366a38f3\n\n#### Build a new elastic resource quota mechinism in Volcano \n\n- Description: design and implement a new hierarchical elastic resource quota mechinism to support resource lending and borrowing to improve the cluster utilization for multi-tenants environment. \n- Expected Outcome: \n - design doc and how to use\n - implement a elastic resource quota mechinism to support min, max and resource sharing\n - implement the hierarchical resource quota\n - produce Blogs about these new cases.\n- Recommend Skills: Go, Kubernetes, Volcano\n- Mentor(s):\n william wang(@william-wang, wang.platform@gmail.com)\n wang yang(@wangyang0616, wangyang8126@gmail.com)\n- Upstream Issue (URL): https://github.com/volcano-sh/volcano/issues/3018\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ffbb6bb3-b9d1-4e96-9f72-4a0566f6b0c3\n\n#### Add user guidance for jobflow\n\n- Description: Since jobflow is an important built-in orchestration engine for Volcano, it is still lack of user guidance. Please add more docs to demonstrate its installation, usage, tips and so on. \n- Expected Outcome: Add docs into volcano-sh/volcano/docs/user-guide and describe the usage of jobflow.\n- Recommended Skills: Volcano, jobflow\n- Mentor(s): Thor Wu (@Thor-wl, 13164644535@163.com)\n- Upstream Issue: https://github.com/volcano-sh/volcano/issues/3013\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/757e329b-0083-4720-bd96-8bbbd6a7aeb3\n\n#### Fix bugs for jobflow to enhance its stability\n\n- Description: As a built-in orchestration engine for Volcano, jobflow acts as an improtant role for users and it's still new-born. Many issues related to its stability are reported recently. Please help make full test for job-flow on the classical scenarios and reslove bugs reported in issues.\n- Expected Outcome: Make full test for jobflow and output the test report, fix bugs reported in recent issues.\n- Recommended Skills: Volcano, jobflow, Golang, UT, E2E\n- Mentor(s): Thor Wu (@Thor-wl, 13164644535@163.com)\n- Upstream Issue: https://github.com/volcano-sh/volcano/issues/3014\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2fa8d7b8-01fa-4375-b3a8-1b626348fedd\n\n### WasmEdge\n\n#### Add matrix operations for OpenCVMini-Wasm-Plugin\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a WebAssembly runtime that supports both interpreter and ahead-of-time modes. To expand its capabilities, WasmEdge provides a plugin system that helps people attach more existing software. OpenCVMini is one of them, intended to help users get a limited OpenCV interface. With this feature, AI inference will have more flexible helper functions for pre-processing and post-processing. In this mentorship, we aim to add more OpenCV capabilities to the WasmEdge environment.\n- Expected Outcome:\n - Define the new interfaces for the OpenCVMini plugin, which supports those functions listed in the upstream issue.\n - Use the above interface and generate related APIs.\n - Implement the functions of the plugin with OpenCV 4.x.\n - Design unit tests and examples for verifying the above functions.\n - Enable the building, testing, and packaging on the upstream CI.\n - Write documents about how to build and use this plugin.\n- Recommended Skills:\n - C++\n - Basic understanding of the Wasm spec\n - Basic understanding of using OpenCV\n - Basic understanding of writing Rust programs\n- Mentor(s):\n - Lîm Tsú-thuàn (@dannypsnl, dannypsnl@secondstate.io)\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2680\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f21bec94-085e-4e2d-94ac-3b61b4471818\n\n#### Support AOT mode in proxy-wasm\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a WebAssembly runtime that supports both interpreter and ahead-of-time modes. For proxy-wasm support, WasmEdge only provides the interpreter mode currently. Such as the other runtimes, WasmEdge should be able to support the AOT mode for better performance. In this mentorship, the mentees will help the WasmEdge project to complete the AOT mode in proxy-wasm proposal and write the docs for examples of running with proxy-wasm.\n- Expected Outcome:\n - Modify the Bazel file to include the LLVM dependency.\n - Modify the code to support running WASM in AOT mode.\n - Add the documentation of proxy-wasm in the WasmEdge docs repo.\n- Recommended Skills:\n - C++\n - Basic understanding of bazel\n- Mentor(s):\n - Yi-Ying He (@q82419, yiying@secondstate.io)\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2686\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3ee046ab-29d9-4e5c-bb7a-4564bd4e2765\n\n#### Create a Rust crate for YOLO model\n\n- Description:\n With [WASI-NN plugins](https://wasmedge.org/docs/category/neural-networks-for-wasi), WasmEdge is well-suited for running AI applications. However, AI applications are more than just the model. The application must pre-process data (such as images, audio and video) into TFLite / PyTorch formats, and convert the inference results back into application data in post-processing. Here are some examples:\n\n * The [mediapipe-rs](https://github.com/WasmEdge/mediapipe-rs) project provides a Rust SDK to build applications for the mediapipe AI models.\n * The [llama2.c](https://github.com/karpathy/llama2.c) application is [compiled to Wasm and runs in WasmEdge](https://medium.com/@michaelyuan_88928/running-llama2-c-in-wasmedge-15291795c470) to generate text using the [llama2](https://ai.meta.com/llama/) models.\n\n In this project, we would like to build a Rust SDK to support applications on the [YOLO models](https://pjreddie.com/darknet/yolo/).\n- Expected Outcome:\n - A Rust SDK that implements the pre-processing and post-processing functions required for the YOLO models. Those functions are implemented in OpenCV and Python in the official YOLO release.\n - Both image and video inputs should be supported.\n - Examples and documentation should be provided.\n- Recommended Skills:\n - OpenCV\n - Rust\n - Tensorflow / Pytorch\n - WebAssembly\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2690\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/63adcf97-cd3e-4c96-a5fc-6076b5a5d511\n\n#### Create a ffmpeg plugin\n\n- Description:\n The [mediapipe-rs](https://github.com/WasmEdge/mediapipe-rs) project provides a Rust SDK to support mediapipe AI models. The SDK provides utility functions to pre-process application data (such as images, audio and video) into TFLite / PyTorch formats, and convert the inference results back into application data. In order to accomplish this, the [mediapipe-rs](https://github.com/WasmEdge/mediapipe-rs) project has made extensive use of the [ffmpeg](https://www.ffmpeg.org/) library. It [compiles ffmpeg to Wasm](https://github.com/WasmEdge/mediapipe-rs/blob/main/src/build.rs) and then builds it together with the application binary.\n\n However, the issue with this approach is that those Wasm-compiled ffmpeg functions are slow. We believe a better approach is to create a ffmpeg plugin for WasmEdge, and allow Wasm applications to call native ffmpeg functions as host functions.\n- Expected Outcome:\n - The deliverables will be\n - A WasmEdge plugin for ffmpeg that is similar to the [WasmEdge OpenCV-mini plugin](https://github.com/WasmEdge/WasmEdge/tree/master/plugins/wasmedge_opencvmini). That is to re-export ffmpeg functions in C style as plugin functions as covered in the [plugin developer guide](https://wasmedge.org/docs/category/wasmedge-plugin-system).\n - A Rust SDK for Wasm programs to access ffmpeg functions in the plugin. Similar to the [WasmEdge OpenCV-mini SDK](https://github.com/second-state/opencvmini)\n - Refactor the mediapipe-rs project to use the ffmpeg plugin instead of compiling ffmpeg to Wasm.\n - We expect the deliverable will cover at least 80% of all ffmpeg functions, and have complete unit test and documentation coverage.\n- Recommended Skills:\n - C/C++\n - ffmpeg\n - Rust\n - WebAssembly\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/2689\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/41a8bf79-a903-4c03-afb7-256fd373c0b0\n" }, { "path": "programs/lfx-mentorship/2023/03-Sep-Nov/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n- Upstream Issue:\n\n```\n\n---\n\n## Proposed Project ideas\n\n---\n" }, { "path": "programs/lfx-mentorship/2024/01-Mar-May/README.md", "content": "# Term 01 - 2024 March - May\n\nStatus: Complete\n\nMentorship duration - three months (12 weeks - full-time schedule)\n\n### Timeline\n\n| activity | date |\n| --- |--------------------------------------------------------------------| \n| project proposals | Monday Jan 8 - Wednesday Jan 24, 8:00 AM PDT |\n| mentee applications open | Monday Jan 29 - Tues Feb 13, 5:00 PM PDT |\n| application review/admission decisions | Wed Feb 14 - Tues Feb 27, 5:00 PM PDT |\n| selection notifications | Thurs Feb 29, 5:00 PM PDT (as selections are made on the platform) |\n| Mentorship program begins with the initial work assignments | Monday March 4 (Week 1) | \n| Midterm mentee evaluations and first stipend payments | Wednesday April 10 (Week 6) |\n| Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals | Wed May 22, 5:00 PM PST (Week 12) |\n| Last day of term | Friday May 31 |\n\n### Project instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2024/01-Mar-May/project_ideas.md, by January 24, 2024.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n## Accepted projects\n\n- [Antrea](#antrea)\n - [East-west connectivity monitoring tool for Pod network](#east-west-connectivity-monitoring-tool-for-pod-network)\n - [Ability to install / upgrade Antrea using the CLI](#ability-to-install--upgrade-antrea-using-the-cli)\n - [Replace deprecated bincover with golang built-in coverage profiling tool](#replace-deprecated-bincover-with-golang-built-in-coverage-profiling-tool)\n- [CNCF TAG Network](#cncf-tag-network)\n - [Mapping Kubernetes Resources: Identifying relationships between all standard and custom resources](#mapping-kubernetes-resources-identifying-relationships-between-all-standard-and-custom-resources)\n- [Chaos Mesh](#chaos-mesh)\n - [Observability for StressChaos](#observability-for-stresschaos)\n- [Cilium](#cilium)\n - [Governance Documentation](#governance-documentation)\n- [Cloud Native Buildpacks](#cloud-native-buildpacks)\n - [Proof of concept for creating multi-arch images using buildkit](#proof-of-concept-for-creating-multi-arch-images-using-buildkit)\n- [CRI-O](#cri-o)\n - [Fully Automated CRI-O Releases](#fully-automated-cri-o-releases)\n- [Flux](#flux)\n - [Conformance tests for AWS](#conformance-tests-for-aws)\n- [Harbor](#harbor)\n - [Harbor CLI](#harbor-cli)\n - [Harbor Satellite](#harbor-satellite)\n- [Inspektor Gadget](#inspektor-gadget)\n - [Support for new types of eBPF programs](#support-for-new-types-of-ebpf-programs)\n - [Testing framework for image-based gadgets](#testing-framework-for-image-based-gadgets)\n- [Istio](#istio)\n - [Improve Test Coverage for Istio Ambient Mesh](#improve-test-coverage-for-istio-ambient-mesh)\n- [Jaeger](#jaeger)\n - [Jaeger-V2 Storage Backends](#jaeger-v2-storage-backends)\n - [Jaeger-V2 Observability](#jaeger-v2-observability)\n - [Jaeger-V2 Adaptive Sampling](#jaeger-v2-adaptive-sampling)\n- [KCL](#kcl)\n - [KCL Package Version Management](#kcl-package-version-management)\n - [KCL IDE Quick Fix](#kcl-ide-quick-fix)\n - [KCL IDE Update KCL Dependencies](#kcl-ide-update-kcl-dependencies)\n- [Knative](#knative)\n - [Contributor Journey Research](#contributor-journey-research)\n - [Cross Namespace Event Links](#cross-namespace-event-links)\n- [Konveyor](#konveyor)\n - [Move2Kube: Exploratory approaches to artifact manipulation.](#move2kube-exploratory-approaches-to-artifact-manipulation)\n - [Move2Kube: Simplify plugin architecture of m2k](#move2kube-simplify-plugin-architecture-of-m2k)\n - [Move2Kube: Advanced Resources support and enhance other Move2Kube components](#move2kube-advanced-resources-support-and-enhance-other-move2kube-components)\n- [Kubearmor](#kubearmor)\n - [Kubearmor Kata Container Support](#kubearmor-kata-container-support)\n - [Leverage OCI Hooks for Container Events](#leverage-oci-hooks-for-container-events)\n - [Dashboards for application behavior and KubeArmor state](#dashboards-for-application-behavior-and-kubearmor-state)\n- [KubeEdge](#kubeedge)\n - [Auto Generate KubeEdge API Document](#auto-generate-kubeedge-api-document)\n - [Image PrePull Feature Enhancement](#image-prepull-feature-enhancement)\n - [Keadm Tool Enhancement](#keadm-tool-enhancement)\n - [Support latest version in keink and run demo on keink](#support-latest-version-in-keink-and-run-demo-on-keink)\n- [KubeVela](#kubevela)\n - [Support versioning for definitions](#support-versioning-for-definitions)\n- [Kyverno](#kyverno)\n - [Kyverno for Envoy Authorization](#kyverno-for-envoy-authorization)\n - [Kyverno VPA Recommender](#kyverno-vpa-recommender)\n - [Convert Kubernetes Best Practices Policies to CEL](#convert-kubernetes-best-practices-policies-to-cel)\n - [Verify Multiple Image Attestations](#verify-multiple-image-attestations)\n- [K8sGPT](#k8sgpt)\n - [Enhance K8sGPT's analyzers Unit Test Coverage](#enhance-k8sgpts-analyzers-unit-test-coverage)\n- [LitmusChaos](#litmuschaos)\n - [Enhancement of litmusctl: Adding E2E Tests, CRUD Probes Commands, and Package Manager Availability](#enhancement-of-litmusctl-adding-e2e-tests-crud-probes-commands-and-package-manager-availability)\n - [Enhancing Chaos Center: Implementing E2E Test Cases and Addressing CVE Issues](#enhancing-chaos-center-implementing-e2e-test-cases-and-addressing-cve-issues)\n - [Enhancements in Chaos Center: Multiple Project Owners and Log Download API](#enhancements-in-chaos-center-multiple-project-owners-and-log-download-api)\n- [Meshery](#meshery)\n - [Meshery: UI Migration from MUI v4 to MUI v5 and NextjS 13](#meshery-ui-migration-from-mui-v4-to-mui-v5-and-nextjs-13)\n - [Meshery: Expand CLI capabilities for registry management](#meshery-expand-cli-capabilities-for-registry-management)\n - [Meshery: Expand integration with Artifact Hub](#meshery-expand-integration-with-artifact-hub)\n- [OpenKruise](#openkruise)\n - [Build simple Web-UI that can integration with exiting PaaS](#build-simple-web-ui-that-can-integration-with-exiting-paas)\n- [OpenTelemetry](#opentelemetry)\n - [One Logging Bridge per Language](#one-logging-bridge-per-language)\n- [Prometheus](#prometheus)\n - [Client\\_golang CI/CD improvements](#client_golang-cicd-improvements)\n- [Service Mesh Performance](#service-mesh-performance)\n - [Service Mesh Performance: Adaptive Load Control with Nighthawk](#service-mesh-performance-adaptive-load-control-with-nighthawk)\n - [Service Mesh Performance: Distributed Load Testing with Nighthawk](#service-mesh-performance-distributed-load-testing-with-nighthawk)\n- [Vitess](#vitess)\n - [Improve Unit Test Coverage](#improve-unit-test-coverage)\n- [Volcano](#volcano)\n - [Volcano supports multi-cluster AI workloads scheduling](#volcano-supports-multi-cluster-ai-workloads-scheduling)\n - [Volcano supports DRA integration](#volcano-supports-dra-integration)\n- [WasmEdge](#wasmedge)\n - [Integrate MLX as a new WASI-NN backend](#integrate-mlx-as-a-new-wasi-nn-backend)\n - [Integrate Intel Extension for Transformers as a new WASI-NN backend](#integrate-intel-extension-for-transformers-as-a-new-wasi-nn-backend)\n - [Integrate whisper.cpp as a new WASI-NN backend](#integrate-whispercpp-as-a-new-wasi-nn-backend)\n - [Integrate burn.rs as a new WASI-NN backend](#integrate-burnrs-as-a-new-wasi-nn-backend)\n\n### Antrea\n\n#### East-west connectivity monitoring tool for Pod network\n\n- Description: As a K8s network plugin (CNI plugin), Antrea provides networking functions for K8s Pods. These Pods are located on different Nodes, which can be in different availability zones, or even different geos. We would like to provide as part of Antrea (built-in capability) a tool to monitor Pod connectivity across the cluster. This tool should be able to report the average network latency between any 2 Nodes in the cluster. The latency information could then be visualized using a heatmap representation in the Antrea web UI.\n- Expected Outcome: A new Antrea API which reports network health information and latency between K8s Nodes. If time allows, the Antrea web UI should also be extended so that latency information can be easily visualized through a heatmap.\n- Recommended Skills: familiarity with Golang, some knowledge about the K8s architecture and APIs, some basic networking knowledge (TCP/IP stack), frontend development experience (React, TypeScript) would be great but not required.\n- Mentor(s):\n - Yang Ding (@Dyanngg, dingyany1995@outlook.com)\n - Anlan He (@heanlan, anlan9771@gmail.com)\n - Antonin Bas (@antoninbas, antonin.bas@gmail.com)\n- Upstream Issue: https://github.com/antrea-io/antrea/issues/5514\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/12b695a0-e05c-46b9-a42d-c7e4709f0129\n\n#### Ability to install / upgrade Antrea using the CLI\n\n- Description: Currently Antrea can be installed using a K8s YAML manifest or through the provided Helm chart. We believe there is value in providing a 3rd installation method, using the \"antctl\" CLI. The CLI installation / upgrade method would have the following advantages: a) more user-friendly, with support for command-line options to customize the installation, b) ability to run sanity checks on the K8s cluster before comitting to the installation, c) when upgrading, the CLI will ensure that Antrea components are upgraded in the optimal order, to minimize workload disruption.\n- Expected Outcome: A new command for antctl, the Antrea CLI, which will provide support for installation and upgrade.\n- Recommended Skills: familiarity with Golang, some knowledge about the K8s architecture and APIs, UX experience would be great but not required.\n- Mentor(s):\n - Quan Tian (@tnqn, tianquan23@gmail.com)\n - Lan Luo (@luolanzone, luolanzone@gmail.com)\n - Antonin Bas (@antoninbas, antonin.bas@gmail.com)\n- Upstream Issue: https://github.com/antrea-io/antrea/issues/5896\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ae950bcf-d16b-4d26-aed0-702c1eedb507\n\n#### Replace deprecated bincover with golang built-in coverage profiling tool\n\n- Description: Currently Antrea uses a third-party tool called [bincover](https://github.com/confluentinc/bincover) to measure code coverage when running end-to-end (e2e) tests. This tool has been deprecated in favor of the built-in Go coverage profiling tool (https://go.dev/testing/coverage/) starting with Go 1.20, and it is no longer maintained. We would like to remove usage of bincover from the Antrea project and start using the built-in Go tool.\n- Expected Outcome: Complete removal of the bincove dependency. Code coverage can still be measured with the same accuracy when running Antrea e2e tests and the results can still be reported to [Codecov](https://about.codecov.io/).\n- Recommended Skills: familiarity with Golang and the Golang testing framework.\n- Mentor(s):\n - Antonin Bas (@antoninbas, antonin.bas@gmail.com)\n - Lan Luo (@luolanzone, luolanzone@gmail.com)\n- Upstream Issue: https://github.com/antrea-io/antrea/issues/4962\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8f08ebb1-05a8-41fb-8c4c-85626f63c195\n\n### CNCF TAG Network\n\n#### Mapping Kubernetes Resources: Identifying relationships between all standard and custom resources\n\n- Description: The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph.\n- Expected Outcome:\n - YAML-formatted definition of one or more relationships per Kubernetes resource.\n - Documentation of each relationship - per component.\n - Development of new types of genealogies - new types of ways in which resources relate to one another and how these relationships might be visualized.\n - Verification of functional relationships\n- Recommended Skills: DevOps, Kubernetes Administration, Light familiarity with all of the CNCF projects and a desire to study each project and their operators/resources.\n- Mentor(s):\n - Mentor Name: Uzair Shaikh (@muzairs15, muzair.shaikh810@gmail.com), Lee Calcote (@leecalcote, leecalcote@gmail.com)\n- Upstream Issue: https://github.com/cncf/tag-network/issues/35\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1e9ac76e-0434-45fc-8137-fc5698f29cd0\n\n### Chaos Mesh\n\n#### Observability for StressChaos\n\n- Description: StressChaos is a chaos experiment that injects stress to the system. The current implementation of StressChaos is lack of observability, most of observability solutions could not observe the stress at Pod level, but only at Node level. This project is to enhance observability for StressChaos.\n- Expected Outcome: Chaos Mesh end users could observe the injected stress at Pod level.\n- Recommended Skills: Golang, Kubernetes, Linux, Observability Tools(e.g. Prometheus, Grafana, etc.)\n- Mentor(s):\n - Zhiqiang Zhou(@STRRL, im@strrl.dev)\n - Yue Yang(@g1eny0ung, g1enyy0ung@gmail.com)\n - Cwen Yin(@cwen0, yincwengo@gmail.com)\n- Upstream Issue: https://github.com/chaos-mesh/chaos-mesh/discussions/3012, https://github.com/chaos-mesh/chaos-mesh/issues/3651\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8ad2c24f-120d-4369-866c-c911a5c885e9\n\n### Cilium\n\n#### Governance Documentation\n\n- Description: This project will focus on governance documentation for the Cilium project with two key parts. First, the governenace documentation should be moved out of the main docs and into the community repo. Second, we need to do an inventory of all of the repos under the project and come up with a lifecycle for them.\n- Expected Outcome: Governance docs in community repo. All repos accounted for and with a lifecycle plan.\n- Recommended Skills: enthusiasm for governance and basic markdown experience\n- Mentor(s):\n - Bill Mulligan(@xmulligan, bill@isovalent.com)\n- Upstream Issue: https://github.com/cilium/community/issues/78 https://github.com/cilium/community/issues/27 https://github.com/cilium/community/issues/82\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/eeaec4a9-5a9c-4cae-945d-f99265e85275\n\n### Cloud Native Buildpacks\n\n#### Proof of concept for creating multi-arch images using buildkit\n\n- Description: A proof of concept to add buildkit support to pack in order to build multi-arch images. Pack is the reference implementation of a Cloud Native Buildpacks platform used to build application images from source code.\n- Expected Outcome: Multi-arch support has been one of the most requested features for Cloud Native Buildpacks, and this would allow end-users/developers to build multi-arch images with the pack cli.\n- Recommended Skills: Golang, Software development literacy, Familiarity building multi-arch containers with Docker and Buildkit. Familiarity with buildpacks will be helpful.\n- Mentor(s):\n - Jerico Pena (@jericop, jericop@gmail.com)\n - Juan Bustamante (@jjbustamante, bustamantejj@gmail.com)\n - Natalie Arellano (@natalieparellano, natalie.arellano@broadcom.com)\n- Upstream Issue: https://github.com/buildpacks/pack/issues/1570\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2c5ced86-d23b-41f5-aec3-59730e29f092\n\n### CRI-O\n\n#### Fully Automated CRI-O Releases\n\n- Description: There are several steps to the CRI-O release process that are manual. Lots of work has been done to update this, but there is still pushing a tag, copying release notes and some other small tasks. This project is about such automation.\n- Expected Outcome:\n - Fully automated release and patch versions of CRI-O\n- Mentor(s):\n - Sascha Grunert (@saschagrunert, sgrunert@redhat.com)\n - Krzysztof Wilczynski (@kwilczynski, kwilczyn@redhat.com)\n- Recommended Skills: Golang\n- Upstream Issue: https://github.com/cri-o/cri-o/issues/4003\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7ed311c5-6b9b-4056-a8ee-acf04b9f55b9\n\n### Flux\n\n#### Conformance tests for AWS\n\n- Description: Flux has several integration points with hyper-scaler platforms e.g., AWS. In general it is tricky to test these satisfactorily, because it requires running in the platform and thereby incurring usage costs. GCP donate credits that are used to test there; and now the Flux project has been generously granted credits to use for testing in AWS, and we can create conformance tests for AWS specifically too.\n- Expected outcome: A suite of conformance tests for AWS integrations in Flux.\n- Recommended skills: AWS, Golang, GitHub Actions\n- Mentor: Stefan Prodan (@stefanprodan, stefan.prodan@gmail.com)\n- Upstream issue: https://github.com/fluxcd/flux2/issues/4619\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/61486d56-9b28-42db-9e61-7a74b846cc15\n\n### Harbor\n\n#### Harbor CLI\n\n- Description: Harbor is a popular and widely adopted container registry. We have developed an initial CLI (https://github.com/goharbor/harbor-cli) that we would like to extend and implement additional functionality, and common workflows that are currently only present in the Web UI. We are seeking a Golangs experienced manatee who can work on the project independently. \n- Expected Outcome: Working Golang Harbor CLI which can be used in the CI/CD implementations that compliment the Web UI covering the typical workflows of Harbor administrators and users. Familiarity with Golang library spf13/cobra and REST/Open API. Well-documented CLI that users love to use, and with the corresponding architectural diagrams under the Harbor. Working CI/CD with GitHub actions that create multi architecture binaries and containers.\n- Recommended Skills: Golang, spf13/cobra\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Yan Wang (@wy65701436, yan-yw.wang@broadcom.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n- Upstream Issue: https://github.com/search?q=Harbor%20CLI&type=repositories\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8654848d-1233-4e9f-8ed6-559af0ea8298\n\n#### Harbor Satellite\n\n- Description: Containers are becoming more and more omnipresent, event outside their natural habitat, the cloud. It is not common today to see that container are running on small and remote devices on the EDGE. Those fleets of devices often don’t have a reliable internet connection or no internet connection at all. Running containers without being able to fetch images is a hard thing to do. So we are bringing the registry closer to the appliances where they are running.\nSince we are not talking about a few registries but many more, it becomes challenging to manage all the registries, this is where the satellite concept comes into place where images are distributes from a central registry.\nThe following slides and video outline the concept and its purpose in more detail.\nhttps://youtu.be/GJ3pnfUocEw?si=F9mn4-sgN1_K6rLK&t=1529\nhttps://docs.google.com/presentation/d/e/2PACX-1vRfcwotFzUSmfmSOmRQccBdJuFUFtIxeFE4mB3L9NgnOBM5tBnCs6uYOzyfUCIpd5xiEueMA1RYTFML/pub?start=false&loop=false&delayms=3000\n- Expected Outcome: The goal is to create a proof of concept, showcasing that such a solution practically works. Candidates should be able to demonstrate, how images can be replicated from a central registry to a registry on the edge location.\nThe demonstration should contain a tunneling solution that has a Golang SDK or can be controlled from a Golang application. Part of the project is the selection and evaluation of different tunneling solutions. \n- Recommended Skills: Golang, OSS contributions, distributed systems\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Yan Wang (@wy65701436, yan-yw.wang@broadcom.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n- Upstream Issue: https://github.com/search?q=repo%3Agoharbor%2Fharbor+Satellite&type=issues\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/31d2e818-5ce1-4f87-aba1-a8b2f71a0e01\n\n### Inspektor Gadget\n\n#### Support for new types of eBPF programs\n\n- Description: Inspektor Gadget is an eBPF tool and systems inspection framework for Kubernetes, containers and Linux hosts. Users can develop gadgets using different kinds of eBPF programs: kprobe, tracepoint, etc. This project will focus on adding support for more kinds of eBPF programs such as uprobes and ensuring the documentation is updated for each of them\n- Expected Outcome: Inspektor Gadget has support for additional eBPF program kinds\n- Recommended Skills: Go, containers, Linux, basics of eBPF\n- Mentor(s):\n - Alban Crequy (@alban, albancrequy@microsoft.com)\n - Mauricio Vásquez (@mauriciovasquezbernal, mauriciov@microsoft.com)\n- Upstream Issue: https://github.com/inspektor-gadget/inspektor-gadget/issues/1912\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f016029e-f15f-4ee9-aaf5-5719bee72b59\n\n#### Testing framework for image-based gadgets\n\n- Description: Inspektor Gadget is an eBPF tool and systems inspection framework for Kubernetes, containers and Linux hosts. Previously, Inspektor Gadget had a set of built-in gadgets. We are now moving to image-based gadgets where users can develop their own gadgets in eBPF and host them in OCI registries. But we don't have a test framework to help gadget authors to test their gadgets. This project will focus on implementing such a framework, possibly taking inspiration from the existing framework for built-in gadgets. The documentation for gadget authors should be updated. This project has the opportunity to expand beyond testing, to work on the gadget development experience over all, for example by creating a github template for gadget development.\n- Expected Outcome: Gadget authors can test their gadgets\n- Recommended Skills: Go, containers, Linux, testing\n- Mentor(s):\n - Alban Crequy (@alban, albancrequy@microsoft.com)\n - Mauricio Vásquez (@mauriciovasquezbernal, mauriciov@microsoft.com)\n- Upstream Issue: https://github.com/inspektor-gadget/inspektor-gadget/issues/2046\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/65719d46-b71f-4778-a29b-3bb878d6ec70\n\n### Istio\n\n#### Improve Test Coverage for Istio Ambient Mesh\n\n- Description: Ambient mesh is now one of the biggest features in Istio, but it is in its early stage. We are in the process of improving the test coverage for Ambient Mesh in order to move it to Beta. Ztunnel works as shared data plane within a node, it subscribes to `Workload` and `Authorization` resources, both need to be well tested.\n- Expected Outcome:\n - Enhanced UnitTest coverage for `Workload` and `Authorization` Delta xDS/Stow interface.\n - Enhanced integration tests for ztunnel Authorization Policy \n- Recommended Skills: Go, Istio Test Framework\n- Mentor(s):\n - Zhonghu Xu (@hzxuzhonghu, zhhxu2011@gmail.com) \n - Faseela K (@kfaseela, k.faseela@gmail.com) \n- Upstream Issue:\n - https://github.com/orgs/istio/projects/9\n - https://github.com/istio/ztunnel/issues/251\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/263ef898-ac07-49d7-9aff-ebd319159163\n\n### Jaeger\n\n#### Jaeger-V2 Storage Backends\n\n- Description: Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. Currently only memory storage is wired in v2, we need to add Elasticsearch, Opensearch, Cassandra, Badger.\n- Expected Outcome: Build out full support in jaeger-v2 for all storage backends supported by jaeger-v1\n- Recommended Skills: Go, scripting, CI/CD\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yash Sharma (yashrsharma44@meta.com)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/5084\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/66aaa053-e7b1-4682-a285-73ce66420f86\n\n#### Jaeger-V2 Observability\n\n- Description: Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. Currently jaeger-v2 components are initialized without observability clients. We need to instantiate appropriate logging, tracing, and metrics clients and pass them to the components. The existing code uses internal metrics API, which needs to be bridged to OTEL metrics to minimize code changes.\n- Expected Outcome: Achieve parity in observability of jaeger-v2 compared to jaeger-v1\n- Recommended Skills: Go, scripting, CI/CD\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yash Sharma (yashrsharma44@meta.com)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/5084\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/077f3bec-e3d3-41f7-a527-655c62661f80\n\n#### Jaeger-V2 Adaptive Sampling\n\n- Description: Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. Jaeger-v1 collector can serve sampling configuration to SDKs, and allows either static configuration (with hot reload) or adaptive sampling that continuously re-calculates the desired sampling probabilities. We need to enable all these capabilities in jaeger-v2.\n- Expected Outcome: Support adaptive sampling in jaeger-v2\n- Recommended Skills: Go, scripting, CI/CD\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yash Sharma (yashrsharma44@meta.com)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/5084\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/00e78fef-e9a7-4e2c-bf29-e6099ac14b65\n\n### KCL\n\n#### KCL Package Version Management\n\n- Description: The KCL package management tool primarily handles the management of third-party KCL packages for the KCL project, which includes tasks such as uploading and downloading these packages. When adding third-party packages to the KCL project, it is important to adhere to version management strategies. This involves carefully selecting and downloading the appropriate version of a package, especially when different versions of the same package are available.\n- Expected Outcome: Add version management to the KCL package management tool.\n- Recommended Skills: golang\n- Mentor(s):\n - Pengfei Xu (@Peefy, xpf6677@gmail.com)\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/kpm/issues/246\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/06b5baee-bdcd-4f5e-9a1a-454191445a01\n\n#### KCL IDE Quick Fix\n\n- Description: When the KCL IDE encounters some errors in the KCL code, it can pop up `Quick Fix` prompts to help users quickly fix the errors.\n- Expected Outcome: Added Quick Fix for some error prompts in KCL IDE.\n- Recommended Skills: rust\n- Mentor(s):\n - Pengfei Xu (@Peefy, xpf6677@gmail.com)\n - Zheng Zhang (@He1pa, he1pa404@gmail.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/kcl/issues/997\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/391edda7-239d-4471-a36a-c03c24e024cb\n\n#### KCL IDE Update KCL Dependencies\n\n- Description: When a KCL package is loaded using KCL IDE, the IDE automatically updates the dependencies of the current KCL package through kpm.\n- Expected Outcome: Add automatic updates for third-party libraries to the IDE.\n- Recommended Skills: rust, go\n- Mentor(s):\n - Pengfei Xu (@Peefy, xpf6677@gmail.com)\n - Zheng Zhang (@He1pa, he1pa404@gmail.com)\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/kcl/issues/998\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/59d5fb6c-153d-4e46-9d1f-2948641b0471\n\n### Knative\n\n#### Contributor Journey Research\n\n- Description: Getting new contributors onboarded into a complex project like Knative is a lot of work for both the new contributors and for the maintainers. This is compounded\n by the fact that many contributors don't stick around after the first few contributions. We would like to perform a research study into why some contributors stay while others\n leave the community after a bit, and determine where we can improve the contributor experience.\n- Expected Outcome: Create a report based off of user research detailing the current contributor journey within Knative and highlighting areas where that can be improved.\n- Recommended Skills: User Research, Communication\n- Mentor(s):\n - Calum Murray (@Cali0707, cmurray@redhat.com)\n - Mariana Mejia (@mmejia02, mariana.mejia@ocadu.ca)\n- Upstream Issue: https://github.com/knative/ux/issues/98\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/54afaf17-4dc9-4783-9641-a95b5a33af9e\n\n#### Cross Namespace Event Links\n\n- Description: One of the most requested features in Knative Eventing over the past few years has been for triggers in different namespaces than brokers, and for subscriptions\n in different namespaces than channels. More information can be found in the upstream issue.\n- Expected Outcome: Knative Eventing Triggers and Subscriptions can reference Brokers or Channels in a namespace different from their own if the user possesses the necessary\n permissions to do so.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s):\n - Calum Murray (@Cali0707, cmurray@redhat.com)\n - Pierangelo Di Pilato (@pierdipi, pierdipi@redhat.com)\n- Upstream Issue: https://github.com/knative/eventing/issues/7530\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/eba6b385-1293-4192-b2b4-7da3afb74476\n\n### Konveyor\n\n#### Move2Kube: Exploratory approaches to artifact manipulation.\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has built-in support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. As part of replatforming, we want to allow artifact manipulation at various levels to handle complex cases of replatforming flows. Example - while re-platforming from Netflix OSS spring boot feign client + eureka setup to Kubernetes (kubedns, kube-dns, services, ingress etc.) could need some artifact changes at different levels (code, architecture etc.).\n- Expected Outcome:\n - Identify various forms of artifact manipulation and explore approaches to support such manipulations.\n- Recommended Skills:\n - Golang\n - program analysis\n- Mentor(s):\n - Akash Nayak (@akash.nayak1, akash.nayak1@ibm.com)\n - Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com)\n - Mehant Kammakomati (@kmehant, mehant.kammakomati2@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/1130\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f304369d-62eb-40e0-b52b-630276bf4000\n\n#### Move2Kube: Simplify plugin architecture of m2k\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. The tool has a powerful plugin based transformer architecture where developers can write their own custom transformer plugins to fulfil their re-platforming needs. However, concepts like path mappings etc could be simplified for better adoption. Example - writing a Move2Kube custom transformer needs developers to understand various concepts such as path mappings etc, can we reduce this learning overhead by simplifying the Move2Kube architecture?\n- Expected Outcome:\n - Come up with a simplified alternative design for plugin architecture for M2K\n - Migrate existing components to support the new design with backward compatibility (good to have).\n- Recommended Skills:\n - Golang\n - K8s\n- Mentor(s):\n - Akash Nayak (@akash.nayak1, akash.nayak1@ibm.com)\n - Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com)\n - Mehant Kammakomati (@kmehant, mehant.kammakomati2@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/1131\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/06986e04-9b64-411f-b7f4-35fec6a70d03\n\n#### Move2Kube: Advanced Resources support and enhance other Move2Kube components\n\n- Description: Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has built-in support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. Currently we have support for resources such as ArgoCD, Tekton, etc. There is still a gap to be covered in the support Move2Kube provides. Example - enhance support for external transformers (GRPC, file/folder permissions, etc.).\n- Expected Outcome:\n - More comprehensive support for Move2Kube advanced resources and other components.\n- Recommended Skills:\n - Golang\n - K8s\n - ArgoCD\n - Tekton\n- Mentor(s):\n - Akash Nayak (@akash.nayak1, akash.nayak1@ibm.com)\n - Harikrishnan Balagopal (@HarikrishnanBalagopal, harikrishnan.balagopal@ibm.com)\n - Mehant Kammakomati (@kmehant, mehant.kammakomati2@ibm.com)\n- Upstream Issue: https://github.com/konveyor/move2kube/issues/1132\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/43693b3c-6512-4c0b-ba1b-f9704bfd0991\n\n### Kubearmor\n\n#### Kubearmor Kata Container Support\n\n- Description: Kata Containers is an open source community working to build a secure container runtime with lightweight virtual machines that feel and perform like containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense.\n- Expected Outcome: KubeArmor natively protecting Kata containers with required Integration.\n- Recommended Skills: Go, Kubernetes, Linux\n- Mentor(s): \n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Prashant Mishra (@primalpimmy, prashant20.pm@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com )\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1340\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0ece2baf-071b-4155-b1e8-696fbe58e991\n\n#### Leverage OCI Hooks for Container Events\n\n- Description: Use OCI hooks and get events in context to container start/stop: Currently KubeArmor mounts docker/containerd/crio UNIX domain socket file in KubeArmor to watch for container events. The aim is to use OCI hooks for getting such container events.\n- Expected Outcome: Eliminate exposing docker/containerd/crio UNIX domain sockets inside a container.\n- Recommended Skills: Go, Kubernetes, Linux\n- Mentor(s): \n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Akshay Gaikwad (@akshay196, akgaikwad001@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com )\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1390\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/70f1ef34-7ddd-466d-a5bc-0f74e98c06f8\n\n#### Dashboards for application behavior and KubeArmor state\n\n- Description: For showing an application's behaviour, we'd like to have a Kibana/Grafana dashboard. We have existing integrations for\nvisualizing alerts with Elastic/Loki and we can use them for creating these.\nWe want to leverage the above for creating a plugin which will allow users to see an application's behavior based on visibility logs sent by KubeArmor.\n- Expected Outcome: A kubernetes dashboard setup that also has the app behaviours described.\n- Recommended Skills: Grafana, Javascript, Go, Kubernetes, Linux\n- Mentor(s): \n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Prashant Mishra (@primalpimmy, prashant20.pm@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com )\n - Anurag Kumar (@kranurag7, kranurag7@linux.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1591\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a604ba9c-565d-4e8c-aed2-dcd4ebedc85d\n\n### KubeEdge\n\n#### Auto Generate KubeEdge API Document \n\n- Description: KubeEdge has introduced several custom APIs, but currently, there is no corresponding API documentation available. We would like to implement automated generation of API documentation and display it on the website documentation to assist users in quickly understanding the APIs and help developers reduce maintenance costs.\n- Expected Outcome: A tool for automatically generating API documentation.\n- Recommended Skills: Golang, Kubernetes, Swagger\n- Mentor(s): \n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n - Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/5159\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b36e22c3-ff66-46b8-9422-510c86f1e3c3\n\n#### Image PrePull Feature Enhancement\n\n- Description: In the latest release, KubeEdge has implemented the ability for image pre pull. However, each task execution only supports images from the same image repository currently. We hope to enhance this feature to support capabilities like overriding images and secrets, complete end-to-end tests for this feature.\n- Expected Outcome: Support image and secret override in image pre pull feature. And E2e tests for this feature are added. \n- Recommended Skills: Golang, Kubernetes, KubeEdge\n- Mentor(s):\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n - Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/5341\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/267cdecd-8ab9-43ab-be0e-ccf70ae1c023\n\n#### Keadm Tool Enhancement\n\n- Description: Keadm(KubeEdge installation tool) now only supports configuring a subset of parameters during EdgeCore installation. We would like to support specifying parameters using `--set` or directly using an existing local configuration file to achieve full parameter configuration and meet the users' requirements. \n- Expected Outcome: Users can use `keadm join --set` or specify the local `edgecore.yaml` to configure EdgeCore.\n- Recommended Skills: Golang, Kubernetes, KubeEdge\n- Mentor(s):\n - Willard Hu (@WillardHu, wei.hu@daocloud.io)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/5317 \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/94e63e48-4b72-4135-b7ca-84687d6f731e\n\n#### Support latest version in keink and run demo on keink\n\n- Description: keink(represent for KubeEdge IN kind) is a project for running local KubeEdge clusters using Docker container \"nodes\", so developers can install a multi-node\n edge cluster in one node. Now we need to support the latest version installation in keink.\n- Expected Outcome: keink can install the latest version of KubeEdge and developers can quickly use keink to run kubeedge, and then develop applications on KubeEdge.\n- Recommended Skills: Kubernetes, KubeEdge, Golang\n- Mentor(s): \n - Hongbing Zhang (@HongbingZhang, hongbing.zhang@daocloud.io)\n - Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/keink/issues/8\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/198a9ab4-1f6b-4db5-8e0a-404486235089\n\n### KubeVela\n\n#### Support versioning for definitions\n\n- Description: 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.\n- Expected Outcome: Support expilict versioning in definitions to help application upgrades and migrations.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s):\n - Fog Dong (@FogDong, wuwuglu19@gmail.com)\n - Zhongpei Qiao (@chivalryq, chivalry.pp@gmail.com)\n- Upstream Issue: https://github.com/kubevela/kubevela/issues/6435\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/acfbadbd-46c2-4647-a489-0db80c709740\n\n### Kyverno\n\n#### Kyverno for Envoy Authorization\n\n- Description: Build an Envoy plugin to support authorisation based on Kyverno policies.\n- Expected Outcome: Enable users to perform autorisation with similar concepts as kyverno and kyverno-JSON using policies.\n- Recommended Skills: Golang, Kubernetes, Envoy\n- Mentor(s):\n - Charles-Edouard Brétéché (@eddycharly, charled.breteche@gmail.com)\n - Anushka Mittal (@anushkamittal2001, anushka@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/9488\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5da34595-8dd2-4045-a77d-e86d4c64fbc3\n\n#### Kyverno VPA Recommender \n\n- Description: A common pain-point heard from users is improper resource allocations, and if Kyverno policies can help with that. This is an exploratory project to see if Kyverno can work with Kubernetes Vertical Pod Autoscalers (VPA).\n- Expected Outcome: Kyverno policies that work with VPA recommender.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s):\n - Jim Bugwadia (@jimbugwadia, jim@nirmata.com)\n - Khaled Emara (@KhaledEmaraDev, khaled.emara@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/9429\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e0124d13-1a8e-4dd9-a77e-d6de227d5163\n\n#### Convert Kubernetes Best Practices Policies to CEL \n\n- Description: Kubernetes Best Practices policies are written using Kyverno patterns and JMESPath, which means they cannot be executed as ValidatingAdmissionPolicy resources in the API server. This project aims to convert Kubernetes Best Practices policies, and other validating policies, to CEL wherever possible.\n- Expected Outcome: Convert Kyverno policies for Kubernetes best practices to CEL.\n- Recommended Skills: Kubernetes, Kyverno policies, CEL\n- Mentor(s):\n - Anusha Hegde (@anusha94, anusha.hegde@nirmata.com)\n - Mariam Fahmy (@MariamFahmy98, mariam.fahmy@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/policies/issues/891\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/521122b6-aed0-475d-93de-fb2cbfff85d2\n\n#### Verify Multiple Image Attestations\n\n- Description: Currently Kyverno cannot verify data across multiple attestations e.g. an image vulnerability scan report and a OpenVEX document. This project will enhance the image verification rules to support flexible checks across multiple attestations.\n- Expected Outcome: Support condition validation across multiple image verification attestations or context entry.\n- Recommended Skills: Golang, Kubernetes, VEX, Cosign, Notary\n- Mentor(s):\n - Vishal Choudhary (@vishal-chdhry, vishal.choudhary@nirmata.com)\n - Shuting Zhao (@realshuting, shuting@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/9456\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f1041093-65f3-4169-8c70-187a0f286aa4\n\n### K8sGPT\n\n#### Enhance K8sGPT's analyzers Unit Test Coverage\n\n- Description: K8sGPT is a tool for scanning Kubernetes clusters, diagnosing and triaging issues with the help of GenAI. It has SRE experience codified into its analyzers. These analyzers are critical for K8sGPT to perform its in-depth analysis. There are a few analysers that have either limited or absent unit tests. The goal is to introduce more unit tests which will reflect mocked problematic/misconfigured K8s resources and assure K8sGPT analysers can catch and identify those test scenarios.\n- Expected Outcome: Introduce and enhance Test Coverage of K8sGPT's analyzers\n- Recommended Skills: Go, Kubernetes \n- Mentor(s):\n - Alex Jones (@AlexsJones, alexsimonjones@gmail.com)\n - Aris Boutselis (@arbreezy, arisboutselis08@gmail.com)\n - Matthis Holleville (@matthisholleville, matthish29@gmail.com)\n - JuHyung Son (@JuHyung-Son, sonju0427@gmail.com)\n- Issue: https://github.com/k8sgpt-ai/k8sgpt/issues/889\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/57907615-6548-462d-81dc-62c88476f122\n\n### LitmusChaos\n\n#### Enhancement of litmusctl: Adding E2E Tests, CRUD Probes Commands, and Package Manager Availability\n\n- Description: The [project](https://github.com/litmuschaos/litmusctl) aims to improve litmusctl by introducing end-to-end (E2E) tests for better release testing and adding CRUD commands for probes, addressing user needs. Additionally, it seeks to enhance user accessibility by making litmusctl available on Brew and Chocolatey package managers.\n- Expected Outcome: The enhancement of litmusctl will include comprehensive E2E testing for improved reliability, the addition of CRUD commands for probes to expand functionality, and availability on Brew and Chocolatey for greater accessibility and user convenience.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s):\n - Vedant Shrotria (@Jonsy13, vedant.shrotria@harness.io)\n - Sarthak Jain (@SarthakJain26, sarthak.jain@harness.io)\n - Nagesh Bansal (@Nageshbansal, nageshbansal59@gmail.com)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/4405\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/48008595-14d2-4725-a0dc-15d441568bc2\n\n#### Enhancing Chaos Center: Implementing E2E Test Cases and Addressing CVE Issues\n\n- Description: This initiative focuses on augmenting the [Chaos Center](https://github.com/litmuschaos/litmus/tree/master/chaoscenter) with comprehensive end-to-end (E2E) test cases, addressing the current gap in testing capabilities. The lack of extensive E2E tests has been a challenge, especially during release cycles. The project also targets fixing identified Common Vulnerabilities and Exposures (CVEs) in the Chaos Center, enhancing the overall security and reliability of the system.\n- Expected Outcome: The project aims to establish a robust E2E testing framework for the Chaos Center, significantly improving test coverage and reliability during releases. Additionally, it focuses on resolving all identified CVEs, thereby enhancing the system's security. These improvements are expected to result in more stable and secure releases, increasing user trust in the Chaos Center.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s):\n - Namkyu Park (@namkyu1999, lak9348@gmail.com)\n - Shubham Chaudhary (@ispeakc0de, shubham.chaudhary@harness.io)\n - Raj Babu Das (@imrajdas, mail.rajdas@gmail.com)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/4406\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/828a5410-6e18-49a8-986e-0ad2dd5ecfa2\n\n#### Enhancements in Chaos Center: Multiple Project Owners and Log Download API\n\n- Description: This project focuses on two major enhancements for the [Chaos Center](https://github.com/litmuschaos/litmus/tree/master/chaoscenter). First, it aims to enable the support for multiple project owners, a feature highly requested by users. This addition will allow for more collaborative and flexible project management within the Chaos Center. Second, the project will develop an API for downloading logs, providing users with easier access to log data. Furthermore, there's a need to update the API documentation to reflect these new changes and ensure that users have the latest information for seamless integration and usage.\n- Expected Outcome: The successful completion of this project will result in the Chaos Center supporting multiple project owners, fostering collaborative and efficient project management. The new log download API will enhance user experience by simplifying access to log data. Additionally, the updated API documentation will ensure that users have clear and current guidelines, supporting better utilization of the new features.\n- Recommended Skills: Golang, ReactJs\n- Mentor(s):\n - Saranya Jena (@Saranya-jena, saranya.jena@harness.io)\n - Sahil Kumar (@SahilKr24, sahil.kumar@harness.io)\n - Hrishav Kumar (@hrishavjha, hrishav.kumar@harness.io)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/4407\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0b526c4c-a8ed-4a81-a3f1-1c6ebf328977\n\n### Meshery\n\n#### Meshery: UI Migration from MUI v4 to MUI v5 and NextjS 13\n\n- Description: Meshery's UI is powerful and utilizes frameworks like Next.js and Material-UI. However, it relies on outdated technology stacks, resulting in performance inefficiencies and increased maintenance overhead.\n- Expected Outcome: Migrate from MUI v4 to MUI v5 and fully utilize features of Nextjs v13. Migrate all class based components to function based component. Reduced code complexity and improved maintainability for long-term sustainability. Responsive and accessible UI that adapts to diverse devices and user needs.\n- Recommended Skills: ReactJs, NextJs, familiarity with Material UI, Redux and Redux Toolkit\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Antonette Caldwell (nebula-aac, pullmana8@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/6680\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9dc784dd-dbfb-4d60-81ce-4da95e0b48a0\n\n#### Meshery: Expand CLI capabilities for registry management\n\n- Description: Meshery CLI is a powerful tool to manage all your cloud native resources, Meshery has internal capability called Registry to store and manage models, categories, component and relationship, presently Meshery’s v0.7 release allow users to view all this information from Mehery UI. We also need to expose Meshery’s registry capability through mesheryctl\n- Expected Outcome: Design mesheryctl subcommands and flags for registering, listing, retrieving, updating, and deleting models, components and relationships. Implement validation and error handling for user input and API responses. Integrate with relevant Meshery APIs to interact with the registry backend.\n- Recommended Skills: Golang, familiarity with Golang CLI framework Cobra\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Uzair Shaikh (@MUzairS15 , muzair.shaikh810@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/8176\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/441ebbbd-8084-4e4c-b072-bc78112502ef\n\n#### Meshery: Expand integration with Artifact Hub\n\n- Description: While Meshery has made significant strides, its integration with Artifact Hub requires expansion and enhancement to maximize users experience. The goal is expand integration between Meshery and Artifact Hub which starts with making Meshery designs as a new Artifact Hub kind.\n- Expected Outcome: Definition and implementation of Meshery patterns as a distinct category within Artifact Hub. Design features to showcase Meshery's unique design patterns, enhancing visibility and accessibility. Collaborate with select publishers to integrate Meshery snapshots into Artifact Hub entries. Enhance user experience by providing visual representations of Meshery-related artifacts.\n- Recommended Skills: Familiarity with Helm charts and Artifact Hub, basic familiarity with Kubernetes\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Aabid Sofi (@aabidsofi19, mailtoaabid01@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/9966\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/83c60c5f-3e79-4532-8ee6-1266e30d21e0\n\n### OpenKruise \n\n#### Build simple Web-UI that can integration with exiting PaaS\n\n- Description: Currently, OpenKruise depends solely on the PaaS or CLI to listing OpenKruise workload display and operations. The lack of a general purpose Web-UI greatly hinder the adoption among developer users. This project is about to build a simple Web-UI that can list OpenKruise workload along with the native K8s workload, and support enhanced operation such as container restart or workload rollout. The Web-UI can be served directly as a dashboard , or as an example of OpenKruise integration in PaaS.\n- Expected Outcome: \n - simple Web-UI\n - integration of the Web-UI with existing PaaS such as [KubeSphere](https://dev-guide.kubesphere.io/extension-dev-guide)\n- Mentor(s):\n - Zhang zhen (@furykerry, furykerry@gmail.com)\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n- Recommended Skills: UX/UI, JavaScript, GoLang (a plus but not mandatory)\n- Upstream Issue: https://github.com/openkruise/kruise/issues/1497\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4d241a4b-e568-4033-8f08-72b0cac60311\n\n### OpenTelemetry\n\n#### One Logging Bridge per Language\n\n- Description: One of the goals set for the OpenTelemetry project in 2024 is to have at least one logging bridge per Language SIG, so that our end-users can start using OTLP Logging natively in their applications. While some languages have such a bridge already, some have the desire to implement at least one bridge but are lacking the engineering resources to do so. This internship starts by taking a look at the current state, marking which languages have a bridge already and which are lacking. The next step is to propose and implement at least one bridge for at least one language that doesn't have such a bridge yet.\n- Expected Outcome: At least one logging bridge is implemented for at least one language.\n- Recommended Skills: One (or more!) of the missing languages supported by OpenTelemetry\n - C++\n - Erlang\n - Go\n - JavaScript\n - PHP\n - Ruby\n - Swift\n- Mentor(s):\n - Juraci Paixão Kröhling (@jpkrohling, juraci.kroehling@grafana.com)\n - Andrzej Stencel (@andrzej-stencel, andrzej@andrzejstencel.pl)\n- Upstream Issue: https://github.com/open-telemetry/community/issues/1865\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2d114b9d-015e-40f4-bdd7-9acbb836d84e\n\n### Prometheus\n\n#### Client_golang CI/CD improvements\n\n- Description: Prometheus' client_golang is the Prometheus SDK for metrics instrumentation for Go applications. Client_golang promises full support for the 3 latests major Go versions, and for this task a lot of manual effort is executed by the community. Client_golang could receive several improvements around its CI/CD pipelines and automation:\n - Golang version upgrades requires autogenerating go files that Go Collector uses to collect Go runtime metrics.\n - Unit tests need to be run for the 3 latest Go versions, and running tests locally with different Go versions is hard at the moment. We can explore locally reproducible CI/CD.\n - The changelog of new releases still requires a lot of manual work, like going through commit history and hand-picking commits that need to be advertised. We want to explore automation around semantic conventional commits that allows Changelog/Release automation.\n- Recommended Skills: Go, Shell, CI/CD\n- Mentor(s):\n - [Arthur Sens](https://github.com/ArthurSens) (arthursens2005@gmail.com)\n - [Kemal Akkoyun](https://github.com/kakkoyun) (kakkoyun@gmail.com)\n- Issue: \n - https://github.com/prometheus/client_golang/issues/1434\n - https://github.com/prometheus/client_golang/issues/1435\n - https://github.com/prometheus/client_golang/issues/1436\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8c1ba948-5237-4bae-9dd2-ee9580b5a018\n\n### Service Mesh Performance\n\n#### Service Mesh Performance: Adaptive Load Control with Nighthawk\n\n- Description: The adaptive load controller operates by iteratively running optimization routines to ascertain the maximum load a system can sustain. Typically, this maximum load is determined by the system's capacity to handle requests per second (rps). The metrics, such as CPU usage and latency, collected from the system under test (SUT) serve as constraints to assess whether the SUT can sustain the imposed load. However, it lacks comprehensive lifecycle management functionalities. This hinders its adoption and limits its potential for continuous performance monitoring and optimization.\n- Expected outcome:\nImplement mechanisms to trigger alerts and notifications based on performance thresholds or significant changes in key metrics.\nIntegrate Nighthawk testing with existing CI/CD pipelines for automated performance validation and optimization as part of the development and deployment process.\n- Recommended Skills: Golang, familiarity with Service Mesh, grpc, docker, kubernetes\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Xin Huang (@gyohuangxin, xin1.huang@intel.com)\n- Upstream Issue: https://github.com/service-mesh-performance/service-mesh-performance/issues/416\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/98b9a7d7-4dd4-45aa-96f9-145e058efcee\n\n#### Service Mesh Performance: Distributed Load Testing with Nighthawk\n\n- Description: Many performance benchmarks are limited to single instance load generation (single pod load generator). This limits the amount of traffic that can be generated to the output of the single machine that the benchmark tool runs on in or out of a cluster. Overcoming this limitation would allow for more flexible and robust testing. Distributed load testing in parallel poses a challenge when merging results without losing the precision we need to gain insight into the high tail percentiles. Distributed load testing offers insight into system behaviors that arguably more accurately represent real-world behaviors of services under load as that load comes from any number of sources.\n- Expected Outcome: Implementation of distributed load generation in Nighthawk. Integration of Nighthawk with relevant service mesh performance testing scenarios. Capability to invoke Nighthawk for distributed load testing through APIs and command-line interfaces. Implementation of reporting mechanisms for distributed load testing results.\n- Recommended Skills: Golang, familiarity with HTTP/HTTPS performance testing tools, Service Mesh, grpc, familiarity with containerization technologies, like Docker would be helpful.\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Xin Huang (@gyohuangxin, xin1.huang@intel.com)\n- Upstream Issue: https://github.com/service-mesh-performance/service-mesh-performance/issues/415\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bad94872-bd61-4960-915a-ea1945ddd15c\n\n### Vitess\n\n#### Improve Unit Test Coverage\n\n- Description: Vitess is a scalable cloud-native database system for horizontal scaling of MySQL.The project is over 10 years old and there are parts of the code that don’t have very good unit test coverage. Revamping these code files and adding unit test coverage will help with the overall project health. Having strong unit testing is also useful in preventing introducing bugs when making code changes to these files. The task of the mentee would be to add said unit tests for the given code files. At the time of writing this proposal, the unit test coverage in Vitess stands at 47.3% of all lines of code.\n- Expected Outcome: Improved unit test coverage in Vitess.\n- Recommended Skills: Go, SQL, Unit testing\n- Mentor(s): \n - [Manan Gupta](https://github.com/GuptaManan100) (manan@planetscale.com)\n - [Harshit Gangal](https://github.com/harshit-gangal) (harshit@planetscale.com)\n- Issue: https://github.com/vitessio/vitess/issues/14931\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/efed074b-3c68-4337-90ab-2a3f2d15c836\n\n### Volcano\n\n#### Volcano supports multi-cluster AI workloads scheduling\n\n- Description: Volcano provides rich scheduling capabilities for AI workloads in the field of single cluster. In large model training scenarios, a single cluster cannot meet the computing power requirements of jobs, more and more users hope to submit jobs uniformly on multiple clusters for large model training, volcano needs to provide various scheduling capabilities, such as job management, gang scheduling, queue management, etc., and select the appropriate cluster for jobs to cope with the requirements of large model training.\n- Expected Outcome:\n - Implement a basic multi-clusters scheduling framework integrated with multi-clusters scheduler like [Karmada](https://github.com/karmada-io/karmada) or other multi-cluster orchestration.\n - Implement gang scheduling, fair scheduling in multi-cluster.\n - Implement queue management in multi-cluster.\n- Recommended Skills: Go, Kubernetes, Volcano\n- Mentor(s):\n - william wang(@william-wang, wang.platform@gmail.com)\n - Xuzheng Chang(@Monokaix, changxuzheng@huawei.com)\n- Upstream Issue: https://github.com/volcano-sh/volcano/issues/3310\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/132a4971-6969-4ca6-a695-783ece3ac768\n\n#### Volcano supports DRA integration\n\n- Description: [DRA](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) is a new generation device management mechanism for kubernetes. It introduces a new resource request API `ResourceClaim`, which requires kubelet, kube-controller-manager, scheduler, and third-party device management controllers to cooperate with each other to work. The kube-scheduler has implemented corresponding scheduling capabilities, Volcano also needs to implement the DRA scheduling plug-in to integrate the DRA function.\n- Expected Outcome:\n - A design document describing how to integrate DRA into volcano.\n - Implement DRA plugin in volcano.\n- Recommended Skills: Go, Kubernetes, Volcano\n- Mentor(s):\n - william wang(@william-wang, wang.platform@gmail.com)\n - Xuzheng Chang(@Monokaix, changxuzheng@huawei.com)\n- Upstream Issue: https://github.com/volcano-sh/volcano/issues/3143\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3c2d290a-6e93-4185-88f5-56736365fe85\n\n### WasmEdge\n\n#### Integrate MLX as a new WASI-NN backend\n\n- Description: LLM is a hot topic, there are more and more frameworks to make the execution of LLM faster. WasmEdge already integrated the [llama.cpp](https://github.com/ggerganov/llama.cpp) as one of the backend. And we want to bring more. [MLX](https://github.com/ml-explore/mlx) is an array framework on Apple silicon created by Apple machine learning research. With MLX, we believe it can have a huge improvement on macOS.\n- Expected Outcome: A new plugin provides a MLX [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) backend, a test suite for validating the plugin, documents and examples for explaining how to use the plugin.\n- Recommended Skills: C++, Wasm\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n - dm4 (@dm4, dm4@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3168\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/395d3659-e7c2-413f-8f95-42d079c9d0bc\n\n#### Integrate Intel Extension for Transformers as a new WASI-NN backend\n\n- Description: LLM is a hot topic, there are more and more frameworks to make the execution of LLM faster. WasmEdge already integrated the [llama.cpp](https://github.com/ggerganov/llama.cpp) as one of the backend. Running LLM with CPU only is huge for those users who don't have GPU. We would like to integrate [Intel Extension for Transformers](https://github.com/intel/intel-extension-for-transformers) as a new WASI-NN backend to provide a faster CPU inference performance.\n- Expected Outcome: A new plugin provides a Intel Extension for Transformers [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) backend, a test suite for validating the plugin, documents and examples for explaining how to use the plugin.\n- Recommended Skills: C++, Wasm\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n - dm4 (@dm4, dm4@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3169\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8b592388-6a17-4a8f-82e4-121131c217d0\n\n#### Integrate whisper.cpp as a new WASI-NN backend\n\n- Description: WasmEdge supports PyTorch, TensorFlow Lite, llama.cpp, and more NN backend. Dealing with the Voice to Text is a big thing that we want to achieve. To make it possible, we would like to integrate [whisper.cpp](https://github.com/ggerganov/whisper.cpp), a port of OpenAI's Whisper model in C/C++ as a new [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) backend.\n- Expected Outcome: A new plugin provides a whisper.cpp [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) backend, a test suite for validating the plugin, documents and examples for explaining how to use the plugin.\n- Recommended Skills: C++, Wasm\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n - dm4 (@dm4, dm4@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3170\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a5c2cc3e-a8fe-4fcb-b74f-be74b65a6385\n\n#### Integrate burn.rs as a new WASI-NN backend\n\n- Description: WasmEdge supports PyTorch, TensorFlow Lite, llama.cpp, and more NN backend. [Burn.rs](https://github.com/tracel-ai/burn) is a new deep learning framework built using Rust. The portability, flexibility, and compute efficiency are important to Wasm. That's why we would love to have `burn.rs` as a new [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) backend.\n- Expected Outcome: A new plugin provides a burn.rs [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) backend, a test suite for validating the plugin, documents and examples for explaining how to use the plugin.\n- Recommended Skills: Rust, Wasm\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n - dm4 (@dm4, dm4@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3172\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/16b35930-5b29-43af-b02c-cdf851069c85\n\n" }, { "path": "programs/lfx-mentorship/2024/01-Mar-May/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n- Upstream Issue:\n\n```\n\n---\n\n## Proposed Project ideas\n\n" }, { "path": "programs/lfx-mentorship/2024/02-Jun-Aug/README.md", "content": "# Term 02 - 2024 June - August\n\nStatus: Complete\n\nMentorship duration - three months (11 weeks - full-time schedule)\n\n### Timeline\n\n| activity | date |\n| --- | --- |\n| project proposals | Monday April 8 - Wed May 8, 2024, 5:00 PM PDT |\n| mentee applications open | Monday May 13 - Tues May 28, 5:00 PM PDT |\n| application review/admission decisions | Wed May 29 - Tues June 11, 5:00 PM PDT |\n| selection notifications | Wed June 12, 5:00 PM PDT |\n| Mentorship program begins with the initial work assignments | Monday June 17 (Week 1) |\n| Midterm mentee evaluations and first stipend payments | Wednesday July 24 (Week 6) |\n| Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals | Wed Aug 28, 5:00 PM PST (Week 12) |\n| Last day of term | Friday Aug 30 |\n\n### Project Instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2024/02-Jun-Aug/project_ideas.md, by April 24, 2024.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n## Accepted projects\n\n- [Cilium](#cilium)\n - [Cilium Technical Outcomes](#cilium-technical-outcomes)\n- [Copacetic](#copacetic)\n - [Add new scenarios to Copa's existing image patching features](#add-new-scenarios-to-copas-existing-image-patching-features)\n- [Crossplane](#crossplane)\n - [Make Crossplane Easy - Improving the Developer Experience](#make-crossplane-easy---improving-the-developer-experience)\n- [Harbor](#harbor)\n - [Harbor CLI](#harbor-cli)\n - [Harbor Satellite](#harbor-satellite)\n- [in-toto](#in-toto)\n - [Add GUAC support](#add-guac-support)\n - [Documentation Boost!](#documentation-boost)\n - [Sigstore support for in-toto-jenkins](#sigstore-support-for-in-toto-jenkins)\n- [Jaeger](#jaeger)\n - [Jaeger-V2 Observability and Healthchecks](#jaeger-v2-observability-and-healthchecks)\n - [Jaeger-V2 Service Performance Monitoring](#jaeger-v2-service-performance-monitoring)\n - [Jaeger-V2 Kafka-based architecture](#jaeger-v2-kafka-based-architecture)\n- [Karmada](#karmada)\n - [Certificate Lifecycle Management](#certificate-lifecycle-management)\n- [KCL](#kcl)\n - [KCL Package Management Dependencies Sparse Checkout](#kcl-package-management-dependencies-sparse-checkout)\n - [Optimization of KCL LSP prompt information](#optimization-of-kcl-lsp-prompt-information)\n - [Supports tree-sitter for KCL](#supports-tree-sitter-for-kcl)\n- [Knative](#knative)\n - [Improve Knative Eventing Onboarding](#improve-knative-eventing-onboarding)\n - [Knative - applying pre-prepared website design](#knative---applying-pre-prepared-website-design)\n- [KubeArmor](#kubearmor)\n - [Improve System Test Coverage and Pratices for KubeArmor](#improve-system-test-coverage-and-pratices-for-kubearmor)\n- [KubeEdge](#kubeedge)\n - [Iterating Enhancement for KubeEdge Dashboard](#iterating-enhancement-for-kubeedge-dashboard)\n - [Router Manager Support HA](#router-manager-support-ha)\n - [KubeEdge test cases enhancement](#kubeedge-test-cases-enhancement)\n - [KubeEdge Documentation Improvement](#kubeedge-documentation-improvement)\n- [Kubernetes](#kubernetes)\n - [Update Image Signing to Meet New Infra Requirements](#update-image-signing-to-meet-new-infra-requirements)\n- [Kubescape](#kubescape)\n - [Advanced Kubescape plugin features for VSCode](#advanced-kubescape-plugin-features-for-vscode)\n - [Backstage plugin that adheres to the new plugin system](#backstage-plugin-that-adheres-to-the-new-plugin-system)\n- [KWOK](#kwok)\n - [Enhancement of Test Cases](#enhancement-of-test-cases)\n - [Enhancement of Technical Outcomes](#enhancement-of-technical-outcomes)\n- [LitmusChaos](#litmuschaos)\n - [Revamp Litmus Helm Agent, UBI migration of Images](#revamp-litmus-helm-agent-ubi-migration-of-images)\n - [Enhancements in Chaoscenter: GitOps Support for Azure Git, Group Chaos Infra by Environments in Infrastructure Selection Modal](#enhancements-in-chaoscenter-gitops-support-for-azure-git-group-chaos-infra-by-environments-in-infrastructure-selection-modal)\n - [Implementing Upgrade Agent Support in Litmus 3.x](#implementing-upgrade-agent-support-in-litmus-3x)\n- [OpenKruise](#openkruise)\n - [Enhancement for Kruise-Game Dashboard](#enhancement-for-kruise-game-dashboard)\n- [Prometheus](#prometheus)\n - [Prometheus Remote Write Benchmarking Capabilities](#prometheus-remote-write-benchmarking-capabilities)\n - [Mark Out-of-order ingestion as stable](#mark-out-of-order-ingestion-as-stable)\n- [Thanos](#thanos)\n - [Compactor: Display TODO plan in UI](#compactor-display-todo-plan-in-ui)\n- [TUF](#tuf)\n - [Documentation analysis and improvements](#documentation-analysis-and-improvements)\n- [Vitess](#vitess)\n - [Improve the website of our automated-benchmarking tool (migrate to shadcn ui and typescript)](#improve-the-website-of-our-automated-benchmarking-tool-migrate-to-shadcn-ui-and-typescript)\n - [Community building and engagement](#community-building-and-engagement)\n- [WasmEdge](#wasmedge)\n - [Support piper as a new backend of the WASI-NN WasmEdge plugin](#support-piper-as-a-new-backend-of-the-wasi-nn-wasmedge-plugin)\n - [Enabling LLM fine tuning in the WASI-NN ggml plugin](#enabling-llm-fine-tuning-in-the-wasi-nn-ggml-plugin)\n - [Create a search-enabled API server for local LLMs](#create-a-search-enabled-api-server-for-local-llms)\n - [Finetune LLM models for Rust coding assistance](#finetune-llm-models-for-rust-coding-assistance)\n\n### Cilium\n\n#### Cilium Technical Outcomes\n\n- Description: On the Cilium [homepage](https://cilium.io), we want to document technical outcomes from using Cilium. Think of these technical outcomes as aggregating some of cilium features to achieve a high level technical goal. These are the current ones we have in mind: Zero Trust Networking, Network Automation, Distributed Firewalling, Cost and Carbon Savings, Multi-cloud Connectivity.\n- Expected Outcome: A section of the Cilium website detailing these technical outcomes. This section on the website can include any supporting materials from the Cilium community i.e blogs, videos, talks, illustrations, etc.\n- Recommended Skills: Technical Writing, some basic working knowlegde of Cilium or the willingness to quickly ramp up, Kubernetes, general familiarity with the cloud native ecosystem, basic React.js(the cilium webiste is built with Gatsby).\n- Mentor(s):\n - Paul Arah(paularah, )\n - Bill Mulligan(xmulligan, )\n- Upstream Issue: \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9ab5c6dc-4735-4dfb-99c0-d00e86aeae60\n\n\n### CNCF TAG Network\n\n#### Mapping CNCF Landscape one Relationship-at-a-time\n\n- Description: While the OpenAPI specifications for Kubernetes offer a taxonomy, integrating a graph data model with formalized ontologies unlocks a multitude of capabilities. Among these, enabling inferencing necessary for natural language processing stands out as a straightforward application. This, in turn, facilitates the possibility of a human-centric query/response interaction. Importantly, advancing to a knowledge semantic graph from a connected systems' graph data model opens the door to building more sophisticated systems.\n\n- Expected Outcome:\n - Identifying new technologies from CNCF landscape and creating new YAML-formatted definitions of one or more relationships.\n - Documentation of each relationship - per component.\n - Development of new types of genealogies - new types of ways in which resources relate to one another and how these relationships might be visualized.\n\n- Recommended Skills: Familiarity with Helm charts and Artifact Hub, basic familiarity with Kubernetes, and familiarity with CNCF different projects would be helpful\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Uzair Shaikh (@muzairs15, muzair.shaikh810@gmail.com)\n- Upstream Issue: https://github.com/cncf/tag-network/issues/39\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bec63054-bc32-4444-b6c5-2b427f527e16\n\n#### Technical Content Creation CNCF Challenges\n\n- Description: On a periodic basis, the CNCF would like to present a public challenge to those that are interested in participating (e.g. “Challenge: Distributed Tracing with Jaeger”).\n\nYour mission in this internship is technical content creation of said challenges through use of markdown, Meshery, and any number of other CNCF projects. Challenges will be created using the Meshery Playground and potentially published in the proposed CNCF Hub. They will be similar too, but slightly different from these [example tutorials](https://docs.meshery.io/guides/tutorials/).\n\nUnderstand that your challenges will be promoted through CNCF channels, reviewed by various project maintainers, and that each challenger (participant) will receive a certain number of points, depending upon whether or not they successfully complete the challenges that you create and in what timeframe they complete those challenges (the faster, the more points). Your challenges will need to vary in level of difficulty.\n\n- Expected Outcome:\n - 10+ new challenges published in CNCF Hub (and Meshery Catalog and Artifact Hub).\n - Challenges can contain more than one objective. Points are earned for each objective completed.\n - Bonus: Extend one or more of Meshery’s Learning Paths.\n\n- Recommended Skills: written English, Kubernetes, DevOps, and familiarity with any number of other CNCF projects, like Prometheus, CoreDNS, Istio, Jaeger, Helm, Harbor, OPA, Rook, SPIFEE, Flux, Argo, Flux, Falco, etc., Jekyll, strong organizational skills\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Nic Jackson (@nicholasjackson), jackson.nic@gmail.com)\n- Upstream Issue: https://github.com/cncf/tag-network/issues/40\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1a620529-f2be-4a6f-8b4d-0562731cb840\n\n\n### Copacetic\n\n#### Add new scenarios to Copa's existing image patching features\n- Description: This project will focus on a series of initial TODOs that are present in the codebase and that have been recently added as issues in GitHub. The issues range from adding custom image repos, to handling custom configuration at the package and system level.\n- Expected Outcome: Added features as suggested by current TODOs in code to enhance Copacetic user experience and features.\n- Recommended Skills: Go, Linux Package Management tools, container images, distroless images, Trivy, knowledge of Copacetic codebase would be useful.\n- Mentors(s):\n - Ashna Mehrotra (@ashnamehrotra, asmehrotra@microsoft.com)\n - Robert Kielty (@RobertKielty, robert.kielty@cncf.io)\n- Upstream Issues: https://github.com/project-copacetic/copacetic/issues/611\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/955a5956-de58-44ea-8760-d606feb82165\n\n### Crossplane\n\n#### Make Crossplane Easy - Improving the Developer Experience\n\n- Description: Crossplane is in use at scale in many production environments, but we get often get feedback that there are many obstacles to learn Crossplane and get to a successfully built production-ready control plane. A major reason for this learning curve is the lack of supporting tools and experiences on top of core Crossplane that could accelerate the community’s attempts to successfully build their platforms. These higher level experiences have recently become a focus for the project and we want to keep delivering awesome experiences that make Crossplane easier to use.\n- Expected Outcome: We expect the mentee to design and code multiple improvements to the Crossplane tooling from the issue linked below. We will start with smaller scoped issues to ramp up and then focus on a bigger deliverable such as adding [validation for Crossplane Functions](https://github.com/crossplane/crossplane/issues/5094). By the end of the term, the mentee will have multiple code PRs merged into the Crossplane codebase.\n- Recommended Skills: Go, Kubernetes, Crossplane, CLI tools, passion for DevEx\n- Mentor(s):\n - Jared Watts (primary) (@jbw976, jbw976@gmail.com)\n - Ezgi Demirel (secondary) (@ezgidemirel, ezgi@upbound.io)\n- Upstream Issue: https://github.com/crossplane/crossplane/issues/3957\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/87e81040-eb5e-4628-babd-820ef23cd261\n\n### Harbor\n\n#### Harbor CLI\n\n- Description: Harbor is a popular and widely adopted container registry. We have developed an initial CLI (https://github.com/goharbor/harbor-cli) that we would like to extend and implement additional functionality, and common workflows that are currently only present in the Web UI. We are seeking a Golangs experienced manatee who can work on the project independently.\n- Expected Outcome: Working Golang Harbor CLI which can be used in the CI/CD implementations that compliment the Web UI covering the typical workflows of Harbor administrators and users. Familiarity with Golang library spf13/cobra and REST/Open API. Well-documented CLI that users love to use, and with the corresponding architectural diagrams under the Harbor. Working CI/CD with GitHub actions that create multi architecture binaries and containers.\n- Recommended Skills: Golang, spf13/cobra\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Yan Wang (@wy65701436, yan-yw.wang@broadcom.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n- Upstream Issue: https://github.com/goharbor/harbor-cli/issues/41\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a8a71ad1-4a1b-422e-9928-01c153ac2daf\n\n#### Harbor Satellite\n\n- Description: In recent years, containers have extended beyond their traditional cloud environments, becoming increasingly prevalent in remote and edge computing contexts. These environments often lack reliable internet connectivity, posing significant challenges in managing and running containerized applications due to difficulties in fetching container images. To address this, the project aims to decentralize container registries, making them more accessible to edge devices. The need for a satellite that can operate independently, store images on disk, and run indefinitely with stored data is crucial for maintaining operations in areas with limited or no internet connectivity.\n Harbor Satellite aims to bring Harbor container registries to edge locations, ensuring consistent, available, and integrity-checked images for edge computing environments. This proposal outlines the development of a stateful, standalone satellite that can function as a primary registry for edge locations and as a fallback option if the central Harbor registry is unavailable.\n- Expected Outcome:\n The goal is to extend the proof of concept\n and demonstrate that such a solution practically works.\n Candidates should be able understanding and implementing the [image](https://github.com/opencontainers/image-spec) and [distribution spec](https://github.com/opencontainers/distribution-spec)\n to replicate images from a central registry to a registry on the edge location.\n- Recommended Skills: Golang, Container, Image-spec, Distribution-spec\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Yan Wang (@wy65701436, yan-yw.wang@broadcom.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n- Upstream Issue: https://github.com/goharbor/harbor/issues/20404\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/93a94aec-8026-4587-b840-52c96ab25020\n\n### in-toto\n\n### Add GUAC support\n\n- Description: The project aims to integrate Graph for Understanding Artifact Composition (GUAC) with in-toto, a framework safeguarding software supply chain integrity. [Graph for Understanding Artifact Composition (GUAC)](https://guac.sh/) aggregates software security metadata into a high fidelity graph database—normalizing entity identities and mapping standard relationships between them. This project seeks to extend in-toto's capabilities by incorporating GUAC, enabling users to query GUAC with Package URLs (purls) and retrieve pertinent attestations.\n- Expected Outcome: Adds functionality to query GUAC, retrieve and parse relevant attestations for the specified artifact.\n- Recommended Skills: Go, Python\n- Mentor(s):\n - Santiago Torres-Arias (@SantiagoTorres, santiagotorres@purdue.edu)\n - Pradyumna Krishna (@PradyumnaKrishna, git@onpy.in)\n- Upstream Issue: https://github.com/in-toto/attestation-verifier/issues/29\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/abfb7093-b057-40da-8be1-c67bd8839698\n\n#### Documentation Boost!\n\n- Description:\n - Help contributors get started with improving the documentation of CNCF projects and TAGs. To start, we'd like mentees to help to\n improve both the documentation of a project, and also encourage them to contribute to other projects. So, view the issues as a starting\n point to help start your career in open source.\n- Expected Outcome:\n - Develop effective documentation for CNCF projects. As a start, the CNCF project in-toto has a fairly clear set of requirements for what\n documentation changes are needed.\n- Recommended Skills:\n - Technical writing\n - Basic understanding of cloud native projects (or a desire to learn!)\n- Mentor(s):\n - Justin Cappos @JustinCappos jcappos@nyu.edu\n - Patrice Chalin @chalin chalin@cncf.io\n - Lukas Pühringer @lukpueh lukas.puehringer@nyu.edu\n- Upstream Issues:\n - https://github.com/in-toto/docs/issues/85\n - https://github.com/in-toto/docs/issues/90\n - https://github.com/in-toto/docs/issues/91\n - https://github.com/in-toto/docs/issues/92\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/34314eb1-0fc3-4802-ab04-2265418c2e48\n\n#### Sigstore support for in-toto-jenkins\n\n- Description: The [in-toto Jenkins plugin](https://github.com/in-toto/in-toto-jenkins-plugin) allows users to generate metadata in their build pipelines. Currently keys or credentials must be provided to the plugin to sign the metadata, whereas Sigstore offers keyless signing and verification. The addition of Sigstore transport will allow seamless uploading of metadata to Rekor transparency log. This project aims to enhance the Jenkins plugin by adding [Sigstore](https://www.sigstore.dev) support, allowing keyless signing and adding Sigstore transport.\n- Expected Outcome: in-toto-jenkins plugins gets support for Sigstore\n- Recommended Skills: Java, Jenkins\n- Mentor(s):\n - Santiago Torres-Arias (@SantiagoTorres, santiagotorres@purdue.edu)\n - Pradyumna Krishna (@PradyumnaKrishna, git@onpy.in)\n- Upstream Issue: https://github.com/in-toto/in-toto-jenkins-plugin/issues/6\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fd34fe37-e736-47bb-b0d5-54a2a0d9875a\n\n### Jaeger\n\n#### Jaeger-V2 Observability and Healthchecks\n\n- Description: Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. (1) Currently jaeger-v2 components are initialized without observability clients. We need to instantiate appropriate logging, tracing, and metrics clients and pass them to the components. The existing code uses internal metrics API, which needs to be bridged to OTEL metrics to minimize code changes. (2) Jaeger-v1 components can report their readiness using an internal health check API that is connected to the healthcheck endpoint on the admin port. We need to implement similar capability in Jaeger-v2.\n- Expected Outcome: Achieve parity in observability of jaeger-v2 compared to jaeger-v1\n- Recommended Skills: Go, scripting, CI/CD\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yash Sharma (yashrsharma44@meta.com)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/5240\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bd752f55-9080-4826-af09-ad86d3614ab2\n\n#### Jaeger-V2 Service Performance Monitoring\n\n- Description: Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. Jaeger-v1 implements a functionality known as [SPM](https://www.jaegertracing.io/docs/latest/spm/), but it requires a separately running OpenTelemetry Collector to produce metrics out of spans using [SpanMetrics Connector](https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/connector/spanmetricsconnector#section-readme). Since Jaeger-v2 is built on top of OTEL Collector, we can run SpanMetrics Connector directly in the Jaeger binary and simplify the setup for the users.\n- Expected Outcome: Achieve parity in SPM of jaeger-v2 compared to jaeger-v1. Implement integration tests. Update documentation accordingly.\n - Extra credit: implement metrics reader directly on top of Elasticsearch/Opensearch and bypass the need for Prometheus.\n- Recommended Skills: Go, scripting, CI/CD\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yash Sharma (yashrsharma44@meta.com)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/5240\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/574c4759-09fa-468d-9cfd-4fbb0fb98c09\n\n#### Jaeger-V2 Kafka-based architecture\n\n- Description: Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. The goal is to implement a deployment mode (supported in Jaeger-v1) that uses Kafka as an intermediate buffer for spans between collector and ingester. It should use the latest version of ibm/sarama driver ([related issue](https://github.com/jaegertracing/jaeger/issues/4591)) and support both original Jaeger formats as well as OpenTelemetry OTLP. It may be possible to utilize the Kafka exporter/receiver from OTEL contrib.\n- Expected Outcome: Achieve parity for Kafka-based deployment jaeger-v2 compared to jaeger-v1, including internal observability. Implement integration tests. Update documentation accordingly.\n- Recommended Skills: Go, scripting, CI/CD\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yash Sharma (yashrsharma44@meta.com)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/5240\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6c6181c6-030a-4053-af29-18f09e5e2c4f\n\n### Karmada\n\n#### Certificate Lifecycle Management\n\n- Description: The Karmada Certificate Lifecycle Management project addresses user challenges in certificate management, focusing on mitigating service disruptions and security risks due to expirations. Key goals include implementing a feature for real-time monitoring of certificates with advance notification for upcoming expirations; creating a comprehensive manual for manual replacement with best practices and visuals; allowing configurable certificate validity during deployment via CLI, Helm charts, and Operator; and designing an automated certificate rotation system to streamline certificate maintenance and ensure continuous security across Karmada environments.\n- Expected Outcome: Certificate Visibility Tool/Feature, Manual Certificate Replacement Guide, Updated Installation Tools with Customizable Certificate Validity, and Automated Certificate Rotation Solution Design or Integration\n- Recommended Skills: Golang, Kubernetes Admin, certificate management, Helm.\n- Mentor(s):\n - Hongcai Ren (@RainbowMango, qdurenhongcai@gmail.com)\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n- Upstream Issue: https://github.com/karmada-io/community/issues/69\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9120164b-feef-4a5a-bd2a-d9ac42bb8d4a\n\n### KCL\n\n#### KCL Package Management Dependencies Sparse Checkout\n\n- Description: `kpm` is a package management tool for KCL. When the scale of KCL project becomes larger and larger, and the external packages that KCL project relies on become more and more, `kpm` will become slow due to the need to download a large number of third-party dependencies. `kpm` needs to support `Sparse-Checkout`, which means downloading specific dependencies as needed rather than all of them, to improve the performance of the kpm.\n- Expected Outcome: When kpm requests dependencies, it can request specific content based on the actual use of the required dependencies, but not all of them.\n- Recommended Skills: golang, rust\n- Mentor(s):\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n - Pengfei Xu (@Peefy, xpf6677@gmail.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/kpm/issues/304\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/09391266-0de5-426b-9e11-ceb4c28202ef\n\n#### Optimization of KCL LSP prompt information\n\n- Description: Optimize KCL LSP(language server protocol) prompt information, including the implementation of type inlayhint and optimization of hover content rendering. Currently, KCL’s hover content is in plain text format and needs to be rendered into a more beautiful style.\n- Expected Outcome: Added type inlayhint in KCL IDE and optimize hover content render.\n- Recommended Skills: rust, LSP\n- Mentor(s):\n - Pengfei Xu (@Peefy, xpf6677@gmail.com)\n - Zheng Zhang (@He1pa, he1pa404@gmail.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/kcl/issues/1244\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6d85e491-332b-4667-9b57-6ec052310494\n\n#### Supports tree-sitter for KCL\n\n- Description: Tree-sitter is a parser generator tool and an incremental parsing library. In order to support more features of the IDE, we need a more complete syntax tree, and for easy integration with the community, we intend to use tree-sitter to build a more complete parser system for KCL.\n\n- Expected Outcome: Supports all of the current KCL syntax, which can pass all test cases.\n- Recommended Skills: rust, LSP\n- Mentor(s):\n - Zheng Zhang (@He1pa, he1pa404@gmail.com)\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/tree-sitter-kcl/issues/2\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/47661e9d-d390-45d8-b05e-0fb3a30612f4\n\n### Knative\n\n#### Improve Knative Eventing Onboarding\n\n- Description:\n Onboarding new end users into a sophisticated system like Knative Eventing presents significant challenges, especially as it involves understanding not only the operational components but also a distinct architectural style - event driven architecture (EDA). These issues are also seen in the current documentation which is often too technical and not geared towards practical guidance. This project seeks to perform a thorough investigation into the barriers that prevent smooth user onboarding and sustained engagement. By identifying these obstacles and developing clearer, more actionable onboarding materials, we aim to enhance the ease of entry and ongoing use of Knative Eventing for all users.\n\n- Expected Outcome:\n1. Produce a detailed report based on user research that outlines the current onboarding experience for new users of Knative Eventing. This report will highlight key barriers and challenges in the documentation and setup process, and recommend actionable improvements to make the onboarding process more user-friendly and less technically daunting.\n\n2. Implement the proposed changes within the Knative community by developing comprehensive onboarding materials and enhancing existing documentation to better support new users.\n\n- Recommended Skills: User Research, Communication, Technical Writing, Content Design\n\n- Mentor(s):\n - Leo Li (@Leo6Leo,leoli@redhat.com)\n - Mariana Mejia (@mmejia02, mariana.mejia@ocadu.ca )\n\n- Upstream Issue:\n https://github.com/knative/ux/issues/130\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1da7e3d2-b170-4236-a2c6-0fa4b0e792e3\n\n#### Knative - applying pre-prepared website design\n\n- Description: Current design of the Knative website (https://knative.dev) does not look modern and contains inconsistent style. Knative UX working group has prepared a new design for the website. We would like to get this design implemented on the website. We also want to ensure with this implementation that the figures in the website include alt text descriptions. We are not looking for full WCAG compliance though.Also, currently the website is not really responsive and doesn’t look good on a mobile device. The group also has a design for the mobile. Finally we have many diagrams on the website that have different styles. We would like to have these diagrams more cohesive. This part is an extended goal though.\n\n- Expected Outcome: New design applied to website; website is made responsive; diagrams look and feel more cohesive.\n\n- Recommended Skills: HTML, CSS, Markdown, SVG, Material for Mkdocs, Figma\n\n- Mentor(s):\n - Ali Ok (@aliok, aliok@redhat.com)\n - Calum Murray (@cali0707, cmurray@redhat.com)\n - Zainab Husain (@zainabhusain227, zainabhusain227@gmail.com)\n\n- Upstream Issue: https://github.com/knative/ux/issues/137\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e18d5c08-312d-4fc1-884c-47c676c12c87\n\n### KubeArmor\n\n#### Improve System Test Coverage and Pratices for KubeArmor\n\n- Description: KubeArmor supports securing many environments ranging from Kubernetes, unorchestrated containers, bare metal and virtual machines. Our testing matrix however doesn't cover many of these completely. In this project, we plan to improve this coverage by introducing automated testing of some of these environments and imrove the scenarios covered in some existing ones. These tests would be written using the Ginkgo framework and automated via GitHub workflows. The matrix we'll target can be found in the upstream issue.\n- Expected Outcome: Improved test coverage; Standards for writing tests for KubeArmor; Stabilization of KubeArmor\n- Recommended Skills: Go, Scripting, Kubernetes, CI/CD (GitHub Actions)\n- Mentor(s):\n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com)\n - Anurag Kumar (@kranurag7, kranurag7@linux.com)\n - Prashant Mishra (@primalpimmy, prashant20.pm@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1749\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a6a22ae5-856d-472f-9a11-17a2375b86ba\n\n### KubeEdge\n\n#### Iterating Enhancement for KubeEdge Dashboard\n\n- Description: Based on the previous release of KubeEdge, a version of the dashboard has been implemented. With the iterative updates of the backend API, the current dashboard may have several issues. In this project, we aim to iterate and update the dashboard to ensure its compatibility with the latest version of KubeEdge. Additionally, we want to refactor the dashboard using more mainstream frameworks such as Material and optimize the user experience of the dashboard.\n- Expected Outcome: new release Dashboard which supports new KubeEgde APIs.\n- Recommended Skills: KubeEdge, Front-end, nodejs\n- Mentor(s):\n - Hongbing Zhang (@HongbingZhang, hongbing.zhang@daocloud.io)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/dashboard/issues/22\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/174db042-047a-4036-a523-1598fa386325\n\n#### Router Manager Support HA\n\n- Description: Users need to communicate between the cloud and the edge. For example, the cloud calls the rest interface of the edge service. In this case, the routing management function of KubeEdge can be used. Currently, routing management function of KubeEdge has some problems in the case of multiple CloudCore copies. The main problem is that when there are multiple copies of CloudCore, whether the cloud sends messages to the edge or reports the message to the cloud, it is not known which CloudCore is sent to it for processing, and there is confusion in message management in the cloud. In this project, we hope router manager can be optimized to support multi-CloudCore scenario.\n- Expected Outcome: Support using router manager in multi-CloudCore scenario.\n- Recommended Skills: Golang, KubeEdge\n- Mentor(s):\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n - jiawei (@JiaweiGithub, jiawei.liu@daocloud.io)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/5561\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0cf43d24-c7f3-4792-81c9-bff4aa01a96e\n\n#### KubeEdge test cases enhancement\n\n- Description: Testing is an important task to ensure project stability, security, and other aspects. Since KubeEdge is built on top of native Kubernetes, in this project, we aim to integrate Kubernetes end-to-end (E2E) test cases into KubeEdge's CI. This integration will help ensure the native compatibility and usability of KubeEdge. Additionally, we also aim to improve the unit tests and increase the coverage of integration tests for KubeEdge.\n- Expected Outcome: Improve KubeEdge test coverage scenarios\n- Recommended Skills: Golang, KubeEdge\n- Mentor(s):\n - Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/5562\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ea773daf-d755-46ec-a80c-1eb5f8bbaf16\n\n#### KubeEdge Documentation Improvement\n\n- Description: Recently, we have updated the directory and structure of the community's official website documentation. We have listed some documentation improvement tasks. In this project, we would like you to have a thorough understanding of KubeEdge and complete these documentation optimization tasks to help users or developers gain a better understanding of and utilize KubeEdge effectively.\n- Expected Outcome: Document optimization of setup, usage guide, and developer guide, adding more FAQs, etc.\n- Recommended Skills: Kubernetes, KubeEdge, docs\n- Mentor(s):\n - zhiying (@zhiyingfang2022, zhiying.fang@daocloud.io)\n - wbc6080 (@wbc6080, wangbincheng4@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/website/issues/433\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0add127b-8504-4940-97ac-ad989f58e109\n\n### Kubernetes\n\n#### Update Image Signing to Meet New Infra Requirements\n\n- Description: The process that signs with Sigstore all container images released on community\n infra was designed for a different serving architecture. When the community\n moved to [registry.k8s.io](https://kubernetes.io/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/)\n and increased 10x the number of registries, the replication of signatures broke\n due to rate limits imposed on the new registries. As part of the project, you will\n be instrumental in implementing the new signing process currently being designed\n by the Kubernetes Release Engineering team. This project will involve heavy rewrites and\n refactoring of parts of the [Image Promoter](https://github.com/kubernetes-sigs/promo-tools),\n the tool that releases community images.\n- Expected Outcome: Implementation of the new signing process, ideally we'll fix\n all inconsistent signatures across community registries.\n- Recommended Skills: Go programming, strong container architecture and registry\n fundamentals, familiarity with [sigstore](https://www.sigstore.dev/),\n [go-containerregistry](https://github.com/google/go-containerregistry) and infrastructure (GCP & AWS).\n- Mentor(s):\n - Adolfo García Veytia (@puerco, puerco@stacklok.com)\n - Jeremy Rickard (@jeremyrickard jrickard@microsoft.com)\n - Marko Mudrinić (@xmudrii, mudrinic.mare@gmail.com)\n - Meha Bhalodiya (@mehabhalodiya, mehabhalodiya@gmail.com)\n- Upstream Issues:\n - https://github.com/kubernetes/registry.k8s.io/issues/187\n - https://github.com/kubernetes/release/issues/2962\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b17b4e21-0c42-4418-91a0-2db3579ffb52\n\n### Kubescape\n\n\n#### Advanced Kubescape plugin features for VSCode\n\n\n- Description: Kubescape has a VSCode plugin to facilitate applying configuration fixes that harden Kubernetes infrastrcutture without creating a burden of context switching on engineers tasked with security scanning and implementing their results.\n- Expected Outcome: Inetgrating container image scanning capabilities in the Kubescape VSCode plugin and implementing\n Kubescape's ability to apply fixes for configuration issues to YAML files or Helm charts directly within their development environment.\n\n- Recommended Skills: Javascript, some familiarity with the inner workings of the VSCode plugin system.\n- Mentor(s):\n - Ben Hirschberg (@slashben, ben@armosec.io)\n - David Wertenteil (@dwertent, dwertent@armosec.io)\n- Upstream Issue: [kubescape/Kubescape#1666](https://github.com/kubescape/kubescape/issues/1666)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b846284b-76e6-45f1-85da-cd36b9bb489e\n\n\n#### Backstage plugin that adheres to the new plugin system\n\n\n- Description: Backstage has become a popular option for an internal portal that provides information for engineers in different capacities. Creating a backstage plugin for Kubescape will ultimately help users achieve their goal of hardening Kubernetes clusters, by being able to view security posture information on Backstage and without context switching.\n- Expected Outcome: A Kubescape plugin for Backstage in which users will be able to get information about their security posture and highest risk workloads at a glance within the orgnizational portal.\n\n- Recommended Skills: Typescript, React, some familiarity with new Backstage plugin system.\n- Mentor(s):\n - Rotem Refael (@rotemamsa, rotem@armosec.io)\n - Matthias Bertschy (@matthyx, matthiasb@armosec.io)\n- Upstream Issue: [kubescape/Kubescape#1667](https://github.com/kubescape/kubescape/issues/1667)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1e20bf55-4bcf-40ef-afee-d2b73948cd79\n\n\n### Kubespray\n\n#### Kubernetes SIG Project Kubespray: bug fixes & enhance helm support for add-ons\n\n- Description: Kubespray is a sig project of Kubernetes. It helps deploy a production-ready Kubernetes cluster with Ansible. The project wants maintainers to help fix bugs and enhance the new features, as shown in the following link: https://github.com/kubernetes-sigs/kubespray/issues/5432. The project will start by tackling some 'help wanted' issues related to bug fixes and documentation. This initial involvement will help the mentee understand the Kubespray implementation and pave the way for potential maintainership.\n- Expected Outcome: Bug fix and enhancement of the helm support for add-ons.\n- Recommended Skills: Ansible, Kubernetes\n- Mentor(s):\n - Kay Yan (yankay, )\n - Mohamed Zaian (mzaian, )\n- Upstream Issue: https://github.com/kubernetes-sigs/kubespray/issues/5432\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/22b0ef86-d390-4ea2-b302-79e819dcbdfc\n\n\n### KWOK\n\n#### Enhancement of Test Cases\n\n- Description: KWOK (Kubernetes WithOut Kubelet) is a toolkit that enables setting up a cluster of thousands of Nodes in seconds. KWOK is currently being used by a number of projects for testing and performance. It is crucial that KWOK itself behaves consistently. The following tests are currently being considered: Unit Test, E2E Test, Edge Cases.\n- Expected Outcome: Improved test coverage for KWOK.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s):\n - Shiming Zhang (wzshiming, )\n - Zhenghao Zhu (Zhuzhenghao, )\n- Upstream Issue: https://github.com/kubernetes-sigs/kwok/issues/1062\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1969ce6c-5468-4842-89a2-06c020bd2ad1\n\n#### Enhancement of Technical Outcomes\n\n- Description: KWOK (Kubernetes WithOut Kubelet) is a toolkit that enables setting up a cluster of thousands of Nodes in seconds. On the KWOK homepage (https://kwok.sigs.k8s.io/), we aim to document the technical outcomes of using KWOK. These outcomes represent the aggregation of some of KWOK's features to achieve a high-level technical goal. Currently, we have the following areas of focus: Chaos Testing, Performance, Simulation, and Scalability.\n- Expected Outcome: A section of the KWOK website detailing these technical outcomes.\n- Recommended Skills: Kubernetes, Technical Writing\n- Mentor(s):\n - Shiming Zhang (wzshiming, )\n - Zhenghao Zhu (Zhuzhenghao, )\n- Upstream Issue: https://github.com/kubernetes-sigs/kwok/issues/1063\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ef8e7637-2eb6-4672-8f6c-c9f9f0677da0\n\n### LitmusChaos\n\n#### Revamp Litmus Helm Agent, UBI migration of Images\n\n- Description: The Litmus Helm Agent, one of the microservice in Litmus, requires modernization for compatibility with Litmus 3.x API changes. Simultaneously, migrating Litmus Chaos container images to Red Hat's Universal Base Image (UBI) enhances security and compatibility. This project aims to revitalize the Helm Agent and streamline image management, ensuring seamless integration and robust deployment in containerized environments.\n- Expected Outcome:\n - Seamless Integration: The Litmus Helm Agent will seamlessly support Litmus 3.x API changes, ensuring compatibility and uninterrupted functionality within the ecosystem.\n - Enhanced Security: Migrating Litmus Chaos container images to Red Hat's Universal Base Image (UBI) will bolster security and compatibility, optimizing deployment in diverse containerized environments.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s):\n - Sayan Mondal (@S-ayanide, sayan.mondal@harness.io)\n - Vedant Shrotria (@Jonsy13, vedant.shrotria@harness.io)\n - Raj Babu Das (@imrajdas, mail.rajdas@gmail.com)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/4634\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/98777e02-dc5b-4380-b6cb-c57603b56e37\n\n### Enhancements in Chaoscenter: GitOps Support for Azure Git, Group Chaos Infra by Environments in Infrastructure Selection Modal\n\n- Description: In this project, we aim to implement GitOps support specifically for Azure Git within Chaoscenter. Additionally, we will enhance the Infrastructure Selection Modal by introducing the capability to group chaos infrastructure based on environments, ensuring better organization and management.\n- Expected Outcome:\n - Seamless integration with Azure Git for GitOps workflows.\n - Introduction of environment-based grouping in the Infrastructure Selection Modal.\n - Improved chaos infrastructure management and user experience in Chaoscenter.\n- Recommended Skills: Golang, Kubernetes, ReactJS\n- Mentors(s):\n - Shubham Chaudhary (@ispeakc0de, shubham.chaudhary@harness.io)\n - Amit Das (@amityt, amit.das@harness.io)\n - Sahil Kumar (@SahilKr24, sahil.kumar@harness.io)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/4633\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e9bf62a9-a7f6-41bb-be7a-e16b7a35a58a\n\n### Implementing Upgrade Agent Support in Litmus 3.x\n\n- Description: Integrating an upgrade agent into Litmus 3.x streamlines Chaoscenter upgrades, eliminating the need for fresh installations. This feature ensures seamless transitions between versions, especially useful when facing significant changes.\n- Expected Outcome:\n - Seamless Upgrades: Integration of the Upgrade Agent ensures smooth transitions during Chaoscenter upgrades, removing the necessity for fresh installations.\n - Simplified Process: Users can upgrade from one version to another without the hassle of reinstallation, saving time and effort.\n- Recommended Skills: Golang, Kubernetes\n- Mentors(s):\n - Saranya Jena (@Saranya-jena, saranya.jena@harness.io)\n - Sarthak Jain (@SarthakJain26, sarthak.jain@harness.io)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/4632\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9ac6f8b4-4f76-41d0-b02b-89c79534e619\n\n\n### Meshery\n\n#### Meshery: Meshery: Project tutorials, design patterns, & publish reference architectures\n\n- Description: Meshery the CNCF’s 10th fastest growing project. As a cloud native manager, Meshery [integrates with 250+ projects](https://meshery.io/integrations) and technologies. For each CNCF project integrated with Meshery, tutorials, sample designs, and deployment patterns with reference architectures need to be created. For the earnest, DevOps-minded intern, this internship represents a vast opportunity to learn, document, and publish tutorials and best practices not only around Meshery, but for any number of the other CNCF projects, too. You will use the [Meshery Playground](https://play.meshery.io)\n\n- Expected Outcome:\n - 25+ new design patterns published in Meshery Catalog and Artifact Hub.\n - 5 new Meshery tutorials published in Meshery Docs.\n - Bonus: Extend one or more of Meshery’s Learning Paths.\n\n- Recommended Skills: written English, Kubernetes, DevOps, and familiarity with any number of other CNCF projects, like Jaeger, Helm, Harbor, Flux, Argo, Flux, Falco, etc., Jekyll, strong organizational skills\n- Mentor(s): Yash Sharma (@Yahsharma1911, yashsharma2572@gmail.com), Lee Calcote (@leecalcote, leecalcote@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/10888\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7ec5139b-fca8-43db-bafc-bdb2faa58047\n\n#### Meshery: End-to-End Testing with Playwright\n\n- Description: Meshery integrates with many other CNCF projects and technologies. Sustaining those integrations is only possible through automation. End-to-end testing with Playwright, GitHub Workflows, and self-documenting test reports is the means to the end of maintaining a healthy state of each of these [Meshery integrations](https://meshery.io/integrations).\n\n- Expected Outcome:\n - Successful migration of E2E tests from Cypress to the Playwright test library within the Meshery project.\n - Implementation of robust and reliable test cases using Playwright to cover a wide range of Meshery's E2E scenarios.\n - Documentation detailing the migration process, and guidelines for future contributions to maintain test quality.\n - Integration of Playwright test suite into the Meshery CI/CD pipeline to ensure continuous testing and reliability of the platform.\n- Recommended Skills: JavaScript, Playwright, GitHub Workflows, Jekyll, Markdown, familiarity with React or Nextjs would be helpful, CI/CD\n - Mentor Name: Aabid Sofi (@aabidsofi19, mailtoaabid01@gmail.com), Lee Calcote (@leecalcote, leecalcote@gmail.com),\n- Upstream Issue: https://github.com/meshery/meshery/issues/10890\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/62f4866e-9461-490d-890d-9f221a3941b4\n\n#### Meshery: Support versioning for Meshery designs\n\n- Description: Meshery design is a common practice of both configuring and operating cloud native infrastructure functionality in a single, universal file. We are seeking to enhance Meshery's capabilities by supporting automatic versioning of Meshery designs based on user sessions. This functionality will enable users to track changes made to their designs by individuals, facilitating the ability to rollback changes at any time.\n\n- Expected Outcome:\n - Update Meshery server and pattern engine to support Meshery design versioning.\n - Update UI to allow users to perform actions related to design versioning.\n - Document changes made in pattern engine and server.\n\n- Recommended Skills: Golang, Kubernetes, Meshery, Familiarity with Helm charts and Artifact Hub, familiarity with React, Nextjs would be helpful\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Uzair Shaikh (@muzairs15, muzair.shaikh810@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/10889\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8e1ab317-9043-4f29-8b83-9b9ffa2b8b40\n\n\n### OpenKruise\n\n#### Enhancement for Kruise-Game Dashboard\n\n- Description: The OpenKruiseGame Dashboard is presently in its basic form, and we aim to significantly expand its functionality going forward. We plan to introduce features such as the ability to filter game servers and perform batch updates on them.\n- Expected Outcome: new release Dashboard which supports searching, querying, updating objects in batch.\n- Recommended Skills: Kubernetes, nodejs, javascript\n- Mentor(s):\n - Qiuyang Liu (@chrisliu1995, chrisliu1995@163.com)\n - Zhongwei Liu (@ringtail, zhongwei.lzw@alibaba-inc.com)\n- Upstream Issue: https://github.com/openkruise/kruise-game/issues/139\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3967228d-75a7-4963-b092-f2e92fcd57c8\n\n### Prometheus\n\n#### Prometheus Remote Write Benchmarking Capabilities\n\n- Description: Prometheus remote write allows users to send their metrics to other time series databases. Though the [Prombench tool](https://github.com/prometheus/test-infra/tree/master/prombench) has existed for a number of years, it has never been extended to support performance testing of Remote Write in a realistic production like environment. With the upcomming Remote Write 2.0 changes to both the underlying implementation as well as the wire format, the need for benchmarking of remote write beyond static Go bechmark tests has increased.\n- Expected Outcome: Build additional (or extends existing) tooling, similar to Prombench’s [load-generator](https://github.com/prometheus/test-infra/tree/master/tools/load-generator) and [avalanche](https://github.com/prometheus-community/avalanche), to support scenarios under which remote write should be performance tested. For example; allowing gradual increases/decreases in # of active series, sudden spikes in active series, various amounts of latency in the server receiving the remote write data, etc. Time permitted, extend Prombench's test suite to include a set of Remote Write tests that can be run via a new command.\n- Recommended Skills: Go, some familiarity with Prometheus or metrics, basic Docker knowledge\n- Mentor(s):\n - Callum Styan (@cstyan, callumstyan@gmail.com),\n - Jesús Vázquez (@jesusvazquez, jesusvzpg@gmail.com)\n - Nico Pazos and Alex Greenbank from Grafana also available to help\n- Upstream Issue: https://github.com/prometheus/prometheus/issues/13995\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0462446f-aeea-4a19-9bd6-f4241ee5e8f2\n\n#### Mark Out-of-order ingestion as stable\n\n- Description: Prometheus is known by not accepting out-of-order samples during ingestion, but recently (2 years ago) [support was added behind a feature-flag](https://github.com/prometheus/prometheus/pull/11075). Since then, many improvements have been made to out-of-order ingestion and it has become one of the requirements for OTLP ingestion in Prometheus. We want to deliver Prometheus 3.0 in a few months, and that requires marking out-or-order ingestion as a stable feature. In this project we will clean up several smaller issues around out-of-order ingestion, hopefully marking it as stable by the end of the mentorship.\n- Recommended Skills: Go, familiarity with Prometheus TSDB.\n- Mentor(s):\n - Bryan Boreham (@bboreham, bjboreham@gmail.com)\n - Jesus Vazquez (@jesusvazquez, jesusvzpg@gmail.com)\n- Upstream Issue: https://github.com/prometheus/prometheus/issues/12631\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/454caa5a-6fd5-4e27-bde4-7649abf6d8ca\n\n\n### Service Mesh Performance\n\n#### Service Mesh Performance: Convergence of Network and Graph topologies\n\n- Description: Opens the door to leveraging algorithms in the areas of Centrality, Community Detection, Pathfinding, Topological Link Prediction, etc. Bringing to bear advances made in Machine Learning / AI / recommendation systems, fraud detection could really help to derive meaning and comprehension for future tools. Another example is how ML + graph approaches are used to find and determine the optimal molecular structure of atoms such that desired physical properties are targeted. This approach could be applied to the problem of workload sizing and estimation for service mesh operators and would-be adopters.\n\n- Expected outcome:\n - Use Neo4j's ability to create graph projections, which copy a subgraph to RAM so that algorithms can be efficiently run.\n- Recommended Skills: Golang, familiarity with Service Mesh, grpc, docker, kubernetes\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Xin Huang (@gyohuangxin, xin1.huang@intel.com)\n- Upstream Issue: https://github.com/service-mesh-performance/service-mesh-performance/issues/422\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c605139b-8736-477a-835a-c6b45112bee4\n\n\n### Thanos\n\n#### Compactor: Display TODO plan in UI\n\n- Description: In the Thanos Compactor UI there is visibility of the global block list and loaded block list. But it would be useful to also have a list of planned and currently running compaction groups in order to see what exactly is in progress. This way it would be easier to diagnose what the Thanos Compactor is currently working on, and possibly what is delaying the progress of compactions. This is especially useful if you have large TSDB blocks in S3 buckets that take time to get compacted.\n- Expected Outcome: We have an endpoint in Compactor that details compaction plan, and this is also visualized in a Compactor UI page.\n- Recommended Skills: Go, React, some familiarity with Prometheus and Thanos\n- Mentor(s):\n - Michael Hoffmann (@MichaHoffmann, mhoffm@posteo.de)\n - Saswata Mukherjee (@saswatamcode, saswataminsta@yahoo.com)\n- Upstream Issue: https://github.com/thanos-io/thanos/issues/7285\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/05b3d261-f874-4b8c-bd7e-c4fa83c979b4\n\n### TUF\n\n#### Documentation analysis and improvements\n\n- Description:\n - Open source projects need help with their documentation! The TUF project is a good place to start. We'd welcome help from others to help here\n and become contributors to other projects / TAGs later in the project period. The mentee will (with minimal guidance from the CNCF team and TUF project) do a [CNCF analysis](https://github.com/cncf/techdocs/blob/main/docs/analysis/howto.md) for the TUF documentation\n- Expected Outcome:\n - Both an improvement of project docs and the development of a new contributor. A mentee will understand how to do technical writing for an open source project.\n- Recommended Skills:\n - Technical writing\n - Basic understanding of security principles\n- Mentor(s):\n - Justin Cappos @JustinCappos jcappos@nyu.edu\n - Patrice Chalin @chalin chalin@cncf.io\n - Lukas Pühringer @lukpueh lukas.puehringer@nyu.edu\n- Upstream Issues:\n - https://github.com/cncf/techdocs/issues/162\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e35f28f9-f333-47a8-a76a-119567cf10ca\n\n### Vitess\n\n#### Improve the website of our automated-benchmarking tool (migrate to shadcn ui and typescript)\n\n- Description:\n - Vitess uses arewefastyet to automatically benchmark its codebase and ensure no performance regression is introduced. This tool benchmarks Vitess every day, and is used to visualize the results of those benchmarks. It is an important tool in the development cycle of Vitess and is used by its maintainers and adopters.\n - [Arewefastyet' website](https://benchmark.vitess.io) has changed quite a lot over the last year, we want to continue improving it by finishing the migration to TypeScript and by using Shadcn components.\n - Moreover, we want to make the website responsive and have a proper Figma that serves as a reference for current and future contributors.\n- Expected Outcome:\n - The mentee is expected to produce a Figma with the design of the website that will be co-authored with the mentor.\n - Re-vamp most of the pages using Shadcn and the design defined with the mentor at the start of the internship period.\n - Add type information for all/most components using TypeScript.\n- Recommended Skills:\n - Be skilled in React/Vite/TypeScript.\n - Must know how to simply use Docker and docker-compose.\n - Experience with Figma is a big plus.\n - Experience with Rest APIs and Golang is a plus too.\n- Mentor(s):\n - Florent Poinsard @frouioui florent@planetscale.com\n - Frances Thai @notfelineit frances@planetscale.com\n- Upstream Issue (URL): https://github.com/vitessio/arewefastyet/issues/525\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cba8a6c6-4b09-4618-98f7-bf24391e8c9e\n\n#### Community building and engagement\n\n- Description:\n - [Vitess](https://vitess.io) is a CNCF project that has been around for a while. It has a strong community of users and contributors. We want to continue growing this community and make sure that everyone feels welcome and included.\n- Expected Outcome:\n - The mentee is expected to evaluate contributor ladder schemes and rewards and produce a recommendation for the Vitess maintainers.\n - Once a decision is made, the mentee is expected to implement the decisions from the maintainer team.\n - The mentee is expected to collect data about Vitess usage from the community and publish the highlights as a blog post.\n - The mentee is expected to review the [Getting Started docs on the Vitess website](https://vitess.io/docs/20.0/get-started/) and enhance them to improve the onboarding experience.\n - The mentee is expected to research and recommend marketing opportunities for Vitess. These could be guest blog posts, podcasts, live streams etc.\n- Recommended Skills:\n - Excellent verbal and written communication skills.\n - Prior experience participating in an open source community is a plus.\n - Should be able to install and run Vitess according to the user guides.\n - Website development skills are a plus.\n- Mentor(s):\n - Deepthi Sigireddi @deepthi deepthi@planetscale.com\n - Florent Poinsard @frouioui florent@planetscale.com\n- Upstream Issue (URL): https://github.com/vitessio/vitess/issues/15895\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1e395914-9adb-4254-a02d-08e6e03e3b93\n\n### WasmEdge\n\n#### Support piper as a new backend of the WASI-NN WasmEdge plugin\n\n- Description: WasmEdge supports PyTorch, TensorFlow Lite, llama.cpp, and more NN backend. Dealing with the text-to-voice is a big thing that we want to achieve. To make it possible, we would like to integrate [piper](https://github.com/rhasspy/piper), A fast, local neural text-to-speech system in C++ as a new [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) backend.\n- Expected Outcome:\n - A new plugin provides a piper [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) backend\n - A test suite for validating the plugin\n - Documents and examples for explaining how to use the plugin.\n- Recommended Skills: C++, Wasm\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n - dm4 (@dm4, dm4@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3381\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/61014739-ac16-4188-bdab-c87c0a502470\n\n#### Enabling LLM fine tuning in the WASI-NN ggml plugin\n\n- Description: WasmEdge is a lightweight and cross-platform runtime for LLM applications. It allows developers to create LLM apps on a Mac or Windows dev machine, compile them to Wasm, and deploy them on Nvidia machines without any changes to the binary app. It achieves application portability across CPUs and GPUs by supporting a W3C standard API called [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn), which abstracts GPU-related AI functions as high-level APIs. At this stage, however, only inference functions are supported. In this project, we aim to support fine-tuning features in WasmEdge. It will improve the developer experience for WasmEdge-enabled LLM tools. To achieve this, we plan to extend the current WASI-NN spec by adding a set of extra APIs, and then implement them by delegating to corresponding functions in llama.cpp embedded in the WasmEdge GGML plugin.\n- Expected Outcome:\n - Use llama2-7b as the base LLM for fine-tuning; the final implementation should handle it correctly.\n - Extend the [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) spec if needed to support the fine-tuning feature.\n - Implement the fine-tuning functions inside [WASI-NN ggml plugin](https://github.com/WasmEdge/WasmEdge/blob/master/plugins/wasi_nn/ggml.h). They will call the corresponding functions in llama.cpp, as the inference functions do.\n - Implement the LoRA-related functions inside the WASI-NN ggml plugin to load the pre-trained LoRA and verify the fine-tuned model.\n - Documentation, examples, tutorials, and demonstration are required.\n- Recommended Skills: C++, WebAssembly, LLM fine-tuning\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n - dm4 (@dm4, dm4@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3209\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/41c5a3df-0b84-4b78-b343-bacfc2a3c4ff\n\n#### Create a search-enabled API server for local LLMs\n\n- Description: WasmEdge is a lightweight inference runtime for AI and LLM applications. The [LlamaEdge project](https://github.com/LlamaEdge) has developed an [OpenAI-compatible API server](https://github.com/LlamaEdge/LlamaEdge/tree/main/api-server) and a [server-side RAG app](https://llamaedge.com/docs/category/server-side-rag) based on WasmEdge. In this project, we aim to use the LlamaEdge components to build a new API server that incorporates real-time Internet search results into LLM answers.\n- Expected Outcome: An OpenAI-compatible local LLM API server that uses Google Search for supplemental context\n- Recommended Skills:\n - Rust language\n - LlamaEdge\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3372\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0a4e08a1-3404-46fc-b0d0-5117ec4ec119\n\n#### Finetune LLM models for Rust coding assistance\n\n- Description: WasmEdge is a lightweight inference runtime for AI and LLM applications. We want to build specialized and finetuned models for WasmEdge community. The model should be supported by WasmEdge and its applications should benefit the WasmEdge community.\n In this project, we will build and compare two finetuned model for Rust coding assistance.\n * A code review model. It aims to be a new backend for the [PR review bot](https://github.com/flows-network/github-pr-summary/) we currently use in the community.\n * A QA model. It should be able to answer user questions about the Rust language and provide explanations. Our goal is to provide an alternative to our [Learn Rust](https://flows.network/learn-rust) app.\n- Expected Outcome: Two finetuned models based on Llama3-8b for Rust code review and QA.\n- Recommended Skills:\n - Rust language\n - ChatGPT and Claude\n - LlamaEdge\n - llama.cpp\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3371\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d52d172e-598d-4817-be97-3338d5b96432\n" }, { "path": "programs/lfx-mentorship/2024/02-Jun-Aug/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n- Upstream Issue:\n\n```\n\n---\n\n## Proposed Project ideas\n\n" }, { "path": "programs/lfx-mentorship/2024/03-Sep-Nov/README.md", "content": "# Term 03 - 2024 September - November\n\nStatus: Ongoing\n\nMentorship duration - three months (12 weeks - full-time schedule)\n\n### Timeline\n\n| activity | date |\n|--------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------| \n| project proposals | Jul 3 - Jul 30 5:00 PM PDT |\n| mentee applications open | Jul 31 - Aug 13 5:00 PM PDT |\n| application review/admission decisions | Aug 14 - Aug 27 5:00 PM PDT |\n| selection notifications | Sept 3, 2024 5:00 PM PDT |\n| Mentorship program begins with the initial work assignments | Sept 9, 2024 | \n| Midterm mentee evaluations and first stipend payments | October 15, 2024 5:00 PM PDT (the week following the National Day holiday in China) |\n| Final mentee evaluations and mentee feedback/blog submission due, second and final stipend payment approvals | Nov 26, 2024 5:00 PM PDT (Giving some time after KubeCon NA) |\n| Last day of term | November 29, 2024 |\n\n### Project Instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here [2024/03-Sep-Nov/project_ideas.md](./project_ideas.md), by July 23, 2024.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n## Accepted projects\n\n\n* [Antrea](#antrea)\n * [Support application-level DNS caches when using FQDN-based security rules](#support-application-level-dns-caches-when-using-fqdn-based-security-rules)\n* [CNCF TAG Network](#cncf-tag-network)\n * [Interrelating Kubernetes Resources: Identifying relationships between all standard and custom resources](#interrelating-kubernetes-resources-identifying-relationships-between-all-standard-and-custom-resources)\n * [CNCF Challenges: Technical Content Creation](#cncf-challenges-technical-content-creation)\n* [Envoy Gateway](#envoy-gateway)\n * [IPv4/IPv6 Dual Stack Support](#ipv4ipv6-dual-stack-support)\n* [Harbor](#harbor)\n * [Harbor CLI](#harbor-cli)\n * [Harbor Satellite](#harbor-satellite)\n* [Inspektor Gadget](#inspektor-gadget)\n * [New gadget for detecting deadlocks](#new-gadget-for-detecting-deadlocks)\n * [Testing Inspektor Gadget gadgets on different kernel versions](#testing-inspektor-gadget-gadgets-on-different-kernel-versions)\n * [Exploring Chaos Engineering with eBPF and Inspektor Gadget](#exploring-chaos-engineering-with-ebpf-and-inspektor-gadget)\n * [Develop DNS/HTTP event generation capabilities in Inspektor Gadget](#develop-dnshttp-event-generation-capabilities-in-inspektor-gadget)\n* [Istio](#istio)\n * [Improve documentation build infrastructure](#improve-documentation-build-infrastructure)\n * [Implement new site search](#implement-new-site-search)\n* [Jaeger](#jaeger)\n * [Jaeger v2 Kubernetes Operator](#jaeger-v2-kubernetes-operator)\n * [Jaeger v2 Helm Chart](#jaeger-v2-helm-chart)\n* [Karmada](#karmada)\n * [Collect and visualize Karmada metrics](#collect-and-visualize-karmada-metrics)\n * [Enhance Karmada controller-manager and schedule testing coverage](#enhance-karmada-controller-manager-and-schedule-testing-coverage)\n * [Enhance the test coverage for the Karmada search, operator, and webhook components](#enhance-the-test-coverage-for-the-karmada-search-operator-and-webhook-components)\n* [KCL](#kcl)\n * [New local dependency storage for KCL package management tool](#new-local-dependency-storage-for-kcl-package-management-tool)\n * [The checksum check of the three-party dependencies](#the-checksum-check-of-the-three-party-dependencies)\n * [KCL Language Server Protocol Support on Lsp4IJ for Jetbrains IDEs](#kcl-language-server-protocol-support-on-lsp4ij-for-jetbrains-ides)\n* [Konveyor AI](#konveyor-ai)\n * [Intelli-j IDE plugin integration of analyzer-lsp for real time updates with Konveyor AI](#intelli-j-ide-plugin-integration-of-analyzer-lsp-for-real-time-updates-with-konveyor-ai)\n * [Enhancing Kai with Data Querying for Fine-Tuning and Potential InstructLab Integration](#enhancing-kai-with-data-querying-for-fine-tuning-and-potential-instructlab-integration)\n* [KubeArmor](#kubearmor)\n * [Implement Fuzz testing for KubeArmor Components](#implement-fuzz-testing-for-kubearmor-components)\n * [Support Podman and OCI Hooks support for unorchestrated environments](#support-podman-and-oci-hooks-support-for-unorchestrated-environments)\n * [Non K8s KubeArmor Enhancements](#non-k8s-kubearmor-enhancements)\n* [KubeEdge](#kubeedge)\n * [Decouple the node cooperation ability and batch management ability of the edgeapplication](#decouple-the-node-cooperation-ability-and-batch-management-ability-of-the-edgeapplication-)\n * [Elastic Inference for Deep Learning Models Using KubeEdge](#elastic-inference-for-deep-learning-models-using-kubeedge-)\n * [Multimodal Large Model Joint Learning Algorithm: Reproduction Based on KubeEdge-Ianvs](#multimodal-large-model-joint-learning-algorithm-reproduction-based-on-kubeedge-ianvs)\n * [Cloud-edge collaborative speculative decoding for LLM based on KubeEdge-Ianvs](#cloud-edge-collaborative-speculative-decoding-for-llm-based-on-kubeedge-ianvs)\n * [Integrate KubeEdge, Sedna, and Volcano for High-Performance Training Task Scheduling](#integrate-kubeedge-sedna-and-volcano-for-high-performance-training-task-scheduling-)\n* [Kubernetes](#kubernetes)\n * [Testeable documentation for the Pod Lifecycle events](#testeable-documentation-for-the-pod-lifecycle-events)\n* [Kyverno](#kyverno)\n * [Cleanup policy - Add deletion propagation support](#cleanup-policy---add-deletion-propagation-support)\n * [Controller autogen - Implement new approach to autogen](#controller-autogen---implement-new-approach-to-autogen)\n * [Kyverno CLI for the Mutate Existing Rule](#kyverno-cli-for-the-mutate-existing-rule)\n * [Policy Exceptions 3.0](#policy-exceptions-30)\n* [Meshery](#meshery)\n * [Meshery: End-to-End Testing with Playwright (Round 2)](#meshery-end-to-end-testing-with-playwright-round-2)\n * [Meshery: Migrate APIs to be schema-driven](#meshery-migrate-apis-to-be-schema-driven)\n * [Meshery: UI Migration from MUI v4 to MUI v5 and Sistent](#meshery-ui-migration-from-mui-v4-to-mui-v5-and-sistent)\n* [OpenKruise](#openkruise)\n * [Visualize Kruise Rollout progress with kubectl plugin](#visualize-kruise-rollout-progress-with-kubectl-plugin)\n * [Game operation and maintenance API](#game-operation-and-maintenance-api)\n* [Prometheus](#prometheus)\n * [Enhance Prometheus Benchmark Suite](#enhance-prometheus-benchmark-suite)\n * [Prometheus Remote-Write v2 support in otel-collector's `prometheusremotewriteexporter`.](#prometheus-remote-write-v2-support-in-otel-collectors-prometheusremotewriteexporter)\n* [Service Mesh Performance](#service-mesh-performance)\n * [CNCF Project Performance Test Dashboard](#cncf-project-performance-test-dashboard)\n* [Thanos](#thanos)\n * [Add support for hedged requests](#add-support-for-hedged-requests)\n* [Vitess](#vitess)\n * [Add new getting started examples](#add-new-getting-started-examples)\n* [WasmEdge](#wasmedge)\n * [WASM Serializer with new proposals](#wasm-serializer-with-new-proposals)\n * [Fix bugs found by fuzzer](#fix-bugs-found-by-fuzzer)\n * [Create an LLM app with deep understanding of a GitHub repo](#create-an-llm-app-with-deep-understanding-of-a-github-repo)\n * [Create a Wasm-based LLM app for financial analysts](#create-a-wasm-based-llm-app-for-financial-analysts)\n\n\n### Antrea\n\n#### Support application-level DNS caches when using FQDN-based security rules\n\nCNCF - Antrea: Application-Level DNS Caches for FQDN-Based Security Rules (2024 Term 3)\n\n- Description: Antrea provides [Network Policy APIs](https://github.com/antrea-io/antrea/blob/main/docs/antrea-network-policy.md) (in the form of K8s CRDs) for K8s cluster administrators and application developers to declare security rules in order to protect workloads. These APIs complement the [Network Policies supported natively in K8s](https://kubernetes.io/docs/concepts/services-networking/network-policies/). When using the Antrea-specific Network Policy APIs, it is possible to use Fully Qualified Domain Names (FQDNs) in order to select the list of external domains with which a K8s application is allowed to communicate, or forbidden from communicating. The current implementation of this feature is not compatible with applications which directly cache the result of DNS queries. We have found that this type of caching is frequent for Java applications, which greatly impacts the usability of FQDN-based security rules. We believe that by defining a new configuration parameter for the Antrea implementation, we can bypass the issue and ensure that the feature can be used even with such applications, providing of course that the parameter is set correctly by users.\n- Expected Outcome: Definition and implementation of a new configuration parameter (`minTLS`) for the Antrea Agent, which will ensure that FQDN-based security rules can be used even with application that cache DNS results. The implementation should come with a sufficient amount of tests (both unit tests and e2e tests), ensuring that the feature is working as expected.\n- Recommended Skills: familiarity with Golang, some knowledge about the K8s architecture and APIs, basic knowledge about networking in particular of the DNS protocol.\n- Mentor(s):\n - Quan Tian (@tnqn, tianquan23@gmail.com)\n - Yang Ding (@Dyanngg, dingyany1995@outlook.com)\n - Antonin Bas (@antoninbas, antonin.bas@gmail.com)\n- Upstream Issue: https://github.com/antrea-io/antrea/issues/6229\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/99e8e0a0-4d82-4ac5-88bc-55b1d1a2c1f4\n\n### CNCF TAG Network\n\n#### Interrelating Kubernetes Resources: Identifying relationships between all standard and custom resources\n\nCNCF - TAG Network: Relating Standard and Custom Kubernetes Resources (2024 Term 3)\n\n- Description: The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph.\n- Expected Outcome: \n - YAML-formatted definition of one or more relationships per Kubernetes resource.\n - Documentation of each relationship - per component.\n - Development of new types of genealogies - new types of ways in which resources relate to one another and how these relationships might be visualized.\n - Verification of functional relationships\n- Recommended Skills: DevOps, Kubernetes Administration, Light familiarity with all of the CNCF projects and a desire to study each project and their operators/resources.\n- Mentor(s):\n - Mentor Name: Uzair Shaikh (@muzairs15, muzair.shaikh810@gmail.com), Lee Calcote (@leecalcote, leecalcote@gmail.com),\n- Upstream Issue: https://github.com/cncf/tag-network/issues/43\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9a276131-1dd9-4816-8518-3da2ce9b6fb1\n\n#### CNCF Challenges: Technical Content Creation\n\nCNCF - TAG Network: CNCF Challenges: Technical Content Creation (2024 Term 3)\n\n- Description: On a periodic basis, the CNCF would like to present a public challenge to those that are interested in participating (e.g. “Challenge: Distributed Tracing with Jaeger”).\n\nYour mission in this internship is technical content creation of said challenges through use of markdown, Meshery, and any number of other CNCF projects. Challenges will be created using the Meshery Playground and published (in what is potentially the CNCF Hub). They will be similar too, but slightly different from these [example tutorials](https://docs.meshery.io/guides/tutorials/).\n\nUnderstand that your challenges will be promoted through CNCF channels, reviewed by various project maintainers, and that each challenger (participant) will receive a certain number of points, depending upon whether or not they successfully complete the challenges that you create and in what timeframe they complete those challenges (the faster, the more points). Your challenges will need to vary in level of difficulty. \n\n- Expected Outcome:\n - 5+ new challenges published\n - Challenges can contain more than one objective. Points are earned for each objective completed.\n - Bonus: Extend one or more of Meshery’s Learning Paths.\n\n- Recommended Skills: written English, Kubernetes, DevOps, and familiarity with any number of other CNCF projects, like Prometheus, CoreDNS, Istio, Jaeger, Helm, Harbor, OPA, Rook, SPIFEE, Flux, Argo, Flux, Falco, etc., Jekyll, strong organizational skills\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Nic Jackson (@nicholasjackson), jackson.nic@gmail.com)\n- Upstream Issue: https://github.com/cncf/tag-network/issues/44\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5c1b69c5-2315-4ec2-8883-7d59f1650a11\n\n### Envoy Gateway\n\n#### IPv4/IPv6 Dual Stack Support\n\nCNCF - Envoy Gateway: IPv4/IPv6 Dual Stack Support (2024 Term 3)\n\n- Description: Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Gateway API resources are used to dynamically provision and configure the managed Envoy Proxies. Currently the implementation only supports Kubernetes clusters with IPv4 enabled, and not IPv6\n- Expected Outcome:\n The managed Envoy Proxy fleet can\n - Accept connections/listen on an interface that has an IPv6 address assigned to it\n - Can route to IPv6 pod endpoints/addresses\n- Recommended Skills: Golang, familiarity with Kubernetes Networking\n- Mentor(s):\n - Jianpeng He (@zirain, zirain@tetrate.io)\n - Arko Dasgupta (@arkodg, arko@tetrate.io)\n- Upstream Issue: https://github.com/envoyproxy/gateway/issues/184\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/408607a5-22a7-469e-ba9b-773e8fb06ace\n\n### Harbor\n\n#### Harbor CLI\n\nCNCF - Harbor: Harbor CLI (2024 Term 3)\n\n- Description: Harbor is a popular and widely adopted container registry. LFX manatees have developed an initial CLI (https://github.com/goharbor/harbor-cli) that we would like to extend and implement additional functionality, and common workflows that are currently only present in the Web UI. We are seeking a Golang experienced manatee who can work on the project independently.\n- Expected Outcome: Working Golang Harbor CLI which can be used in the CI/CD implementations that compliment the Web UI covering the typical workflows of Harbor administrators and users. Familiarity with Golang library spf13/cobra and REST/Open API. Well-documented CLI that users love to use, and with the corresponding architectural diagrams under the Harbor. Working CI/CD with GitHub actions that create multi architecture binaries and containers.\n- Recommended Skills: Golang, spf13/cobra\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Yan Wang (@wy65701436, yan-yw.wang@broadcom.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n- Upstream Issue: https://github.com/goharbor/harbor-cli/issues/142\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/11beb7c5-02b3-4f33-9dc5-3480a43b0869\n\n#### Harbor Satellite\n\n- Description: Containers have extended beyond their traditional cloud environments, becoming increasingly prevalent in remote and edge computing contexts. These environments often lack reliable internet connectivity, posing significant challenges in managing and running containerized applications due to difficulties in fetching container images. To address this, the project aims to decentralize container registries, making them more accessible to edge devices.\n\n- Expected Outcome:\n The goal is to extend the proof of concept \n and demonstrate that such a solution practically works.\n Candidates should be able understanding and implementing the [image](https://github.com/opencontainers/image-spec) and [distribution spec](https://github.com/opencontainers/distribution-spec)\n to replicate images from a central registry to a registry on the edge location.\n- Recommended Skills: Golang, Container, Image-spec, Distribution-spec\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Yan Wang (@wy65701436, yan-yw.wang@broadcom.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n- Upstream Issue: https://github.com/goharbor/harbor/issues/20790\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ed963c1b-6697-4b3f-bef6-578cd9722f47\n\n### Inspektor Gadget\n\n#### New gadget for detecting deadlocks\n\nCNCF - Inspektor Gadget: New gadget for detecting deadlocks (2024 Term 3)\n\n- Description: Inspektor Gadget is an eBPF tool and systems inspection framework for Kubernetes, containers and Linux hosts. In this project, you will write a new gadget in BPF and WASM to detect deadlocks in applications. The BPF program will be attached on mutex locks and mutex unlocks functions with uprobes. The WASM program will build a mutex wait directed graph and look for cycles. Then, the gadget will display the stack trace showing the mutex locks causing the deadlock.\n\n This project builds upon previous work:\n\n - In a previous mentorship project, Inspektor Gadget gained support for uprobes and kernel stack traces (https://www.inspektor-gadget.io/blog/2024/06/supporting-uprobe-based-gadgets-lfx-mentorship-report/).\n - BCC tools include deadlock.py doing the same: https://github.com/iovisor/bcc/blob/master/tools/deadlock_example.txt and https://github.com/iovisor/bcc/blob/master/tools/deadlock.py\n\n However, this project still has challenging issues to resolve:\n\n - Inspektor Gadget does not support dumping stack traces from userspace applications yet\n\n- Expected Outcome: A new gadget detects lock order inversion and prints the stack traces where each mutex was acquired.\n\n- Recommended Skills: Go, BPF, WASM, graph data structure\n\n- Mentor(s):\n - Alban Crequy (@alban, albancrequy@microsoft.com)\n - Burak Ok (@burak-ok, burakok@microsoft.com)\n\n- Upstream Issue: https://github.com/inspektor-gadget/inspektor-gadget/issues/3194\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7fdda09c-0eb8-466b-9fdf-e4b3c6a1d5b3\n\n#### Testing Inspektor Gadget gadgets on different kernel versions\n\nCNCF - Inspektor Gadget: Testing Inspektor Gadget gadgets on different kernel versions (2024 Term 3)\n\n- Description: The Inspektor Gadget gadgets are heavily coupled to the kernel version as they need to access internal kernel data and use different eBPF features. One key feature for Inspektor Gadget is to hide all this complexity from its users: the gadgets should work the same regardless the kernel version they’re running in. To be sure our gadgets (and Inspektor Gadget too) are working fine, we need to run tests on different kernel versions we want to support.\n\n The purpose of this mentorship is to develop a framework that allows gadget developers to (1) implement unit tests for their gadgets (2) and run them on different kernel versions. A previous mentorship successfully implemented a framework for running integration tests (https://github.com/inspektor-gadget/inspektor-gadget/pull/2607), now it’s time to extend that framework to allow running unit tests as well. Some preliminary investigation done in (https://github.com/inspektor-gadget/inspektor-gadget/pull/2638) explored the possibility to use https://github.com/lmb/vimto, it seems it’s the right tool for the job.\n\nExpected Outcome: Gadget developers have a way to run unit tests in different kernel versions for their gadgets in their CI platform\n\n- Recommended Skills: Golang\n\n- Mentor(s):\n - Mauricio Vasquez Bernal (@mauriciovasquezbernal, mauriciov@microsoft.com)\n - Alban Crequy (@alban, albancrequy@microsoft.com)\n\n- Upstream Issue:\n - https://github.com/inspektor-gadget/inspektor-gadget/issues/3195\n - https://github.com/inspektor-gadget/inspektor-gadget/issues/1343\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a0e8bcc0-5c52-48ec-9959-506ce27ad46e\n\n#### Exploring Chaos Engineering with eBPF and Inspektor Gadget\n\nCNCF - Inspektor Gadget: Exploring Chaos Engineering with eBPF and Inspektor Gadget (2024 Term 3)\n\n- Description: Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production, ref. https://principlesofchaos.org/, i.e. to induce errors on a system and see how it behaves. eBPF can be used to induce such errors on a system, it can change the return value of a kernel function, drop or modify network packets, etc.\n\n The goal of this mentorship is to implement a set of gadgets for Inspektor Gadget that helps causing system chaos. These are some ideas of the gadgets that should be implemented:\n\n - DNS: Drop/modify/add latency DNS requests and/or responses based on\n - The container or process performing it\n - The target URL\n - The DNS server\n - TCP/UDP: Drop network packets based on\n - Destination / Source IPs\n - Originating or destination pod or process\n - Simulate system call failures based on\n - Container or process performing the syscall\n - Syscall\n\n The gadgets should expose metrics with the number of times it induced failures, and possibly also provide notifications when those errors were induced.\n\n- Expected Outcome: A set of gadgets with the above functionality should be implemented and merged on the upstream Inspektor Gadget repository. Those gadgets should include documentation and tests.\n\n- Recommended Skills: Golang, eBPF, networking protocols.\n\n- Mentor(s):\n - Michael Friese (@flyth, mfriese@microsoft.com)\n - Mauricio Vasquez Bernal (@mauriciovasquezbernal, mauriciov@microsoft.com)\n\n- Upstream Issue: https://github.com/inspektor-gadget/inspektor-gadget/issues/3196\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c99b5a1f-a1e8-4a9c-93f1-3ee965dabbae\n\n#### Develop DNS/HTTP event generation capabilities in Inspektor Gadget\n\nCNCF - Inspektor Gadget: DNS/HTTP Event Generation Capabilities (2024 Term 3)\n\n- Description: Inspektor Gadget enables users to inspect Linux containers and Kubernetes workloads, offering the powerful capability to monitor traffic for currently running applications. So far, gadgets can only passively monitor events, the ability to generate specific events would be a great addition to the existing features. For example, if users could trigger a DNS request from a specific pod or make an HTTP request to a particular endpoint, Inspektor Gadget could check if the request succeeded or not. Users would then be notified if there are errors/outages/problems in the cluster.\n\n- Expected Outcome: As part of the mentorship, you will:\n\n 1. Explore the best way to implement event generation, external program vs implementing it within Inspektor Gadget.\n 2. Develop DNS/HTTP event generator and see how it works with gadgets.\n 3. Use the event generation in our integration testing.\n\n- Recommended Skills: Golang, Kubernetes and Understanding of DNS/HTTP protocols.\n\n- Mentor(s):\n - Qasim Sarfraz (@mqasimsarfraz, qasimsarfraz@microsoft.com)\n - Burak Ok (@burak-ok, burakok@microsoft.com)\n\n- Upstream Issue: https://github.com/inspektor-gadget/inspektor-gadget/issues/3193\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c7ba30b5-625d-4086-ad09-c60071e01a8c\n\n### Istio\n\n#### Improve documentation build infrastructure\n\nCNCF - Istio: Improve documentation build infrastructure (2024 Term 3)\n\n- Description: The build infrastructure for istio.io currently carries a complete archived copy of the site for each release of Istio. These archived versions should be separated to their own branch, with only the supported versions published. We should also separate out content which is not version-specific (e.g. the home page, news and blogs) so that only the latest version of this content is visible online.\n- Expected Outcome: Updated publishing infrastructure for istio.io which separates evergreen content (home page, blogs) with versioned content (documentation). Drop-downs per docs page allow switching between the supported versions. \n- Recommended Skills: Systems engineering, scripting, programming (Go/Bash), Hugo templating\n- Mentor(s):\n - Craig Box (@craigbox, craig.box AT gee-mail)\n- Upstream Issue: https://github.com/istio/istio.io/issues/15463\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7a9cac67-6cfc-4915-bc39-8f2b5c1a4d00\n\n#### Implement new site search\n\nCNCF - Istio: Implement new site search (2024 Term 3)\n\n- Description: Up to four versions of Istio are supported at one time, and so the documentation for each must be available. Our current site search is outdated and needs to be replaced, so that the search content only exists in the site search, and only fresh content is available on google.com.\n- Expected Outcome: Working site search on istio.io, which lets you search for content for the currently supported versions.\n- Recommended Skills: Hugo, Systems engineering, scripting, programming (Bash/go), Hugo templating\n- Mentor(s):\n - Craig Box (@craigbox, craig.box AT gee-mail)\n- Upstream Issue: https://github.com/istio/istio.io/issues/15464\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/557f553d-6cab-41e5-925e-c8063dc99d7e\n\n### Jaeger\n\n#### Jaeger v2 Kubernetes Operator\n\nCNCF - Jaeger: Jaeger v2 Kubernetes Operator (2024 Term 3)\n\n- Description: Jaeger-v1 has its own Kubernetes Operator (https://github.com/jaegertracing/jaeger-operator) which deploys Jaeger components according to the deployment strategy as well as the database or datastore. The goal of this project is to develop a new operator for [Jaeger-v2](https://github.com/jaegertracing/jaeger/issues/4843) that achieves feature parity with the v1 operator while introducing improvements and new capabilities. This new operator will leverage the [OpenTelemetry operator](https://github.com/open-telemetry/opentelemetry-operator) for Jaeger-v2 deployment while maintaining and enhancing the storage management features from the v1 operator. More details in the [upstream issue](https://github.com/jaegertracing/jaeger/issues/5766).\n- Expected Outcome: By the end of this project, we aim to achieve full feature parity between the Jaeger v2 operator and the v1 operator, with the added benefits of OpenTelemetry integration. The new operator will provide a seamless experience for users, maintaining the robustness and flexibility of v1 while introducing the advantages of v2 and OpenTelemetry.\n- Recommended Skills: Go, scripting, kubernetes, operator framework, CI/CD\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/5766\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f15ad171-503c-41ae-b573-1e3088312dba\n\n#### Jaeger v2 Helm Chart\n\n- Description: Currently, Jaeger v1 has an official Helm chart (https://github.com/jaegertracing/helm-charts), but there isn't one yet for Jaeger v2. The goal of this project is to develop a comprehensive Helm chart for Jaeger v2 that allows for easy deployment and management of Jaeger v2 components in Kubernetes environments. This chart should provide flexibility in configuration, support various deployment scenarios, and integrate well with the new architecture of Jaeger v2. More details in the [upstream issue](https://github.com/jaegertracing/jaeger/issues/5767).\n- Expected Outcome: By the end of this project, we aim to have a production-ready Helm chart for Jaeger v2 that is:\n - Fully functional and tested on the current version of Kubernetes\n - Well-documented with clear usage instructions and examples\n - Flexible enough to support a wide range of deployment scenarios\n - Ready for submission to the official Jaeger Helm chart repository\n- Recommended Skills: Go, scripting, kubernetes, helm, CI/CD\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/5767\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/330c6397-06ed-481c-8c86-13fdcbce3896\n\n### Karmada\n\n#### Collect and visualize Karmada metrics\n\nCNCF - Karmada: Collect and visualize Karmada metrics (2024 Term 3)\n\n- Description: Karmada dashboard now supports one-time metric retrieval, but it is difficult to observe the status of multi-clusters with one-time metric retrieval. Therefore, we would like to implement a lightweight metric collection capability to collect Karmada metrics and visualize them on the Karmada dashboard. This will allow cluster administrators to quickly get the status of the clusters and solve problems within the clusters.\n- Expected Outcome:\n - Metric Collection and Storage Design Document\n - Query Analysis Interface & Front-end Visualization\n- Recommended Skills:\n - Kubernetes\n - Go\n - gin\n - react\n - sqlite\n- Mentor(s):\n - Wenjiang Ding (@warjiang, 1096409085@qq.com)\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n- Upstream Issue: https://github.com/karmada-io/dashboard/issues/62\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5af36c01-f146-4092-8920-97322df6589c\n\n#### Enhance Karmada controller-manager and schedule testing coverage\n\nCNCF - Karmada: Enhance Karmada controller-manager and schedule testing coverage (2024 Term 3)\n\n- Description: Karmada would like to improve the UT coverage of the code to better maintain the quality of the code and reduce the introduction of defects. Increase the UT coverage rate to 50% to 60% (currently, the UT coverage rate is [28.26%](https://app.codecov.io/gh/karmada-io/karmada) ). The entire Karmada repository is a bit large for one project, so we will split it into two projects. The current parts mainly target the `karmada-controller-manager` and `karmada-scheduler` components.\n- Expected Outcome:\n - Increase the UT (Unit Test) coverage by more than 25% and add more than 4000 lines of code coverage in the following directories.\n```\npkg/controllers\npkg/dependenciesdistributor\npkg/descheduler\npkg/detector\npkg/estimator\npkg/scheduler\npkg/resourceinterpreter\npkg/util\n```\n- Recommended Skills:\n - Go\n - Cloud Native\n- Mentor(s):\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n - Zhuang Zhang (@zhzhuang-zju, m17799853869@163.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/5235\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/78bd7568-0f36-4648-8a5c-2ba6444ac76a\n\n#### Enhance the test coverage for the Karmada search, operator, and webhook components\n\nCNCF - Karmada: Enhance Test Coverage for Search, Operator, and Webhook Components (2024 Term 3)\n\n- Description: Karmada would like to improve the UT coverage of the code to better maintain the quality of the code and reduce the introduction of defects. Increase the UT coverage rate to 50% to 60% (currently, the UT coverage rate is [28.26%](https://app.codecov.io/gh/karmada-io/karmada) ). The entire Karmada repository is a bit large for one project, so we will split it into two projects. The current focus is mainly on `karmada-search`, `karmada-operator`, `karmada-webhook` components.\n- Expected Outcome:\n - Increase the UT (Unit Test) coverage by more than 25% and add more than 5500 lines of code coverage except for the following directories.\n```\npkg/controllers\npkg/dependenciesdistributor\npkg/descheduler\npkg/detector\npkg/estimator\npkg/scheduler\npkg/resourceinterpreter\npkg/util\n```\n- Recommended Skills:\n - Go\n - Cloud Native\n- Mentor(s):\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n - Chaosi Pan (@chaosi-zju, chaosi@zju.edu.cn)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/5236\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1a732552-02b6-4b69-bbf6-d7ea12354e8d\n\n### KCL\n\n#### New local dependency storage for KCL package management tool\n\nCNCF - KCL: New local dependency storage for KCL package management tool (2024 Term 3)\n\n- Description: `kpm` is a package management tool for KCL. `kpm` needs to refactor the local storage structure of the current dependencies to support storage of packages with the same name from different OCI registes and caching of the remote dependencies.\n- Expected Outcome: The local storage structure has been designed in issue https://github.com/kcl-lang/kpm/issues/384, and the feature in issue need to be implemented.\n- Recommended Skills: golang\n- Mentor(s):\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n - Pengfei Xu (@Peefy, xpf6677@gmail.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/kpm/issues/384\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bf3f9155-df89-481d-ab8e-17c36a1d91da\n\n#### The checksum check of the three-party dependencies\n\n- Description: `kpm` is a package management tool for KCL. `kpm` currently lacks checksum verification for dependencies, so this part needs to be completed to support package integrity verification and package source verification\n\n- Expected Outcome: Complete the workflow of adding checksum through `kpm` when uploading package and verifying checksum through `kpm` when downloading package\n- Recommended Skills: golang\n- Mentor(s):\n - Pengfei Xu (@Peefy, xpf6677@gmail.com)\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n- Co-Mentor:\n - Akash Kumar (@AkashKumar7902, meakash7902@gmail.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/kpm/issues/394\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ade2c7db-ce6e-4c9c-bb4d-8a9e6ff1cf17\n\n#### KCL Language Server Protocol Support on Lsp4IJ for Jetbrains IDEs\n\n- Description: Currently, the KCL IDE plug-in based on Jetbrains LSP cannot support all versions of Jetbrains IDE, so migrate the KCL IDE plug-in to Lsp4IJ to support all versions of Jetbrains IDE.\n\n- Expected Outcome: KCL IDE plug-in is migrated to Lsp4IJ\n- Recommended Skills: Java\n- Mentor(s):\n - Zheng Zhang (@He1pa, he1pa404@gmail.com)\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/intellij-kcl-lsp/issues/3\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/dd72885b-3f85-44af-a176-dd04717fb6dc\n\n### Konveyor AI\n\n#### Intelli-j IDE plugin integration of analyzer-lsp for real time updates with Konveyor AI\n\nCNCF - Konveyor AI: IntelliJ plugin for Real-Time Updates with analyzer-lsp (2024 Term 3)\n\n- Description: Konveyor provides a unified experience of tools to help organizations modernize their applications at scale, transitioning them to Kubernetes and cloud-native technologies. Recently the Konveyor community began the development of a Generative AI approach for application modernization called Konveyor-AI. Konveyor AI accelerates application migration by discovering migration incidents in the source code and providing LLM-generated fixes in a diff view presentation. When proposed changes are accepted, it provides real-time updates on the number of incidents. The presentation side for this work is currently serviced via an IDE extension for VSCode.\nWe aim to expand Konveyor AI by developing an IntelliJ plugin. Our first step involves integrating the static code analysis tool, analyzer-lsp, into the IntelliJ plugin. We plan to create a common module for interaction with analyzer-lsp, which can be used in multiple IDE plugins, starting with VSCode and IntelliJ. Currently, the IntelliJ IDE uses the Konveyor CLI tool, Kantra, for analysis and transformation, but we need to replace Kantra with analyzer-lsp to optimize real-time updates.\n\n- Expected Outcome:\nDefine and implement a new module or library to facilitate integration of analyzer-lsp into multiple IDEs. We will start with VSCode and IntelliJ to begin.\n\n- Recommended Skills: Typescript, Java, Basic software development skills (command line, git)\n\n- Mentor(s):\n - Hiteshwari Patel (@hhpatel14, patelhiteshwari95@gmail.com)\n - Savitha Raghunathan (@sraghunathan, saveetha13@gmail.com)\n\n- Upstream Issue: https://github.com/konveyor/enhancements/issues/187\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0d392e44-e3ce-4799-8082-35ae48910f24\n\n#### Enhancing Kai with Data Querying for Fine-Tuning and Potential InstructLab Integration\n\nCNCF - Konveyor AI: Data Querying for Kai & InstructLab Integration Potential (2024 Term 3)\n\n- Description:\n - Kai is a tool designed to leverage AI for application modernization by analyzing code, identifying issues, and suggesting fixes. We aim to enhance Kai by developing a robust data querying mechanism to facilitate fine-tuning processes. This enhancement will lay the groundwork for potential future integration with InstructLab, an open-source AI project enabling community contributions to Large Language Models (LLMs) by adding new skills or knowledge. The primary focus will be on creating mechanisms to query and utilize data effectively, with a stretch goal of integrating static analysis tools and implementing an agent-based workflow.\n - This project will significantly enhance Kai’s backend, making it more scalable and capable of providing deeper code insights while also contributing to the enrichment of LLMs through InstructLab. It will offer a rich learning experience for participating students, covering backend development, workflow management, and contributing to open-source AI projects.\n\n- Expected Outcome:\n - Successfully develop and implement a data querying mechanism in Kai to facilitate fine-tuning processes.\n - Demonstrate the enhanced backend with improved data querying capabilities.\n - Participate actively in community meetings, presenting progress and insights.\n - Create a detailed blog post documenting the project, its outcomes, and potential future directions, including the possible integration with InstructLab.\n - (Stretch Goal) Develop a reusable module for agent-based workflows into Kai, enhancing its ability to detect and report code issues.\n\n- Recommended Skills:\n - Python\n - Podman / Docker\n - Basic Software Development skills (command line, git)\n \n- Mentor(s):\n - Jonah Sussman (@JonahSussman, jsussman@redhat.com)\n - Fabian von Feilitzsch (@fabianvf, fvonfeil@redhat.com)\n\n- Upstream Issue: https://github.com/konveyor/enhancements/issues/191\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8493016e-975f-4559-8833-db4c884b2fc5\n\n### KubeArmor\n\n#### Implement Fuzz testing for KubeArmor Components\n\nCNCF - KubeArmor: Implement Fuzz testing for KubeArmor Components (2024 Term 3)\n\n- Description: Implement fuzz testing for KubeArmor using a suitable tool like oss-fuzz or AFL. Generate a comprehensive input set to guide the fuzz testing, profile execution using tools like pprof to detect anomalies, and identify components such as the policy controller, operator, configmap handler, and GRPC endpoints for testing. Document the entire process for repeatability in future versions and develop an automation strategy for ongoing fuzz testing.\n- Expected Outcome: Improved OSSF Score; Standards for Fuzz Testing for KubeArmor; Stabilization of KubeArmor\n- Recommended Skills: Go, Kubernetes, Fuzz Testing Experience\n- Mentor(s):\n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com)\n - Prateek Nandle (@Prateeknandle, prateeknandle@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1367\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/91bd7201-e83f-444c-9157-f82f4c56d060\n\n#### Support Podman and OCI Hooks support for unorchestrated environments\n\nCNCF - KubeArmor: Support Podman and OCI Hooks support for unorchestrated environments (2024 Term 3)\n\n- Description: Leverage OCI hooks to obtain container start/stop events and container details for KubeArmor, replacing the current UNIX domain socket file method. Integrate Podman support for unorchestrated environments, ensuring policy enforcement and alerts/telemetry validation. Design the implementation to gather necessary container information and verify functionality with Podman as well as Containerd without Unix Socket.\n- Expected Outcome: Work with Podman in rootless mode and Eliminate exposing UNIX domain sockets for other container runtimes\n- Recommended Skills: Go, Container Runtime Interface, Linux\n- Mentor(s):\n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com)\n - Abdulrahman Elawady (@AbdelrahmanElawady, abdoelawady125@gmail.com)\n - Rishabh Soni (@rootxrishabh, risrock02@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1814\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c693a6b1-d034-4140-8aba-dfe02fbef48a\n\n#### Non K8s KubeArmor Enhancements\n\nCNCF - KubeArmor: Non K8s KubeArmor Enhancements (2024 Term 3)\n\n- Description: Extend KubeArmor features to non-Kubernetes environments by implementing karmor recommend for host policies and unorchestrated containers, and enabling dynamic configuration for default posture and visibility through kubearmor.yaml, a new gRPC service, and karmor commands. Enhance karmor profile for host logs, support karmor install for VMs, and validate policies for non-Kubernetes setups.\n- Expected Outcome: User friendly KubeArmor functionality including Application Behaviour and Policy Management in non-Kubernetes environments.\n- Recommended Skills: Go, Container Runtime Interface, Linux\n- Mentor(s):\n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com)\n - Prateek Nandle (@Prateeknandle, prateeknandle@gmail.com)\n - Rishabh Soni (@rootxrishabh, risrock02@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1815\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/87d64083-e1fa-4aa4-a828-ca24e5ae96b3\n\n### KubeEdge\n\n#### Decouple the node cooperation ability and batch management ability of the edgeapplication \n\nCNCF - KubeEdge: Decouple Node Cooperation and Batch Management in EdgeApplication (2024 Term 3)\n\n- Description: EdgeApplication can be overrides deployment spec(i.e. replicas, image, commands and environments) via the node group, and pod traffics are closed-loop in a node group(Deployments managed by EdgeApplication share a Service). But in the real scenario, the scope of nodes that need batch operations is different from that of nodes that need to collaborate with each other. Therefore, we need to have a solution to decouple the node cooperation ability and batch management ability of the edgeapplication. \n\n- Expected Outcome:\n - Proposal of this issue's solution. \n - Achieve that edgeapplication can be overridden via the node group or node label selector.\n - Fix the issue of closed-loop flow control.\n\n- Recommended Skills: Kubernetes, KubeEdge, Golang\n\n- Mentor(s):\n - Willard (@WillardHu, wei.hu@daocloud.io)\n - Elias Wang (@wbc6080, wangbincheng4@huawei.com)\n\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/5755\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/89fe7f6c-052b-4597-9ba3-c016858b1835\n\n#### Elastic Inference for Deep Learning Models Using KubeEdge \n\nCNCF - KubeEdge: Elastic Inference for Deep Learning Models Using KubeEdge (2024 Term 3)\n\n- Description: The rapid advancement of AI has led to the widespread application of deep learning models across various fields. However, the resource demands for model inference tasks can fluctuate significantly, especially during peak periods, posing a challenge to the system's computing capabilities. To address this varying load demand, we propose an elastic inference solution leveraging KubeEdge and Horizontal Pod Autoscaling (HPA) to enable dynamic scaling of inference tasks. By utilizing KubeEdge, we can distribute inference tasks across different edge devices and cloud resources, achieving efficient resource utilization and task processing.\n\n- Expected Outcome:\n - Based on kubeedge to complete an elastic scaling AI inference example\n - Based on kubeedge and sedna to complete the joint inference task elastic scaling development and output example\n - Output blog\n\n- Recommended Skills: \n - KubeEdge and its subproject Sedna frameworks.\n - Experience in deploying and managing Kubernetes, including configuring and tuning the HPA mechanism.\n - Expertise in developing and tuning deep learning models. \n - Programming experience, particularly in Python and Go.\n\n- Mentor(s):\n - ming tang (@tangming1996, ming.tang@daocloud.io)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/5753\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1f58cbe5-fe3a-4d0f-9875-b1725ecac223\n\n#### Multimodal Large Model Joint Learning Algorithm: Reproduction Based on KubeEdge-Ianvs\n\nCNCF - KubeEdge: Multimodal Large Model Joint Learning via KubeEdge-Ianvs Reproduction (2024 Term 3)\n\n- Description: KubeEdge-Ianvs currently focuses on edge-cloud collaborative learning (training and inference) for a single modality of data. However, edge devices, such as those in autonomous vehicles, often capture multimodal data, including GPS, LIDAR, and Camera data. Single-modal learning can no longer meet the precise inference requirements of edge devices. Therefore, this project aims to integrate mainstream multimodal large model joint learning algorithms into KubeEdge-Ianvs edge-cloud collaborative learning, providing multimodal learning capabilities.\n\n- Expected Outcome: A benchmark suite for multimodal large language models deployed at the edge using KubeEdge-Ianvs\n - Modify and adapt the existing edge-cloud data collection interface to meet the requirements of multimodal data collection\n - Implement a Multimodal Large Language Model (MLLM) benchmark suite based on Ianvs\n - Reproduce mainstream multimodal joint learning (training and inference) algorithms and integrate them into Ianvs single-task learning\n - (Advanced) Test the effectiveness of multimodal joint learning in at least one of Ianvs' advanced paradigms (lifelong learning, incremental learning, federated learning, etc.).\n\n- Recommended Skills: TensorFlow/Pytorch, LLMs, KubeEdge-Ianvs\n\n- Mentor(s):\n - Chuang Hu (@CreativityH, hchuchuang@gmail.com)\n - Zimu Zheng (@MooreZheng, zimu.zheng@huawei.com)\n\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/123\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d5d315c7-aaee-46ee-895e-a0f9e6ffed4b\n\n#### Cloud-edge collaborative speculative decoding for LLM based on KubeEdge-Ianvs\n\nCNCF - KubeEdge: Cloud-Edge Speculative Decoding for LLM via KubeEdge-Ianvs (2024 Term 3)\n\n- Description: The autoregressive decoding mode of LLM determines that LLM can only be decoded serially, which limits its inference speed. Speculative decoding technique can be used to decode LLM in parallel with the help of draft model, so as to improve the inference speed of LLM without loss of accuracy. However, the speculative decoding technology of LLM does not consider the application in the cloud-edge distributed environment. This project aims to implement cloud-edge collaborative speculative decoding based on KubeEdge-Ianvs, an open source cloud-edge collaborative distributed machine learning platform, so as to further improve the LLM inference speed in cloud-edge environment.\n\n- Expected Outcome:\n - Implement an example of cloud-edge collaborative speculative decoding based on KubeEdge-Ianvs platform.\n - (Optional) Propose a more efficient cloud-edge collaborative speculative decoding algorithm.\n\n- Recommended Skills: KubeEdge-Ianvs, LLM, Pytorch, Python\n\n- Mentor(s):\n - Shijing Hu (@hsj576, sjhu21@m.fudan.edu.cn)\n - Zimu Zheng (@MooreZheng, zimu.zheng@huawei.com)\n\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/126\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bfa8251f-a975-4e07-8e7a-915df3518551\n\n#### Integrate KubeEdge, Sedna, and Volcano for High-Performance Training Task Scheduling \n\nCNCF - KubeEdge: Integrate KubeEdge, Sedna, and Volcano for Efficient Task Scheduling (2024 Term 3)\n\n- Description: KubeEdge and Sedna have already enabled edge-cloud collaborative training and collaborative inference capabilities. We aim to explore and foster collaborations with more communities to provide enhanced AI capabilities. By integrating Volcano, we aim to achieve high-performance scheduling within the cloud-edge collaborative framework, thereby pushing the boundaries of what can be achieved in distributed AI and edge computing.\n\n- Expected Outcome: \n - Successfully deploy a training task using KubeEdge and Sedna, and provide an example in the\n - Integrate Volcano within Sedna's architecture to achieve high-performance scheduling of training tasks\n - (Optional) Successfully deploy Kubeflow within the KubeEdge architecture and complete the deployment of an training task, with a blog post documenting the process.\n\n- Recommended Skill: KubeEdge, KubeEdge-Sedna, Volcano\n\n- Mentor(s): \n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n - Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/5762\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/49fa6dab-9cb5-4889-bbeb-66c4a5545f8f\n\n### Kubernetes\n\n#### Testeable documentation for the Pod Lifecycle events\n\n- Description: Kubernetes Pods are the unit of execution. Pods's API surface is limited, but yet presenting many challenges for people authoring complex behaviors like proper graceful termination, probes, or advances initialization behaviors. Documentation and testing of those scenarios is limited. The misunderstanding of pod lifecycle and edge casesoften lead to reliability issues in Pods. Lately there were limited efforts to document and test those behaviors. Creating a skaffolding to document and test those behaviors will help temendously the Kubernetes project as well as end users.\n- Expected Outcome: Skaffolding in https://github.com/kubernetes/website/ to add new pod lifecycle behavios descriptions. Tests for those edge cases. And cross linking between tests and documentation.\n- Recommended Skills: familiarity with Golang, some knowledge about the K8s and containers, understanding of Hugo is a plus.\n- Mentor(s):\n - Sergey Kanzhelev (@SergeyKanzhelev, S.Kanzhelev@live.com)\n - Tim Allclair (@tallclair, tallclair@google.com)\n- Upstream Issue: https://github.com/kubernetes/kubernetes/issues/126369\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/127b628a-a5f1-4ced-a2ac-7892148699a0\n\n### Kyverno\n\n#### Cleanup policy - Add deletion propagation support\n\n- Description: Support specifying the deletion propagation policy in cleanup policies and TTL-based cleanup.\n- Expected Outcome:\n1. Support specifying the deletion propagation policy in cleanup policies\n2. Support specifying the deletion propagation policy with TTL-based cleanup\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s):\n - Charles-Edouard Brétéché (@eddycharly, charled.breteche@gmail.com)\n - Vishal Choudhary (@vishal-chdhry, vishal.choudhary@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/10755\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6d3ce005-6d61-48ad-a50c-00e3bed91c29\n\n#### Controller autogen - Implement new approach to autogen\n\n- Description: Implement a new policy rules autogen system based on extracting the pod spec from higher-level controllers.\n- Expected Outcome:\n1. The new system works by applying the same rules on the extracted pod spec instead of generating new rules for higher-level controllers\n2. The system treats pods and higher-level controllers exactly the same from a policy stand point\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s):\n - Charles-Edouard Brétéché (@eddycharly, charled.breteche@gmail.com)\n - Vishal Choudhary (@vishal-chdhry, vishal.choudhary@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/10756\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0f2bbc4b-6caa-42fa-a697-d20c1e89ca09\n\n#### Kyverno CLI for the Mutate Existing Rule\n\nCNCF - Kyverno: Kyverno CLI for the Mutate Existing Rule (2024 Term 3)\n\n- Description: Support the mutateExisting rule in Kyverno CLI\n- Expected Outcome: Allow users to be able to apply mutate existing policies to resources from 1. file systems; 2. clusters.\n- Recommended Skills: Golang, Kubernetes, Cobra\n- Mentor(s):\n - Shuting Zhao (@realshuting, shuting@nirmata.com)\n - Mariam Fahmy (@MariamFahmy98, mariam.fahmy@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/4354\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/56bf0ae9-a919-42df-bd0e-e3d6910cbeef\n\n#### Policy Exceptions 3.0\n\nCNCF - Kyverno: Policy Exceptions 3.0 (2024 Term 3)\n\n- Description: Support some enhancements to Policy Exceptions.\n- Expected Outcome:\n1. Support list of PolicyException namespaces (--exceptionNamespace flag)\n2. PolicyExceptions to have a status object and report readiness in printer column\n3. Support imageReferences in Policy Exceptions for verify image rules\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s):\n - Mariam Fahmy (@MariamFahmy98, mariam.fahmy@nirmata.com)\n - Shuting Zhao (@realshuting, shuting@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/9478\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5632d7c3-a383-4e31-816a-7b38d89a327f\n\n### Meshery\n\n#### Meshery: End-to-End Testing with Playwright (Round 2)\n\nCNCF - Meshery: End-to-End Testing with Playwright (2024 Term 3)\n\n- Description: Meshery integrates with many other CNCF projects and technologies. Sustaining those integrations is only possible through automation. End-to-end testing with Playwright, GitHub Workflows, and self-documenting test reports is the means to the end of maintaining a healthy state of each of these [Meshery integrations](https://meshery.io/integrations). \n \n- Expected Outcome: \n - Successful migration of E2E tests from Cypress to the Playwright test library within the Meshery project.\n - Implementation of robust and reliable test cases using Playwright to cover a wide range of Meshery's E2E scenarios.\n - Documentation detailing the migration process, and guidelines for future contributions to maintain test quality.\n - Integration of Playwright test suite into the Meshery CI/CD pipeline to ensure continuous testing and reliability of the platform.\n- Recommended Skills: JavaScript, Playwright, GitHub Workflows, Jekyll, Markdown, familiarity with React or Nextjs would be helpful, CI/CD\n - Mentor Name: Aabid Sofi (@aabidsofi19, mailtoaabid01@gmail.com), Lee Calcote (@leecalcote, leecalcote@gmail.com),\n- Upstream Issue: https://github.com/meshery/meshery/issues/11494\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a9113576-7216-46a7-bc9a-f922c1c62f8d\n\n#### Meshery: Migrate APIs to be schema-driven\n\nCNCF - Meshery: Migrate APIs to be schema-driven (2024 Term 3)\n\n- Description: Enhance Meshery’s APIs capability by migrating to a schema-driven approach, which will ensure consistency, validation, and easier integration. It involves versioning and defining API schemas using OpenAPI/Swagger at https://github.com/meshery/schemas and auto generating structs. You will be ensuring all Meshery APIs aligns with defined schemas and are consistent.\n\n- Expected Outcome: Identifying APIs and updating them to conform these schemas. Enhance API documentation to reflect the schema-driven approach. Updating APIs to ensure they are consistent and doing validation against defined schemas.\n\n- Recommended Skills: Golang, Kubernetes, Swagger, JSON schemas, familiarity with React, Nextjs would be helpful\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Yash Sharma (@Yashsharma1911, yashsharma2572@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/11495\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/796982d7-09b9-40b3-94f2-3b32cdcdfbf6\n\n#### Meshery: UI Migration from MUI v4 to MUI v5 and Sistent\n\nCNCF - Meshery: UI Migration from MUI v4 to MUI v5 and Sistent (2024 Term 3)\n\n- Description: Meshery's UI is powerful and utilizes frameworks like Next.js and Material-UI. However, it relies on outdated technology stacks, resulting in performance inefficiencies and increased maintenance overhead.\n- Expected Outcome: Migrate from MUI v4 to MUI v5 and fully utilize features of Nextjs v13 and Sistent. Migrate all class based components to function based components. Reduced code complexity and improved maintainability for long-term sustainability. Responsive and accessible UI that adapts to diverse devices and user needs.\n- Recommended Skills: ReactJs, NextJs, familiarity with Material UI, Redux and Redux Toolkit\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Antonette Caldwell (@nebula-aac, pullmana8@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/11493\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c98d0652-03c1-4409-bf1c-7240a4947d39\n\n### OpenKruise\n\n#### Visualize Kruise Rollout progress with kubectl plugin\n\nCNCF - OpenKruise: Visualize Kruise Rollout progress with kubectl plugin (2024 Term 3)\n\n- Description: [Kruise Rollout](https://github.com/openkruise/rollouts) provide plugin-n-play progressive delivery for cloud native apps. The goal of this project is to develop a kubectl plugin so as to visualize rollout progress, e.g. the rollout steps, traffic status and involved pods. The kubectl plugin can leverage the existing [kruise kubectl plugin project](https://github.com/openkruise/kruise-tools), and can use the [Argo kubectl plugin](https://argo-rollouts.readthedocs.io/en/stable/features/kubectl-plugin/#visualizing-rollouts-and-experiments) as a reference.\n- Expected Outcome: \n * kruise-tools enhancement for kruise rollout visualization\n * Well-documented with clear usage instructions and examples\n- Mentor(s):\n - Zhang Zhen (@furykerry, furykerry@gmail.com)\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n- Recommended Skills: Kubernetes, GoLang\n- Upstream Issue: https://github.com/openkruise/kruise-tools/issues/94\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/766ae869-a807-470c-aec2-e63ead04e0e2\n\n#### Game operation and maintenance API\n\nCNCF - OpenKruise: Game operation and maintenance API (2024 Term 3)\n\n- Description: kruise-game contains two CRDs GameServer and GameServerSet. Game servers can be managed by deploying or changing the corresponding CR. However, in actual production use, a release or operation and maintenance action is often a combination of a series of operations on CR. For example, set the GameServer image tag with ids 1, 7, and 10 to v0.3; adjust the update priority of GameServer with ids 5, 9, and 11 before updating the game server, etc. Therefore, a set of APIs with operation and maintenance semantics is needed, which users can directly use or integrate into their own operation and maintenance platform to facilitate operation and maintenance operations.\n- Expected Outcome:\n * A service component that includes multiple APIs\n- Recommended Skills: Golang, Kubernetes, RESTful API\n- Mentor(s):\n - Liu Zhongwei (@ringtail, zhongwei.lzw@alibaba-inc.com)\n - Liu Qiuyang (@chrisliu1995, chrisliu1995@163.com)\n- Upstream Issue: https://github.com/openkruise/kruise-game/issues/166\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1f2605c8-c9f3-4a13-95d5-062bd024f9be\n\n### Prometheus\n\n#### Enhance Prometheus Benchmark Suite\n\n- Description: PromBench is the automated system for benchmarking Prometheus, intended to be a realistic comparison for users. It sets up a Kubernetes cluster, configures Prometheus to monitor many fake services, and simulates users querying the data.\n- Expected Outcome: PromBench should cover more of Prometheus functionality, making it a more useful benchmark for users.\n- Recommended Skills: Go, Prometheus\n- Mentor(s):\n - Bryan Boreham (@bboreham, bjboreham@gmail.com)\n - Kemal Akkoyun (@kakkoyun, kakkoyun@gmail.com)\n- Upstream Issue: https://github.com/prometheus/test-infra/issues/707\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b9a0e569-0f73-40dc-94d2-8dc3d376dbc6\n\n#### Prometheus Remote-Write v2 support in otel-collector's `prometheusremotewriteexporter`.\n\nCNCF - Prometheus: Remote-Write v2 in otel-collector's prometheusremotewriteexporter (2024 Term 3)\n\n- Description: Prometheus recently [announced the second version of it's remote-write protocol](https://prometheus.io/docs/specs/remote_write_spec_2_0/), with support for new features on top of performance and cost savings. The work to be done is contribute support for this new protocol in the OpenTelemtry-Collector-Contrib repository, more specifically to the `prometheusremotewriteexporter` component.\n- Expected Outcome: `prometheusremotewriteexporter` component with support for PRW v2.\n- Recommended Skills: Go, Prometheus, OpenTelemetry.\n- Mentors(s):\n - Arthur Silva Sens (@ArthurSens, arthursens2005@gmail.com)\n - Arve Knudsen (@aknuds1, arve.knudsen@pm.me)\n - David Ashpole (@dashpole, dashpole@google.com)\n- Upstream Issue: https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/33661\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3fa26f90-87aa-46a4-80f9-00195ae276e8\n\n### Service Mesh Performance\n\n#### CNCF Project Performance Test Dashboard\n\nCNCF - Service Mesh Performance: CNCF Project Performance Test Dashboard (2024 Term 3)\n\n- Description: In coordination with CNCF TAG Network, the current performance dashboard at https://smp-spec.io/dashboard is proposed to be incorporated into CNCF project level-moving criteria in that each CNCF project will be encouraged (mandated?) to incorporate ongoing performance tests into their build and release processes, resulting in ongoing performance analysis of each project.\n- Expected Outcome: \n - Dashboard Enhancement: Expand the existing performance dashboard to capture and visualize performance test results for non-service mesh projects. This will involve integrating with various data sources, designing user-friendly interfaces, and implementing robust data analysis pipelines.\n - GitHub Workflow Integration: Collaborate with other CNCF projects to configure their GitHub workflows to automatically run load tests using the Meshery GitHub Action. This will streamline the performance testing process and ensure that results are consistently collected and published to the dashboard.\t\n- Recommended Skills: Golang, familiarity with HTTP/HTTPS performance testing tools, Service Mesh, grpc, familiarity with containerization technologies, like Docker would be helpful.\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Xin Huang (@gyohuangxin, xin1.huang@intel.com)\n- Upstream Issue: https://github.com/service-mesh-performance/service-mesh-performance/issues/432\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f0add302-47e2-4918-ba86-7a3570b3540c\n\n### Thanos\n\n#### Add support for hedged requests\n\n- Description: The long-tail requests sometimes are inevitable between the Thanos Store Gateway and an external cache. Lowering the timeouts between the store-gateway and the cache service isn't a greater way to address this problem. Using a HTTP client to issue hedged requests to object storage and other parts of Thanos' stack could help reduce tail latency by a lot.\n- Expected Outcome: By the end of the term, the mentee will have a deeper knowledge of Thanos and have improved our HTTP request tail latencies considerably!\n- Recommended Skills: Go, HTTP, Prometheus, Thanos\n- Mentor(s):\n - Giedrius Statkevičius (@GiedriusS, giedriuswork@gmail.com)\n - Saswata Mukherjee (@saswatamcode, saswataminsta@yahoo.com)\n- Upstream Issue: https://github.com/thanos-io/thanos/issues/6712\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/541a5bb5-09fd-47a9-a244-a65386aa7f7c\n\n### Vitess\n\n#### Add new getting started examples\n\nCNCF - Vitess: Add new getting started examples (2024 Term 3)\n\n- Description: Vitess is a cloud-native database, while managing Vitess can be complex, the list of our getting started guide and code examples is not very exhaustive. We would like to have a mentee work on growing the list of code examples and guide to help new users acquire Vitess. Given the mentee's fresh eyes, we would like them to contribute to the troubleshooting / common issues guide too.\n- Expected Outcome: By the end of the term, the mentee will have a deeper knowledge of Vitess and shipped at least one guide in every area of Vitess.\n- Recommended Skills: Go, Distributed Database, Communication\n- Mentor(s):\n - Florent Poinsard (@frouioui, florent@planetscale.com)\n - Matt Lord (@mattlord, mlord@planetscale.com)\n- Upstream Issue: https://github.com/vitessio/website/issues/1798\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/51f85b18-1184-443c-9e9a-5f00d9cd5040\n\n### WasmEdge\n\n#### WASM Serializer with new proposals\n\nCNCF - WasmEdge: WASM Serializer with new proposals (2024 Term 3)\n\n- Description: WasmEdge provides WASM module serializer in C API level for developers to convert the loaded WASM structure back into binary format. But after supporting the `function-references`, `GC`, `relaxed-SIMD`, and `exception-handling` proposals in WasmEdge, the partitions of these proposals in serializer are not implemented yet. Thus, we would invite mentees to complete the binary format serialization with the above WASM proposals in WasmEdge.\n- Expected Outcome:\n * Complete the serialization of the new module extensions in WASM proposals.\n * Complete the serialization of the new instructions added in WASM proposals.\n * Add some basic unit tests with hand-writing WASM binaries.\n- Recommended Skills: C++, WASM, git\n- Mentor(s):\n - Yi-Ying He (@q82419, yiying@secondstate.io)\n - Hung-Ying, Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3585\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c96de5c4-e1c3-4a02-a18a-65507d1cb675\n\n#### Fix bugs found by fuzzer\n\nCNCF - WasmEdge: Fix bugs found by fuzzer (2024 Term 3)\n\n- Description: WasmEdge received several bug reports, which Fuzzer found. We would like to ask mentees to investigate and determine whether the issue is real, figure out solutions, or mark it as a `won't-fix` issue if it's invalid. To apply for this mentorship, you should also submit a proposal as part of the application materials. Please check the upstream issue for the detailed target list and the proposal template.\n- Expected Outcome: At least fix/determine 60% of the mentioned issues.\n- Recommended Skills: git, C++, WebAssembly\n- Mentor(s):\n - Hung-Ying, Tai (@hydai, hydai@secondstate.io)\n - Yi-Ying He (@q82419, yiying@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3584\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/824beced-74a9-4b65-9db3-c20589b9d0f6\n\n#### Create an LLM app with deep understanding of a GitHub repo\n\nCNCF - WasmEdge: Create an LLM app with deep understanding of a GitHub repo (2024 Term 3)\n\n- Description: LLM assisted coding is one of the most promising application areas for modern AI. It will also have profound impact on open source software development. As many projects have demonstrated, \"feeding\" an LLM with contents from a GitHub repo will make it better at understanding coding tasks for this project. In this project, we will take a modern approach to build LLM agents based on LlamaEdge / WasmEdge, and supplement it with deep knowledge of open source projects on GitHub. The goal is for the agent to answer questions and solve problems raised by the open source community.\n- Expected Outcome:\n * Build an automated tool to extract and process all files in a repo. That includes source code and docs.\n * develop a GitHub bot to capture all change files and update the knowledge base in real time.\n * generate a summary for each file (using an LLM) and supplement with its file path and other meta data.\n * create a vector database with the summary and original text. The vector is computed from the summary to improve search efficiency.\n * Run an LLM agent node with the RAG database from the repo.\n * Create a GitHub bot that can read new issues and respond with either an answer or a coding suggestion based on the content inside the repo.\n * Evaluate the answer quality.\n- Recommended Skills:\n * Rust\n * [LlamaEdge](https://github.com/LlamaEdge/LlamaEdge) -- see a [tutorial](https://llamaedge.com/docs/user-guide/get-started-with-llamaedge)\n * ChatGPT and LLMs\n * The [RAG process](https://llamaedge.com/docs/category/server-side-rag)\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n - Hung-Ying, Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3581\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7909e713-a081-49d9-b14e-4ee5a36e0e97\n\n#### Create a Wasm-based LLM app for financial analysts\n\nCNCF - WasmEdge: Create a Wasm-based LLM app for financial analysts (2024 Term 3)\n\n- Description: We would like to develop an LLM-based financial data analytics application using open source LLMs, embedding models, the LlamaEdge application server, vector databases, and data processing tools. It will provide an open source \"template\" and showcase \"best practices\" for similar applications in this fast growing application area.\n- Expected Outcome:\n * Create a data processing pipeline in Python or Rust to automatically\n * collect public company’s SEC 10-Q quarterly reports and press releases. e.g., [Apple 10-Q](https://www.sec.gov/edgar/browse/?CIK=0000320193) and [Apple press release](https://www.apple.com/newsroom/2024/05/apple-reports-second-quarter-results/)\n * generate a summary for each SEC 10-Q and press release documents using an LLM service such as [LlamaParse](https://docs.llamaindex.ai/en/stable/llama_cloud/llama_parse/) or [EYELEVEL xRay](https://dashboard.eyelevel.ai/xray/)\n * create and continuously update a vector database with the summary and original text. The vector is computed from the summary to improve search efficiency.\n * Create a server-side RAG app that can chat with the vector knowledge base of financial statements.\n * Evaluate the answer quality\n * Explore LLM function calling to incorporate real-time information and actions\n- Recommended Skills:\n * Python\n * [LlamaEdge](https://github.com/LlamaEdge/LlamaEdge) -- see a [tutorial](https://llamaedge.com/docs/user-guide/get-started-with-llamaedge)\n * ChatGPT and LLMs\n * The [RAG process](https://llamaedge.com/docs/category/server-side-rag)\n * Rust (optional)\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n - Hung-Ying, Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3580\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/75feef58-e372-4797-846a-c6a5d6087a19\n\n" }, { "path": "programs/lfx-mentorship/2024/03-Sep-Nov/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n - 2nd Mentor Name (@mentor_github, mentor@email.addy)\n- Upstream Issue:\n\n```\n\n---\n\n## Proposed Project ideas\n" }, { "path": "programs/lfx-mentorship/2025/01-Mar-May/README.md", "content": "# Term 01 - 2025 March - May\n\nStatus: Planning\n\nMentorship duration - three months (full-time schedule)\n\n### Timeline\n\n| **Activity** | **Date** |\n|------------------------------------|--------------------------------------------------------------------------|\n| **Project Proposals Open** | Wednesday, January 8 - Tuesday February 4, 2025 |\n| **Mentee Applications Open** | Wednesday, February 5 - Tuesday February 18, 2025 11AM PST (19:00 UTC) |\n| **Application Review Period** | Wednesday, February 19 – Tuesday, February 25, 2025 11AM PST (19:00 UTC) |\n| **Selection Notifications** | Thursday, February 27, 2025 |\n| **Mentorship Program Begins** | Monday, March 3, 2025 |\n| **Midterm Mentee Evaluations Due** | Tuesday, April 15, 2025 11AM PDT (18:00 UTC) |\n| **First Stipend Payments** | Wednesday, April 16, 2025 |\n| **Final Mentee Evaluations Due** | Tuesday, May 27, 2025 11AM PDT (18:00 UTC) |\n| **Second Stipend Payments** | Wednesday, May 28, 2025 |\n| **Last Day of Term** | Friday, May 30, 2025 |\n\n### Project instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2025/01-Mar-May/project_ideas.md, by February 4, 2025.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n## Table of Contents\n\n* [Antrea](#antrea)\n * [Support L4 protocol filters in PacketCapture API](#support-l4-protocol-filters-in-packetcapture-api)\n* [Envoy Gateway](#envoy-gateway)\n * [Integrating CNCF Fuzzing Framework for Envoy Gateway](#integrating-cncf-fuzzing-framework-for-envoy-gateway)\n * [Enhancing Envoy Gateway Documentation Using CNCF Tech Docs Analysis Framework](#enhancing-envoy-gateway-documentation-using-cncf-tech-docs-analysis-framework)\n* [Harbor](#harbor)\n * [Harbor CLI](#harbor-cli)\n * [Harbor Satellite](#harbor-satellite)\n* [Headlamp (a Kubernetes UI)](#headlamp-a-kubernetes-ui)\n * [Headlamp: Instrument with OpenTelemetry](#headlamp-instrument-with-opentelemetry)\n * [Headlamp: Make a Headlamp plugin for KEDA](#headlamp-make-a-headlamp-plugin-for-keda)\n * [Headlamp: Build Plugin Installation Container](#headlamp-build-plugin-installation-container)\n* [Inspektor Gadget](#inspektor-gadget)\n * [Building gadgets with Rust](#building-gadgets-with-rust)\n * [Implementing unit tests](#implementing-unit-tests)\n * [Inspekting and analysing gadgets](#inspekting-and-analysing-gadgets)\n* [Istio](#istio)\n * [Support TLS for Istio metrics endpoints](#support-tls-for-istio-metrics-endpoints)\n * [Improve documentation build infrastructure](#improve-documentation-build-infrastructure)\n * [Implement new site search](#implement-new-site-search)\n* [Jaeger](#jaeger)\n * [Jaeger: Upgrade Storage Backends to V2 Storage API](#jaeger-upgrade-storage-backends-to-v2-storage-api)\n * [Upgrade charts and graphs in Jaeger UI](#upgrade-charts-and-graphs-in-jaeger-ui)\n* [Karmada](#karmada)\n * [Karmada Self-Signed Certificate Content Standardization](#karmada-self-signed-certificate-content-standardization)\n * [Implement multi-cluster management in the Karmada dashboard](#implement-multi-cluster-management-in-the-karmada-dashboard)\n* [KCL](#kcl)\n * [A test framework developed for the KCL package management tool](#a-test-framework-developed-for-the-kcl-package-management-tool)\n * [KPM & LSP Integrated](#kpm--lsp-integrated)\n* [Kmesh](#kmesh)\n * [Re-design and implement the Kmesh website](#re-design-and-implement-the-kmesh-website)\n * [Kmesh eBPF unit test](#kmesh-ebpf-unit-test)\n * [Add the Kmesh e2e Test](#add-the-kmesh-e2e-test)\n * [Metrics for TCP Long Connection](#metrics-for-tcp-long-connection)\n* [Knative](#knative)\n * [Design and Implement Levels for Educational Game](#design-and-implement-levels-for-educational-game)\n* [KubeArmor](#kubearmor)\n * [Providing Zero-Trust policies for popular workloads](#providing-zero-trust-policies-for-popular-workloads)\n* [KubeEdge](#kubeedge)\n * [Domain-specific large model benchmarks: the edge perspective](#domain-specific-large-model-benchmarks-the-edge-perspective)\n * [Enhance Dependency Management and Documentation for KubeEdge-Ianvs](#enhance-dependency-management-and-documentation-for-kubeedge-ianvs)\n * [Enhance KubeEdge testing coverage](#enhance-kubeedge-testing-coverage)\n * [KubeEdge Dashboard Enhancement - BFF](#kubeedge-dashboard-enhancement---bff)\n * [Community Website Comprehensive Upgrade Project: Homepage Renewal and Expansion of Core Pages](#community-website-comprehensive-upgrade-project-homepage-renewal-and-expansion-of-core-pages)\n* [KubeStellar](#kubestellar)\n * [Implement a Binding Policy Frontend Supported by Binding Policy Backend Endpoints](#implement-a-binding-policy-frontend-supported-by-binding-policy-backend-endpoints)\n * [Implement a Binding Policy Backend to Support UI Frontend](#implement-a-binding-policy-backend-to-support-ui-frontend)\n * [Implement a WDS Backend to Support UI Frontend Operations](#implement-a-wds-backend-to-support-ui-frontend-operations)\n * [Implement a WDS Frontend Supported by WDS Backend](#implement-a-wds-frontend-supported-by-wds-backend)\n * [Implement an ITS Frontend Supported by ITS Backend Endpoints](#implement-an-its-frontend-supported-by-its-backend-endpoints)\n * [Implement an ITS Backend to Support UI Frontend Operations](#implement-an-its-backend-to-support-ui-frontend-operations)\n* [Kyverno](#kyverno)\n * [Chainsaw Tests For New Policy Types](#chainsaw-tests-for-new-policy-types)\n * [Sample Policies For New Policy Types](#sample-policies-for-new-policy-types)\n * [Mutating Admission Policy Integration](#mutating-admission-policy-integration)\n* [LitmusChaos](#litmuschaos)\n * [Enhancing CI/CD Integration for LitmusChaos: SDK Development and Chaos-CI-Lib Revamp](#enhancing-cicd-integration-for-litmuschaos-sdk-development-and-chaos-ci-lib-revamp)\n * [Improve the code coverage for observability in the LitmusChaos components](#improve-the-code-coverage-for-observability-in-the-litmuschaos-components)\n * [Expanding the LitmusChaos Tutorials - Day 0, Day 1, and Day 2 User Flows](#expanding-the-litmuschaos-tutorials---day-0-day-1-and-day-2-user-flows)\n* [Meshery](#meshery)\n * [Meshery Model Support for kro ResourceGraphDefinitions (RGDs)](#meshery-model-support-for-kro-resourcegraphdefinitions-rgds)\n * [Hands-on tutorials using Meshery Playground](#hands-on-tutorials-using-meshery-playground)\n * [Expanding end-to-end test coverage in Meshery using Playwright](#expanding-end-to-end-test-coverage-in-meshery-using-playwright)\n* [Microcks](#microcks)\n * [Improving Microcks CLI](#improving-microcks-cli)\n * [Update the Microcks Hub frontend and make it deployable on-premises](#update-the-microcks-hub-frontend-and-make-it-deployable-on-premises)\n * [Microcks Hub: Expanding Sandbox and Mocking Capabilities for Key Industry APIs](#microcks-hub-expanding-sandbox-and-mocking-capabilities-for-key-industry-apis)\n * [Expanding Microcks community documentation for advanced installations](#expanding-microcks-community-documentation-for-advanced-installations)\n * [Improving Microcks delivery and validation with GitHub Actions CI deployment tests](#improving-microcks-delivery-and-validation-with-github-actions-ci-deployment-tests)\n * [Building Community-Driven documentation for deploying Microcks in cloud production environments](#building-community-driven-documentation-for-deploying-microcks-in-cloud-production-environments)\n * [Streamlining Microcks Deployment on AWS Marketplace](#streamlining-microcks-deployment-on-aws-marketplace)\n* [OpenKruise](#openkruise)\n * [Implement Fuzz testing for OpenKruise](#implement-fuzz-testing-for-openkruise)\n* [Prometheus](#prometheus)\n * [Get `PrometheusRemoteWriteReceiver` in OTel-Collector to Alpha Maturity](#get-prometheusremotewritereceiver-in-otel-collector-to-alpha-maturity)\n * [UX Research: How users expect to use OTLP Resource Attributes in Prometheus](#ux-research-how-users-expect-to-use-otlp-resource-attributes-in-prometheus)\n* [Thanos](#thanos)\n * [Add support for new PromQL aggregations](#add-support-for-new-promql-aggregations)\n* [TUF](#tuf)\n * [Metadata Repository Visualization](#metadata-repository-visualization)\n* [Vitess](#vitess)\n * [Enhance flag support across Vitess Components](#enhance-flag-support-across-vitess-components)\n * [Develop an FAQ Chatbot for Vitess using Retrieval-Augmented Generation](#develop-an-faq-chatbot-for-vitess-using-retrieval-augmented-generation)\n* [Volcano](#volcano)\n * [Volcano supports queue-level scheduling policies](#volcano-supports-queue-level-scheduling-policies)\n * [Coordinate descheduler and Volcano to support resource defragmentation](#coordinate-descheduler-and-volcano-to-support-resource-defragmentation)\n * [Volcano dashboard feature enhancements](#volcano-dashboard-feature-enhancements)\n* [WasmEdge](#wasmedge)\n * [Implement a new WasmEdge installer in Rust](#implement-a-new-wasmedge-installer-in-rust)\n * [Implement component model's validator](#implement-component-models-validator)\n * [Improve the WasmEdge-based Rust coding assistant for inference-time scaling](#improve-the-wasmedge-based-rust-coding-assistant-for-inference-time-scaling)\n * [Create a Japanese translation agent for CNCF videos](#create-a-japanese-translation-agent-for-cncf-videos)\n\n\n## Projects\n\n### Antrea\n\n#### Support L4 protocol filters in PacketCapture API\n\n- Description: As a Kubernetes (K8s) network plugin (CNI plugin), Antrea provides networking functions for K8s Pods and includes various troubleshooting tools for cluster administrators and application developers to diagnose networking issues. The [PacketCapture feature](https://github.com/antrea-io/antrea/blob/main/docs/packetcapture-guide.md) was introduced recently and allows capturing network traffic for specific endpoints using predefined filters similar to those supported by libpcap/tcpdump. Users can initiate a packet capture through a Kubernetes Custom Resource Definition (CRD) or a CLI command. The Antrea control plane then generates and injects the corresponding BPF program, and the captured packets can be exported as a pcap file. Currently, only a limited set of filters is supported. With this project, we aim to introduce additional filters, particularly Layer 4 protocol filters, such as TCP flags for the TCP transport protocol. These new filters will enable Antrea users to target network traffic more precisely.\n- Expected Outcome: Extend the API definition for the PacketCapture CRD with additional filter fields, and implement the new API functionality by mapping the new fields to the corresponding BPF instructions. The new fields should also be exposed in the corresponding `antctl` CLI commands. The implementation should come with a sufficient amount of tests (both unit tests and e2e tests), ensuring that the new functionality is working as expected.\n- Recommended Skills: familiarity with Golang, some knowledge about the K8s architecture and APIs, basic knowledge about networking protocols (IP/TCP/UDP/ICMP).\n- Mentor(s):\n - Antonin Bas (@antoninbas, antonin.bas@gmail.com)\n - Hang Yan (@hangyan, hang.yan@hotmail.com)\n- Upstream Issue: https://github.com/antrea-io/antrea/issues/6864\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c1b6fda9-e2e6-41e1-8495-68abe9e980ca\n\n### Envoy Gateway\n\n#### Integrating CNCF Fuzzing Framework for Envoy Gateway\n\n- Description: [Envoy Gateway](https://gateway.envoyproxy.io) has become a crucial part of modern cloud-native infrastructures, \nproviding a simplified way to deploy and manage [Envoy Proxy](https://www.envoyproxy.io).\nEnsuring the reliability and security of Envoy Gateway is paramount for its growing user base.\n\nFuzzing, a widely-used technique for identifying software vulnerabilities and bugs, can significantly enhance the robustness of Envoy Gateway.\nBy integrating the [CNCF Fuzzing Framework](https://github.com/cncf/cncf-fuzzing), this project aims to improve the \nsecurity posture of Envoy Gateway through comprehensive automated testing.\n\n- Expected Outcome:\n - Add a fuzz test that covers 80% of code paths for translating Gateway API input configuration into xDS output.\n - Enable continuous fuzzing using [OSS-Fuzz](https://github.com/google/oss-fuzz).\n- Recommended Skills: Go, scripting.\n- Mentor(s):\n - Arko Dasgupta (@arkodg, arko@tetrate.io)\n - Teju Nareddy (@nareddyt, tnareddy@confluent.io)\n- Upstream Issue: https://github.com/envoyproxy/gateway/issues/3124\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/44020e81-1218-49aa-95e0-ee3e03998eb3\n\n#### Enhancing Envoy Gateway Documentation Using CNCF Tech Docs Analysis Framework\n\n- Description: The **Envoy Gateway** project provides a simplified way to use **Envoy Proxy as an API Gateway**,\nand its documentation is critical to enabling adoption, onboarding new users, and improving developer experience.\nWhile the existing documentation covers core concepts and use cases, applying the **CNCF Tech Docs Analysis Framework**\nwill help assess and systematically enhance its **clarity, completeness, and usability**.\n\nThis project aims to evaluate and improve the [Envoy Gateway website and documentation](https://gateway.envoyproxy.io) by\nleveraging the structured analysis methodology from the [CNCF Tech Docs Analysis Framework](https://github.com/cncf/techdocs/blob/main/docs/analysis/howto.md).\nThe outcome will be a **comprehensive documentation improvement plan**, with targeted updates and best practices implemented.\n\n- Expected Outcome:\n - Apply the **CNCF Tech Docs Analysis Framework** to assess Envoy Gateway docs\n - Identify gaps in **content, structure, readability, and technical accuracy**\n - Improve documentation **organization, navigation, and developer onboarding**\n - Optimize technical guides, examples, and API references\n - (Stretch Goal) Introduce best practices for **continuous documentation improvement**\n\n- Recommended Skills:\n - Familiarity with **Envoy Proxy, Envoy Gateway, Kubernetes, and API Gateways** (or willingness to learn)\n - Experience with **Markdown, static site generators (e.g., Hugo), and GitHub-based workflows**\n - Interest in **developer experience, technical writing, and open-source documentation**\n - Ability to conduct structured **documentation analysis and usability improvements**\n\n- Mentor(s):\n - Erica Hughberg (@missBerg, erica.hughberg@tetrate.io)\n - Arko Dasgupta (@arkodg, arko@tetrate.io)\n- Upstream Issue: https://github.com/envoyproxy/gateway/issues/5203\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2b752e3d-d55b-40de-a702-13b88aff974a\n\n### Harbor\n\n#### Harbor CLI\n\n- Description: Harbor is a widely adopted container registry, and its initial CLI has been developed by LFX mentees. The goal is to extend this CLI by implementing additional functionalities and workflows that are currently only available in the Web UI. The CLI should be useful for Harbor administrators and users, especially to manage workflows within CI/CD pipelines. We seek a Golang-experienced mentee to enhance the CLI independently.\n- Expected Outcome:\n - Extend the Harbor CLI to include essential commands not yet implemented.\n - Add new features to improve Harbor management via the CLI, enabling robust workflows in CI/CD environments.\n- Recommended Skills: Golang, spf13/cobra\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n- Upstream Issue: https://github.com/goharbor/harbor-cli/issues/315\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/769b7e87-f2f5-4532-b247-392b1897ea50\n\n#### Harbor Satellite\n\n- Description: Containers have extended beyond their traditional cloud environments, becoming increasingly prevalent in remote and edge computing contexts. These environments often lack reliable internet connectivity, posing significant challenges in managing and running containerized applications due to difficulties in fetching container images. To address this, the project aims to decentralize container registries, making them more accessible to edge devices.\n- Expected Outcome:\n The goal is to extend the proof of concept and demonstrate that such a solution practically works.\n Candidates should be able understanding and implementing the [image](https://github.com/opencontainers/image-spec) and [distribution spec](https://github.com/opencontainers/distribution-spec)\n to replicate images from a central registry to a registry on the edge location.\n- Recommended Skills: Golang, Container, Image-spec, Distribution-spec\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n- Upstream Issue: https://github.com/goharbor/harbor/issues/21469\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ff3431c0-3cb1-4c07-bd10-21a8e495c897\n\n### Headlamp (a Kubernetes UI)\n\n#### Headlamp: Instrument with OpenTelemetry\n\n- Description: Headlamp is a Kubernetes UI which is extensible. Having it instrumented with OpenTelemetry would allow those operating it to get information for debugging it when problems happen.\n- Expected Outcome: Headlamp backend and frontend are instrumented so those that want to use OpenTelemetry when operating Headlamp can. There's documentation and a blog post with a demo video explaining how it's used.\n- Recommended Skills: golang, TypeScript\n- Mentor(s):\n - Rene Dudfield (@illume, renedudfield@microsoft.com)\n - Kautilya Tripathi (@knrt10, ktripathi@microsoft.com)\n - Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n- Upstream Issue: https://github.com/headlamp-k8s/headlamp/issues/2799\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d961bfc7-00e1-4c05-bf1a-f9c7ddf1756a\n\n#### Headlamp: Make a Headlamp plugin for KEDA\n\n- Description: Headlamp is a Kubernetes UI which is extensible. KEDA is a Kubernetes-based Event Driven Autoscaler. With KEDA, one can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. While KEDA provides excellent functionality for scaling workloads based on event sources and custom metrics, monitoring and managing KEDA resources through Kubernetes dashboards remains challenging.\n- Expected Outcome: Create a Headlamp plugin that provides comprehensive visibility and management capabilities for KEDA resources, enabling users to do the following. 1. View and manage ScaledObjects and ScaledJobs through a intuitive interface. 2. Monitor real-time scaling metrics and trigger states. 3. Troubleshoot scaling behaviors with integrated logging and event visualization.\n- Recommended Skills: Golang, TypeScript. Kubernetes and KEDA too would be nice to have.\n- Mentor(s):\n - Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n - Rene Dudfield (@illume, renedudfield@microsoft.com)\n - Kautilya Tripathi (@knrt10, ktripathi@microsoft.com)\n- Upstream Issue: https://github.com/headlamp-k8s/headlamp/issues/2791\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ceebb991-978f-4782-8435-195637f433aa\n\n#### Headlamp: Build Plugin Installation Container\n\n- Description: Headlamp is a Kubernetes UI which is extensible through plugins. Currently, plugin installation in Kubernetes environments requires manual intervention. We need a containerized solution that can automatically install plugins during Headlamp's deployment using Kubernetes-native approaches like init containers and ConfigMaps.\n- Expected Outcome:\n 1. A containerized version of headlamp-plugin CLI that can be used as an init container\n 2. Helm chart updates to support plugin installation via configuration\n 3. Automated container builds as part of Headlamp's release process\n 4. Documentation and examples showing how to use the plugin installer container\n 5. Integration tests validating the plugin installation process\n- Recommended Skills: Kubernetes, TypeScript, Shell scripting\n- Mentor(s):\n - Kautilya Tripathi (@knrt10, ktripathi@microsoft.com)\n - Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n - Rene Dudfield (@illume, renedudfield@microsoft.com)\n- Upstream Issue: https://github.com/headlamp-k8s/headlamp/issues/2787\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/992fc67e-ff9e-41fd-8062-28ec8733903f\n\n### Inspektor Gadget\n\n#### Building gadgets with Rust\n\n- Description: Inspektor Gadget is an eBPF tool and systems inspection framework for Kubernetes, containers and Linux\n hosts. A Gadget is an OCI image that includes one or more eBPF programs, metadata YAML file, and optionally, WASM modules for post processing. Today, Inspektor Gadget provides tooling to build gadgets from source code written in C (for the eBPF module) and Go (for the WASM module). This project is about adding support from building gadgets from Rust both for eBPF programs and for WASM modules.\n- Expected Outcome: users can write their gadgets in Rust.\n- Recommended Skills: Rust, Go, eBPF, WASM\n- Mentor(s):\n - Mauricio Vasquez Bernal (@mauriciovasquezbernal, mauriciov@microsoft.com)\n - Francis Laniel (@eiffel-fl, flaniel@linux.microsoft.com)\n- Upstream Issue: https://github.com/inspektor-gadget/inspektor-gadget/issues/3950\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/42dd5a60-47f9-4f7c-b895-49ce6c81a59a\n\n#### Implementing unit tests\n\n- Description: Inspektor Gadget is an eBPF tool and systems inspection framework for Kubernetes, containers and Linux hosts. A Gadget is an OCI image that includes one or more eBPF programs, metadata YAML file, and optionally, WASM modules for post processing. As OCI images, they use the same tooling as containers: building, pushing/pulling from OCI Registries.\nEven though there are many integration tests, we wish to increase the coverage of unit tests for the majority of internal packages. These packages are essential, and a bad commit could lead to unseen disruptions. Debugging and diagnosing through integration tests is cumbersome and takes too much time.\n- Expected Outcome:\n - Find out which packages are in most need of unit tests\n - Create a mock class/framework if needed\n - Implement unit tests\n- Recommended Skills: Go\n- Mentors:\n - Burak Ok (@burak-ok, burakok@microsoft.com)\n - Qasim Sarfraz (@mqasimsarfraz, qasimsarfraz@microsoft.com)\n- Upstream Issue: https://github.com/inspektor-gadget/inspektor-gadget/issues/3835\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d3a1a899-1ca0-4e10-a402-01ef6fde26f2\n\n#### Inspekting and analysing gadgets\n\n- Description: Inspektor Gadget is an eBPF tool and systems inspection framework for Kubernetes, containers and Linux\n hosts. A Gadget is an OCI image that includes one or more eBPF programs, metadata YAML file, and optionally, WASM modules for post processing. As OCI images, they use the same tooling as containers: building, pushing/pulling from OCI Registries. But today, Inspektor Gadget does not have good tooling for inspecting a gadget: the `ig image inspect` command just gives the gadget name, digest and creation date without further details.\n- Expected Outcome: the `ig image inspect` command tells the architectures supported by the gadget, the layers included in the OCI image, the data sources with their fields, the eBPF parameters. Additionally, inspecting the eBPF module can provide the ELF sections, the eBPF maps and the disassembled eBPF bytecode annotated with the source when available.\n- Recommended Skills: Go, eBPF\n- Mentors:\n - Alban Crequy (@alban, albancrequy@microsoft.com)\n - Jose Blanquicet (@blanquicet, josebl@microsoft.com)\n- Upstream Issue: https://github.com/inspektor-gadget/inspektor-gadget/issues/3387\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a6d66c40-3d12-4fa4-88bf-18574f6b4ec0\n\n### Istio\n\n#### Support TLS for Istio metrics endpoints\n\n- Description: [Istio](https://istio.io) extends Kubernetes to establish a programmable, application-aware network. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments\n\nIstio does not support HTTPs based metric scraping for control plane, gateway, and Envoy sidecar [metrics](https://istio.io/latest/docs/ops/integrations/prometheus/#tls-settings)\n\nThis could have some security related consequences:\n\n- An attacker might find some sensitive information that they can use for their advantage. For example, Envoy /stats endpoint can be used to enumerate all upstream services in the cluster.\n- In theory an attacker could masquerade the metrics endpoint(s) and inject fake data to monitoring systems, in order to e.g. hide an ongoing attack, confuse the system to autoscale up/down etc.\n\nIt would be nice to protect the metrics endpoints with TLS, using mutual authentication. While this feature is a big one covering multiple components,\nthe easiest component alone is intended to be covered as part of this internship.\n\n- Expected Outcome:\n - Implement HTTPS metrics for ztunnel component\n - Add unit tests and integration tests for the feature\n - Add documentation for the functionality\n- Recommended Skills: Rust, Go, scripting, Kubernetes, Istio Ambient basics.\n- Mentor(s):\n - Faseela K (@kfaseela, k.faseela@gmail.com)\n - Benjamin Leggett (@bleggett, benjamin.leggett@solo.io)\n - Jianpeng He(@zirain, zirain2009@gmail.com)\n - Ian Rudie (@ilrudie, ian.rudie@solo.io)\n- Upstream Issue: https://github.com/istio/istio/issues/54760\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9b1a1e87-2757-4f4f-aa58-49d55fc07b16 \n\n#### Improve documentation build infrastructure\n\n- Description: The build infrastructure for istio.io currently carries a complete archived copy of the site for each release of Istio. These archived versions should be separated to their own branch, with only the supported versions published. We should also separate out content which is not version-specific (e.g. the home page, news and blogs) so that only the latest version of this content is visible online.\n- Expected Outcome: Updated publishing infrastructure for istio.io which separates evergreen content (home page, blogs) with versioned content (documentation). Drop-downs per docs page allow switching between the supported versions. \n- Recommended Skills: Systems engineering, scripting, programming (Go/Bash), Hugo templating\n- Mentor(s):\n - Craig Box (@craigbox, craig.box AT gee-mail)\n- Upstream Issue: https://github.com/istio/istio.io/issues/15463\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2fe99eb2-abc3-454f-b80a-ffd336fa2788\n\n#### Implement new site search\n\n- Description: Up to four versions of Istio are supported at one time, and so the documentation for each must be available. Our current site search is outdated and needs to be replaced, so that the search content only exists in the site search, and only fresh content is available on google.com.\n- Expected Outcome: Working site search on istio.io, which lets you search for content for the currently supported versions.\n- Recommended Skills: Hugo, Systems engineering, scripting, programming (Bash/go), Hugo templating\n- Mentor(s):\n - Craig Box (@craigbox, craig.box AT gee-mail)\n- Upstream Issue: https://github.com/istio/istio.io/issues/15464\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a8165dc1-fb52-40ca-bd1f-862a5176df98\n\n### Jaeger\n\n#### Jaeger: Upgrade Storage Backends to V2 Storage API\n\n- Description: [Jaeger](https://www.jaegertracing.io/) is an open-source, distributed tracing platform designed to monitor and troubleshoot microservices-based systems. A critical component of Jaeger is its storage backends, where traces captured by Jaeger are stored. With the release of Jaeger v2 last year we introduced a new, more efficient Storage API v2. However, the existing backend implementations in Jaeger are still using v1 API that is only wrapped in the v2 adapter, which prevents them from benefiting from the new capabilities such as batch writes and result streaming. The objective of this project is to upgrade some (or all) backend implementations to use the Storage API v2 natively. Please refer to the upstream issue for more details.\n- Expected Outcome:\n - Upgrade memory and Elasticsearch backends to use the Storage API v2 natively.\n - Bonus: upgrade Cassandra and Badger backends to use the Storage API v2 natively.\n- Recommended Skills: Go, scripting, CI/CD, familiarity with Elasticsearch/Cassandra a plus but not required.\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Mahad Zaryab (@mahadzaryab1, mahadzaryab1@gmail.com)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/6458\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5ce2b62c-94a9-44e9-95bc-b83a13c0a0e6\n\n#### Upgrade charts and graphs in Jaeger UI\n\n- Description: [Jaeger](https://www.jaegertracing.io/) is an open-source, distributed tracing platform designed to monitor and troubleshoot microservices-based systems. Jaeger UI pioneered many new visualizations for analyzing distributed traces. However, over time, it accumulated views that utilize different and sometimes deprecated viz libraries. The objective is to standardize charting / graphing libraries used in Jaeger UI, upgrade their dependencies, and add new visualization features. Please refer to the upstream issue for more details.\n- Expected Outcome:\n - Jaeger UI is not using deprecated dependencies\n - Consistent look and feel of graphs\n - Bonus: side panel for details for a given node\n - Bonus: overlaying metrics on the graph (as edge annotations and node coloring to reflect health / error rates)\n - Bonus: varying node displays depending on the type of node and implementation language\n- Recommended Skills: Javascript, Typescript, React, NPM, Vite.js\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n- Upstream Issue: https://github.com/jaegertracing/jaeger-ui/issues/2534\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/48ebfb59-eab7-4d22-8373-30a0bbfb12f7\n\n### Karmada\n\n#### Karmada Self-Signed Certificate Content Standardization\n\n- Description: In the existing [Karmada](https://github.com/karmada-io/karmada) architecture, each component should have its own unique certificates to ensure clear identity and security. Best practices dictate that each component's name be used as the Common Name (CN) in its certificate to facilitate identity differentiation. However, currently, all Karmada components share same identical certificate content, leading to confusion and potential security risks.\nThe objective of this project is to enhance the compliance of the Karmada certificate system by ensuring that each component possesses distinct certificates that reflect its identity. This will improve system security, reduce management complexity, and align with industry standards. This project aims to achieve the following standards:\n - Utilize a single CA certificate for the entire Karmada system.\n - Issue individual server certificates for each server component, using the component name as the CN.\n - Issue individual client certificates for each client component, using the component name as the CN, same client can use consistent certificate for different servers.\n- Expected Outcome:\n - Complete the issuance of different certificates for 8 server components and import the certificate content into the corresponding certificate Secrets.\n - Complete the issuance of different certificates for 11 client components and import the certificate content into the corresponding certificate Secrets or Config Secrets.\n- Recommended Skills:\n - Familiarity with Golang, Kubernetes, and Karmada.\n - Basic understanding of certificate management.\n- Mentor(s):\n - Chaosi Pan (@chaosi-zju, chaosi@zju.edu.cn)\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/6091\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8d2d522f-8838-4baa-9be4-d13dab30289b\n\n#### Implement multi-cluster management in the Karmada dashboard\n\n- Description: The Karmada dashboard has already implemented the management of resources in the control plane. Apart from that, we hope to implement the management of resources in the member cluster: once users add Kubernetes resources and the corresponding policy resources on the control plane, they can switch to the corresponding member cluster seamlessly, check the status of Kubernetes resources in the specific member cluster. Kubernetes dashboard is one of the most popular single-cluster management tools, which uses client-go sdk to communicate with the apiserver to manage resources in the cluster. A great deal of client-go related logic can be extended to muli-cluster easily, due to the karmada-aggregated-apiserver component and the compatibility design between Kubernetes resource and Karmada resoruces. So we hope to combine the Kubernetes dashboard with the karmada-aggregated-apiserver component to implement multi-cluster management in the Karmada dashboard.\n- Expected Outcome:\n - Proposal for multi-cluster management base on `karmada-aggregated-apiserver`.\n - Tools to lift Kubernetes dashboard with specific version into Karmada dashboard repo, and implement management of resources in member cluster based on `karmada-aggregated-apiserver`.\n - Typical ui for member-cluster management:\n - list/detail/delete/update action for `deployment` resources.\n - log viewer for `pod`.\n - web terminal for `pod`，which user can attach the running pod, and execute tempory commands.\n- Recommended Skills: Kubernetes, Go, gin, react, webgl\n- Mentor(s):\n - Wenjiang Ding (@warjiang, 1096409085@qq.com)\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n- Upstream Issue: https://github.com/karmada-io/dashboard/issues/182\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4fb84d25-bcc0-4190-a233-760ef0b22797\n\n### KCL\n\n#### A test framework developed for the KCL package management tool\n\n- Description: The main content of this topic is to refer to the structure of the test part of common programming languages, such as go and rust, to develop a test framework for KCL's package management tool to help developers better write test cases for the project. The main function of the test framework is to provide a mock environment that supports compiling KCL and interacting with simulated environments such as OCI/Git registry.\n- Expected Outcome: \n - A mock environment is started during testing. This mock environment can complete the test without being affected by the network.\n - In this mock environment, complete the test of: `kcl run`, `kcl mod add`, `kcl mod pull`, `kcl mod push`.\n- Recommended Skills: Go, Rust\n- Mentor(s):\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n - Heipa (@He1pa, he1pa404@gmail.com)\n- Upstream Issue: https://github.com/kcl-lang/kpm/issues/593\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b9fafd6f-194a-48c8-be37-05a644b00b6d\n\n#### KPM & LSP Integrated\n\n- Description: Sometimes users will edit the `kcl.mod` file in the IDE to update project dependencies. The integration between LSP and KPM needs to be strengthened, it mainly includes two parts of functions. \n - According to the content written by the user in the kcl.mod file, the IDE automatically calls the `kcl run/mod add/mod metadata` and other functions, and feeds back the results in the IDE. \n - According to the user's operations in the command line, the changes of `kcl.mod` and project content are synchronized to the IDE.\n\nexamples:\n\n1. When users update kcl.mod in the IDE, the required dependencies are automatically downloaded.\n\n2. When users use the kpm tool to update dependencies, the IDE can be updated (recompiled). For example\n```kcl\nimport k8s # Error: Module not found\n```\n\nuse `kcl mod add k8s` to download the dependency `k8s`.\n\nkpm will download the k8s package and then the IDE errors will be eliminated\n\n- Expected Outcome: \n - Complete at least the following parts:\n - IDE triggers automatic dependencies updates of package management tools.\n - Automatic synchronization of kcl.mod files.\n - IDE users actively trigger dependency downloads, it looks like: a button or link for user to download the missing dependencies.\n - After the dependency update is complete, the IDE triggers a recompile to clear the error\n- Recommended Skills: Go, Rust\n- Mentor(s):\n - Heipa (@He1pa, he1pa404@gmail.com)\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n- Upstream Issue: https://github.com/kcl-lang/kcl/issues/1847\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/012a9fb4-286b-4a76-ad7a-2de644427109\n\n### Kmesh\n\n#### Re-design and implement the Kmesh website\n\n- Description: The existing Kmesh website theme struggled to meet existing development needs. Therefore, there is a need to redesign the Kmesh website and replace the theme to make it easier for developers to add documentation. Development instructions for the website are also provided.\n- Expected Outcome:\n - The website has more readable documentation, covering user cases, developer courses, etc. \n - Docs about how to develop website.\n- Recommended Skills: JS, Kmesh, Html\n- Mentor(s):\n - ZhenCheng Li(@LiZhenCheng9527, leezhencheng6@gmail.com),\n - Zhonghu Xu(@hzxuzhonghu, zhhxu2011@gmail.com)\n- Upstream Issue: https://github.com/kmesh-net/website/issues/115\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6269bdd1-1004-465c-bbdc-6a230988c899\n\n#### Kmesh eBPF unit test\n\n- Description: As the community features continue to expand, the number of eBPF programs in the data plane has increased. Due to the inherent limitations of eBPF (third-state encoding, neither user space nor kernel space, running in a kernel virtual machine with a dedicated instruction set), Kmesh implements complex governance logic through features like tail call and map-in-map, which poses challenges for data plane quality protection.\neBPF, a recently introduced programmable technology in the kernel, currently has an immature ecosystem. The industry is actively exploring eBPF testing capabilities (e.g., Unit Testing eBPF). This project aims to develop an eBPF UT testing framework in conjunction with the Kmesh project to ensure the quality of the Kmesh data plane.\n- Expected Outcome:\n - Export Kmesh eBPF programs to support UT test case.\n - Export design documentation for eBPF UT tests\n- Recommended Skills: C, eBPF, (go)\n- Mentor(s):\n - Xin Liu(@bitcoffeeiux, 854182924@qq.com)\n - Changye Wu(@nlgwcy, wuchangye@huawei.com)\n- Upstream Issue: https://github.com/kmesh-net/kmesh/issues/1209\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/58b458ba-6be0-4dd9-b194-bfe6f98d2a2c\n\n#### Add the Kmesh e2e Test\n\n- Description: Kmesh now has an e2e testing framework, but it only covers some of the usage scenarios for key features. More test cases need to be covered to ensure the stability of key features.\n- Expected Outcome:\n - e2e Test Cases\n - Documentation maintenance for e2e testing\n- Recommended Skills: go, Kmesh\n- Mentor(s):\n - Zengzeng Yao(@yaozegzeng, yaozengzeng@huawei.com)\n - Zhonghu Xu(@hzxuzhonghu, zhhxu2011@gmail.com)\n- Upstream Issue: https://github.com/kmesh-net/kmesh/issues/1210\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2a955954-1a86-4835-be29-f4c70bfd77d2\n\n#### Metrics for TCP Long Connection\n\n- Description: Currently, Kmesh metrics are only reported when a TCP connection is closed. In the case of long connections, it is not possible to know the status before the connection is closed. Therefore, we hope to add the capability to periodically report metrics for long connections.\n- Expected Outcome:\n - proposal\n - code\n - user guide.\n- Recommended Skills: go, c, eBPF\n- Mentor(s):\n - Changye wu(@nlgwcy, wuchangye@huawei.com)\n - ZhenCheng Li(@LiZhenCheng9527, leezhencheng6@gmail.com)\n- Upstream Issue: https://github.com/kmesh-net/kmesh/issues/1211\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c5dadaed-445e-4a74-825b-3e2f1a8b2be1\n\n### Knative\n\n#### Design and Implement Levels for Educational Game\n\n- Description: The Knative community is developing an educational game to teach concepts about event driven architectures and how to build them with Knative. A good overview of the project was [presented at KubeCon NA 2024](https://youtu.be/TTBKh6F4v-g?si=MRmx6a2YJsl7y0Q-). We are currently looking to tale our initial prototype and turn it into a full game. In this project, you will help achieve this by designing levels that teach architectural concepts, and implementing those levels in the Godot game engine.\n- Expected Outcome: Identify key event driven architecture patterns, design levels to teach the patterns, implement the levels in Godot.\n- Recommended Skills: Godot, Game Development, Event Driven Architecture\n- Mentor(s):\n - Calum Murray (@Cali0707, calum.murray@mail.utoronto.ca)\n - Zainab Husain (@zainabhusain227, zainabhusain227@gmail.com)\n - Angelina Zhai (@AngelinaZhai, angelina.zhai@mail.utoronto.ca)\n- Upstream Issue: https://github.com/knative-extensions/educational-game/issues/8\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/58392ddd-4d5a-491e-9b09-6035aa4c907e\n\n### KubeArmor\n\n#### Providing Zero-Trust policies for popular workloads\n\n- Description: KubeArmor can whitelist processes and assets based on set of rules provided through the policies. This feature allows KubeArmor to achieve zero trust for a workload. However, knowing the allowed behaviour for a workload and manually creating these policies is a pain. Therefore we want to provide Zero-trust policies for popular workloads like grafana, WordPress, redis, etc. (let's say some 100 workloads). We want to make these Zero-Trust policies available as artifacts.\n \n- Expected Outcome: Create a registry of policies that allow users to seamlessly fetch and apply policies for popular workloads.\n\n- Extended Goal: Since applications will have newer versions and the existing Zero-Trust policies may not work as expected. We can have an automated system to generate these Zero-Trust policies and so we can also automate the process of generating Zero-Trust policies for every version available or newer versions as well.\n \n- Recommended Skills: familiarity with Golang, K8s CRD(Custom Resource Definition), YAML.\n- Mentor(s):\n - Rishabh Soni (@rootxrishabh, risrock02@gmail.com)\n - Prateek Nandle (@Prateeknandle, prateeknandle@gmail.com)\n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1959\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5f7ef24a-a57b-477d-940f-9989f1bec481\n\n### KubeEdge\n\n#### Domain-specific large model benchmarks: the edge perspective\n\n- Description: Based on existing datasets, the issue aims to build an advanced benchmark for edge-oriented domain-specific large models on KubeEdge-Ianvs. It aims to help all Edge AI application developers validate and select the best-matched domain-specific large models. For Edge AI service providers, it also helps identify which scenarios, edge nodes, or even locations could have the best performance or improvement for their models.\n- Expected Outcome: \n - Domain-specific Large Model Benchmark for the edge, including test datasets, testing toolkits, and usage guidelines.\n - (Advanced) Design and implementation of specific evaluation metrics.\n - (Advanced) Survey and research reports.\n- Recommended Skills: KubeEdge-Ianvs, Python, LLMs\n- Mentor(s):\n - Zimu Zheng (@MooreZheng, zimu.zheng@hotmail.com)\n - hsj576 (@hsj576, sjhu21@m.fudan.edu.cn)\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/177\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e3fc44d9-9ddd-42e6-a9be-8f6c2a114672\n\n#### Enhance Dependency Management and Documentation for KubeEdge-Ianvs\n\n- Description: Ianvs is currently grappling with significant dependency management challenges. It lacks a robust system to handle updates and ensure compatibility. As Python versions, dependency libraries, and Ianvs features continuously evolve, many existing examples fail to run, resulting in a surge of inquiries in the Issues section. Moreover, new PRs are often merged without being tested against historical examples, making it difficult to guarantee the functionality of past features through manual Code Review alone. There is an urgent need for a more comprehensive CI testing framework to maintain the usability of Ianvs features as the project progresses. Additionally, the online documentation is outdated, which can be quite confusing for new users.\n- Expected Outcome: \n - Update the Contributing Guide\n - Develop a New Quick Start Example with Comprehensive Documentation\n - Update Documentation for Other Paradigm Usage\n- Recommended Skills: KubeEdge, Ianvs, Python, CI/CD pipelines\n- Mentor(s):\n - FuryMartin (@FuryMartin, furymartin9910@outlook.com)\n - hsj576 (@hsj576, sjhu21@m.fudan.edu.cn)\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/178\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8961c0b4-0e34-43be-9022-384a4847f5d3\n\n#### Enhance KubeEdge testing coverage\n\n- Description: KubeEdge would like to improve the UT coverage of the code to better maintain the quality of the code and reduce the introduction of defects. Increase the UT coverage rate to 60% to 70% (currently, the UT coverage rate is 38.69% ). It is important to note that in addition to requiring the overall UT coverage of KubeEdge to meet the requirements, the UT coverage of each core code directory(cloud/, edge/, keadm/ and pkg/) also needs to exceed 60%.\n- Expected Outcome: Increase the UT coverage rate to 60% to 70%\n- Recommended Skills: KubeEdge, Go, Testing\n- Mentor(s):\n - Elias Wang (@wbc6080, wangbincheng4@huawei.com)\n - Fisher Xu (@fisherxu, fisherxu1@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6101\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a85be883-5139-4e69-8859-6662f7ffd71d\n\n#### KubeEdge Dashboard Enhancement - BFF\n\n- Description: To improve the performance of KubeEdge dashboard, we would like to introduce a BFF (Backend for Frontend) layer. It serves as a middle layer to handle the communication between the dashboard and the KubeEdge API, providing a more efficient, secure, and maintainable solution.\n- Expected Outcome: \n - Integrate with [keink](https://github.com/kubeedge/keink)\n - Error handling and retry\n - Data pre-processing (Optional)\n- Recommended Skills: KubeEdge, JavaScript, React\n- Mentor(s):\n - Chen Su (@ghosind, ghosind@gmail.com)\n - Elias Wang (@wbc6080, wangbincheng4@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/dashboard/issues/37\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/16217666-64ec-45e7-842b-9df5ceb07382\n\n#### Community Website Comprehensive Upgrade Project: Homepage Renewal and Expansion of Core Pages\n\n- Description: To improve the user experience of the KubeEdge official website, this project will focus on homepage design enhancements, the addition of new pages, and improvements to community resources. The goal of this project is to enhance the website's usability, increase user engagement, and attract more users to KubeEdge by enhancing training content and hardware compatibility support.\n- Expected Outcome:\n - Design and optimization of the homepage, including design and code updates. \n - New page: Showcase for KubeEdge course videos, including design and code updates. \n - New page: \"Hardware Compatibility\" page, including design and code updates. \n - Design and optimization of the partner page, including design and code updates. \n - Optimization of community resources, improving documentation and onboarding experience to ensure users can easily get started and effectively use KubeEdge.\n- Recommended Skills: KubeEdge, JavaScript, Docusaurus\n- Mentor(s):\n - Hongbing Zhang (@HongbingZhang, hongbing.zhang@daocloud.io)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/website/issues/665\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/576c6710-942b-41cc-9e51-113c1957fc02\n\n### KubeStellar\n\n#### Implement a Binding Policy Frontend Supported by Binding Policy Backend Endpoints\n\n_CNCF - KubeStellar: Implement Binding Policy Frontend with Backend Endpoints (2025 Term 1)_\n\n- Description\nThis project focuses on developing the UI components necessary for managing Binding Policies in KubeStellar. Users should be able to create, update, delete, and view policies via an intuitive interface while ensuring seamless integration with the backend API.\n\n- Objectives\n - Develop UI components for managing Binding Policies (CRUD operations).\n - Implement validation mechanisms to ensure policies comply with Kubernetes standards.\n - Provide real-time updates on policy status and binding information.\n - Improve UI design for a seamless user experience.\n- Expected Outcomes\n - A fully functional Binding Policy management UI.\n - Smooth user interaction with the backend API.\n - Modern UI with real-time validation and feedback.\n- Recommended Skills\n - Frontend Development: Node.js, React, Vite, and REST API integration.\n - Backend Development: Go and Kubernetes API communication.\n - Cluster Management: Familiarity with Kubernetes clusters and associated workflows.\n - UI/UX Design: Experience in designing interfaces for system operators.\n- Mentor(s)\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n - Braulio Dumba (dumb0002, braulio.dumba@ibm.com)\n- Upstream Issue: https://github.com/kubestellar/ui/issues/54\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8bbb76e3-07e5-404d-9335-28cc0d8ecf0c\n\n#### Implement a Binding Policy Backend to Support UI Frontend\n\nDescription\nThis project focuses on implementing the backend API for managing Binding Policies. The API should support creating, reading, updating, and deleting policies while ensuring robust validation and performance.\n\n- Objectives\n - Develop backend API endpoints for Binding Policy management.\n - Ensure proper validation and enforcement of Kubernetes standards.\n - Optimize backend performance for handling multiple policy requests.\n - Implement logging and error handling for better debugging.\n- Expected Outcomes\n - A secure and scalable backend API for Binding Policies.\n - Full CRUD functionality accessible from the UI.\n - Improved validation and performance optimizations.\n- Recommended Skills\n - Frontend Development: Node.js, React, Vite, and REST API integration.\n - Backend Development: Go and Kubernetes API communication.\n - Cluster Management: Familiarity with Kubernetes clusters and associated workflows.\n - UI/UX Design: Experience in designing interfaces for system operators.\n- Mentor(s)\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n - Braulio Dumba (dumb0002, braulio.dumba@ibm.com)\n- Upstream Issue: https://github.com/kubestellar/ui/issues/53\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d9f46954-3b56-4e42-b83c-dd3dee2b8b6d\n\n#### Implement a WDS Backend to Support UI Frontend Operations\n\n- Description\nThis project will focus on implementing the backend infrastructure necessary to manage Workload Description Space (WDS) operations. The backend will support UI functionalities such as workload deployment and visualization.\n\n- Objectives\n - Develop API endpoints for workload deployment to WDS.\n - Implement workload status tracking and log retrieval.\n - Ensure efficient workload resource retrieval.\n- Expected Outcomes\n - A robust WDS backend to support UI functionalities.\n - Secure API integrations for workload management.\n - Efficient backend processes for workload deployment and tracking.\n- Recommended Skills\n - Frontend Development: Node.js, React, Vite, and REST API integration.\n - Backend Development: Go and Kubernetes API communication.\n - Cluster Management: Familiarity with Kubernetes clusters and associated workflows.\n - UI/UX Design: Experience in designing interfaces for system operators.\n- Mentor(s)\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n - Braulio Dumba (dumb0002, braulio.dumba@ibm.com)\n- Upstream Issue: https://github.com/kubestellar/ui/issues/52\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/885239e6-6a95-410f-9aae-00fd8b4c5f09\n\n#### Implement a WDS Frontend Supported by WDS Backend\n\n- Description\nThis project focuses on enhancing the KubeStellar UI with WDS-related functionalities, allowing users to manage and deploy workloads effectively.\n\n- Objectives\n - Implement UI components for managing workloads in WDS.\n - Integrate real-time workload deployment tracking.\n - Enhance UI design for better user experience and usability.\n - Display visual indicators for workload placement across multiple clusters.\n- Expected Outcomes\n - A user-friendly UI for managing WDS workloads.\n - Real-time feedback on deployment status.\n - Improved visualization of workload distribution.\n- Recommended Skills\n - Frontend Development: Node.js, React, Vite, and REST API integration.\n - Backend Development: Go and Kubernetes API communication.\n - Cluster Management: Familiarity with Kubernetes clusters and associated workflows.\n - UI/UX Design: Experience in designing interfaces for system operators.\n- Mentor(s)\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n - Braulio Dumba (dumb0002, braulio.dumba@ibm.com)\n- Upstream Issue: https://github.com/kubestellar/ui/issues/51\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e549191d-6880-4a98-8fd2-ec5fc47ecc92\n\n#### Implement an ITS Frontend Supported by ITS Backend Endpoints\n\n- Description\nThis project aims to develop the frontend components for managing clusters in the Inventory and Transport Space (ITS). Users should be able to onboard and manage clusters through an intuitive UI.\n\n- Objectives\n - Develop UI components for cluster onboarding and management.\n - Implement validation and error handling for cluster registration.\n - Ensure smooth integration with backend APIs for real-time updates.\n - Provide a guided onboarding experience for adding new clusters.\n- Expected Outcomes\n - A fully functional ITS management UI.\n - Improved usability for adding and managing clusters.\n - Seamless backend integration for real-time data updates.\n- Recommended Skills\n - Frontend Development: Node.js, React, Vite, and REST API integration.\n - Backend Development: Go and Kubernetes API communication.\n - Cluster Management: Familiarity with Kubernetes clusters and associated workflows.\n - UI/UX Design: Experience in designing interfaces for system operators.\n- Mentor(s)\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n - Braulio Dumba (dumb0002, braulio.dumba@ibm.com)\n- Upstream Issue: https://github.com/kubestellar/ui/issues/50\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b3805d32-03c4-4d5f-b56e-613ac24629c1\n\n#### Implement an ITS Backend to Support UI Frontend Operations\n\n- Description\nThis project focuses on building the backend functionality necessary for managing clusters in ITS. It will provide API endpoints to support the frontend’s cluster onboarding and management features.\n\n- Objectives\n - Develop backend APIs for ITS cluster management.\n - Implement validation and security features for onboarding new clusters.\n - Ensure high performance and scalability for handling multiple clusters.\n - Optimize API interactions for faster response times.\n- Expected Outcomes\n - A fully functional ITS backend with API support.\n - Secure and efficient cluster onboarding processes.\n - Scalable architecture for managing large Kubernetes deployments.\n- Recommended Skills\n - Frontend Development: Node.js, React, Vite, and REST API integration.\n - Backend Development: Go and Kubernetes API communication.\n - Cluster Management: Familiarity with Kubernetes clusters and associated workflows.\n - UI/UX Design: Experience in designing interfaces for system operators.\n- Mentor(s)\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n - Braulio Dumba (dumb0002, braulio.dumba@ibm.com)\n- Upstream Issue: https://github.com/kubestellar/ui/issues/49\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/11478e3c-ac06-4d15-a11f-a7bf1f9994e3\n\n### Kyverno\n\n#### Chainsaw Tests For New Policy Types\n\n- Description: Kyverno 1.14 is introducing new policy types based on the upstream Kubernetes ValidatingAdmissionPolicy and MutatingAdmissionPolicy resources, as well as a new ImageVerificationPolicy based on CEL. This project will add e2e tests using Chainsaw for these new policy types.\n- GitHub Issue: [Chainsaw testing](https://github.com/kyverno/kyverno/issues/12065)\n- Recommended Skills: Golang, Kubernetes, ValidatingAdmissionPolicy\n- Mentor(s): Charles-Edouard Brétéché (@eddycharly, charles.edouard@nirmata.com)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d9683d35-0ad4-4c32-b32d-f058d37cf94f\n\n#### Sample Policies For New Policy Types\n\n- Description: Kyverno 1.14 is introducing new policy types based on the upstream Kubernetes ValidatingAdmissionPolicy and MutatingAdmissionPolicy resources, as well as a new ImageVerificationPolicy based on CEL. This project will focus on the website and sample policy updates using the new policy types.\n- GitHub Issue: https://github.com/kyverno/kyverno/issues/12085 \n- Recommended Skills: Golang, Kubernetes, ValidatingAdmissionPolicy, MutatingAdmissionPolicy\n- Mentor(s): Jim Bugwadia [@JimBugwadia](https://github.com/JimBugwadia)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/59295005-33de-4665-82b5-d315d108da31\n\n#### Mutating Admission Policy Integration\n- Description: This project will focus on Integrating the new Kubernetes MutatingAdmissionPolicy with Kyverno CLI for the apply and test commands. \n- GitHub Issue: https://github.com/kyverno/kyverno/issues/10573\n- Recommended Skills: Golang, Kubernetes, MutatingAdmissionPolicy\n- Mentor(s): Mariam Fahmy (@MariamFahmy98, mariam.fahmy@nirmata.com), Shuting Zhao (@realshuting, shuting@nirmata.com)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1db4df12-49f2-467e-93c2-1625e462eb20\n\n### LitmusChaos\n\n#### Enhancing CI/CD Integration for LitmusChaos: SDK Development and Chaos-CI-Lib Revamp\n\nCNCF - LitmusChaos: CI/CD Integration, SDK Development & Chaos-CI-Lib Revamp (2025 Term 1)\n\n- Description: This task aims to improve the CI/CD experience for LitmusChaos by developing a dedicated SDK that integrates seamlessly with existing CI libraries. The revamped Chaos CI Library will align with Litmus 3.x, eliminating outdated installation steps and enabling direct invocation of prebuilt chaos experiments. Additionally, CI action templates will be refined to optimize tunables, ensuring a smoother and more efficient workflow for users leveraging GitHub and GitLab pipelines.\n- Expected Outcome:\n - Seamless CI/CD integration with a new Chaos CI SDK\n - A modernized Chaos-CI-Lib compatible with Litmus 3.x\n - Optimized CI action templates for GitHub and GitLab pipelines\n- Recommended Skills: Go, scripting, CI/CD, familiarity with LitmusChaos is a plus but not required.\n- Mentor(s):\n - Shubham Chaudhary (@ispeakc0de, shubham.chaudhary@harness.io)\n - Vedant Shrotria (@Jonsy13, vedant.shrotria@harness.io )\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/5038\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/445a6158-3ba7-429e-b0e1-f7417ff9a724\n\n#### Improve the code coverage for observability in the LitmusChaos components\n\nCNCF - LitmusChaos: Improve code coverage for observability in LitmusChaos components (2025 Term 1)\n\n- Description: Enhancing observability across key components, including chaos-runner, chaos-operator, and litmus-go. By adding distributed tracing(span, span attributes, and error tracking) and exporting logs to the Open Telemetry Collector.\n- Expected Outcome:\n - Enhanced observability with OpenTelemetry in key LitmusChaos components\n - Detailed span instrumentation for improved tracing and error tracking\n - Logs seamlessly exported to OpenTelemetry Collector\n- Recommended Skills: OpenTelemetry, Go, familiarity with LitmusChaos is a plus but not required\n- Mentor(s):\n - Namkyu Park (@namkyu1999, lak9348@gmail.com)\n - Adarsh Kumar (@Adarshkumar14, adarsh.kumar@harness.io)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/5039\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/55d8f0a4-86d5-4a90-890b-e8750a27dc60\n\n#### Expanding the LitmusChaos Tutorials - Day 0, Day 1, and Day 2 User Flows\n\nCNCF - LitmusChaos: Expand Tutorials – Day 0, Day 1 & Day 2 User Flows (2025 Term 1)\n\n- Description: This task focuses on improving the LitmusChaos documentation by structuring and creating tutorials into Day 0, Day 1, and Day 2 workflows tailored for different users. Instead of documenting individual faults (which would require constant maintenance), the goal is to create user-flow-based guides that help users understand chaos engineering principles at different levels of expertise, from beginners experimenting with sample apps to advance users implementing chaos in real-world systems. Additionally, this task will involve tech doc improvements, fixing structural issues, removing duplicates, and ensuring a clear and intuitive documentation experience for the community\n- Expected Outcome:\n - Structured Day 0, Day 1, and Day 2 tutorials for different user levels\n - Improved documentation clarity and reduced redundancy\n - Persona-based chaos experiment guides for real-world use cases\n- Recommended Skills: Techincal Writing, Research Skills, familiarity with LitmusChaos is a plus but not required\n- Mentor(s):\n - Sayan Mondal (@S-ayanide, sayanmondal342@gmail.com)\n - Smriti Satyanarayana (@SmritiSatya, smriti.satyanarayana@harness.io)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/5037\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e10bdb01-ef2b-41c5-9a84-6891ecaf6364\n\n### Meshery\n\n#### Meshery Model Support for kro ResourceGraphDefinitions (RGDs)\n\n- Description: Enhance Meshery's existing orchestration capabilities to include support for kro ResourceGraphDefinitions (RGDs) as first-class [Meshery Models](https://docs.meshery.io/concepts/logical/models). This involves enabling Meshery to manage and orchestrate RGDs, similar to how it handles other Kubernetes resources. The project will also include generating support for ResourceGraphDefinition in Meshery's Model generator.\n\n- Expected Outcome: Meshery will be able to orchestrate and manage kro RGDs. This includes the ability to deploy, configure, and manage the lifecycle of RGDs through Meshery. The Meshery Model generator will be updated to automatically generate models for kro RGDs, simplifying their integration and management within Meshery. This will be an officially supported feature of Meshery.\n- Recommended Skills: Golang, Cuelang, Well-written and well-spoken English, Kubernetes, DevOps\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Mia Grenell (@miacycle, mia.grenell2337@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/13520\n- LFX URL: https://crowdfunding.lfx.linuxfoundation.org/projects/2ce4cf0b-05e0-430a-b9e1-3df46d917ef6\n\n#### Hands-on tutorials using Meshery Playground\n\n- Description: Learning paths with hands-on labs are a crucial resource for DevOps engineers and cloud-native practitioners. The Meshery Playground provides a live cluster environment, making it an ideal platform for learning every kind of cloud and cloud native technology. Meshery Docs is in need of comprehensive tutorials and scenarios covering common infrastructure management use cases.\n\nYour mission in this internship is to create and publish a series of hands-on tutorials using Meshery Playground. Each tutorial will include step-by-step guides, live demonstrations, and interactive labs using the Playground allowing learners to apply their knowledge directly without the hassle of any configuration.These tutorials will be reviewed by various project maintainers and then published in [guides/tutorials](https://docs.meshery.io/guides/tutorials).\n\n- Expected Outcome:\n - 10+ new tutorials published in Meshery Docs.\n - Each tutorial should be interactive, guiding users through infrastructure management scenarios.\n - Tutorials should vary in complexity, catering to beginners and advanced learners\n- Recommended Skills: written English, Markdown, Kubernetes, DevOps, and hands-on experience with cloud-native tools.\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), James Horti (@hortison, james.horton2337@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/13521\n- LFX URL: https://crowdfunding.lfx.linuxfoundation.org/projects/4cca92b8-ede6-4396-8d3f-68cfa2ec911c\n\n#### Expanding end-to-end test coverage in Meshery using Playwright\n\n- Description: Meshery integrates with many other CNCF projects and technologies. Sustaining those integrations is only possible through automation. To automate functional integration and end-to-end testing, Meshery now uses Playwright as one of the tools for browser testing. End-to-end tests run with each pull request to ensure that changes do not break existing functionality.\n\nExpanding the coverage of E2E tests is crucial to improving the reliability of Meshery’s UI and workflows. This project focuses on writing Playwright-based tests for more Meshery components, ensuring robust test coverage across the platform.\n\n- Expected Outcome:\n - Development of comprehensive E2E test cases for additional Meshery components using Playwright.\n- Recommended Skills: JavaScript, Playwright, GitHub Workflows, familiarity with React or Nextjs would be helpful, CI/CD\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Aabid Sofi (@aabidsofi19, mailtoaabid01@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/13514\n- LFX URL: https://crowdfunding.lfx.linuxfoundation.org/projects/abd10fed-e03f-4425-863e-157accfe354f\n\n### Microcks\n\n#### Improving Microcks CLI\n\n- Description: Microcks (https://microcks.io/) is a cloud native, open source tool under CNCF for API and microservices mocking and testing.\nThis project seeks to enhance our CLI tool by integrating frameworks like Cobra CLI.\n- Expected Outcome: @JulienBreux has started some work on creating a utility tool called `mksctl` [here](https://github.com/JulienBreux/mksctl).\nThe base of `mksctl` has also been reversed into the `1.x` branch of the `microcks-cli` repo [here](https://github.com/microcks/microcks-cli/tree/1.x). The main goals of a new CLI version are:\n - Provide the same interface for exiting test and import commands\n - Provide a way to easily install this tool via integration with packet manager (brew, apt or others)\n - Allow developers to easily start new Microcks instances with mksctl start and mksctl stop, for example\n - Allows quick addition of new commands like import from URL, import all the files from a directory, create job, list jobs, and so on.\nMoving to standard tools like Cobra CLI is a way to make it more scalable so that people can contribute and add the features they want.\n- Recommended Skills: Go, scripting, CLI, APIs.\n- Mentor(s):\n - Yacine Kheddache (@yada, yacine@microcks.io)\n - Laurent Broudoux (@lbroudoux, laurent@microcks.io)\n - Julien Breux (@JulienBreux, julien.breux@gmail.com)\n- Upstream Issue: https://github.com/microcks/microcks-cli/issues/97\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7ceac2ef-6290-4e2a-87aa-db93d909b27b\n\n#### Update the Microcks Hub frontend and make it deployable on-premises\n\n- Description: Microcks (https://microcks.io/) is a cloud native, open source tool under CNCF for API and microservices mocking and testing.\n[Microcks Hub](https://hub.microcks.io) is a community-driven hub that aggregates standards or product-related API mocks and test suites.\nMicrocks hub was created a long time ago with a technology stack we should refresh (Angular 8 at the moment). \n- Expected Outcome:\n - refresh UI aligned with ongoing work and decisions taken for the main Microcks UI, see: https://github.com/orgs/microcks/discussions/1458\n - It was initially designed to be deployable only in a single public instance, but there are requests to make it deployable on-premises.\n - We're looking for contributions on this part, such as helping develop Docker Compose files, Kubernetes Helm Charts, or whatever makes sense.\n - The code base is hosted on https://github.com/microcks/hub.microcks.io\n- Recommended Skills: UI, Front End Developer, [Svelte](https://svelte.dev/) and [SvelteKIt](https://svelte.dev/docs/kit/introduction#What-is-SvelteKit), [Vite](https://vite.dev/)...\n- Mentor(s):\n - Yacine Kheddache (@yada, yacine@microcks.io)\n - Laurent Broudoux (@lbroudoux, laurent@microcks.io)\n- Upstream Issue: https://github.com/microcks/hub.microcks.io/issues/76\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/faccb875-1d96-44f5-aef7-95c53403d636\n\n#### Microcks Hub: Expanding Sandbox and Mocking Capabilities for Key Industry APIs\n\nCNCF - Microcks: Expand Microcks Hub Sandbox & Mocking for Key Industry APIs (2025 Term 1)\n\n- Description: Microcks (https://microcks.io/) is a cloud native, open source tool under CNCF for API and microservices mocking and testing.\nThis project aims to enhance the [Microcks Hub](https://hub.microcks.io/) by updating the existing sandbox environment or adding new hub entries to mock key APIs IT industry leaders use. The goal is to make it easier for developers to test and prototype integrations with popular APIs like GitHub, Twilio, Stripe, or Salesforce using Microcks.\n- Expected Outcome: Participants can choose to focus on one or both of the following aspects:\n 1. Update and Refresh the Existing Sandbox:\n - Improve the sandbox environment provided by Microcks Hub for existing mock APIs.\n - Ensure compliance with the latest versions of existing APIs.\n - Enhance documentation, usability, and deployment mechanisms.\n 2. Add New Hub Entries for Key Industry APIs:\n - Develop mock entries for leading APIs like GitHub, Twilio, Stripe, or Salesforce, but we welcome any ideas...\n - Ensure the mocks cover essential endpoints and realistic request-response pairs.\n - Provide detailed examples and use cases to support integration testing.\n- Recommended Skills: OpenAPI, API dev mock & test, YAML, \n- Mentor(s):\n - Yacine Kheddache (@yada, yacine@microcks.io)\n - Laurent Broudoux (@lbroudoux, laurent@microcks.io)\n- Upstream Issue: https://github.com/microcks/hub.microcks.io/issues/77\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/04da9d38-b9f8-435f-9200-8359f55ccf92\n\n#### Expanding Microcks community documentation for advanced installations\n\n- Description: Microcks (https://microcks.io/) is a cloud native, open source tool under CNCF for API and microservices mocking and testing.\nMicrocks depends on community contributions to address installation, setup, and infrastructure maintenance topics that fall outside the scope of the core project. This project aims to enhance the [Microcks Community Repository](https://github.com/microcks/community/tree/main/install) by providing detailed guides to help users with advanced and production-grade setups.\n- Expected Outcome:\n - Fostering community members to share their technical knowledge on those topics,\n - Making contributions easy and straightforward - easily gathering this knowledge\n - Promoting contributed content with new access from the documentation, improved integration with our social communications, etc...\n- Recommended Skills: Technical Writer, open source principles and community management \n- Mentor(s):\n - Yacine Kheddache (@yada, yacine@microcks.io)\n - Laurent Broudoux (@lbroudoux, laurent@microcks.io)\n- Upstream Issue: https://github.com/microcks/community/issues/34\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6b4c516d-fc01-4ab3-8147-13273fcde76b\n\n#### Improving Microcks delivery and validation with GitHub Actions CI deployment tests\n\nCNCF - Microcks: Improve delivery & validation with GitHub Actions CI deployment tests (2025 Term 1)\n\n- Description: Microcks (https://microcks.io/) is a cloud native, open source tool under CNCF for API and microservices mocking and testing.\nThis project focuses on enhancing the reliability and quality of Microcks releases by introducing comprehensive CI deployment tests and validations using GitHub Actions. While the project already includes unit and integration tests, recent issues (ex: https://github.com/microcks/microcks/issues/1470 and https://bugs.openjdk.org/browse/JDK-8345296) with dependencies have underscored the need for end-to-end validation to ensure new integrations do not introduce bugs or regressions.\\\n\\\nParticipants will develop workflows for building and deploying Microcks and running automated tests to confirm its functionality under real-world scenarios. This will help prevent edge cases and dependency-related issues affecting the Microcks community and adopters. This project improves the delivery process to ensure that Microcks' releases meet the community's expectations for quality and reliability.\n- Expected Outcome: Workflows encompass a bunch of deployment tests:\n - Test container images (with docker, with podman, and on different architectures)\n - Testing of common docker-compose configurations\n - Testing of Helm chart with different setup options\n- Recommended Skills: GitHub actions, deployment tests, QA, Docker, Helm chart...\n- Mentor(s):\n - Yacine Kheddache (@yada, yacine@microcks.io)\n - Laurent Broudoux (@lbroudoux, laurent@microcks.io)\n- Upstream Issue: https://github.com/microcks/microcks/issues/1480\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0c667baa-94bf-405c-ada6-c2bea3bf3e56\n\n#### Building Community-Driven documentation for deploying Microcks in cloud production environments\n\nCNCF - Microcks: Community-Driven Docs for Deploying Microcks in Cloud Production (2025 Term 1)\n\n- Description: Microcks (https://microcks.io/) is a cloud native, open source tool under CNCF for API and microservices mocking and testing.\nThis project aims to support the growing Microcks adopter community by fostering a collaborative effort to document production-grade deployment strategies for cloud environments. While the core Microcks maintainers focus on features, security, and enhancements, the adopters are responsible for production setups. However, a shared repository of best practices can help users learn from one another in a true open-source spirit. This project will empower the community to deploy Microcks confidently in diverse cloud environments, fostering collaboration and sharing of expertise among adopters.\n- Expected Outcome: Participants will contribute to the Microcks community repository (https://github.com/microcks/community/tree/main/install) by documenting deployment workflows for popular cloud providers, such as AWS, GCP, and Azure, as well as other providers like OVH, Oracle, Scaleway, or Koyeb. Deliverables will include guides on utilizing cloud-native services (e.g., PostgreSQL, MongoDB, IDP) to create robust and scalable Microcks installations ideally on managed Kubernetes services from the provider.\n- Recommended Skills: GitOps, SRE, Infra as code, cloud.\n- Mentor(s):\n - Yacine Kheddache (@yada, yacine@microcks.io)\n - Laurent Broudoux (@lbroudoux, laurent@microcks.io)\n- Upstream Issue: https://github.com/microcks/community/issues/32\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1b766ba2-3de6-4eb4-8e0d-f79105b000b0\n\n#### Streamlining Microcks Deployment on AWS Marketplace\n\n- Description: Microcks (https://microcks.io/) is a cloud native, open source tool under CNCF for API and microservices mocking and testing.\nThis project focuses on creating a validated and repeatable SaaS architecture for deploying Microcks on AWS, with the ultimate goal of listing it on the AWS Marketplace through the AWS Partner Network Co-Sell program. By addressing the community's frequent demand, this initiative will simplify Microcks' adoption while leveraging a complete suite of AWS services to ensure scalability, security, and ease of deployment.\\ The core Microcks maintainers focus on features, security, and enhancements. The adopters are responsible for production setups. However, a shared repository of best practices can help users learn from one another in a true open-source spirit. Participants will contribute to the Microcks community repository (https://github.com/microcks/community/tree/main/install) by documenting the AWS Marketplace deployment.\n- Expected Outcome: This project will enable Microcks adopters to confidently deploy production-ready setups on AWS, ensuring the scalability and reliability needed for enterprise environments. By integrating Microcks into the AWS Marketplace, the project will further enhance its visibility and adoption within the AWS ecosystem. Key objectives include:\n - Designing and validating a SaaS architecture that is compliant with AWS Foundational Technical Review (FTR).\n - Utilizing AWS-native services such as EKS, Aurora (PostgreSQL), DocumentDB, API Gateway, IAM, and CloudFormation for an end-to-end deployment.\n - Streamlining deployment workflows to create an open source, community-maintained solution that organizations can quickly adopt.\n- Recommended Skills: AWS and AWS services, CloudFormation.\n- Mentor(s):\n - Yacine Kheddache (@yada, yacine@microcks.io)\n - Laurent Broudoux (@lbroudoux, laurent@microcks.io)\n- Upstream Issue: https://github.com/microcks/community/issues/33\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/51c0d803-95ea-48c1-b966-5946b8599662\n\n### OpenKruise\n\n#### Implement Fuzz testing for OpenKruise\n\n- Description: Implement fuzz testing for OpenKruise using a suitale tool like oss-fuzz. Generate a comprehensive input set to guide the fuzz testing, and identify features that accept complex user inputs for testing. Document the entire process for repeatability in future versions and integrate the fuzz testing into CI pipeline.\n- Expected Outcome:\n - Add a fuzz test that covers important features including workoadspread,uniteddeployment, sidecarset and resourcedistribution.\n - Enable continuous fuzzing using [OSS-Fuzz](https://github.com/google/oss-fuzz).\n- Recommended Skills: Go, Kubernetes, Fuzz Testing Experience\n- Mentor(s):\n - Zhang Zhen (@furykerry, furykerry@gmail.com)\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n- Upstream Issue: https://github.com/openkruise/kruise/issues/1713\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/82bfa5b9-67a9-41ce-ba8b-f027cda4521e\n\n### Prometheus\n\n#### Get `PrometheusRemoteWriteReceiver` in OTel-Collector to Alpha Maturity\n\n- Description: In recent discussions with the team, we decided that Prometheus won't be exporting its data with the OTLP format, however, Prometheus is still committed to have good import/export compatibility with OpenTelemetry. Last year Prometheus release the second version of its Remote-Write protocol, which translates a lot better with the OTLP format and the team started working on a PRW receiver in the collector-contrib project. This project is about getting this component into the finish line and publish it as an stable component in the collector.\n- Expected Outcome: PrometheusRemoteWriteReceiver considered Alpha and released with OpenTelemetry-Collector-Contrib.\n- Recommended Skills: Prometheus Remote-Write, OTLP, Go.\n- Mentor(s):\n - Arthur Sens (@ArthurSens, arthursens2005@gmail.com)\n- Upstream Issue: https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/37277\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/47603a7d-4dc7-48f0-968f-21c2f18f4e3c\n\n#### UX Research: How users expect to use OTLP Resource Attributes in Prometheus\n\n- Description: In the last year Prometheus has tackled and solved many UX problems that OTel users had when sending OTLP data to Prometheus. One challenge that remains unsolved is how do users expect to use OTLP Resource Attributes in Prometheus. This project is about conducting a UX research that explores the main problems users are facing today with the current state of Resource Attributes and Prometheus and coming up with ideas how to solve them.\n- Expected Outcome: \n - Preliminary artifacts (e.g., research plan) shared as project progresses.\n - Research report, summarizing the findings.\n - A spoken presentation including research method and results.\n - Stretch goal: apply to present the project at KubeCon.\n- Recommended Skills:\n - Interest or currently working in UX Research and Design.\n - Familiarity with databases and querying.\n - Being comfortable to talk with End-Users in English.\n- Mentor(s):\n - Arthur Sens (@ArthurSens, arthursens2005@gmail.com)\n - Amy Super (@amy-super, amy.super@grafana.com)\n - Andrej Kiripolsky (@AndrejKiri, andrej.kiripolsky@gmail.com)\n- Upstream Issue: https://github.com/prometheus/prometheus/issues/15909\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/36e3f336-ce78-4074-b833-012015eb59be\n\n### Thanos\n\n#### Add support for new PromQL aggregations\n\nThanos (https://thanos.io) has its own PromQL (Prometheus (https://prometheus.io) querying language) engine. The original PromQL engine recently added support for new aggregations. We are missing support for them in the Thanos PromQL engine (https://github.com/thanos-io/promql-engine).\n\nIn this project you will implement support for `limitk` and `limit_ratio`. See issue (https://github.com/thanos-io/promql-engine/issues/515). This will unblock users who need this functionality.\n\nThe project is interesting because you will learn how query engines are implemented, about distributed query execution.\n\n- Expected Outcome: `limitk`, `limit_ratio` are supported in the Thanos PromQL engine (local & distributed modes), tests are written for them\n- Recommended Skills: Go programming language experience\n- Mentor(s): #\n - Giedrius Statkevičius (@GiedriusS, giedriuswork@gmail.com)\n - Saswata Mukherjee (@saswatamcode, saswataminsta@yahoo.com)\n- Upstream Issue (URL): https://github.com/thanos-io/promql-engine/issues/515\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d58c0d26-e276-4ca5-b2ca-21e6582fbcf7\n\n### TUF\n\n#### Metadata Repository Visualization\n\nA [TUF](https://theupdateframework.com/) metadata repository consists of signed metadata files, which are read by TUF clients when securely downloading artifacts. The [metadata](https://theupdateframework.com/docs/metadata/) contains information about the artifacts and about the metadata itself, most notably, who is trusted to sign what.\n\nA suitable visual representation of this trust hierarchy makes TUF's security properties more accessible to end-users, and, more importantly, allows metadata signers to carefully review metadata changes before signing them.\n\nIn this project you will, together with your mentor and the TUF community, identify requirements for the visualization of a TUF metadata repository and build a corresponding web app.\n\n- Expected Outcome: Identify requirements and build a basic web app to visualize TUF metadata. *(Initial requirements may be inspired by the `tuf-on-ci` use case.)*\n- Recommended Skills: Front-end web development, Information Visualization\n- Mentor(s): # \n - Lukas Pühringer (@lukpueh, lukas.puehringer@nyu.edu) - primary\n - Jussi Kukkonen (@jku, jku@goto.fi)\n- Upstream Issue (URL): https://github.com/theupdateframework/specification/issues/312\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ea1a5098-29ce-4799-82e0-07416ab4b56a\n\n### Vitess\n\n#### Enhance flag support across Vitess Components\n\nVitess is a distributed database system built on MySQL. Flags are widely used in Vitess for configuring components. As part of a major Vitess flag restructure, support for dynamic flag configuration was introduced. However, several Vitess components have not yet fully adopted this feature. This project involves modifying these components to fully integrate dynamic flags and performing additional flag-related refactors where necessary.\n\n- Expected Outcome: Improved flag support across all Vitess components, ensuring consistent and flexible configuration management.\n- Recommended Skills: golang\n- Mentor(s):\n- Deepthi Sigireddi (@deepthi, deepthi@planetscale.com)\n- Rohit Nayak (@rohit-nayak-ps, rohit@planetscale.com)\n- Upstream Issue: https://github.com/vitessio/vitess/issues/17687\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2bb1bdc0-3fd7-4537-b44f-9afde27ed9fe\n\n#### Develop an FAQ Chatbot for Vitess using Retrieval-Augmented Generation\n\nVitess is a distributed database system built on MySQL. Developers often need to search through documentation, Slack \ndiscussions, and GitHub issues to find answers. This project will implement an AI-powered FAQ chatbot using \n**Retrieval-Augmented Generation**, integrating **vector search** with an **LLM** (like OpenAI, DeepSeek, \nGPT-4, Mistral, Llama3). The chatbot will be available via a **CLI and Slack bot** for developer support.\n\n- Expected Outcome: A chatbot that provides accurate Vitess-related answers via CLI and Slack, using indexed documentation and discussions for retrieval.\n- Recommended Skills: golang, python, LLM APIs, vector databases\n- Mentor(s):\n - Rohit Nayak (@rohit-nayak-ps, rohit@planetscale.com)\n - Manan Gupta (@GuptaManan100, manan@planetscale.com)\n- Upstream Issue: https://github.com/vitessio/vitess/issues/17690\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/077e714c-63ad-477d-8124-e879a7ea8fe2\n\n### Volcano\n\n#### Volcano supports queue-level scheduling policies\n\n- Description: Volcano supports unified scheduling of online and offline workloads, provides a wealth of scheduling plugins and algorithms, and can distinguish different tenants through queue distinction. The current scheduling policy is a global configuration, and all jobs in the queue use the same scheduling policy, but in actual scenarios, different tenants may need to use different scheduling policies due to different usage scenarios. Therefore, volcano needs to support setting and using different scheduling policies at the queue level instead of using a globally unified scheduling policy.\n- Expected Outcome:\n - A new field is added to the queue CRD, and users can set scheduling policies at the queue level.\n - Volcano scheduler implements different scheduling policies based on the queue in which the job is located.\n- Recommended Skills: Kubernetes, GO, Volcano\n- Mentor(s):\n - Xuzheng Chang(@Monokaix, 2536818783@qq.com)\n - Zicong Chen(@JesseStutler, jesseincomparable@hotmail.com)\n- Upstream Issue: https://github.com/volcano-sh/volcano/issues/3992\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a785c059-fb70-41aa-88a2-62692ab2ca98\n\n#### Coordinate descheduler and Volcano to support resource defragmentation\n\n- Description: Volcano community has provided Volcano descheduler to support descheduling. Currently, load-aware rescheduling is supported. Resource fragmentation is a problem that users are more concerned about. Volcano needs to provide a resource defragmentation strategy based on the existing descheduler, and needs to ensure that the evicted pods can be rescheduled successfully, which requires the cooperation of the rescheduler and the scheduler to solve resource fragmentation and maximize resource utilization.\n- Expected Outcome:\n - Implementing a resource defragmentation strategy based on Volcano descheduler.\n - The Volcano descheduler works in conjunction with the Volcano scheduler to ensure that evicted pods can be re-scheduled successfully.\n- Recommended Skills: Kubernetes, GO, Volcano\n- Mentor(s):\n - Xuzheng Chang(@Monokaix, 2536818783@qq.com)\n - Zicong Chen(@JesseStutler, jesseincomparable@hotmail.com)\n- Upstream Issue: https://github.com/volcano-sh/volcano/issues/3948\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/607246c3-f48b-446c-a7cc-10c0068c553f\n\n#### Volcano dashboard feature enhancements\n\n- Description: Volcano dashboard is a volcano resource front-end display tool. Currently, it only supports viewing resources, and the resources displayed are limited. It needs to support viewing more resources, and supports operations such as creation and deletion.\n- Expected Outcome:\n - Supports viewing resources other than volcano related resources.\n - Supports add, delete, modify and query resources such as queues and volcano jobs.\n- Recommended Skills: Kubernetes, React, Node, JS\n- Mentor(s):\n - Xuzheng Chang(@Monokaix, 2536818783@qq.com)\n - Zicong Chen(@JesseStutler, jesseincomparable@hotmail.com)\n- Upstream Issue: https://github.com/volcano-sh/dashboard/issues/11\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/438c1fec-d3d3-4ab0-82ce-499993f8b681\n\n### WasmEdge\n\n#### Implement a new WasmEdge installer in Rust\n\n- Description: Create a new tool in Rust that provides: Support cross-operating systems, including Linux(amd64 and aarch64), macOS(Intel models and Apple Silicon models), and Windows(amd64); Simplifies installation of the WasmEdge runtime and its plugins in a single tool called wasmedgeup; Automatically handles versioning, dependencies, OS/ARCH detection, and ensure the same user experience across operating systems and architectures. For more details, please refer to the upstream issue.\n- Expected Outcome:\n - A Rust implemented installer in [wasmedgeup](https://github.com/WasmEdge/wasmedgeup).\n - A document to describe how to use.\n - A CI workflow to build and test on Linux(Ubuntu, Fedora), macOS, and Windows.\n- Recommended Skills:\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3990\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/79119ceb-7c52-4b9f-b1f2-694b9d1117e3\n\n#### Implement component model's validator\n\n- Description: The current validator of component model inside of WasmEdge only check nested module and ensure VM can run the nested modules without problem, but the validations from component model are mostly skipped.\n- Expected Outcome:\n - One should create a workable (merged into upstream) implementation of validator by working on\n - `include/validator/validator_component.h`\n - `lib/validator/validator_component.cpp`\n - The visitor pattern are already setup.\n- Recommended Skills:\n - Since component model proposal separate their validation spec, one should able to\n find requirements from https://github.com/WebAssembly/component-model/tree/main/design/mvp\n - Implements it in C++.\n- Mentor(s):\n - Lîm Tsú-thuàn (@dannypsnl, dannypsnl@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3966\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/97f77900-7f5c-45e4-9b0c-638c2db6a8e4\n\n#### Improve the WasmEdge-based Rust coding assistant for inference-time scaling\n\n- Description: In a [previous LFX mentorship project](https://github.com/WasmEdge/WasmEdge/issues/3495), we have created an [LLM-based coding assistant grounded in Rust programming language skills](https://huggingface.co/datasets/gaianet/learn-rust). We aim to further improve the Rust coding assistant by incorporating inference-time compute that utilizes the Rust compiler for feedback. One of the greatest advantages of Rust is its powerful and strict compiler, and the detailed error message generated by the compiler. The Rust compiler could give valuable feedbacks to code generating LLMs to improve the code quality.\n- Expected Outcome:\n - Run a [Qwen Coder 2.5 LLM locally](https://github.com/GaiaNet-AI/node-configs/tree/main/qwen-2.5-coder-7b-instruct) or access it via an API.\n - Create an LLM system prompt that describes the structure and key elements of a `cargo` project. It will guide the LLM to generate multiple files (artifacts) for a complete project.\n - Create a Python program to send user requests to the LLM and parse the generated result into locally cached files.\n - Use a local Rust compiler to build the generated project. Sends the error messages back to the LLM to re-generate.\n - Iterate until there is no more errors.\n - Build a web API for the Python program that takes OpenAI compatible requests and return OpenAI compatible results.\n- Recommended Skills:\n - Rust\n - [LlamaEdge](https://llamaedge.com/docs/user-guide/llm/full-openai)\n - LLMs like ChatGPT\n - Coding assistant like GitHub Copilot\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3985\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/626ca1e4-9869-4401-8e45-68041ebc98cf\n\n#### Create a Japanese translation agent for CNCF videos\n\n- Description: WasmEdge is a cross-platform and lightweight runtime for AI models. It can run a variety of GenAI models, such as [LLM](https://llamaedge.com/docs/user-guide/llm/get-started-with-llamaedge), [whisper](https://llamaedge.com/docs/user-guide/speech-to-text/quick-start-whisper) (voice to text), and [GPT-SoVITS](https://llamaedge.com/docs/user-guide/text-to-speech/gpt-sovits) (text to voice) on your own computers. By combining those 3 models together, developers in the WasmEdge community has created “video translation” applications that can translate video and audio content into another language. One such application is [VideoLangua.com](http://videolangua.com/) In this mentorship, we would like to build a Japanese translator agent that are specifically tailored to CNCF technical content.\n- Expected Outcome:\n - Use whisper to extract a time-stamped English transcript from a sample of CNCF videos. Develop whisper prompt that are suitable for CNCF technical content.\n - Evaluate and select LLMs that are good at English to Japanese translation.\n - Develop LLM prompts that are suitable for CNCF technical content.\n - Train Japanese TTS actor models for GPT-SoVITS using PyTorch.\n - Create dictionaries for how to pronounce CNCF technical words in Japanese.\n - Evaluate the synthesized Japanese voice.\n- Recommended Skills:\n - The mentee must speak Japanese fluently.\n - He or she needs to be familiar with technical content in CNCF videos.\n - He or she should also be familiar with GenAI APIs (eg OpenAI API) and be able use PyTorch.\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n - Miley Fu (@MileyFu, miley@secondstate.io)\n - Vivian Hu (@alabulei1, vivian@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/3986\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5ba528fe-9704-4e11-b46d-607a5ad1e838\n" }, { "path": "programs/lfx-mentorship/2025/01-Mar-May/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n- Upstream Issue:\n\n```\n\n---\n\n\n## Proposed Project ideas\n" }, { "path": "programs/lfx-mentorship/2025/02-Jun-Aug/README.md", "content": "# Term 02 - 2025 Jun - Aug\n\nStatus: Planning\n\nMentorship duration - three months (full-time schedule)\n\n### Timeline\n\n| **Activity** | **Dates (2025)** |\n|--------------------------------|--------------------------------------------------------------------------------|\n| **Project Proposals Open** | Wed, April 16 – Tue, May 13, 2025 11AM PDT (18:00 UTC) |\n| **Mentee Applications Open** | Thurs, May 15, 2025 11AM PDT (18:00 UTC) – Tue, May 27 2025 11AM PDT (18:00 UTC) |\n| **Application Review Period** | Wed, May 28 – Tue, June 3, 2025 11 AM PDT (18:00 UTC) |\n| **Selection Notifications** | Wed, June 4, 2025 |\n| **Mentorship Program Begins** | Mon, June 9, 2025 |\n| **Midterm Mentee Evaluations** | Tues, July 15, 2025 11AM PDT (18:00 UTC) |\n| **First Stipend Payments** | Wednesday, July 16, 2025 |\n| **Final Mentee Evaluations** | Tues, August 26, 2025 11AM PDT (18:00 UTC) |\n| **Second Stipend Payments** | Wednesday, Aug 27, 2025 |\n| **Last Day of Term** | Fri, August 29, 2025 |\n\n### Project instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2025/02-Jun-Aug/project_ideas.md, by May 13, 2025.\nPlease limit proposals to 4-5 proposals per CNCF project.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n* [Antrea](#antrea)\n * [Improvements to the PacketCapture feature](#improvements-to-the-packetcapture-feature)\n * [Replace Dependabot with Renovate for automatic dependency updates](#replace-dependabot-with-renovate-for-automatic-dependency-updates)\n* [Cartography](#cartography)\n * [Fill in missing AWS resource types for CloudGoat scenarios](#fill-in-missing-aws-resource-types-for-cloudgoat-scenarios)\n* [Cilium](#cilium)\n * [Cilium Technical Outcomes](#cilium-technical-outcomes)\n* [CloudNativePG](#cloudnativepg)\n * [Implementing “Declarative Management of PostgreSQL Foreign Data Wrappers” in CloudNativePG](#implementing-declarative-management-of-postgresql-foreign-data-wrappers-in-cloudnativepg)\n* [Copacetic](#copacetic)\n * [Wiz Scanning Support](#wiz-scanning-support)\n* [Envoy Gateway](#envoy-gateway)\n * [Progressive Rollouts of the Envoy Proxy fleet during Envoy Gateway upgrades](#progressive-rollouts-of-the-envoy-proxy-fleet-during-envoy-gateway-upgrades)\n* [Harbor](#harbor)\n * [Harbor CLI](#harbor-cli)\n * [Harbor Satellite: Implementing a Eventing System for Satellite](#harbor-satellite-implementing-a-eventing-system-for-satellite)\n * [Implementing Ground Control for Harbor Satellite](#implementing-ground-control-for-harbor-satellite)\n* [Headlamp](#headlamp-)\n * [Kubernetes Headlamp UI: UX Audit and Design Improvements for Plugins](#kubernetes-headlamp-ui-ux-audit-and-design-improvements-for-plugins)\n * [Kubernetes UI Headlamp Plugin: Karpenter Autoscaling Insights and Management](#kubernetes-ui-headlamp-plugin-karpenter-autoscaling-insights-and-management)\n * [Kubernetes UI Headlamp: Gateway API Service Mesh Visualization](#kubernetes-ui-headlamp-gateway-api-service-mesh-visualization)\n * [Kubernetes UI Headlamp: Implement Kubernetes API Caching, Pagination, and Search](#kubernetes-ui-headlamp-implement-kubernetes-api-caching-pagination-and-search)\n* [Inspektor Gadget](#inspektor-gadget-)\n * [[PM Mentorship] Traceloop GTM Strategy and Execution](#pm-mentorship-traceloop-gtm-strategy-and-execution)\n* [Istio](#istio)\n * [Expand testing for Multi-Cluster in Ambient](#expand-testing-for-multi-cluster-in-ambient)\n * [Update documentation CMS build pipeline](#update-documentation-cms-build-pipeline)\n* [Jaeger](#jaeger)\n * [Jaeger demo on Kubernetes](#jaeger-demo-on-kubernetes)\n * [Upgrade Jaeger-UI to React v19](#upgrade-jaeger-ui-to-react-v19)\n* [Kgateway](#kgateway)\n * [Mission: Scale Possible! Build Automated Scale Tests for kgateway](#mission-scale-possible-build-automated-scale-tests-for-kgateway)\n * [OpenTelemetry is an AI Gateway’s Best Friend: Extending Observability to kgateway’s AI Extensions](#opentelemetry-is-an-ai-gateways-best-friend-extending-observability-to-kgateways-ai-extensions)\n* [Krkn](#krkn)\n * [Chaos scenario rollback feature](#chaos-scenario-rollback-feature)\n* [kube-burner](#kube-burner)\n * [Enhancements around k8s performance testing](#enhancements-around-k8s-performance-testing) \n* [KubeEdge](#kubeedge)\n * [Automatically generate unit tests and e2e tests based on LLM](#automatically-generate-unit-tests-and-e2e-tests-based-on-llm)\n * [Device Anomaly Detection Framework Based on KubeEdge](#device-anomaly-detection-framework-based-on-kubeedge)\n * [Embodied Intelligence Benchmarking Framework for Industrial Manufacturing with KubeEdge-Ianvs](#embodied-intelligence-benchmarking-framework-for-industrial-manufacturing-with-kubeedge-ianvs)\n * [Support KubeEdge EdgeNode Runing on RK3588 Chip](#support-kubeedge-edgenode-runing-on-rk3588-chip)\n* [Kubernetes](#kubernetes)\n * [Graduate the kubeadm feature gate WaitForAllControlPlaneComponents to GA](#graduate-the-kubeadm-feature-gate-waitforallcontrolplanecomponents-to-ga)\n* [KubeStellar](#kubestellar)\n * [Building a Plugin System for KubeStellar](#building-a-plugin-system-for-kubestellar)\n * [Developing a Marketplace UI and Optimize the Current UI](#developing-a-marketplace-ui-and-optimize-the-current-ui)\n * [Enhancing KubeStellar core Helm chart by reducing its reliance on initContainers](#enhancing-kubestellar-core-helm-chart-by-reducing-its-reliance-on-initcontainers)\n * [Extending KubeFlex with a new type of Control Plane](#extending-kubeflex-with-a-new-type-of-control-plane)\n * [Implementing a Model Context Protocol for KubeStellar MCP Server](#implementing-a-model-context-protocol-for-kubestellar-mcp-server)\n * [UX/UI Mentorship: Design System Foundations for KubeStellar](#uxui-mentorship-design-system-foundations-for-kubestellar)\n* [Kyverno](#kyverno)\n * [Improve Test Coverage and Docs for New Policy Types](#improve-test-coverage-and-docs-for-new-policy-types)\n * [Optimize Kyverno CLI In-cluster Resource Loader](#optimize-kyverno-cli-in-cluster-resource-loader)\n* [OpenCost](#opencost)\n * [Enterprise Ready OpenCost: Integration Testing](#enterprise-ready-opencost-integration-testing)\n* [OpenKruise](#openkruise)\n * [add best practice to use openkruise workload with Karmada etc](#add-best-practice-to-use-openkruise-workload-with-karmada-etc)\n * [Build simple dashboard to view and operate OpenKruise workload](#build-simple-dashboard-to-view-and-operate-openkruise-workload-)\n * [OpenKruiseGame controlplane HA deployment support](#openkruisegame-controlplane-ha-deployment-support)\n * [Support progressDeadlineSeconds for Cloneset](#support-progressdeadlineseconds-for-cloneset)\n* [OpenYurt](#openyurt)\n * [OpenYurt Dashboard Enhancements](#openyurt-dashboard-enhancements)\n* [PipeCD](#pipecd)\n * [Support deploy application using OpenTofu with PipeCD plugin](#support-deploy-application-using-opentofu-with-pipecd-plugin)\n * [Support managing SQL schema using PipeCD SQL plugin](#support-managing-sql-schema-using-pipecd-sql-plugin)\n* [Volcano](#volcano)\n * [Enhance JobFlow Functionality](#enhance-jobflow-functionality)\n * [Enhance Volcano Dashboard UX and Functionality](#enhance-volcano-dashboard-ux-and-functionality)\n * [Enhance Volcano Official Documentation](#enhance-volcano-official-documentation)\n * [Implement Volcano Scheduler Simulator](#implement-volcano-scheduler-simulator)\n* [WasmEdge](#wasmedge)\n * [Create an MCP-based AI agent to help LF certificate prep](#create-an-mcp-based-ai-agent-to-help-lf-certificate-prep)\n * [Port WasmEdge and the WASI-NN ggml backend to the s390x platform](#port-wasmedge-and-the-wasi-nn-ggml-backend-to-the-s390x-platform)\n * [Support bitnet.cpp as a new WASI-NN plugin](#support-bitnetcpp-as-a-new-wasi-nn-plugin)\n * [Use Runwasi with WasmEdge runtime to test multiple WASM apps as cloud services](#use-runwasi-with-wasmedge-runtime-to-test-multiple-wasm-apps-as-cloud-services)\n\n\n### Copacetic\n\n#### Wiz Scanning Support\n\nCNCF - Copacetic: Wiz Scanning Support (2025 Term 2)\n\n- Description: Copacetic currently doesn't support vulnerability scan reports by Wiz scanning. This mentorship project will extend Copa's support to cover this new scanning schema using a pre-existing template. \n- Expected Outcome: The mentee will produce the following\n 1. Design doc for Wiz Scanning\n 2. Wiz Plugin Integration\n 3. End to End integration tests\n- Recommended Skills:\n - Golang\n - Docker\n - Basic Git knowledge\n- Mentor(s):\n - Ashna Mehrotra (ashnamehrotra, ashnamehrotra@gmail.com)\n - Leonard Wang (leodewang, leonardwang2000@gmail.com)\n - Robbie Cronin (robert-cronin, robbiecronin@microsoft.com)\n- Upstream Issue: https://github.com/project-copacetic/copacetic/issues/867\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a4839420-3881-46cd-849a-f57784158f49\n\n\n### OpenCost\n\n#### Enterprise Ready OpenCost: Integration Testing\n\nCNCF - OpenCost: Enterprise Ready OpenCost: Integration Testing (2025 Term 2)\n\n- Description:\nWe need enhanced integration tests to prepare OpenCost for graduation and enterprise readiness. This proposed project will deliver a comprehensive suite of integration tests designed to facilitate development and contribution by third parties, while protecting the stability of OpenCost for our tens of thousands of users. These tests will validate both the quality of the data collected by OpenCost, and the correct operation of the APIs. We have recently implemented a pipeline that builds real stacks for these tests to hit - we now need to fill that framework up with great tests. See the testing strategy document @ https://github.com/opencost/opencost/blob/develop/docs/testing/AUTOMATED_TESTING.md for the current state of testing, and the infrastructure that we have put into place to support this mentorship effort. \n\n- Expected Outcome\n - A comprehensive integration test suite as defined in the linked ticket. \n - All tests run and pass automatically in pre-existing per-push integration test pipeline. \n - Approach for each integration test is documented \n - Endpoint coverage % and parameter coverage % is calculated \n - Any unfinished or follow on work is documented via issues on OpenCost\n\n- Recommended Skills\n - Test Development\n - REST API\n - Golang\n - GitHub Actions\n - Public Cloud Providers\n\n- Mentor\n - Alex Meijer (@ameijer , alexander.meijer@ibm.com)\n - Cliff Colvin (@cliffcolvin , clifford.colvin@ibm.com)\n - Matt Bolt (@mbolt35 , matthew.bolt@ibm.com)\n\n- Upstream Issue: [https://github.com/opencost/opencost/issues/3141](https://github.com/opencost/opencost/issues/3141)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/79cfd37e-3259-49ff-82d2-58970fbbef6f\n\n\n### Cartography\n\n#### Fill in missing AWS resource types for CloudGoat scenarios\n\nCNCF - Cartography: Fill in missing AWS resource types for CloudGoat scenarios (2025 Term 2)\n\n- Description:\n Cartography currently does not ingest many of the AWS resource types used in popular CloudGoat attack/detection scenarios. This mentorship project will extend Cartography’s AWS plugin and schema to cover these missing resources, enabling security practitioners to visualize and query full CloudGoat labs end‑to‑end. The mentee will:\n 1. Audit the AWS resource types used across selected CloudGoat scenarios.\n 2. Update Cartography’s schema to include each resource, with appropriate labels and key properties.\n 3. Implement ingestion functions in the AWS plugin, including relationship discovery (e.g., linking log groups to CloudWatch alarms).\n 4. Add Cypher sample queries and Python examples to the docs demonstrating how to explore one's infrastructure.\n\n- Expected Outcome:\n - Support for the full list of AWS resources used in CloudGoat (e.g. SSM parameters, CodeBuild projects, CloudWatch metrics/alarms, SNS topics/subscriptions, ECS/EFS resources, Glue jobs, API Gateway, Cognito, Secrets Manager, etc.).\n - Full list in the linked issue\n - Automated test coverage for each new resource type.\n - Updated documentation and example notebooks showing end‑to‑end CloudGoat use cases with Cartography.\n\n- Recommended Skills:\n - Python \n - AWS SDK (boto3) \n - Graph databases / Neo4j (Cypher) \n - Familiarity with Cartography’s module architecture \n - Basic security knowledge \n\n- Mentor(s):\n - Kunaal Sikka (@kunaals, kunaal@subimage.io)\n - Alex Chantavy (@achantavy, alex@subimage.io)\n\n- Upstream Issue: https://github.com/cartography-cncf/cartography/issues/1552\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/de67557d-4c27-4ca6-9c93-015636d28682\n\n\n### CloudNativePG\n\n#### Implementing “Declarative Management of PostgreSQL Foreign Data Wrappers” in CloudNativePG\n\nCNCF - CloudNativePG: Declarative Management of PostgreSQL FDWs (2025 Term 2)\n\n- Description: This project aims to extend the CloudNativePG operator to\n support declarative configuration of foreign data wrappers through its\n Database custom resource. PostgreSQL supports the SQL/MED (Management of\n External Data) specification, enabling access to external data sources through\n standard SQL queries. These sources—known as foreign data—are accessed via\n foreign data wrappers (FDWs), which are libraries that handle the\n connection and data exchange with the external systems. A variety of FDWs are\n available for PostgreSQL. Of particular interest for this project is the\n `postgres_fdw` extension, which facilitates access to other PostgreSQL\n instances.\n\n- Expected Outcome:\n - A detailed design discussion documented in the upstream issue in\n CloudNativePG GitHub repository, involving mentors, maintainers, and the\n community.\n - A fully working pull request implementing support for declarative foreign\n data wrappers, complete with:\n - Reconciliation logic for the Database resource controller\n - Documentation\n - Automated tests integrated into the CI/CD pipeline\n\n- Recommended Skills:\n - Go programming (operator development)\n - Kubernetes and CRDs (Custom Resource Definitions)\n - Git and GitHub workflows\n - CloudNativePG\n - Familiarity with PostgreSQL internals and SQL syntax\n\n- Mentor(s):\n - Gabriele Bartolini (@gbartolini, gabriele.bartolini@enterprisedb.com)\n - Leonardo Cecchi (@leonardoce, leonardo.cecchi@enterprisedb.com)\n - Marco Nenciarini (@mnencia, marco.nenciarini@enterprisedb.com)\n - Armando Ruocco (@armru, armando.ruocco@enterprisedb.com)\n\n- Upstream Issue: https://github.com/cloudnative-pg/cloudnative-pg/issues/4683\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/53fa853e-b5fa-4d68-be71-f005c75aea89\n\n\n### Inspektor Gadget \n\n#### [PM Mentorship] Traceloop GTM Strategy and Execution\n\nCNCF - Inspektor Gadget: Traceloop GTM Strategy and Execution (2025 Term 2)\n\n- Description: \n This is a Project Management mentorship (product management for open source) for the project Inspektor Gadget (IG). [Inspektor Gadget](inspektor-gadget.io) is a powerful observability tool that enables security, monitoring and troubleshooting on Linux and Kubernetes. The framework uses a concept called “gadgets” which uses a technology called eBPF to enable us to drive valuable insights from the Linux kernel. Today, we have a very powerful gadget called [Traceloop](https://inspektor-gadget.io/docs/latest/gadgets/traceloop). However, as you can see the documentation around it is quite minimal and we need a strategy around how to bring this gadget to market in a big way. With Traceloop users can debug crashing applications as demonstrated [here](https://www.youtube.com/watch?v=IoiDvzIZ3ok&list=PLnfCaIV4aZe9oQ7REBuP0PWwp-NEbFlGR&index=30). Our goal is to make community members aware of traceloop and therefore Inspektor Gadget to a) decrease time to resolution for developers debugging their applications b) drive adoption of the project . \n\n- Expected Outcome:\n Increased awareness of the gadget Traceloop and Inspektor Gadget, and also a repeatable framework is established that can be easily scaled to other gadgets\n\n- Recommended Skills:\n - User Research\n - Translating User Needs to Technical Requirements\n - Marketing Analytics\n - Go-to-market strategy\n - Roadmapping and Prioritization\n - Marketing Content Creation\n - Documentation and Communication\n - Community Engagement\n - You do NOT need to have all of these skills to be successful in this role. By the end of this mentorship you will have exposure to these skills and the opportunity to build them out. \n\n- Mentor(s):\n - Maya Singh (@mayasingh17, mayasingh@microsoft.com)\n - Slava Falico (@vfalico, vfalico@gmail.com)\n \n- Upstream Issue: [RFE] Inspektor Gadget Traceloop Gadget Go to Market Strategy and Execution (CNCF Mentorship Program) [inspektor-gadget/inspektor-gadget Issue #4417](https://github.com/inspektor-gadget/inspektor-gadget/issues/4417)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a5f01d86-252f-48c2-90b7-c616dc5072d8\n\n\n### Kubernetes\n\n#### Graduate the kubeadm feature gate WaitForAllControlPlaneComponents to GA\n\nCNCF - Kubernetes: Graduate kubeadm WaitForAllControlPlaneComponents to GA (2025 Term 2)\n\n- Description: \nThe feature gate WaitForAllControlPlaneComponents is used to\nenhance the health checks performed by kubeadm on control plane node creation,\nto not only check the availability of the kube-apisever, but also check\nthe kube-controller-manager and kube-scheduler. In kubeadm 1.33, the feature gate\nwas promoted to Beta. As part of this LFX project it can be promoted to GA,\nby finalizing the remaining work, such as, code changes, documentation updates\nand e2e test updates.\n- Expected Outcome: The feature gate is graduated to GA\n- Recommended Skills: golang, Kubernetes, kubeadm\n- Mentor(s):\n - Shida Qiu (@SataQiu)\n - Paco Xu (@pacoxu)\n- Type: maintainer mentorship (only for maintainers to work on as part of a one-off LFX Project)\n- Upstream Issue (URL): https://github.com/kubernetes/kubeadm/issues/2907\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c546b376-f57d-4181-b2fe-4acf6586e0cb\n\n\n### KubeStellar\n\n#### UX/UI Mentorship: Design System Foundations for KubeStellar\n\nCNCF - KubeStellar: Design System Foundations (2025 Term 2)\n\n- Description:\nEstablish a lightweight, scalable design system that brings visual consistency, reusable components, and clear UX guidance across the full scope of KubeStellar. The system will support multiple user-facing surfaces, including websites, software interfaces, and CLI-based tools. This mentorship will serve as the foundational design phase, setting the stage for a future front-end development and implementation effort planned for later this year. Special emphasis will be placed on the documentation site and contributor-facing tooling to ensure immediate impact and long-term scalability.\n\n- Expected Outcome:\nThe mentorship will deliver a scalable yet lightweight design system tailored to KubeStellar's needs. It will include a component inventory, reusable UI patterns, a full CSS specification, and visual guidelines to ensure consistency and usability across the project's five active areas. While this phase focuses on foundational design work, it will directly support a future implementation phase—enabling contributors to efficiently apply the system to KubeStellar's interfaces, including UI, Docs, and CLI-based tooling. Special emphasis will be placed on ensuring the documentation site benefits immediately from this structure.\n\n- Deliverables:\n-UI Audit Summary: A documented audit of existing UI elements across KubeStellar interfaces, identifying inconsistencies and opportunities for improvement.\n- Design Foundations Guide: A foundational set of visual guidelines including typography, color palette, spacing, and layout grids.\n- Reusable Component Designs: Figma mockups of commonly used UI components (e.g., buttons, cards, inputs, navigation) with states and interaction guidance.\n- Component Usage Documentation: A concise guide explaining how and when to use each component, with practical examples for developers and contributors.\n- Figma Starter Library: A structured, shareable Figma file including design tokens, reusable components, and layout references.\n- Full CSS Specification: A developer-ready CSS reference that maps all design tokens, spacing scales, typography, color values, and component styles—designed to simplify implementation and align with frontend frameworks if needed.\n- Homepage Hero Mock: A visual concept and animation-ready mockup for the KubeStellar homepage hero section.\n- Docs Master Page Mock: A fully designed layout for a documentation master page, featuring structural layout, navigation, and UI-integrated component examples.\n- Stretch Goal: If time allows, conduct an information architecture analysis of the current documentation site and provide recommendations. This may include proposing the separation of non-documentation content into standalone sites to improve clarity and user experience.\n\n- Recommended Skills:\n- UX/UI Design\n- Figma Proficiency\n- Design Systems (e.g., Material UI, Carbon)\n- Responsive Design\n- Visual Consistency\n- Open Source Mindset\n- Developer Collaboration (e.g., GitHub, handoff tools)\n- React\n- Documentation Skills\n\n- Mentors:\n- Andrea Velázquez (@andreuxxxx, andrea@buoyant.io)\n- Kevin Roche (@KPRoche, kproche@us.ibm.com)\n\n- Upstream Issue: https://github.com/kubestellar/kubestellar/issues/2912\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1cd69035-2bab-47f1-9774-952e9ec0d43e\n\n#### Building a Plugin System for KubeStellar\n\nCNCF - KubeStellar: Building a Plugin System (2025 Term 2)\n\n- Description: \nThis project aims to develop a plugin system for KubeStellar that will allow users to discover, install, and manage plugins that extend KubeStellar's functionality. The plugin system will provide a centralized hub for community-contributed plugins, enhancing KubeStellar's extensibility and user experience. The implementation will include a backend API written in Go and a frontend interface built with React.\n\n- Expected Outcome\n - A fully functional plugin system integrated into KubeStellar's UI\n - Backend API for plugin management (upload, discovery, installation, updates)\n - Frontend components for browsing, searching, and installing plugins\n - Plugin versioning and compatibility checking\n - User ratings and reviews for plugins\n - Documentation for plugin developers and users\n\n- Recommended Skills\n - Go\n - React.ts\n - REST API\n - Kubernetes\n - KubeStellar\n - Docker\n - containerization\n - Git\n - GitHub workflow\n\n- Mentor\n - Rishi Mondal (@MAVRICK-1 , mavrickrishi@gmail.com)\n - Andy Anderson (@clubanderson , andy@clubanderson.com)\n - Rahul Vishwakarma (@manzil-infinity180 , rahulvs2809@gmail.com)\n- Upstream Issue: [https://github.com/kubestellar/ui/issues/606](https://github.com/kubestellar/ui/issues/606)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cf08311b-a7cf-4309-9989-5f85ba2b05b3\n\n#### Implementing a Model Context Protocol for KubeStellar MCP Server\n\nCNCF - KubeStellar: Model Context Protocol for MCP Server (2025 Term 2)\n\n- Description: \nThis project aims to develop a Model Context Protocol for KubeStellar's Management Control Plane (MCP) server. The protocol will establish a standardized communication framework between KubeStellar's internal components and the AI models used for command interpretation. By defining clear context boundaries, semantic structures, and state management patterns, the protocol will enable the MCP server to maintain consistent understanding of the multi-cluster environment while processing natural language management commands across KubeStellar deployments.\n\n- Expected Outcome\n - A fully specified Model Context Protocol defining the interaction between KubeStellar and AI models\n - Implementation of protocol handlers in TypeScript or Python for the MCP server\n - Context management system that maintains KubeStellar state information for accurate command interpretation\n - Serialization and deserialization mechanisms for efficiently passing cluster state to models\n - Protocol extension mechanisms for supporting different AI providers\n - Performance optimizations for minimizing latency in command processing\n - Comprehensive test suite validating protocol reliability under various operational conditions\n\n- Recommended Skills\n - KubeStellar\n - Model Context Protocol\n - protocol design and implementation\n - TypeScript\n - Python\n - AI model\n - GenAi\n - serialization formats\n - efficient data structures\n - distributed systems state management\n\n- Mentor\n - Rishi Mondal (@MAVRICK-1 , mavrickrishi@gmail.com)\n - Andy Anderson (@clubanderson , andy@clubanderson.com)\n\n- Upstream Issue: [https://github.com/kubestellar/ui/issues/607](https://github.com/kubestellar/ui/issues/607)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/161ae153-3d60-499e-9791-863635d68864\n\n#### Developing a Marketplace UI and Optimize the Current UI\n\nCNCF - KubeStellar: Marketplace UI and UI Optimization (2025 Term 2)\n\n- Description: \nThis project focuses on creating a comprehensive plugin marketplace UI for KubeStellar that enables users to easily discover, install, update, and delete plugins directly from the interface. The marketplace will provide a seamless user experience with intuitive navigation, detailed plugin information, and streamlined management workflows. Additionally, the project will implement advanced resource filtering capabilities throughout the KubeStellar UI, allowing users to efficiently search, sort, and filter various resources based on multiple criteria.\n\n- Expected Outcome:\n - A fully functional plugin marketplace UI integrated into KubeStellar\n - Installation, deletion, and update workflows for plugins with visual feedback\n - Plugin categorization, ratings, and search functionality\n - Dependency management and compatibility checking for plugins\n - Advanced resource filtering system across the UI with support for multiple filter criteria\n - Filter persistence across user sessions\n - Responsive design that works across different device sizes\n - Performance optimizations to ensure smooth interaction even with many plugins/resources\n - Installation and Setup Guide integrated directly into KubeStellar UI with cluster readiness checker, guided installation wizard, and real-time error feedback and resolution flows\n\n- Recommended Skills:\n - React\n - TypeScript\n - REST API integration\n - Golang\n - Kubernetes\n - KubeStellar\n - State management\n - GitHub workflow\n\n- Mentor\n - Rishi Mondal (@MAVRICK-1 , mavrickrishi@gmail.com)\n - Andy Anderson (@clubanderson , andy@clubanderson.com)\n - Onkar Shelke (@onkar717, onkarwork2234@gmail.com)\n\n- Upstream Issue: [https://github.com/kubestellar/ui/issues/615](https://github.com/kubestellar/ui/issues/615)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a23f93b7-e384-4515-a165-c01e4ecd00ad\n\n#### Extending KubeFlex with a new type of Control Plane\n\nCNCF - KubeStellar: Extending KubeFlex with a new Control Plane (2025 Term 2)\n\n- Description: \nKubeFlex is a flexible and scalable platform for running lightweight Kubernetes control plane APIs to support specific use-cases in cloud and edge computing environments. It supports various kinds of control planes, such as: vcluster, ocm, host, etc. This project aims to extend KubeFlex to support a new type of control plane that provides the full components of a control plane in a typical Kubernetes cluster (e.g., API Server, Scheduler, Controller-Manager, etc.). This new control plane will be based on K3s and it will allow KubeFlex to support new use-cases such as multi-tenant scenarios.\n- Expected Outcome: A new type of KubeFlex provided control plane based on k3s\n- Recommended Skills: Golang, Kubernetes, K3s\n- Mentor(s):\n - Paolo Dettori: (@pdettori, dettori@us.ibm.com)\n - Braulio Dumba: (@dumb0002, Braulio.Dumba@ibm.com)\n- Upstream Issue (URL): [https://github.com/kubestellar/kubeflex/issues/347](https://github.com/kubestellar/kubeflex/issues/347)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d5499737-549b-498a-922a-695ef3955725\n\n#### Enhancing KubeStellar core Helm chart by reducing its reliance on initContainers\n\nCNCF - KubeStellar: Reduce Helm chart initContainers reliance (2025 Term 2)\n\n- Description: \nThis project aims to investigate and implement ideas for improving KubeStellar Core Helm chart reliance by contributing improvements to Helm project and reducing its reliance on initContainers for waiting/gathering/processing Kubernetes resources that are used by other containers (for example, KubeFlex Control Planes and their kubeconfigs).\n- Introduce an annotation that would make Helm wait for user-specified resources\n- Introduce priority/coordination of Helm resource creation\n- Introduce an alternative path for dependence chart override values\n- Introduce a mechanism for a chart to require a specified Helm min version or range\n- Introduce an alternative to kubectl initContainers\n\n- Expected Outcome\n - A comprehensive investigation of potential alternative methods and approaches\n - Contributions to Helm project to introduce new features that would allow to improve the quality of KubeStellar Core chart\n - A solution implementation that reduces the reliance on kubectl initContainers\n\n- Recommended Skills\n - Helm\n - Go\n - REST API\n - Kubernetes\n - KubeStellar\n - Docker\n - containerization\n - Git\n - GitHub workflow\n\n- Mentor\n - Franco Stellari (@francostellari , fstellari@gmail.com)\n - Andy Anderson (@clubanderson , andy@clubanderson.com)\n\n- Upstream Issues:\n - [https://github.com/kubestellar/kubestellar/issues/2890](https://github.com/kubestellar/kubestellar/issues/2890)\n - [https://github.com/helm/helm/issues/30669](https://github.com/helm/helm/issues/30669)\n - [https://github.com/helm/helm/issues/30670](https://github.com/helm/helm/issues/30670)\n - [https://github.com/helm/helm/issues/30671](https://github.com/helm/helm/issues/30671)\n - [https://github.com/helm/helm/issues/30672](https://github.com/helm/helm/issues/30672)\n\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a56d987c-f754-4e2f-b159-2ea578ca5e56\n\n### Meshery\n\n#### Model relationships for Azure services\n\nCNCF - Meshery: Model relationships for Azure services (2025 Term 2)\n\nMeshery Models are declarative representations of infrastructure and applications. Within these models, Relationships define how different Components (e.g., Kubernetes resources, Cloud services) interact and depend on each other. These relationships are crucial for visualizing, understanding, and managing complex cloud native systems.\n\nThis internship focuses on significantly expanding the breadth and depth of Meshery Relationships across a wide array of technologies supported by Meshery. As Meshery continues to integrate with more cloud-native technologies (Kubernetes, public clouds, and all CNCF projects), there's a growing need to accurately model the intricate relationships between their components - vital for providing users with comprehensive insights and control over their deployments.\n\n- Recommended Skills: DevOps, systems administration, solutions architecture. Experience with Kubernetes, Azure and its services.\n- Responsibilities:\n - Research and Analyze Technologies: Dive deep into various cloud-native technologies (e.g., different compute services, databases, messaging systems, network services, etc.) to understand their components and how they interconnect.\n - Develop Relationship Definitions: Create and contribute relationship definitions, typically in JSON or YAML format, to the Meshery models. \n - Model Inter-Technology Interactions: Focus particularly on defining relationships between components from different technologies (e.g., how a Kubernetes deployment relates to an AWS RDS instance, or how a Linkerd service interacts with a Prometheus monitoring component).\n - Document New Relationships: Clearly document the newly defined relationships, their purpose, and how they are represented within Meshery designs, contributing to the official Meshery documentation.\n- Expected Outcome:\n - A multitude of new relationships defined both intra and inter Azure services.\n - Policy Contribution: For advanced interns, there may be opportunities to contribute to the Rego policies that evaluate and enforce these relationships.\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Sangram Rath (@sangramrath, sangram.rath@gmail.com, Mia Grenell (@miacycle, mia.grenell2337@gmail.com))\n- Issue: https://github.com/meshery/meshery/issues/14793\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8a048110-059d-4928-bd94-00fd5f5e500d\n\n#### Model relationships for AWS services\n\nCNCF - Meshery: Model relationships for AWS services (2025 Term 2)\n\n- Description:\nMeshery Models are declarative representations of infrastructure and applications. Within these models, Relationships define how different Components (e.g., Kubernetes resources, Cloud services) interact and depend on each other. These relationships are crucial for visualizing, understanding, and managing complex cloud native systems.\n\nThis internship focuses on significantly expanding the breadth and depth of Meshery Relationships across a wide array of technologies supported by Meshery. As Meshery continues to integrate with more cloud-native technologies (Kubernetes, public clouds, and all CNCF projects), there's a growing need to accurately model the intricate relationships between their components - vital for providing users with comprehensive insights and control over their deployments.\n\n- Recommended Skills: DevOps, systems administration, solutions architecture. Experience with Kubernetes, AWS and its services.\n- Responsibilities:\n - Research and Analyze Technologies: Dive deep into various cloud-native technologies (e.g., different compute services, databases, messaging systems, network services, etc.) to understand their components and how they interconnect.\n - Develop Relationship Definitions: Create and contribute relationship definitions, typically in JSON or YAML format, to the Meshery models. \n - Model Inter-Technology Interactions: Focus particularly on defining relationships between components from different technologies (e.g., how a Kubernetes deployment relates to an AWS RDS instance, or how a Linkerd service interacts with a Prometheus monitoring component).\n - Document New Relationships: Clearly document the newly defined relationships, their purpose, and how they are represented within Meshery designs, contributing to the official Meshery documentation.\n- Expected Outcome:\n - A multitude of new relationships defined both intra and inter AWS services.\n - Policy Contribution: For advanced interns, there may be opportunities to contribute to the Rego policies that evaluate and enforce these relationships.\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Sangram Rath (@sangramrath, sangram.rath@gmail.com, Mia Grenell (@miacycle, mia.grenell2337@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/14794\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d548f403-0d7f-4ca5-88f1-393ae592a05a\n\n#### Meshery Model Support for kro ResourceGraphDefinitions (RGDs)\n\nCNCF - Meshery: Model support for kro ResourceGraphDefinitions (2025 Term 2)\n\n- Description: Enhance Meshery's existing orchestration capabilities to include support for kro ResourceGraphDefinitions (RGDs) as first-class Meshery Models. This involves enabling Meshery to manage and orchestrate RGDs, similar to how it handles other Kubernetes resources. The project will also include generating support for ResourceGraphDefinition in Meshery's Model generator.\n- Expected Outcome:\n - Meshery will be able to orchestrate and manage kro RGDs. This includes the ability to deploy, configure, and manage the lifecycle of RGDs through Meshery. The Meshery Model generator will be updated to automatically generate models for kro RGDs, simplifying their integration and management within Meshery. This will be an officially supported feature of Meshery.\n- Recommended Skills: Golang, well-written and well-spoken English, Kubernetes, DevOps\n- Mentors: Lee Calcote (@leecalcote, leecalcote@gmail.com), Aabid Sofi (@aabidsofi19, mailtoaabid01@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/13520\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b993ee7d-6b52-47e8-a651-e1c6c91e5d2b\n\n#### Workflow Engine in Meshery\n\nCNCF - Meshery: Workflow engine integration (2025 Term 2)\n\n- Description: Integrate a new architectural component into Meshery: a workflow engine, using Temporal. This project involves shifting Meshery off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.\n- Recommended Skills: Golang, Temporal, ReactJS\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Rian Cteulp (@ritzorama, rian.cteulp@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/14795\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6244b48c-1fc6-4b1c-b965-7df7e117b06d\n\n#### Solutions Architecture of Popular Cloud Native Deployments\n\nCNCF - Meshery: Solutions architecture for cloud-native deployments (2025 Term 2)\n\n- Description: Learning paths with hands-on labs are a crucial resource for DevOps engineers and cloud-native practitioners. The Meshery Playground provides a live cluster environment, making it an ideal platform for learning every kind of cloud and cloud native technology. Meshery Docs is in need of comprehensive tutorials and scenarios covering common infrastructure management use cases. Mission is to create and publish a series of hands-on tutorials using Meshery Playground. Each tutorial will include step-by-step guides, live demonstrations, and interactive labs using the Playground allowing learners to apply their knowledge directly without the hassle of any configuration.These tutorials will be reviewed by various project maintainers and then published in guides/tutorials.\n- Expected Outcome:\n - 10+ new solution architectures (designs) published in Meshery Catalog\n - Each design is ideally adjoined with an interactive tutorial (using Meshery Playground), guiding users through infrastructure.\n - Tutorials should vary in complexity, catering to beginners and advanced learners.\n- Recommended Skills: written English, Markdown, Kubernetes, DevOps, and hands-on experience with cloud-native tools\n- Mentor(s): Sangram Rath (@sangramrath, sangram.rath@gmail.com), Lee Calcote (@leecalcote, leecalcote@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/14796\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b1fcdcd9-0066-4a9a-a879-7d5624b02727\n\n### OpenKruise\n\n#### add best practice to use openkruise workload with Karmada etc\n\nCNCF - OpenKruise: Best practice for Karmada/OCM integration (2025 Term 2)\n\n- Description: \nKarmada and OCM are popular multi-cluster orchestration system, OpenKruise advance workload had been integrated with these orchestration system by community users, this project aims to provide official guidelines for the usage of OpenKruise in Karmada and OCM.\n\n- Expected Outcome:\n - A complete document of Karmada and OCM integration with common OpenKruise workload(e.g. CloneSet, Advance StatefulSet) including supported features and current limitation\n - Possible code fix of problems found in the integration \n\n- Recommended Skills\n - Kuberntetes\n - technical document writing with markdown\n \n- Mentor(s):\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n - Sun Weixiang(@veophi, Vec.G.Sun@gmail.com)\n\n- Upstream Issue: [https://github.com/openkruise/kruise/issues/2005](https://github.com/openkruise/kruise/issues/2005)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8e20df07-bd63-48ba-8078-18567c42597f\n\n#### OpenKruiseGame controlplane HA deployment support\n\nCNCF - OpenKruise: OpenKruiseGame HA deployment support (2025 Term 2)\n\n- Description:\nThe Kruise Game Controller Manager currently stores cache information for network plugins in memory, resulting in its single-replica deployment. From a business stability architecture perspective, it is necessary to migrate the cache out of memory to enable Kruise Game to transition to a multi-replica deployment. Besides, the current webhook certificate is self-signed by the controller. When the number of copies is more than one, an unauthenticated error will occur, so this needs to be modified.\n\n- Expected Outcome:\n - support multi-replicas deployment\n - support webhook certificate signing using cert manager \n\n- Recommended Skills:\n - Go\n - Kubernetes\n\n- Mentor:\n - Qiuyang Liu (@chrisliu1995, chrisliu1995@163.com)\n - Zhongwei Liu (@ringtail, zhongwei.lzw@alibaba-inc.com)\n\n- Upstream Issue:[https://github.com/openkruise/kruise-game/issues/220](https://github.com/openkruise/kruise-game/issues/220)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/411dea84-5f3c-46d5-823f-67b7c8f3d0e9\n\n#### Support progressDeadlineSeconds for Cloneset\n\nCNCF - OpenKruise: progressDeadlineSeconds for CloneSet (2025 Term 2)\n\nThis project aims to support progressDeadlineSeconds in CloneSet so as to provide information about whether the deployment is failed. The meaning of `progressDeadlineSeconds` is quite similar to the one in native kuberentes workload(`deployment`), but it need extra support for the time counting during CloneSet is paused due to partition restriction.\n\n- Recommended Skills\n - Kubernetes\n - Golang\n - operator development\n\n- Expected Outcome\n - A fully functional progressDeadlineSeconds supporting code with necessary unit and integration tests\n - complete document of the progressDeadlineSeconds and related CloneSet new condition in the status \n\n- Mentor\n - Yuxing Yuan(@ABNER-1, abner199709@gmail.com)\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n \n- Upstream Issue:[https://github.com/openkruise/kruise/issues/2006](https://github.com/openkruise/kruise/issues/2006)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f249fa01-8c21-4898-ab02-234653cb8256\n\n#### Build simple dashboard to view and operate OpenKruise workload \n\nCNCF - OpenKruise: Simple dashboard for workloads (2025 Term 2)\n\n- Description: Currently, OpenKruise depends solely on the PaaS or CLI to listing OpenKruise workload display and operations. The lack of a general purpose Web-UI greatly hinder the adoption among developer users. This project is about to build a simple Web-UI that can list OpenKruise workload along with the native K8s workload, and support enhanced operation such as container restart or workload rollout. The Web-UI is preferably developed using UI extensions of existing PaaS e.g. Kubesphere and Rancher.\n\n- Expected Outcome:\n - simple Web-UI\n - integration of the Web-UI with existing PaaS such as [KubeSphere](https://dev-guide.kubesphere.io/extension-dev-guide)\n- Recommended Skills: \n - UX/UI(react)\n - JavaScript\n - GoLang\n - Kubesphere/Rancher development(prefered but not mandatory ) \n- Mentor(s):\n - Zhang Zhen (@furykerry, furykerry@gmail.com)\n - Zhong Tianyun (@AiRanthem, airanthem666@gmail.com)\n- Upstream Issue: https://github.com/openkruise/kruise/issues/1497\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/217a88a5-ecbc-46b8-9e90-b68993a8ae45\n\n\n### Harbor\n\n#### Harbor CLI\n\nCNCF - Harbor: Harbor CLI enhancements (2025 Term 2)\n\n- Description: Harbor is a widely adopted container registry, and its initial CLI has been developed by LFX mentees. The goal is to extend this CLI by implementing additional functionalities and workflows that are currently only available in the Web UI. The CLI should be useful for Harbor administrators and users, especially to manage workflows within CI/CD pipelines. We seek a Golang-experienced mentee to enhance the CLI independently.\n\n- Expected Outcome:\n - Extend the Harbor CLI to include essential commands not yet implemented.\n - Add new features to improve Harbor management via the CLI for Harbor Administration, enabling robust workflows in CI/CD environments.\n - Review and test all implemented commands to ensure they work as expected.\n\n- Recommended Skills: Golang, spf13/cobra\n\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n\n- Upstream Issue: https://github.com/goharbor/harbor-cli/issues/450\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0d80c83f-259b-46e7-98af-47406891649a\n\n#### Implementing Ground Control for Harbor Satellite\n\nCNCF - Harbor: Ground Control for Harbor Satellite (2025 Term 2)\n\n- Description: As edge computing grows, managing container registries at edge becomes a challenge. Ground Control (GC) is a centralized control plane that manages and coordinates distributed edge registries, known as satellites. GC handles satellite registration, state management, robot account creation and management. It is deployed near the central Harbor registry and acts as the brain of the distributed registry system.\n\n- Expected Outcome:\n - Extend build and release pipelines using Dagger.\n - Implement satellite sync for status and health reporting.\n - Improve artifact state and configuration updates through OCI-compliant state artifacts.\n - Add e2e tests for Ground Control functionality including state publication and robot account management.\n\n- Recommended Skills\n - REST API\n - Golang\n - GitHub workflow\n - Dagger\n - PostgreSQL\n - sqlc\n - [OCI Image Spec](https://github.com/opencontainers/image-spec/blob/main/spec.md)\n - [Distribution Spec](https://github.com/opencontainers/distribution-spec/blob/main/spec.md)\n \n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n\n- Upstream Issue: https://github.com/goharbor/harbor/issues/21959\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c445172e-5a5f-41f9-b4eb-89cbfe2f3434\n\n#### Harbor Satellite: Implementing a Eventing System for Satellite\n\nCNCF - Harbor: Eventing System for Harbor Satellite (2025 Term 2)\n\n- Description:\nHarbor Satellite is a lightweight, OCI-compliant registry (currently based on Zot) designed to run on edge devices, such as Raspberry Pi or ARM-based hardware. It acts as a local container registry for edge devices and workloads. The satellite autonomously fetches configuration and state, registers with Ground Control, reports its status, and optionally sends system-level events to connected edge systems.\n\n- Expected Outcome:\n - Implement an eventing mechanism to notify edge systems about critical state transitions (e.g., \"state update ready\", \"sync complete\").\n - Improve build and release pipelines.\n - Make the satellite functional on ARM-based edge devices (like Raspberry Pi).\n - Add reliable state and health reporting back to Ground Control.\n - Add e2e tests to validate artifact fetching, status reporting, and eventing.\n\n- Recommended Skills\n - Golang\n - Containers\n - Edge Computing\n - OCI Image/Distribution Spec\n - Webhooks\n - Event-Driven Architecture\n\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n\n- Upstream Issue: https://github.com/goharbor/harbor/issues/21986\n- LFX\n\n\n### PipeCD\n\n#### Support deploy application using OpenTofu with PipeCD plugin\n\nCNCF - PipeCD: OpenTofu deployment plugin (2025 Term 2)\n\n- Description: In the latest evolution of PipeCD, the plugin architecture for piped has been established (ref: [PipeCD plugin-arch blog](https://pipecd.dev/blog/2024/11/28/overview-of-the-plan-for-pluginnable-pipecd/)), paving the way for community-developed plugins. Previously, PipeCD already supported deploying applications using Terraform, with the Terraform plugin being developed by the maintainer team to ensure continued support for existing users. Meanwhile, OpenTofu has emerged within the Cloud Native landscape as a drop-in alternative to Terraform. To align with this development, we aim to extend PipeCD’s support to enable the deployment of OpenTofu applications, just as we have done for Terraform.\n \n- Expected Outcome:\n - OpenTofu plugin for PipeCD\n - Possible update plugin SDK while develop the OpenTofu plugin\n - Possible update docs how to develop PipeCD plugin\n - Blog about how to develop a PipeCD plugin on [https://pipecd.dev/blog/](https://pipecd.dev/blog/)\n \n- Recommended Skills:\n - Golang\n - Terraform / OpenTofu\n - GitOps\n - Contrinous Delivery (CD)\n\n- Mentor(s):\n - Khanh Tran (@khanhtc1202, khanhtc1202@gmail.com)\n - Shinnosuke Sawada-Dazai (@Warashi, shin@warashi.dev)\n - Yoshiki Fujikane (@ffjlabo, ffjlabo@gmail.com)\n\n- Upstream Issue: https://github.com/pipe-cd/pipecd/issues/5807\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ca6413f6-6f97-4e41-aad8-8d2bbe17251d\n\n#### Support managing SQL schema using PipeCD SQL plugin\n\nCNCF - PipeCD: SQL schema management plugin (2025 Term 2)\n\n- Description: With the latest advancements in PipeCD, the plugin architecture for piped has been successfully established (ref: [PipeCD plugin-arch blog](https://pipecd.dev/blog/2024/11/28/overview-of-the-plan-for-pluginnable-pipecd/)), opening the door for community-driven plugin development. While GitOps traditionally focuses on managing workload states, what about database states? Tools like [sqldef](https://github.com/sqldef/sqldef) can be incredibly helpful, especially when adopting a GitOps approach.\n \n- Expected Outcome:\n - SQL plugin for PipeCD\n - Possible update plugin SDK while develop the SQL plugin\n - Possible update docs how to develop PipeCD plugin\n - Blog about how to develop a PipeCD plugin on [https://pipecd.dev/blog/](https://pipecd.dev/blog/)\n\n- Recommended Skills:\n - Golang\n - SQL\n - GitOps\n - Continuos Delivery (CD)\n\n- Mentor(s):\n - Khanh Tran (@khanhtc1202, khanhtc1202@gmail.com)\n - Shinnosuke Sawada-Dazai (@Warashi, shin@warashi.dev)\n - Yoshiki Fujikane (@ffjlabo, ffjlabo@gmail.com)\n\n- Upstream Issue: https://github.com/pipe-cd/pipecd/issues/5808\n\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f56d4b7f-be23-4349-8066-f6526b863068\n\n\n### Istio\n\n#### Expand testing for Multi-Cluster in Ambient\n\nCNCF - Istio: Multi-cluster Ambient testing expansion (2025 Term 2)\n\n\ndescription: |\n Istio is a service mesh platform used by thousands of companies to secure and manage their microservices traffic, most often in a single Kubernetes cluster.\n However, the ability to operate across multiple clusters is an important feature in Istio's traditional Sidecar mode, and work to support\n it in Istio's Ambient mode is making rapid progress. To call any feature complete,\n comprehensive testing is needed. Given that multicluster Istio Ambient is a new mode of operating, we will\n need to both adapt tests for existing features to ensure they work across multiple clusters,\n as well as identify multi-cluster specific scenarios we want to codify in tests.\n\n These kinds of tests exist mode in both the main Istio repository, as well as in the istio.io\n website's repository. The docs tests are equally as important, as they prove that the\n instructions we give to users actually work.\n\nexpectedOutcome:\n - Audit existing ambient integration tests for cases that do not support multi-cluster testing patterns.\n - Refactor those tests, using Istio's testing infrastructure to cover features within a multi-cluster environment.\n - Work with Istio maintainers to identify opportunities for testing new scenarios that exist only for ambient multi-cluster.\n - As documentation is written for https://istio.io, verify that the user instructions (kubectl commands, YAML snippets, etc.) actually work end-to-end.\n - Gain hands-on experience with Istio's codebase, service mesh architectures, and Kubernetes multi-cluster patterns.\n - Help us catch regressions and bugs\n\n- Recommended Skills:\n - Go\n - Kubernetes\n - Istio\n - Basic networking knowledge\n\n\n- Mentor(s):\n - Steven Jin (@stevenjin8, sjinxuan@microsoft.com)\n - Steven Landow (@stevenctl, steven.landow@solo.io)\n\n- Upstream Issue: https://github.com/istio/istio/issues/56228\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/958b17bf-e4f2-42fc-a7f3-01d95c53ee73\n\n\n#### Update documentation CMS build pipeline\n\nCNCF - Istio: Update documentation CMS build pipeline (2025 Term 2)\n\n- Description: istio.io is a large application in and of itself: static content is available in three languages with multiple versions, and\n a large testing infrastructure acts as the end-to-end testing for the Istio project, validating that the project works as\n documented whenever an update is made to the docs or Istio itself.\n \n In this project, you will be mentored towards maintainership of the Istio documentation build pipeline, including completing\n recently started work on multi-version availability and its integration with search engines, bringing the tooling for the\n deployment pipeline up to date, and laying groundwork for large content changes as ambient mode moves towards the default.\n- Expected Outcome:\n - Clean builds and publishes, with no lingering warnings or errors\n - Updated documentation on contributing tests, such that a new user can easily contribute testable documentation\n - Published process for users to see old versions of the docs, where we no longer publish them on istio.io\n- Recommended Skills: Integration, Systems engineering, scripting, programming (Bash/go), Hugo templating\n- Mentor(s):\n - Craig Box (@craigbox, craig.box AT gee-mail)\n- Upstream Issue: https://github.com/istio/istio.io/issues/16491\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3c42c0b6-cd32-42ca-b32e-1865f42a9f21\n\n### Krkn\n\n#### Chaos scenario rollback feature\n\nCNCF - Krkn: Chaos scenario rollback feature (2025 Term 2)\n\n- Description:
\nWe intend to refactor the current Scenario Plugin API and add a new feature in the plugin abstract class to restore all the changes performed by krkn in the cluster in case run method encounters some kind of exception before ending the execution and or if the run failed for external infrastructure failures.\n- Expected Outcome:
\nThe cluster status should be rolled back to the original condition before the scenario execution.\n- Recommended Skills:
\n - python\n - kubernetes\n - container runtime environments\n - common cloud platforms\n- Mentor(s):\n - Tullio Sebastiani (@tsebastiani, tsebasti@redhat.com) \n - Naga Ravi Chaitanya Elluri (@chaitanyaenr, nelluri@redhat.com)\n - Paige Patton (@paigerube14, ppatton@redhat.com)\n- Upstream Issue: https://github.com/krkn-chaos/krkn/issues/804\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/92e42a9c-fc0a-46bf-8ca7-69ad673dcce0\n\n\n### Kyverno\n\n#### Optimize Kyverno CLI In-cluster Resource Loader\n\nCNCF - Kyverno: Optimize Kyverno CLI In-cluster Resource Loader (2025 Term 2)\n\n- Description: Kyverno provides robust support for applying multiple policy types to Kubernetes cluster resources via CLI. However, the resource loading mechanisms vary significantly across different policy types, resulting in inconsistent behavior and limited scalability when handling large resource sets.\n\n- Expected Outcome: Develop a unified, reusable in-cluster resource loading framework that standardizes resource retrieval across all policy types, and optimize performance when loading large numbers of resources.\n\n- Recommended Skills:\n - Golang\n - Kubernetes\n - Cobra\n\n- Mentor(s): \n - Mariam Fahmy (@MariamFahmy98, mariam.fahmy@nirmata.com)\n - Shuting Zhao (@realshuting, shuting@nirmata.com)\n - Yugandhar (@yrsuthari, ysuthari@gmail.com)\n\n- Upstream Issue (URL): \n - https://github.com/kyverno/kyverno/issues/12973\n - https://github.com/kyverno/kyverno/issues/12967\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/98a5686a-3f18-4a79-ac9d-9ffa228a6e26\n\n#### Improve Test Coverage and Docs for New Policy Types\n\nCNCF - Kyverno: Improve Test Coverage and Docs for New Policy Types (2025 Term 2)\n\n- Description: Kyverno 1.14+ introduces several new policy types including ValidatingPolicy, ImageValidatingPolicy, and others that extend the platform's capabilities. To ensure reliability and stability of these new features, we need to systematically improve test coverage through comprehensive Chainsaw tests and targeted unit tests.\n\n- Expected Outcome: \n - Good test coverage for new policy types\n - Documentation for new policy types\n\n- Recommended Skills:\n - Golang\n - Chainsaw\n - Kubernetes\n - Testing\n\n- Mentor(s):\n - Charles-Edouard Brétéché (@eddycharly, charled.breteche@gmail.com)\n - Frank Jogeleit (@fjogeleit, frank.jogeleit@nirmata.com)\n\n- Upstream Issue (URL): \n - https://github.com/kyverno/kyverno/issues/13011\n\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ef446774-4fe7-4027-8c9b-e1e125c643ae\n\n\n### WasmEdge\n\n#### Port WasmEdge and the WASI-NN ggml backend to the s390x platform\n\nCNCF - WasmEdge: Port WasmEdge and WASI-NN ggml backend to s390x (2025 Term 2)\n\n- Description: WasmEdge provides cross-platform support for amd64 and arm64 for executing AI/LLM applications. We would like to support as many new hardware platforms as possible, so developers and users will no longer need to worry about the actual hardware. All they need to do is develop their AI agent or LLM applications once and deploy their services anywhere. For more information, please check the upstream issue.\n- Expected Outcome:\n - Make the WasmEdge toolchain support the s390x platform, including the interpreter and the AOT mode.\n - Ensure the WASI-NN ggml plugin can execute without any issues on the s390x platform.\n - Implement test suites to verify the above behaviors.\n - Write a document discussing the compilation, installation, execution, and verification of the work.\n- Recommended Skills:\n - C++\n - s390x\n - LLVM\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io) - Primary\n - dm4 (@dm4, dm4@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4010\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d82c102b-4f82-4ca8-9627-25ef9d745321\n\n#### Use Runwasi with WasmEdge runtime to test multiple WASM apps as cloud services\n\nCNCF - WasmEdge: Use Runwasi with WasmEdge runtime to test multiple WASM apps (2025 Term 2)\n\n- Description: With WasmEdge serving as one of Runwasi’s standard runtimes, and as our C++-implemented library continues to evolve, we also need a verification process integrated into Runwasi to streamline and validate the stability of both container and cloud environments.\n- Expected Outcome:\n - A concise GitHub workflow demonstrates Runwasi end-to-end testing on Kubernetes.\n - Need to design an interactive application scenario that supports multiple nodes\n - Try to incorporate the use of the WasmEdge plugin into this scenario\n - Document\n- Recommended Skills:\n - Rust\n - C++\n - GDB\n - git / github workflow\n - shell script\n- Mentor(s):\n - Vincent (@CaptainVincent, vincent@secondstate.io) - Primary\n - yi (@0yi0 yi@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4011\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e54744c7-0435-42bb-b9aa-60e8df1c9081\n\n\n#### Support bitnet.cpp as a new WASI-NN plugin\n\nCNCF - WasmEdge: Support bitnet.cpp as a new WASI-NN plugin (2025 Term 2)\n\n- Description: WasmEdge provides several AI frameworks as WASI-NN plugins to enable the power of AI/LLM applications for developers and users. We are always eager to add new backends to improve coverage of all models and hardware. BitNet.cpp, released by Microsoft, offers the ability to run 1-bit LLMs quickly without a GPU. We would like to support this framework so that people with limited resources, such as CPU-only hardware, can enjoy the amazing world brought by LLMs.\n- Expected Outcome:\n 1. A new WASI-NN plugin supports [BitNet](https://github.com/microsoft/BitNet).\n 2. Use the pure C++ interface from BitNet without any Python dependencies.\n 3. The plugin must run the model listed in the BitNet repository, e.g., [BitNet b1.58 2B4T - Scaling Native 1-bit LLM](https://huggingface.co/microsoft/bitnet-b1.58-2B-4T).\n 4. A tutorial and example for demonstration.\n 5. A CI workflow for building, testing, and releasing the built assets.\n- Recommended skills:\n - C++\n - [WASI-NN](https://github.com/WebAssembly/wasi-nn)\n - GitHub workflows\n - LLMs\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n - dm4 (@dm4, dm4@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4110\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d7ee97d4-ee89-4cce-a128-34f87fe2fb5a\n\n#### Create an MCP-based AI agent to help LF certificate prep\n\nCNCF - WasmEdge: Create an MCP-based AI agent to help LF certificate prep (2025 Term 2)\n\n- Description: You will create an AI agent based on open-source Large Language Models (LLMs) running on the CNCF WasmEdge runtime and an MCP server. The application will tie together key components in a modern AI agent stack to create a useful application. The AI agent will ask, answer, and explain practice questions for a specific tech certification program. It enables students to study for the certificate tests more effectively.\n- Expected Outcome:\n - Deliverable 1: create a MCP server with 2 functions\n - `get_random_question()`: The function selects a random question from a list. It returns both the question and the answer. This function is called by the LLM when it detects that the user asked for a new practice question.\n - `get_question_and_answer()`: The function searches an input text from the database for an corresponding question and answer.\n - Deliverable 2: create a practice question / answer database on a subject that you are most familiar with. The MCP functions will\n - Deliverable 3: Create an agent app based on the LlamaEdge framework with a\n - Wokflow 1\n - The user asks a question. The LLM calls MCP function `get_question_and_answer()`\n - The agent adds the answer to the context\n - The LLM converse with the user with knowledge about the question and its answer\n - Workflow 2\n - The user asks for a practice question. The LLM calls MCP function `get_random_question()` to get the question and answer.\n - Both the question and answer are added to the context.\n - The LLM responds to the user with the question ONLY.\n - It carries on the conversation around that question.\n- Recommended skills:\n - AI agent concepts\n - LLM and [tool calls](https://llamaedge.com/docs/user-guide/llm/tool-call)\n - [Running open-source LLMs locally](https://llamaedge.com/docs/user-guide/llm/full-openai)\n - [Running MCP servers](https://github.com/decentralized-mcp/servers/tree/main/example)\n - Rust\n - Python\n- Mentor(s):\n - Michael Yuan (@juntao michael@secondstate.io)\n - Vivian Hu (@alabulei1 vivian@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4109\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5070cba4-8c1e-4392-8cf8-cd9bebb5277e\n\n\n### OpenYurt\n\n#### OpenYurt Dashboard Enhancements\n\nCNCF - OpenYurt: OpenYurt Dashboard Enhancements (2025 Term 2)\n\ndescription: |\n OpenYurt is an open-source edge cloud-native platform designed to streamline application management and resource orchestration in edge computing scenarios.\n This project aims to enhance the yurt-dashboard (the core management interface of OpenYurt) by implementing internationalization support, \n integrating edge AI capabilities, and upgrading core API versions to improve global accessibility, technical innovation, and system stability.\n The project will leverage the React frontend framework, Golang backend services, and Kubernetes ecosystem toolchain to provide developers with a more efficient edge cloud-native experience.\n\nexpectedOutcome:\n - i18n Implementation: Extract existing Chinese text and complete English translations using LinguiJS framework\n Implement frontend language-switching functionality with dynamic user selection\n - Edge AI Integration: Containerize and develop deployment templates for at least 3 open-source edge AI applications in the dashboard\n - API Modernization: Align with OpenYurt' latest API standards to ensure platform compatibility and security.\n\n- Recommended Skills:\n - Proficiency in React/TypeScript and LinguiJS internationalization framework\n - Strong Golang backend development skills with Kubernetes Operator pattern knowledge\n - Deep understanding of Kubernetes API mechanisms and CRD version migration experience\n - Prior experience in edge computing or AI application deployment (e.g., KubeEdge, K3s)\n - Excellent technical writing skills in both English and Chinese\n\n- Mentor(s):\n - Lu Chen (@luc99hen, luc99.en@gmail.com)\n - Bingchang Tang (@zyjhtangtang, bingchang07@gmail.com)\n\n- Upstream Issue:\n - i18n Support: https://github.com/openyurtio/yurt-dashboard/issues/50\n - Edge AI Integration: https://github.com/openyurtio/yurt-dashboard/issues/44\n - API Upgrade: https://github.com/openyurtio/yurt-dashboard/issues/43\n\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0d59f3ef-8de1-4264-9a0e-96afbe3558af\n\n\n### Volcano\n\n#### Enhance JobFlow Functionality\n\nCNCF - Volcano: Enhance JobFlow Functionality (2025 Term 2)\n\n- Description: The Volcano community introduced JobFlow to address inter-job dependencies. Through the concepts of JobTemplate and JobFlow, users can declare and orchestrate multiple Volcano jobs, leveraging control flow primitives such as sequential, parallel, conditional, branching, and looping execution. JobFlow aims to facilitate the migration of AI, BigData, and HPC workloads to the cloud-native environment. The current JobFlow functionality requires further enhancements to meet more complex real-world scenarios. Ref: https://github.com/volcano-sh/volcano/tree/master/docs/design/jobflow.\n\n- Expected Outcome:\n - Support modifying parameters of a JobTemplate when referenced in a JobFlow, for example, changing container image versions, adjusting resource limits, etc.\n - Implement a configurable retry mechanism for failed jobs within a JobFlow, for example, supporting exponential backoff retry policies, setting maximum retry attempts, etc.\n - Introduce richer control flow statements such as if, switch, and for statements, for example, conditional branching based on the status of upstream tasks, iterative execution of specific task sets, etc.\n\n- Recommended Skills: Kubernetes, GO, Volcano\n\n- Mentor(s):\n - Jiang Dong(@dongjiang1989, dongjiang2010@gmail.com)\n - Xuzheng Chang(@Monokaix, 2536818783@qq.com)\n\n- Upstream Issue: [https://github.com/volcano-sh/volcano/issues/4275](https://github.com/volcano-sh/volcano/issues/4275)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6e853798-e2a3-445f-89f4-63c2e5acc58b\n\n#### Implement Volcano Scheduler Simulator\n\nCNCF - Volcano: Implement Volcano Scheduler Simulator (2025 Term 2)\n\n- Description: For users of Kubernetes and Volcano schedulers, the scheduling process is often a black box. Understanding how scheduling decisions are made and evaluating the functionality and performance of the scheduler, especially when introducing new scheduling features, can be challenging. Setting up a full-fledged Kubernetes cluster and generating realistic workloads to observe scheduling behavior can be resource-intensive and time-consuming. Users need a lightweight and efficient way to verify the correctness and performance implications of scheduler changes without the overhead of a real cluster. The kube-scheduler community has addressed this need with `kube-scheduler-simulator`, and the Volcano community would greatly benefit from a similar tool.\n\n- Expected Outcome:\n - Implement a Volcano scheduler simulator capable of simulating the core scheduling logic of the Volcano scheduler.\n - The simulator should be able to receive simulated Kubernetes cluster states (e.g., Nodes, Pods, Queues) and Volcano configurations as input.\n - The simulator should output the simulated scheduling results, including the Node to which a Pod is scheduled, and the decision-making process information (e.g., considered Nodes, filtering and scoring results).\n - (Optional) The simulator could provide basic performance metrics output, such as simulated scheduling latency.\n - Provide clear usage documentation and examples to facilitate users in verifying functionality and performance using the simulator.\n\n- Recommended Skills: Kubernetes, GO, Volcano\n\n- Mentor(s):\n - lowang-bh(@lowang-bh, lhui_wang@163.com)\n - Xuzheng Chang(@Monokaix, 2536818783@qq.com)\n \n- Upstream Issue: [https://github.com/volcano-sh/volcano/issues/4276](https://github.com/volcano-sh/volcano/issues/4276)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/017774aa-f821-49c6-b701-fef1a0fae17b\n\n#### Enhance Volcano Dashboard UX and Functionality\n\nCNCF - Volcano: Enhance Volcano Dashboard UX and Functionality (2025 Term 2)\n\n- Description: The Volcano Dashboard serves as the frontend for displaying Volcano resources. Currently, it supports resources like Volcano Jobs, Queues, and Pods, but editing often involves raw YAML, which is not user-friendly for modifying or creating new resources. To improve user experience, this project aims to enhance the Dashboard's interactivity and user-friendliness, as well as support the display of hierarchical Queues and HyperNode resources.\n\n- Expected Outcome:\n - Improve resource display and editing interfaces by providing more user-friendly interaction methods, such as using forms or visual editors instead of direct YAML editing for creating and modifying resources.\n - Support the display of hierarchical Queues and HyperNode resources with mouse-click expand/collapse functionality to clearly visualize resource relationships.\n - Optimize the user interface design to enhance aesthetics and ease of use.\n - Refactor the backend code to improve maintainability and scalability.\n - Display both key information and full information for resources, with an option to switch between views.\n - (Optional) Support the display and management of more resource types.\n\n- Recommended Skills: Kubernetes, React, Node, JS\n\n- Mentor(s):\n - Xuzheng Chang(@Monokaix, 2536818783@qq.com)\n - Zicong Chen(@JesseStutler, jesseincomparable@hotmail.com)\n\n- Upstream Issue: [https://github.com/volcano-sh/volcano/issues/4277](https://github.com/volcano-sh/volcano/issues/4277)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e81c895a-69f9-4c63-b4fe-e9352c3fa2e7\n\n#### Enhance Volcano Official Documentation\n\nCNCF - Volcano: Enhance Volcano Official Documentation (2025 Term 2)\n\n- Description: As Volcano's functionality grows and its integration with the broader ecosystem deepens, the community documentation needs to be updated and iterated upon to provide better user guidance and experience. Clear and comprehensive documentation helps users quickly get started with Volcano and reduces the cost of usage and configuration. Currently, some documentation is scattered across the GitHub repository and needs to be migrated to the official website to provide a unified entry point for users.\n\n- Expected Outcome:\n - Migrate the documentation from the GitHub repository that is not yet on the official website to the official website.\n - Provide detailed explanations of the functionality of Volcano Scheduler, Volcano Controller, Volcano Agent, and Volcano Admission components, including the meaning of their respective startup parameters.\n - Supplement the documentation for core features such as JobFlow and vGPU virtualization.\n - Add a \"Best Practices\" section offering recommendations and configuration examples for using Volcano in various scenarios.\n - Include a \"Troubleshooting\" section that collects and organizes common issues and their solutions.\n\n- Recommended Skills: Technical Writing, Markdown, Git, Hugo or other static site generators\n\n- Mentor(s):\n - Xuzheng Chang(@Monokaix, 2536818783@qq.com)\n - Zicong Chen(@JesseStutler, jesseincomparable@hotmail.com)\n\n- Upstream Issue: [https://github.com/volcano-sh/volcano/issues/4278](https://github.com/volcano-sh/volcano/issues/4278)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a8bafeea-f608-4e73-9a44-ca60c309536f\n\n\n### Jaeger\n\n#### Upgrade Jaeger-UI to React v19\n\nCNCF - Jaeger: Upgrade Jaeger-UI to React v19 (2025 Term 2)\n\n- Description: [Jaeger](https://www.jaegertracing.io/) is an open-source, distributed tracing platform designed to monitor and troubleshoot microservices-based systems. Jaeger-UI is the web UI for Jaeger, built with [React](https://react.dev/). The current version of React used by Jaeger-UI is v18. This project aims to upgrade Jaeger-UI to React v19, in order to stay up to date with the dependencies.\n- Expected Outcome: A working version of Jaeger-UI upgraded to React v19, with all the features and functionality of the current version. This may include a need to upgrade or replace some other dependencies that may not be compatible with the latest React.\n- Recommended Skills: Javascript, React, HTML, CSS, Web development, UI/UX design, Testing\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n- Upstream Issue: https://github.com/jaegertracing/jaeger-ui/issues/2764\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6816e614-2e9e-492e-9d28-c91506cde073\n\n#### Jaeger demo on Kubernetes\n\nCNCF - Jaeger: Jaeger demo on Kubernetes (2025 Term 2)\n\n- Description: [Jaeger](https://www.jaegertracing.io/) is an open-source, distributed tracing platform designed to monitor and troubleshoot microservices-based systems. We provide an easy getting started guide using `docker compose`, but we would also like to run a live demo that people can access directly from the Jaeger website. This project aims to create a Kubernetes deployment for the Jaeger demo, including the Jaeger backend and the UI, HotROD demo app, and the Service Performance Monitoring setup, so that users can try out the project in action and we can use this for various events to promote the project. This should be something which automatically deploys the new versions when they are released. The data in the demo environment should either be a rolling buffer or purged daily. It might even be a good idea to just recreate the environment daily which might solve both problems at once. This can be determined by the mentee. We currently have access to an Oracle Cloud environment where this can be stood up for “dev” and “prod” as managed kubernetes clusters.\n- Expected Outcome: A working version of Jaeger demo auto-deployed on Oracle Cloud. Automatic version upgrades. Config as code. Security. Monitoring. Documentation.\n- Recommended Skills: Kubernetes, Cloud, Security, Monitoring\n- Mentor(s):\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/7115\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/14c5fcdd-61b9-40a1-8a10-27a1bba76b3d\n\n\n### Headlamp \n\n#### Kubernetes UI Headlamp: Implement Kubernetes API Caching, Pagination, and Search\n\nCNCF - Headlamp: Kubernetes API caching, pagination & search (2025 Term 2)\n\nDescription: Headlamp currently fetches Kubernetes API data directly from the frontend, which can lead to performance bottlenecks and unnecessary API load. Introducing a caching layer in the headlamp-server backend will reduce API calls, improve response times, and enable more efficient data handling. This enhancement will also allow for improved pagination—fetching only the data needed for the current view—and enable backend-powered search functionality, reducing the need for the frontend to download large datasets.\n\nExpected Outcome:\n\n- A backend caching layer for Kubernetes API responses, scoped per user context to ensure data isolation and security.\n- A new pagination API that allows the frontend to request only the currently visible page of data.\n- A search API that queries the cached data, enabling fast and efficient search without full data downloads.\n- Documentation and possibly a demo video explaining the architecture and usage of the new caching, pagination, and search features.\n\nRecommended Skills: Golang (Optional: Kubernetes API)\n\nMentor(s):\n- Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n- Rene Dudfield (@illume, renedudfield@microsoft.com)\n- Kautilya Tripathi (@knrt10, ktripathi@microsoft.com)\n\nUpstream Issue: https://github.com/kubernetes-sigs/headlamp/issues/3230\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1b9a4a99-2d92-4c1a-ac34-7fe554bf6393\n\n#### Kubernetes UI Headlamp: Gateway API Service Mesh Visualization\n\nCNCF - Headlamp: Gateway API Service Mesh Visualization (2025 Term 2)\n\nDescription: The Gateway API is becoming the standard for Kubernetes service networking, including ingress, traffic routing, and service mesh use cases. While Headlamp has built-in support for Gateway API resources, there is currently no integrated way to visualize and manage service mesh topologies, traffic flows, and policies. This feature aims to enhance Headlamp with a visual and interactive interface for understanding and managing service meshes built on the Gateway API.\n\nExpected Outcome:\n\nA Headlamp feature that enables users to:\n\n- Visualize service mesh topologies using Gateway API resources (e.g., Gateways, Routes, Services)\n- Overlay traffic flow data, latency, error metrics, and traffic policies (e.g., splitting, retries, timeouts) on the resource map\n- Leverage existing Headlamp Map and CRD extension capabilities for seamless integration\n- Documentation and possibly a demo video or blog post.\n \nRecommended Skills: TypeScript, React (Optional: Kubernetes Gateway API)\n\nMentor(s):\n- Rene Dudfield (@illume, renedudfield@microsoft.com)\n- Kautilya Tripathi (@knrt10, ktripathi@microsoft.com)\n- Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n\nUpstream Issue: https://github.com/kubernetes-sigs/headlamp/issues/2798\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/62e272ef-e950-45dd-9c57-71d216d22ed2\n\n#### Kubernetes UI Headlamp Plugin: Karpenter Autoscaling Insights and Management\n\nCNCF - Headlamp: Karpenter Autoscaling Insights and Management (2025 Term 2)\n\nDescription: Karpenter is a dynamic Kubernetes node autoscaler that provisions compute resources in response to real-time workload demands. While Karpenter is powerful, it lacks a native UI for visualizing its autoscaling behavior and managing its custom resources. This plugin will integrate Karpenter-specific insights into Headlamp, leveraging Headlamp’s existing CRD support to provide a focused, user-friendly interface for understanding and managing Karpenter’s decisions.\n\nExpected Outcome:\n\nA Headlamp plugin that provides:\n\n- Show Karpenter Provisioners, NodePools, and NodeClasses, including their constraints and current status.\n- Real-time display of scaling decisions, such as which pods triggered provisioning and why.\n- A dashboard for pending pods with unmet scheduling requirements, highlighting why they couldn’t be scheduled.\n- Integration with Kubernetes events and Karpenter metrics to show provisioning latency, node lifecycle events, and cost efficiency.\n- A configuration editor for Karpenter Custom Resource Definitions(CRDs) using Headlamp’s existing CRD facilities.\n- Documentation and possibly a demo video or blog post.\n\nRecommended Skills: TypeScript, React (Optional: Kubernetes API, Karpenter)\n\nMentor(s):\n\n- Kautilya Tripathi (@knrt10, ktripathi@microsoft.com)\n- Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n- Rene Dudfield (@illume, renedudfield@microsoft.com)\n\nUpstream Issue: https://github.com/kubernetes-sigs/headlamp/issues/3231\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5ca70394-f568-4bbf-a88d-4e5af8b235cf\n\n#### Kubernetes Headlamp UI: UX Audit and Design Improvements for Plugins\n\nCNCF - Headlamp: UX Audit and Design Improvements for Plugins (2025 Term 2)\n\nDescription:\nHeadlamp is a Kubernetes UI that supports a growing ecosystem of plugins, including integrations with CNCF projects like Flux, KEDA, and Falco. As the number and complexity of these plugins grow, ensuring a consistent, intuitive, and user-friendly experience becomes increasingly important. This project will focus on conducting UX audits of existing Headlamp plugins, identifying usability issues, and proposing design improvements. It will also explore user personas (e.g., operators vs. developers) to inform design decisions and help shape the future of plugin UX in Headlamp.\n\nExpected Outcome:\nA design-led UX audit and improvement initiative that includes:\n\n- A review of selected Headlamp plugins to identify usability issues and inconsistencies\n- User research and persona development to better understand plugin audiences\n- Design proposals and mockups for improving plugin UIs and workflows\n- Collaboration with technical mentors to help implement selected improvements\n- Optional exploration of UX needs for recent Kubernetes features or under-designed areas in Headlamp\n\nRecommended Skills: UX design, UI design, user research, Figma or similar tools\n(Optional: familiarity with Kubernetes, Headlamp, or frontend development)\n\nMentor(s):\n- Joaquim Rocha (@joaquimrocha, joaquimm@microsoft.com)\n- Ivelisse Capellan Heyer (@ivelisseca, ivelisseca@microsoft.com)\n- Grant Florence (@Gflo3, gflorence@microsoft.com)\n\nUpstream Issue: https://github.com/kubernetes-sigs/headlamp/issues/3233\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4d736149-aa95-4f31-b01c-a54c754614d0\n\n\n### Kgateway\n\n#### OpenTelemetry is an AI Gateway’s Best Friend: Extending Observability to kgateway’s AI Extensions\n\nCNCF - Kgateway: OpenTelemetry Observability for AI Extensions (2025 Term 2)\n\n- Description:\n\nKgateway can be used as an “AI Gateway” that allows applying traditional\ntraffic management, security, and resiliency policies when reaching out to LLM\nproviders. It also allows sending a request to another server for processing\nthings like prompt guards or enrichment before we send it off to the LLM\nproviders. An important aspect in any system that has lots of moving parts is\nobservability: the collection of metrics and other information that allow you\nto identify issues and troubleshoot a live system.\n\nThis project aims to enable OpenTelemetry support in kgateway’s AI extensions\nby allowing users to configure a gRPC tracing collector. This feature enables\nspan propagation from the AI extensions extproc server and exporting traces to\nan OpenTelemetry-compatible backend (e.g., OpenTelemetry Collector, Jaeger,\nZipkin, or Datadog). This feature will build on Envoy’s native tracing\ncapabilities and aligns with industry-standard observability practices. This\nwill make it easier to debug, monitor, and optimize traffic flowing to LLM\nProviders through kgateway.\n\n- Expected Outcome:\n - Design and implement an API to enable tracing for the kgateway’s AI extproc extension.\n - Extend the AI extensions extproc server with OpenTelemetry tracing.\n - Create end-to-end (e2e) tests to validate configuration and trace propagation.\n - Write documentation for plugin developers and end users\n - Gain hands-on experience with AI providers, OpenTelemetry, tracing platforms, Envoy, Kubernetes, and kgateway while building real observability features!\n\n- Recommended Skills:\n - Golang\n - Python\n - GitHub workflow\n - Otel\n - Kubernetes\n - Kubernetes Gateway API\n - Envoy\n\n- Mentor(s):\n - Nina Polshakova (@npolshakova, ninapolshakova@gmail.com)\n - Steven Landow (@stevenctl, steven.landow@solo.io)\n\n- Upstream Issue: https://github.com/kgateway-dev/kgateway/issues/11177\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/347952bc-15c6-48f7-9c4e-aad7dffb3817\n\n#### Mission: Scale Possible! Build Automated Scale Tests for kgateway\n\nCNCF - Kgateway: Automated scale tests for kgateway (2025 Term 2)\n\nDescription:\n- This project aims to design and build a suite of automated scale tests for kgateway that would run as part of our builds and releases process. These tests will help us understand how kgateway behaves under a large number of Kubernetes gateway resources and kgateway extensions, and load tests to ensure it performs reliably as usage scales. You'll gain hands-on experience with performance testing, infrastructure automation, and Kubernetes-based systems.\n\nExpected Outcome:\n- Design and a scale testing suite\n- Build a scale test suite for kgateway\n- Analyze test results to identify bottlenecks or failure points\n- Write developer-facing documentation\n- Explore Oracle Developer cloud and determine if it is suitable for kgateway’s scale tests.\n\nRecommended Skills:\n- Golang\n- GitHub workflow\n- Kubernetes\n\nMentor(s):\n - Nina Polshakova (@npolshakova, ninapolshakova@gmail.com)\n - Lawrence Gadban (@lgadban, lawrence.gadban@solo.io) \n\nUpstream Issue: https://github.com/kgateway-dev/kgateway/issues/11210 \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d713bc73-3257-4d21-b533-97e0ccadf7bb\n\n\n### Envoy Gateway\n\n#### Progressive Rollouts of the Envoy Proxy fleet during Envoy Gateway upgrades\n\nCNCF - Envoy Gateway: Progressive Envoy Proxy Rollouts during Gateway Upgrades (2025 Term 2)\n\n- Description:\nEnvoy Gateway translates Kubernetes-native Gateway API resources into xDS configuration consumed by Envoy Proxy.\nIt also manages the lifecycle of the Envoy Proxy fleet by generating Kubernetes resources such as Deployments and Services.\n\nCurrently, upgrades to Envoy Gateway (the control plane) result in immediate, in-place updates to the associated Envoy Proxy fleet (the data plane).\nWhile this operation is designed to be zero-downtime, some users prefer a staged upgrade process where the control plane is updated first,\nfollowed by a progressive rollout of the data plane.\n\nThis project aims to design and implement support for progressive data plane upgrades, allowing users to decouple the control and data plane upgrade processes. \nThis would provide enhanced control and safer rollout strategies (e.g., canary or blue-green deployments).\n\n- Expected Outcome:\n - Design a two-step upgrade workflow that separates control plane and data plane updates.\n - Implement configuration or CRD support to control rollout strategy of the Envoy Proxy fleet.\n - Add documentation and example manifests for users to adopt the new workflow.\n\n- Recommended Skills: Golang, Kubernetes, CD tools (like Argo Rollouts and Flagger).\n\n- Mentor(s):\n - Arko Dasgupta (@arkodg, arko@tetrate.io)\n - Kateryna Nezdolii (@nezdolik, kateryna.nezdolii@gmail.com)\n\n- Upstream Issue: https://github.com/envoyproxy/gateway/issues/4494\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5c427ca3-19f3-4c66-887c-3a3489893300\n\n\n### Antrea\n\n#### Replace Dependabot with Renovate for automatic dependency updates\n\nCNCF - Antrea: Automate dependency updates with Renovate (2025 Term 2)\n\n- Description: Antrea currently relies on Github's Dependabot to automatically updated dependencies (Go modules / Github Actions) on the main branch. There is a key limitation with Dependabot, which is that it doesn't support automatically updating dependencies with security vulnerabilities in \"active\" release branches (for Antrea minor versions which are currently actively supported). This limitation means that maintainers have to manually backport Dependabot patches when they address security vulnerabilities, which has become a burden. [Renovate](https://docs.renovatebot.com/) is an alternative tool for dependency management, and it seems that it offers richer configuration options and may not suffer from the same limitation as Dependabot.\n- Expected Outcome: Migrate the Dependabot config to a Renovate config for the main Antrea repository (antrea-io/antrea), as well as for all other repositories (under the antrea-io organization) which currently use Dependabot. Dependencies that are currently updated as a group (e.g., `golang.org/x` modules) should remain that way. The Renovate config should include provisions to automatically perform security updates in active release branches. The change should not impact developer workflows and the Antrea release cycle; all experiments should be performed in a fork.\n- Recommended Skills: familiarity with the Github ecosystem, including Github Actions, and with the standard Github dev workflows.\n- Mentor(s):\n - Quan Tian (@tnqn, tianquan23@gmail.com)\n - Lan Luo (@luolanzone, luolanzone@gmail.com)\n - Antonin Bas (@antoninbas, antonin.bas@gmail.com)\n- Upstream Issue: https://github.com/antrea-io/antrea/issues/7155\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/62d69fd5-6c90-4ba1-b260-a5dc247fc3cf\n\n#### Improvements to the PacketCapture feature\n\nCNCF - Antrea: Enhance PacketCapture with IPv6 and flexible filters (2025 Term 2)\n\n- Description: As a Kubernetes (K8s) network plugin (CNI plugin), Antrea provides networking functions for K8s Pods and includes various troubleshooting tools for cluster administrators and application developers to diagnose networking issues. The [PacketCapture feature](https://github.com/antrea-io/antrea/blob/main/docs/packetcapture-guide.md) was introduced recently (Antrea v2.2) and allows capturing network traffic for specific endpoints using predefined filters similar to those supported by libpcap/tcpdump. Users can initiate a packet capture through a Kubernetes Custom Resource Definition (CRD) or a CLI command. The Antrea control plane then generates and injects the corresponding BPF program, and the captured packets can be exported as a pcap file. In the last iteration of the LFX mentorship program, we added support for L4 filters (TCP flags, ICMP type & code) to the PacketCapture API, to enable Antrea users to target network traffic more precisely. We would like to keep improving the PacketCapture feature with 1) IPv6 support, 2) more flexibility when providing the source and destination, 3) the ability to specify the capture point for traffic (source or destination Pod).\n- Expected Outcome: Extend the API definition for the PacketCapture CRD, and implement the new API functionality by generating the correct BPF instructions. The `antctl` CLI command for PacketCapture should be updated as needed to accomodate for the API changes. The implementation should come with a sufficient amount of tests (both unit tests and e2e tests), ensuring that the new functionality is working as expected.\n- Recommended Skills: familiarity with Golang, some knowledge about the K8s architecture and APIs, basic knowledge about networking protocols (IP/TCP/UDP/ICMP).\n- Mentor(s):\n - Hang Yan (@hangyan, hang.yan@hotmail.com)\n - Antonin Bas (@antoninbas, antonin.bas@gmail.com)\n- Upstream Issue: https://github.com/antrea-io/antrea/issues/6861, https://github.com/antrea-io/antrea/issues/6976, https://github.com/antrea-io/antrea/issues/6863\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7dc05f9c-b90d-4fe0-bf43-d6bf10ea29a2\n\n\n### KubeEdge\n\n#### Embodied Intelligence Benchmarking Framework for Industrial Manufacturing with KubeEdge-Ianvs\n\nCNCF - KubeEdge: Industrial embodied intelligence benchmarking framework (2025 Term 2)\n\n- Description: As industrial manufacturing accelerates its digital transformation through advancements in robotics, adaptive production lines, and smart testing systems, cloud-edge collaboration has emerged as a critical enabler for deploying embodied intelligence in complex operational environments. Contemporary industry requirements for embodied intelligence now extend beyond basic task execution to encompass multimodal perception-decision integration, dynamic environment adaptation, and distributed device orchestration. Existing benchmarking frameworks exhibit limitations in evaluating scenario-specific embodied attributes inherent to industrial settings. This initiative leverages the KubeEdge-Ianvs collaborative AI framework, integrating domain-specific test datasets, simulation environments, and quantitative metrics to establish a certified industrial-grade evaluation infrastructure for embodied intelligence systems.\n- Expected Outcome:\n - Develop an industrial-grade embodied intelligence dataset through systematic classification and reorganization of existing resources across four standardized task categories\n - Design standardized validation suites within KubeEdge-Ianvs\n - Deploy reference baseline algorithms using the developed validation suites to establish performance benchmarks within KubeEdge-Ianvs\n- Recommended Skills: Python, Benchmark, Dataset, Embodied Intelligence\n- Mentor(s):\n - Zimu Zheng (@MooreZheng, zimu.zheng@hotmail.com)\n - Mengzhuo Chen (@IcyFeather233, icyfeather@foxmail.com)\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/197\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bd625cf2-dba9-4246-8c32-746fcc05c8e0\n\n#### Device Anomaly Detection Framework Based on KubeEdge\n\nCNCF - KubeEdge: Device anomaly detection framework (2025 Term 2)\n\n- Description: The current KubeEdge platform represents device states using three statuses: Desired, ObservedDesired, and Reported. The device states displayed on the platform are entirely reliant on the Mapper, which collects and reports data from the device side. However, due to limitations in the Mapper implementation, physical device malfunctions, network delays, and potential network attacks, the device states shown on the platform may not accurately reflect the actual state of the devices. In the KubeEdge platform, if applications depend on device states for decision-making, such inconsistencies in state representation may lead to undesirable outcomes. Therefore, this project aims to design a device state anomaly detection framework for KubeEdge. By exploring the causal relationships among device states, the framework will establish lightweight anomaly detection capabilities and provide a comprehensive toolchain encompassing data collection, model training, real-time anomaly detection, and results visualization.\n- Expected Outcome:\n - A general-purpose device anomaly detection framework that supports user-defined detection algorithms\n - A complete technical design document including model selection, training procedures, and detailed architecture diagrams for both training and online detection components\n - A machine learning model and corresponding anomaly detection algorithm capable of capturing causal relationships among device states, trained and tested using standard frameworks\n - An online anomaly detection module integrated into the KubeEdge device state reporting workflow, enabling real-time analysis through a model inference hook\n- Recommended Skills: KubeEdge, IoT, Machine Learning\n- Mentor(s):\n - Liwei Shen (@meixiezichuan, shenliwei@fudan.edu.cn)\n - Elias Wang (@wbc6080, wangbincheng4@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6312\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1d432ec0-17cf-4092-9356-f69b1d5e140e\n\n#### Automatically generate unit tests and e2e tests based on LLM\n\nCNCF - KubeEdge: LLM-generated unit and e2e tests automation (2025 Term 2)\n\n- Description: Unit test and e2e test coverage is a critical metric for ensuring code quality and stability. However, many codebases suffer from low test coverage, which increases the risk of release quality, undetected bugs and regressions. We can leverage Large Language Models (LLMs) like DeepSeek to automatically generate unit tests/e2e tests for code with low coverage, then integrate this into CI/CD pipelines to submit Pull Requests (PRs) for people reviewing.\n- Expected Outcome:\n - Research open-source tools compatible with LLM（DeepSeek) for automated unit test/e2e test generation\n - Integrate the automated test generation tool into CI/CD\n - Trigger the tool automatically based on code changes and submit a Pull Request (PR)\n- Recommended Skills: KubeEdge, LLM, Golang, DevOps\n- Mentor(s):\n - Yue Li (@liyuerich, yue.li@daocloud.io)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6318\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c936cda3-d842-4286-a38a-7138d5b04f51\n\n#### Support KubeEdge EdgeNode Runing on RK3588 Chip\n\nCNCF - KubeEdge: Support RK3588 edge nodes (2025 Term 2)\n\n- Description: The RK3588 chip, developed by Rockchip, is widely used in edge computing devices due to its balanced computational power, rich interface options, and low power consumption. Supporting RK3588 edge devices is crucial for expanding the KubeEdge ecosystem. However, it has not yet been fully validated whether RK3588-based edge nodes can be seamlessly integrated with KubeEdge. This project aims to establish complete compatibility between RK3588 and KubeEdge.\n- Expected Outcome:\n - Debug and Support KubeEdge EdgeNode running on RK3588 Chip.\n - Successfully deploy edge pods on edge node based on RK3588.\n - Achieve node management and metrics for nodes and pods.\n - Complete hardware compatibility testing and output documentation or a blog.\n- Recommended Skills: KubeEdge, Hardware, Golang\n- Mentor(s):\n - Hongbing Zhang (@HongbingZhang, hongbing.zhang@daocloud.io)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6320\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6ea6aa02-023f-492f-addd-28087e9810a3\n\n\n### Cilium\n\n#### Cilium Technical Outcomes\n\nCNCF - Cilium: Document technical outcomes on website (2025 Term 2)\n\n- Description: On the Cilium [homepage](https://cilium.io), we want to document technical outcomes from using Cilium. Think of these technical outcomes as aggregating some of cilium features to achieve a high level technical goal. These are the current ones we have in mind: Zero Trust Networking, Network Automation, Distributed Firewalling, Cost and Carbon Savings, Multi-cloud Connectivity.\n- Expected Outcome: A section of the Cilium website detailing these technical outcomes. This section on the website can include any supporting materials from the Cilium community i.e blogs, videos, talks, illustrations, etc.\n- Recommended Skills: Technical Writing, some basic working knowlegde of Cilium or the willingness to quickly ramp up, Kubernetes, general familiarity with the cloud native ecosystem, basic React.js(the cilium webiste is built with Gatsby).\n- Mentor(s):\n - Bill Mulligan(xmulligan, )\n- Upstream Issue: \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8c677ed1-cec0-44b7-93aa-60f90ddb7949\n\n### kube-burner\n\n#### Enhancements around k8s performance testing\n\nCNCF - kube-burner: Enhancements around k8s performance testing (2025 Term 2)\n\n- Description:\n We intend to get some help around open issues in the repository and also come up with new use cases and scenarios for performance testing any kubernetes distribution. We love new perspectives and are always open to new ideas alongside what we have as tracked work in github issues.\n- Expected Outcome:\n The knock down some of open critical issues and bring in new perspective to the project.\n- Recommended Skills:\n - Golang\n - Kubernetes\n - Cloud Platforms\n- Mentor(s):\n - Vishnu Challa (@vishnuchalla, vchalla@redhat.com) \n - Raul Sevilla (@rsevilla87, rsevilla@redhat.com)\n- Upstream Issues: https://github.com/kube-burner/kube-burner/issues \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fa247b88-8f80-4b1e-97b3-903ae3ea2be5\n\n" }, { "path": "programs/lfx-mentorship/2025/02-Jun-Aug/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n- Upstream Issue:\n\n```\n\n---\n\n## Proposed Project ideas" }, { "path": "programs/lfx-mentorship/2025/03-Sep-Nov/README.md", "content": "# Term 03 - 2025 Sept - Nov\n\nStatus: Planning\n\nMentorship duration - three months (full-time schedule)\n\n### Timeline\n\n| **Activity** | **Dates (2025)** |\n|----------------------------------------------------|-------------------------------------------------------------------------------------|\n| **Project Proposals Open** | Wed, July 2 – Tue, July 29, 2025 11AM PDT (18:00 UTC) |\n| **Mentee Applications Open** | Thurs, July 31, 2025 11AM PDT (18:00 UTC) – Tue, August 12, 2025 11AM PDT (18:00 UTC) |\n| **Application Review Period** | Wed, August 13 – Tue, August 26, 2025 11AM PDT (18:00 UTC) |\n| **Selection Notifications** | Wed, August 27 |\n| **Mentorship Program Begins (Work Phase, Week 1)** | Mon, September 8 |\n| **Midterm Mentee Evaluations** | Tues, Oct 14, 2025 11AM PDT (18:00 UTC) |\n| **First Stipend Payments** | Wed, Oct 15, 2025 |\n| **Final Mentee Evaluations** | Tues, November 25, 2025, 11AM PST (19:00 UTC) |\n| **Second Stipend Payments** | Wed, Nov 26, 2025 |\n| **Last Day of Term** | Fri, November 28 |\n\n### Project instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2025/03-Sep-Nov/project_ideas.md, by July 29, 2025.\nPlease limit proposals to 4-5 proposals per CNCF project.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n* [Cartography](#cartography)\n * [IAM Whatever You Say IAM - GCP and Azure edition](#iam-whatever-you-say-iam---gcp-and-azure-edition)\n * [Make map of Azure and Google Compute Cloud resources](#make-map-of-azure-and-google-compute-cloud-resources)\n* [Cilium](#cilium)\n * [Evaluate SEO, AEO, and AIO for cilium.io](#evaluate-seo-aeo-and-aio-for-ciliumio)\n* [CloudNativePG](#cloudnativepg)\n * [Rebuilding CloudNativePG Documentation for Multi-Version Support with Docusaurus](#rebuilding-cloudnativepg-documentation-for-multi-version-support-with-docusaurus)\n * [Chaos Testing](#chaos-testing)\n * [Refresh cnpg-i-hello-world to align with the current state of CNPG-I](#refresh-cnpg-i-hello-world-to-align-with-the-current-state-of-cnpg-i)\n* [Harbor](#harbor)\n * [Harbor CLI - System Settings and Configuration](#harbor-cli---system-settings-and-configuration)\n * [Extend Harbor's Pluggable Scanner API for Runtime Behavior Profiles](#extend-harbors-pluggable-scanner-api-for-runtime-behavior-profiles)\n * [Harbor Satellite: Q&A and Docs](#harbor-satellite-qa-and-docs)\n * [Harbor Satellite: Implementing a Eventing System for Satellite](#harbor-satellite-implementing-a-eventing-system-for-satellite)\n* [Jaeger](#jaeger)\n * [Next-Generation Jaeger Demo with OpenTelemetry and OpenSearch (2025 Term 3)](#next-generation-jaeger-demo-with-opentelemetry-and-opensearch-2025-term-3)\n* [Kagent](#kagent)\n * [Building cloud native agents for Kagent](#building-cloud-native-agents-for-kagent)\n* [Karmada](#karmada)\n * [Support TFJob and PyTorchJob in Karmada via Default Resource Interpreters](#support-tfjob-and-pytorchjob-in-karmada-via-default-resource-interpreters)\n * [Support TrainJob and SparkApplication in Karmada via Default Resource Interpreters](#support-trainjob-and-sparkapplication-in-karmada-via-default-resource-interpreters)\n * [Support RayCluster and RayJob in Karmada via Default Resource Interpreters](#support-raycluster-and-rayjob-in-karmada-via-default-resource-interpreters)\n * [Support Volcano Job and Notebook in Karmada via Default Resource Interpreters](#support-volcano-job-and-notebook-in-karmada-via-default-resource-interpreters)\n* [kgateway](#kgateway)\n * [Improve kgateway ecosystem integrations documentation](#improve-kgateway-ecosystem-integrations-documentation-)\n * [kgateway, agentgateway, and observability improvements](#kgateway-agentgateway-and-observability-improvements)\n* [Kmesh](#kmesh)\n * [Improving Ipsec's Stability and Ease of Use](#improving-ipsecs-stability-and-ease-of-use)\n * [Kmesh Orion replace waypopint](#kmesh-orion-replace-waypopint)\n* [Knative](#knative)\n * [Enhancing the Knative func CLI Experience](#enhancing-the-knative-func-cli-experience)\n* [Krkn](#krkn)\n * [Implementing the resiliency score feature](#implementing-the-resiliency-score-feature)\n* [Kube State Metrics](#kube-state-metrics)\n * [Automate the release process](#automate-the-release-process)\n* [KubeArmor](#kubearmor)\n * [KubeArmor Observability Spectrum Enhancement](#kubearmor-observability-spectrum-enhancement)\n * [KubeArmor Unit Test Coverage Audit](#kubearmor-unit-test-coverage-audit)\n* [KubeEdge](#kubeedge-)\n * [Deep integration of KubeEdge with AMD edge nodes](#deep-integration-of-kubeedge-with-amd-edge-nodes)\n * [Industrial Embodied Intelligence Benchmarking Dataset for KubeEdge-Ianvs](#industrial-embodied-intelligence-benchmarking-dataset-for-kubeedge-ianvs)\n * [Comprehensive Example Restoration for KubeEdge Ianvs](#comprehensive-example-restoration-for-kubeedge-ianvs)\n * [Research on Deploying Small Language Models with KubeEdge and Integrating with Enterprise AI Platforms](#research-on-deploying-small-language-models-with-kubeedge-and-integrating-with-enterprise-ai-platforms)\n * [Device Anomaly Detection Framework Based on KubeEdge](#device-anomaly-detection-framework-based-on-kubeedge)\n* [KubeSlice](#kubeslice)\n * [Implement Dynamic IPAM for the Slice Overlay Network](#implement-dynamic-ipam-for-the-slice-overlay-network)\n * [Implement Custom Topology Definition for a Slice](#implement-custom-topology-definition-for-a-slice)\n * [Implement Comprehensive Unit & Integration Testing for kubeslice-cli](#implement-comprehensive-unit--integration-testing-for-kubeslice-cli)\n * [Enhance and Automate End-to-End (E2E) Testing Across the KubeSlice Ecosystem](#enhance-and-automate-end-to-end-e2e-testing-across-the-kubeslice-ecosystem)\n* [KubeStellar](#kubestellar)\n * [Allow a WDS to work with more than one ITS](#allow-a-wds-to-work-with-more-than-one-its)\n * [Implementing End-to-End Playwright Testing for KubeStellar UI](#implementing-end-to-end-playwright-testing-for-kubestellar-ui)\n * [KubeStellar Design System Implementation and Cloud Hosting](#kubestellar-design-system-implementation-and-cloud-hosting)\n * [Developer Relations & Community Growth for KubeStellar UI](#developer-relations--community-growth-for-kubestellar-ui)\n * [Model Context Protocol and A2A Communication Framework for KubeStellar UI](#model-context-protocol-and-a2a-communication-framework-for-kubestellar-ui)\n * [Implement KubeStellar controller logic to map WECs resources status to READY state of corresponding resource definitions in WDSes](#implement-kubestellar-controller-logic-to-map-wecs-resources-status-to-ready-state-of-corresponding-resource-definitions-in-wdses)\n* [Kubernetes](#kubernetes)\n * [Improve Kubernetes Reference Docs Generator](#improve-kubernetes-reference-docs-generator)\n* [Kyverno](#kyverno)\n * [Convert Kyverno Sample Policies to Use New CEL-Based Policy Types](#convert-kyverno-sample-policies-to-use-new-cel-based-policy-types)\n * [Support Namespaced CEL-Based Policies](#support-namespaced-cel-based-policies)\n * [Enhance Kyverno Documentation](#enhance-kyverno-documentation)\n * [kube-burner](#kube-burner)\n * [Enhancements around k8s performance testing](#enhancements-around-k8s-performance-testing)\n* [Meshery](#meshery)\n * [Relationships for AWS services](#relationships-for-aws-services)\n * [Relationships for GCP services](#relationships-for-gcp-services)\n * [Solutions Architecture of Popular Cloud Native Deployments](#solutions-architecture-of-popular-cloud-native-deployments)\n* [OpenCost](#opencost)\n * [Develop MCP Server for Agentic AI interaction with OpenCost](#develop-mcp-server-for-agentic-ai-interaction-with-opencost)\n * [OpenCost Data Model 2.0](#opencost-data-model-20)\n* [OpenKruise](#openkruise)\n * [SidecarSet support setting sidecar resources adaptively](#sidecarset-support-setting-sidecar-resources-adaptively-)\n * [Promote kruise api version from v1alphal1 to v1beta1](#promote-kruise-api-version-from-v1alphal1-to-v1beta1)\n * [Bring progressive delivery capability for native kubernetes DaemonSet](#bring-progressive-delivery-capability-for-native-kubernetes-daemonset)\n * [Enhance Robustness and Usability of Kruise-Game](#enhance-robustness-and-usability-of-kruise-game)\n* [OpenTelemetry](#opentelemetry)\n * [Developing Guidelines for OTel Survey Analysis and Communication](#developing-guidelines-for-otel-survey-analysis-and-communication)\n* [OpenYurt](#openyurt)\n * [OpenYurt Docker Extension for Simplified Deployment](#openyurt-docker-extension-for-simplified-deployment)\n* [PipeCD](#pipecd)\n * [Prepare documentation for PipeCD v1 release](#prepare-documentation-for-pipecd-v1-release)\n* [Podman Container Tools](#podman-container-tools)\n * [Implement flushing of conntrack entries in Netavark on network changes](#implement-flushing-of-conntrack-entries-in-netavark-on-network-changes)\n* [Prometheus](#prometheus)\n * [Prototyping Prometheus for exploratory use cases](#prototyping-prometheus-for-exploratory-use-cases)\n * [Prometheus Remote Write 2.0 stability](#prometheus-remote-write-20-stability)\n * [Prometheus Native Summaries](#prometheus-native-summaries)\n* [WasmEdge](#wasmedge)\n * [Pointer alignment checking for WASI host function arguments](#pointer-alignment-checking-for-wasi-host-function-arguments)\n * [Implement the remaining features of wasmedgeup](#implement-the-remaining-features-of-wasmedgeup)\n * [Rust Coder for Claude Code](#rust-coder-for-claude-code)\n * [Support the Responses API in Llama Nexus](#support-the-responses-api-in-llama-nexus)\n\n### Cilium\n\n#### Evaluate SEO, AEO, and AIO for cilium.io\n\n- Description: Improve how cilium.io content is discovered, ranked, and reused by search engines and AI tools. This includes enhancing technical SEO, optimizing for answer engines like Google SGE and Perplexity (AEO), and structuring content to be easily cited and used by large language models (AIO). The mentee will perform audits, recommend improvements, and implement changes across meta tags, structured data, documentation formatting, and content strategy.\n- Expected Outcome: SEO, AEO, and AIO audit report for cilium.io, Implementation of structured metadata (e.g., FAQ schema, article metadata, canonical URLs), TL;DR summaries or answer-first formatting added to key documentation and product pages, Deep-linked, self-contained concept pages created or refactored for LLM usability, Improved search visibility and AI result representation (tracked via baseline comparison)\n- Recommended Skills: Basic web development (HTML, Markdown, GitHub-based sites), Understanding of SEO fundamentals, Interest in AI, answer engines, or technical documentation, Familiarity with static site generators\n- Mentor(s):\n - Bill Mulligan (@xmulligan, bill@isovalent.com)\n- Upstream Issue: https://github.com/cilium/cilium.io/issues/633\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ab291439-bfbe-411f-ae31-91e552f01e66\n\n### Jaeger\n\n#### Next-Generation Jaeger Demo with OpenTelemetry and OpenSearch (2025 Term 3)\n\n- Description: This project will create a Kubernetes deployment for the full stack: the OpenTelemetry Demo application, the Jaeger backend components (Collector, Query), and OpenSearch as a storage backend. The environment will be automatically redeployed weekly to ensure it is always fresh and to solve the problem of data retention. The entire stack will be hosted on a managed Kubernetes cluster (Oracle Kubernetes Engine) within an Oracle Cloud environment generously donated to the project.\n- Expected Outcome:\n - A working, publicly accessible Jaeger demo featuring the OpenTelemetry Demo application, deployed on Oracle Cloud.\n - Fully automated, weekly deployments using the existing Helm-based automation and GitHub Actions.\n - The entire environment defined as \"Configuration as Code\".\n - A secure deployment following best practices for public-facing services.\n - The UIs for Jaeger, the OTel Demo, the load generator, and OpenSearch Dashboards exposed -publicly via the existing demo.jaegertracing.io URL.\n - Public-facing documentation on the Jaeger website explaining the demo architecture and linking to the automation code.\n- Recommended Skills: Kubernetes, Cloud, Security, Monitoring\n- Mentor(s):\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/7327\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/216f0f5d-6a7a-45f1-9592-2336ce734b2c\n\n### OpenCost\n\n#### Develop MCP Server for Agentic AI interaction with OpenCost\n\n- Description: We would like OpenCost to more effectively integrate with AI agents. To do this, we need to implement a Model Context Protocol (MCP) server to surface the information from the OpenCost API. This is a great opportunity to learn about MCP servers, and help us build an interface for AI agents to obtain reliable cost/usage information so that they can accomplish their business goals. \n- Expected Outcome: We would like an MCP server integrated into OpenCost. This MCP server should support queries on allocations, assets, and cloud costs. The MCP server should support the full range of allocations, assets, and cloud cost query parameters. A demo video should be recorded showing an interaction with the MCP server, and used to obtain costing information in a conversational setting. In addition, integration tests must be created in the OpenCost Integration Tests repo that test all interactions with the MCP server\n- Recommended Skills: Golang, MCP, Comfort with OpenCost, Cost/Usage reporting, AI agent interfacing and usage, documentation writing\n- Mentors \n - Alex Meijer (@ameijer, alexander.meijer@ibm.com)\n - Matt Bolt (@Mbolt35, matthew.bolt@ibm.com)\n- Upstream Issue: https://github.com/opencost/opencost/issues/3239\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3a83e46e-b950-4c57-bfa1-4b44bdadfad6\n\n#### OpenCost Data Model 2.0\n\n- Description: OpenCost's data model is now 6 years old, and we have learned a great deal long the way. Based on these learnings, we would like to revamp how OpenCost represents its cost and usage data across the stack. We want to set OpenCost up for the next set of features and scale by building a solid foundation for the way we represent data. \n- Expected Outcome: We would make the UID of Kubernetes objects into a first class citizen. These UID based objects would then be grouped in a similar hierarchy to the way Kubernetes itself is organized. A successful conclusion of this project would see an additional emitter implemented in OpenCost, that emits data objects stored in compressed protobuf which reflect a hierarchy of Kubernetes objects. The mentors will help establish this hierarchy. This hierarchy should then be tested via integration tests against the existing objects, and key metrics compared to be equal across those. \n- Recommended Skills: Golang, Object Oriented Design, Comfort with OpenCost, Cost/Usage reporting, Protobuf, Compression, Prometheus, documentation writing\n- Mentors \n - Alex Meijer (@ameijer, alexander.meijer@ibm.com)\n - Niko Kovacevic (@nikovacevic, nicholas.kovacevic@ibm.com)\n - Sean Holcomb (@Sean-Holcomb, sean.holcomb@ibm.com)\n- Upstream Issue: https://github.com/opencost/opencost/issues/3240\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c64774be-9c42-4405-9536-1e77977a5414\n\n### OpenTelemetry\n\n#### Developing Guidelines for OTel Survey Analysis and Communication\n- Description: Various special interest groups (a.k.a. SIGs) in the OpenTelemetry project run surveys to understand the experience of the end-users better. To run surveys efficiently, SIG End-user provides guidelines and assistance to people running surveys. In the past, SIG End-user focused on providing guidelines around survey design. Now we would like to move forward and cover survey data analysis and communication findings. \n- Expected Outcome: The mentee in this project will describe a step-by-step survey data analysis process and tools that OTel contributors without deep data analytics knowledge can leverage to analyze their survey data – from cleaning and coding of data, through descriptive statistics, cross-tabulation, to visualization. In addition, the mentee will come up with suggestions on how to improve existing and/or propose new ways to communicate survey findings from surveys to the OpenTelemetry community. [Bonus] The mentee might also execute one survey to test out the guidelines.\n- Recommended Skills\n - Being comfortable to talk with end-users and stakeholders in English.\n - Interest or currently working in UX, user research, or data analytics\n - Familiarity with spreadsheets (Google Sheets, Excel)\n - Basic understanding of databases and querying\n - [Bonus] Familiarity with Python and its data science libraries (e.g., pandas, numpy)\n- Mentors\n - Adriana Villela (@avillela, adriana.villela@gmail.com) \n - Andrej Kiripolsky (@AndrejKiri andrej.kiripolsky@gmail.com)\n- Upstream Issue: https://github.com/open-telemetry/sig-end-user/issues/143\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4a1f10ed-82f8-4611-95c4-3bac0b165609\n\n### KubeStellar\n\n#### Allow a WDS to work with more than one ITS\n\n- Description: Currently a Workload Description Space (WDS) has Binding objects that refer to inventory objects in exactly one Inventory and Transport Space (ITS). This mentorship project would generalize that, allowing references to inventory objects in multiple ITSes. Bear in mind scalability concerns.\n- Expected Outcome: generalized API and implementation as described.\n- Recommended Skills: Familiarity with Kubernetes and KubeStellar.\n- Mentor(s):\n - Rainui Ly (@rxinui, rainui.ly@gmail.com)\n - Mike Spreitzer (@Mike Spreitzer, mspreitz@us.ibm.com)\n- Upstream Issue: https://github.com/kubestellar/kubestellar/issues/3072\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/77a6f9f0-bd0f-4eb4-9d37-408b517f9208\n\n#### Implementing End-to-End Playwright Testing for KubeStellar UI\n\n- Description:\n This project focuses on building a robust end-to-end testing framework for the KubeStellar UI using Playwright. The goal is to ensure seamless user experiences by automating critical workflows, enhancing test coverage, and catching UI issues early across various browsers and environments. This includes setting up Playwright from scratch, writing reusable and scalable test suites using the Page Object Model (POM), and integrating these tests into the CI/CD pipeline. Special focus will be given to WebSocket-based testing, authentication, and resource-heavy scenarios in a multi-cluster Kubernetes context.\n- Expected Outcome:\n - End-to-end testing setup with Playwright integrated into the KubeStellar frontend\n - Comprehensive test suites for login, cluster/resource management, and binding policy workflows\n - Page Object Model-based modular test architecture\n - Mocking framework for WebSocket and REST API-based interactions\n - Visual regression testing integrated into GitHub Actions CI\n - Test coverage for key workflows\n - Cross-browser testing across Chromium, Firefox, Safari, and WebKit\n - Flaky test rate under 5% with parallel test execution and retry strategies\n - Documentation for writing, running, and debugging tests locally and in CI\n- Recommended Skills:\n - TypeScript / JavaScript\n - Playwright or similar frameworks (Cypress, Puppeteer)\n - React and frontend testing\n - Page Object Model architecture\n - GitHub Actions / CI/CD\n - WebSocket and REST API mocking\n - HTML/CSS/browser debugging\n - Kubernetes basics (optional but helpful)\n- Mentor(s):\n - Shivam Kumar (@btwshivam, shivam200446@gmail.com) \n - Andy Anderson (@clubanderson, andy@clubanderson.com) \n - Rishi Mondal (@MAVRICK-1, mavrickrishi@gmail.com) \n - Onkar Shelke (@onkar717, onkarwork2234@gmail.com)\n- Upstream Issue: \n [https://github.com/kubestellar/ui/issues/1334](https://github.com/kubestellar/ui/issues/1334)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b992256e-ed5f-44f3-8c13-8f3d8726fe00\n\n#### KubeStellar Design System Implementation and Cloud Hosting\n\n- Description: \n This LFX Term 3 project will transform the KubeStellar Design System foundations (created in Term 2) into a production-ready implementation using Next.js (Nextra or Mintlify) and deploy it on Oracle Cloud Infrastructure. The project will deliver a unified design language across all KubeStellar interfaces, featuring immersive animations and interactive components that enhance UX while maintaining performance and accessibility.\n- Expected Outcome: \n - Implement the complete KubeStellar Design System as a production-ready component library.\n - Build an interactive documentation site using Nextra or Mintlify.\n - Develop advanced 3D visualizations and micro-interactions using Three.js and animation libraries.\n - Deploy the design system and documentation to Oracle Cloud with enterprise-grade reliability.\n - Establish automated CI/CD pipelines for continuous deployment and semantic versioning.\n - Provide seamless integration paths for all KubeStellar interfaces (web UI, docs, CLI tools).\n - Ensure accessibility compliance while delivering visually engaging experiences.\n- Recommended Skills: \n - React & Next.js (Nextra, Mintlify) expertise.\n - Design Systems: Token-based implementation at scale.\n - 3D & Animation Development: Three.js, Framer Motion, GSAP, Lottie.\n - TypeScript, Tailwind, CSS Modules expertise.\n - Cloud Deployment: Oracle Cloud or similar experience.\n - DevOps & CI/CD: GitHub Actions, Docker, Kubernetes.\n - Accessibility & Performance Optimization.\n- Mentor(s):\n - Saumya Kumar (@oksaumya, saumyakr2006@gmail.com)\n - Shivam Kumar (@btwshivam, shivam200446@gmail.com) \n - Andrea Velázquez (@andreuxxxx, andrea@buoyant.io)\n - Kevin Roche (@KPRoche, kproche@us.ibm.com) \n- Upstream Issue: \n https://github.com/kubestellar/docs/issues/5\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/df6a6816-6c24-4464-98ca-38acc0764f83\n \n#### Developer Relations & Community Growth for KubeStellar UI\n\n- Description: This Developer Relations project aims to accelerate KubeStellar UI adoption by building a vibrant community around this multi-cluster Kubernetes management interface. The mentee will establish KubeStellar's online presence across key platforms, create technical content showcasing multi-cluster management capabilities, produce regular demo livestreams, improve documentation for contributors, implement community feedback mechanisms, and represent the project at CNCF events.\n- Expected Outcome: Established social media presence for KubeStellar, daily technical blog series, weekly/bi-weekly livestream demos, improved contributor documentation, active GitHub Discussions, community feedback system with analytics, and at least one CNCF talk submission.\n- Recommended Skills: Technical writing for developer content, video production and demo skills, Kubernetes and multi-cluster management knowledge, community management experience, social media strategy, basic web analytics, public speaking, familiarity with open-source workflows\n- Mentor(s):\n - Onkar Shelke (@onkar717, onkarwork2234@gmail.com)\n - Andy Anderson (@clubanderson, andrew.anderson@ibm.com)\n - Rishi Mondal (@MAVRICK-1, mavrickrishi@gmail.com)\n - Aayush Saini (@AayushSaini101, kumaraayush9810@gmail.com)\n- Upstream Issue: https://github.com/kubestellar/ui/issues/1403\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/72839cf1-1b27-4008-aa11-dfea483bd6ee\n\n#### Model Context Protocol and A2A Communication Framework for KubeStellar UI\n\n- Description: This project focuses on implementing an enhanced Model Context Protocol (MCP) and A2A communication framework for KubeStellar's Management Control Plane server. It builds upon the foundation MCP implementation to include advanced A2A coordination capabilities, distributed AI agent communication, and sophisticated context management for multi-cluster environments.\n- Expected Outcome: A fully specified Model Context Protocol with A2A communication extensions, implementation of protocol handlers in Python for the MCP server, A2A communication framework enabling AI agent coordination, context management system for KubeStellar state information, serialization mechanisms for cluster state, protocol extension mechanisms for different AI providers, performance optimizations, and comprehensive test suite.\n- Recommended Skills: Knowledge of KubeStellar's component architecture, protocol design and implementation experience, strong TypeScript or Python skills, familiarity with AI model interaction patterns, understanding of KubeStellar's object model, experience with serialization formats and data structures, distributed systems state management, and A2A communication patterns.\n- Mentor(s):\n - Rishi Mondal (@MAVRICK-1, mavrickrishi@gmail.com)\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n - Onkar Shelke (@onkar717, onkarwork2234@gmail.com)\n - Shivam Kumar (@btwshivam, shivam200446@gmail.com)\n- Upstream Issue: https://github.com/kubestellar/ui/issues/1481\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ee612f4c-ddb8-4f80-8692-3c975bc500a3\n\n#### Implement KubeStellar controller logic to map WECs resources status to READY state of corresponding resource definitions in WDSes\n\n- Description: \n This project aims to enhance the KubeStellar controller to reflect the readiness status of WEC resources in their corresponding WDS resource definitions. Currently, users must inspect status objects manually to determine propagation and readiness. This improvement is especially useful for tools like Argo CD, which rely on accurate READY status to show resources as synced.\n\n- Expected Outcome: \n - Design an efficient architecture to map the status of WEC resources back to their originating WDS resource.\n - Implement the controller logic to update WDS resource readiness based on the aggregated readiness of all corresponding WECs.\n - Ensure the updated WDS READY state integrates well with tools like Argo CD, showing accurate sync states.\n - Validate and demonstrate that resources in WDS appear correctly synced post implementation.\n\n- Recommended Skills: \n - Golang \n - Kubernetes controllers and CRDs \n - Distributed systems basics \n - Familiarity with Argo CD (optional but preferred)\n\n- Mentor(s): \n - [Franco Stellari] (@francostellari, fstellari@gmail.com)\n - [Rupam Manna] (@Rupam-It, mannarupam3@gmail.com)\n\n- Upstream Issue: https://mentorship.lfx.linuxfoundation.org/project/7b85c3fc-57ab-451d-a43a-c84251c4bc91\n https://github.com/kubestellar/kubestellar/issues/2809\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7b85c3fc-57ab-451d-a43a-c84251c4bc91\n\n### Prometheus\n\n#### Prototyping Prometheus for exploratory use cases\n\n- Description: Through a LFX Mentorship done in March-May, we performed [UX research](https://github.com/prometheus/prometheus/issues/15909) focusing on different ways Prometheus could deal with OpenTelemetry's Resource Attributes. One of the insights that this research showed us is that Prometheus and OpenTelemetry were primarily designed for different use-cases. While Prometheus focuses on monitoring metrics that the user knows that exist, one of OpenTelemetry's goals is to enable exploration of your data while the user doesn't really know what he/she is looking for. This mentorship will take the next steps on those research findings, exploring ideas about how Prometheus can enable the \"Exploration\" use case. \n- Expected Outcome:\n - Two or more sets of wireframes based on ideation workshop\n - Spoken presentation and report summarizing the findings and deliverables\n - Stretch goal: Apply to present findings at an upcoming conference\n- Recommended Skills:\n - Interest or currently working in UX Research and Design.\n - Familiarities with databases and querying.\n - Being comfortable to talk with End-Users in English.\n- Mentors:\n - Arthur Silva Sens (@ArthurSens, arthursens2005@gmail.com)\n - Amy Super (@amy-super, amy.super@grafana.com) \n- Upstream Issue: https://github.com/prometheus/prometheus/issues/16924\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d16f520b-2b77-4eac-bbd9-5c4cc5fdccf5\n \n#### Prometheus Remote Write 2.0 stability\n\n- Description: In the past few quarters, a lot of work has gone into the new Remote Write 2.0 (PROM-35) proposal, and a new spec has been successfully established https://prometheus.io/docs/specs/prw/remote_write_spec_2_0/. But there is still a lot of work that needs to be done to declare it stable, in terms of stability and performance in Prometheus, and general adoption from the wider Prometheus ecosystem.\n- Expected Outcome: Since this is a large initiative, for this round of mentorship, we want to focus on the following tasks,\n - Add 2.0 support to compliance test; make it easy to test write and receive implementations.\n - Ensure RW new features works on agent mode (test for agent mode with metadata-wal-records and type-and-unit features).\n - Ensure Prometheus uses the official RW client\n- Recommended Skills: Go, Prometheus\n- Mentor(s):\n - Juraj Michalek (@jmichalek132, juraj.michalek132@gmail.com)\n - Bartek Plotka (@bwplotka, bwplotka@gmail.com)\n - Saswata Mukherjee (@saswatamcode, saswataminsta@yahoo.com)\n- Upstream Issue: https://github.com/prometheus/prometheus/issues/16945\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cc7aedbe-d634-4b91-9d18-62df9e7d858b\n\n#### Prometheus Native Summaries\n\n- Description: Prometheus Summaries are less but still widely used metric type. Currently, similar to classic histogram, a single summary is composed of multiple counter series. The native summary idea proposes to structure the summary type metric samples into a complex sample, similar to native histograms. As a result, bringing meanigful storage efficiency and transactionality gains. This project offers an opportunity to introduce relatively complex database change across Prometheus scraping, WAL, TSDB and querying; considering the precedense of native histograms. This project will allow mentee to learn about Prometheus, generally database internals as well as observabvility needs.\n- Expected Outcome: The proposal and demo Prometheus implementation is published.\n- Recommended Skills: Go, Prometheus\n- Mentor(s):\n - Bartek Plotka (@bwplotka, bwplotka@gmail.com)\n - Jonathan Silva (@perebaj, perebaj@gmail.com)\n- Upstream Issue: https://github.com/prometheus/prometheus/issues/16949\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6bd5c5e0-25fc-4214-89ca-a48456d477b9\n\n### Podman Container Tools\n\n#### Implement flushing of conntrack entries in Netavark on network changes\n\n- Description:\n This project will involve implementing conntrack entry clearing into Netavark, Podman's network management tool.\n Stale conntrack entries can cause network traffic to be dropped if a UDP port is rebound while a container is running.\n Netavark is written in Rust, but the Rust netlink bindings (located [here](https://github.com/rust-netlink/netlink-packet-netfilter)) presently do not include support for Conntrack.\n As such, the first step of the project will be to expand these bindings to cover Conntrack.\n Netavark can then make use of the bindings to flush Conntrack entries on network change, and tests implemented to verify this functionality.\n- Expected Outcome:\n - Rust bindings for Conntrack implemented in the [rust-netlink](https://github.com/rust-netlink/netlink-packet-netfilter) library\n - Netavark modified to use these bindings to drop Conntrack entries at appropriate times\n - Tests in Netavark repository to verify this functionality\n- Recommended Skills:\n - Rust\n - Some C knowledge preferred\n - Basic networking - knowledge of IP addresses, ports, etc\n- Mentor(s):\n - Matthew Heon (@mheon, mheon@redhat.com) - primary\n - Paul Holzinger (@Luap99, pholzing@redhat.com)\n- Upstream Issue (URL):\n [containers/netavark#1045](https://github.com/containers/netavark/issues/1045)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/07efb861-3c5b-4bc2-9986-593656750ffc\n\n### Kube State Metrics\n\n#### Automate the release process\n\n- Description: Build upon the stale patches that aim to automate the release process for Kube State Metrics. This project will focus on implementing a fully automated release pipeline that includes steps outlined in the subproject's [RELEASE.md](https://github.com/kubernetes/kube-state-metrics/blob/main/RELEASE.md). The mentee will work on integrating these features into the existing CI/CD workflow, ensuring that releases are consistent, reliable, and easy to manage.\n- Expected Outcome: A fully automated release process for Kube State Metrics, including versioning, changelog generation, and artifact creation (through k8s.io).\n- Recommended Skills: Familiarity with CI/CD pipelines, basic scripting skills, understanding of versioning and changelog best practices, experience with GitHub Actions or similar CI/CD tools.\n- Mentor(s):\n - Pranshu Srivastava (@rexagod, rexagod@gmail.com)\n - Manuel Rüger (@mrueg, manuel@rueg.eu)\n- Upstream Issue: https://github.com/kubernetes/kube-state-metrics/issues/2711\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6f4f89b9-16e8-4cd5-933e-5478c32c448f\n\n### CloudNativePG\n\n#### Rebuilding CloudNativePG Documentation for Multi-Version Support with Docusaurus\n\n- Description: The current documentation of CloudNativePG (a Kubernetes-native\n Postgres operator) is statically built using `mkdocs` from Markdown sources,\n which must live with the rest of the source code as they are part of it. We\n want to modernise this process and introduce multi-version support, helping\n users find accurate information for the version they are running in production.\n This project aims to rebuild the documentation site using Docusaurus\n (preferred) or an equivalent static site generator to enable multi-version\n documentation and version selection. Additionally, any initiatives that improve\n content structure, navigation, searchability, and clarity are welcome, provided\n they enhance logical flow and maintainability while aligning with CNCF and user\n expectations. The documentation is hosted on GitHub Pages under the\n CloudNativePG website domain.\n\n- Expected Outcome:\n\n - Incremental set of pull requests (PRs) with:\n\n - Site built with Docusaurus (or equivalent) with version selector working.\n - Content restructured for clarity and easier navigation.\n - Clean, consistent navigation structure and enhanced search capabilities.\n - Staging website capabilities.\n - Deployment workflow to GitHub Pages using Dagger and GitHub Actions.\n\n - A clear contributor guide explaining how maintainers can add or update\n documentation for each version in the future.\n\n- Recommended Skills:\n\n - Markdown\n - Git and GitHub workflows\n - Static site generators (preferably Docusaurus, Hugo, or MkDocs)\n - Basic YAML/TOML configuration\n - Familiarity with Kubernetes, PostgreSQL and CloudNativePG\n\n- Mentor(s):\n - Gabriele Bartolini (@gbartolini, gabriele.bartolini@enterprisedb.com)\n - Francesco Canovai (@fcanovai, francesco.canovai@enterprisedb.com)\n - Leonardo Cecchi (@leonardoce, leonardo.cecchi@enterprisedb.com)\n\n- Upstream Issue: https://github.com/cloudnative-pg/cloudnative-pg/issues/8122\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/86a647c1-88c7-474f-b093-6abb58197083\n\n#### Chaos Testing\n\n- Description: We want to expand the scope of the CloudNativePG tests,\n introducing a full-fledged chaos testing framework that can be\n used to better validate the resilience, fault tolerance and recovery\n mechanisms of CloudNativePG.\n\n- Expected Outcome:\n - Selection of a Kubernetes-native chaos testing framework (e.g., LitmusChaos or Chaos Mesh).\n - Design and automation of an initial set of chaos experiments covering common failure scenarios.\n - Integration of these experiments into CI/CD to ensure reproducible testing.\n - Collection of clear observability metrics (e.g., failover time, data consistency) to assess resilience and recovery.\n - Documentation and guidelines to help contributors create and run new chaos experiments safely.\n\n\n- Recommended Skills:\n\n - Experience with chaos testing frameworks (preferably LitmusChaos or Chaos Mesh).\n - Familiarity with Kubernetes, PostgreSQL, and CloudNativePG.\n - Understanding of observability tools such as Prometheus or Grafana.\n\n- Mentors:\n - Gabriele Bartolini (@gbartolini, gabriele.bartolini@enterprisedb.com)\n - Francesco Canovai (@fcanovai, francesco.canovai@enterprisedb.com)\n - Jonathan Gonzalez (@sxd, jonathan.gonzalez@enterprisedb.com)\n - Marco Nenciarini (@mnencia, marco.nenciarini@enterprisedb.com)\n\n- Upstream issue: https://github.com/cloudnative-pg/cloudnative-pg/issues/8174\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0858ce07-0c90-47fa-a1a0-95c6762f00ff\n\n#### Refresh cnpg-i-hello-world to align with the current state of CNPG-I\n\n- Description: The cnpg-i-hello-world project was created to help developers get\n started with building plugins for CloudNativePG using the CNPG-I framework.\n However, the project is now outdated and requires significant maintenance and\n updates to reflect the current capabilities of CNPG-I. The goal is to bring it\n in line with the latest state of the interface and ensure it serves as a solid\n reference for:\n\n - Understanding how to use CNPG-I\n - Developing and prototyping new plugins\n\n- Expected Outcome:\n - Review and update the codebase to match the latest CNPG-I interface and conventions\n - Ensure it follows the latest best practices for plugin development\n - Expand and improve examples as needed\n - Integrate CNPG-I documentation where appropriate to provide better guidance for developers\n\n- Recommended Skills:\n - Go programming\n - Kubernetes\n - CloudNativePG\n\n- Mentors:\n - Gabriele Bartolini (@gbartolini, gabriele.bartolini@enterprisedb.com)\n - Armando Ruocco (@armru, armando.ruocco@enterprisedb.com)\n - Leonardo Cecchi (@leonardoce, leonardo.cecchi@enterprisedb.com)\n - Marco Nenciarini (@mnencia, marco.nenciarini@enterprisedb.com)\n\n- Upstream issue: https://github.com/cloudnative-pg/cnpg-i-hello-world/issues/183\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cabc7391-4956-42b2-b91c-d261816b7289\n\n### KubeArmor\n\n#### KubeArmor Observability Spectrum Enhancement\n\n- Description: This project focuses on improving KubeArmor's observability by integrating key Prometheus metrics. The goal is to offer simple explanations for security policy enforcement and alerting within Kubernetes clusters. \n- Key Metrics to Focus On:\n - Number of Policies Applied \n - Number of Alerts Triggered \n - List of Active Policies \n - Policy Status (Active/Inactive) \n- Expected Outcome: Successful integration of these Prometheus metrics, making them accessible via a Prometheus endpoint and adhering to best practices for metric exposition. \n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/1902 \n- Associated Repository: https://github.com/kubearmor/kubearmor-prometheus-exporter\n\nMentors:\n - Rishabh Soni (@rootxrishabh, risrock02@gmail.com) \n - Aryan Sharma (@Aryan-sharma11, aryan1126.sharma@gmail.com) \n - Ramakant Sharma (@rksharma95, ramakant@accuknox.com) \n - Barun Acharya (@daemon1024, barun1024@gmail.com) \n\nRecommended Skills:** Go, Prometheus, Kubernetes, Git\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ca9220f2-1d8d-4977-80fd-068a6f756cc6\n\n#### KubeArmor Unit Test Coverage Audit\n- Description: This project aims to systematically analyze and substantially improve KubeArmor's unit test coverage. It involves identifying untested code paths, designing and implementing new unit tests for crucial modules, and establishing a robust testing framework to boost code quality. \n- Goals:\n - Measure Coverage: Accurately measure and report current unit test coverage for all Go packages. \n - Prioritized Test Implementation: Write new unit tests, prioritizing core modules like core, monitor, enforcer, log, and feeder, and addressing other packages with no test files. \n - Identify Untested Components: Pinpoint major untested functionalities and propose specific test scenarios. \n - Achieve Measurable Improvement: Submit pull requests that significantly increase overall unit test coverage. \n- Expected Outcome: A detailed coverage report, a suite of new, effective unit tests, and a measurable improvement in test coverage, leading to enhanced code quality and reliability. \n- Upstream Issue: https://github.com/kubearmor/KubeArmor/issues/2130 \n- Associated Repository: https://github.com/kubearmor/KubeArmor \n- Testing Guide Reference: https://github.com/kubearmor/KubeArmor/blob/main/contribution/testing_guide.md \n\nRecommended Skills: Go, Kubernetes, Testing Methodologies (unit testing, mocking), Git. \n \nMentors:\n - Rishabh Soni (@rootxrishabh, risrock02@gmail.com) \n - Aryan Sharma (@Aryan-sharma11, aryan1126.sharma@gmail.com) \n - Ramakant Sharma (@rksharma95, ramakant@accuknox.com) \n - Nishant Singh (@tesla59, talktonishantsingh.ns@gmail.com) \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c0ae5caa-3c82-4b4a-8890-703278ca7fda\n\n### Cartography\n\n#### IAM Whatever You Say IAM - GCP and Azure edition\n\nImplement Resource Permission Relationships for GCP and Azure\n\n- Description:\nWant to be a cloud hacker?\n\nIn the cloud, answering the question \"who has access to what\" is surprisingly complex: we need to know what identities exist, what permission policies and controls apply to them, what resources (storage, compute, networking) exist, what permissions apply to those, and we need to tie those together. [Cartography](https://github.com/cartography-cncf/cartography) is an ambitious open source project that aims to do just that.\n\nIn this project, our goal is to model and map cloud IAM relationships in GCP and Azure so users can answer “who can access what resources” across multi-cloud environments.\n\nWe previously did this in AWS as seen in [“IAM: Whatever You Say I Am”](https://eng.lyft.com/iam-whatever-you-say-iam-febce59d1e3b), and we would love to complete our coverage of this across the major cloud providers.\n\n- Expected Outcome:\n - Design and implement support for evaluating permission objects in GCP and Azure to draw paths such as `(:GCPUser)-[:CAN_READ]->(:GCPBucket)` or `(:AzureServicePrincipal)-[:CAN_READ]->(:StorageAccount)`.\n - Bonus: opportunity to author or co-author a blog post or video demo\n\n- Recommended Skills:\n - Python\n - Ability to handle feedback gracefully is required\n - Familiarity with cloud security permissions and interest in information security strongly preferred\n - Familiarity with cloud IAM (GCP or Azure or AWS)\n - Strong written and verbal communication skills in English required\n - Basic Neo4j/Cypher knowledge a plus but not necessary\n\n- Mentor(s):\n - Alex Chantavy (@achantavy, chantavy@gmail.com)\n - Kunaal Sikka (@kunaals, kunaal@subimage.io)\n\n- Upstream Issues:\n - https://github.com/cartography-cncf/cartography/issues/1734\n - https://github.com/cartography-cncf/cartography/issues/1735\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/28c3d20f-2bb6-42d1-93b5-45bdb33c72bf\n\n#### Make map of Azure and Google Compute Cloud resources\n\nVibe-code your way to making the world's most complete infra map.\n\n- Description:\n[Cartography](https://github.com/cartography-cncf/cartography) makes maps of the cloud so that security and devops teams can find and fix problems. Think about it like the [Maurauder's Map](https://simple.wikipedia.org/wiki/Marauder%27s_Map) from Harry Potter.\n\nCartography has very good AWS coverage, but lacks support for many Azure and GCP resources. With your help, we can fix this! Companies around the world use Cartography to better understand their infra, and you can be a part of this. Most of these modules should be conducive to coding with agents (we have a well-documented [AGENTS.md](https://github.com/cartography-cncf/cartography/blob/master/AGENTS.md)!), so if you enjoy writing in Python, want to learn about information security/devops, and moving fast, this is the project for you.\n\n- Expected Outcome:\n - Design and implement graph schemas for missing Azure and AWS objects in Cartography\n\n- Mentor(s):\n - Alex Chantavy (@achantavy, chantavy@gmail.com)\n - Kunaal Sikka (@kunaals, kunaal@subimage.io)\n\n- Recommended Skills:\n - Python\n - Ability to handle feedback gracefully is required\n - Strong written and verbal communication skills in English required\n - Interest in cloud security or devops is a plus\n - Basic Neo4j/Cypher knowledge a plus but not necessary\n - Familiarity with LLM-based coding tools is a plus but not necessary\n\nUpstream issues\n- https://github.com/cartography-cncf/cartography/issues/1736\n- https://github.com/cartography-cncf/cartography/issues/415\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6e60c1da-b78a-40c5-b527-613c00375e72\n\n### KubeSlice\n\n#### Implement Dynamic IPAM for the Slice Overlay Network\n\n- Description: In the current KubeSlice design, IP address management (IPAM) for slice overlay networks is static and inefficient. A predefined CIDR block (e.g., 10.1.0.0/16) is divided into a fixed number of subnets regardless of how many clusters participate in the slice, leading to significant IP space wastage. \n This project aims to implement a dynamic IPAM system that allocates IP subnets to clusters on demand and reclaims unused ranges when clusters leave the slice. It will ensure efficient address utilization, synchronization across clusters, and integration with the KubeSlice control plane.\n\n- Expected Outcome:\n - A dynamic IPAM allocator integrated with the KubeSlice controller or sidecar component.\n - Support for on-demand IP allocation and subnet reclamation when clusters join or leave a slice.\n - Conflict resolution and state synchronization across clusters using CRDs or distributed storage.\n - Documentation on how the system works, configuration options, and edge case behaviour.\n\n- Recommended Skills: \n Go (Golang), Kubernetes controllers and CRDs, IPAM concepts, networking (CIDRs, subnets).\n\n- Mentor(s):\n - Gourish Biradar (@gourishbiradar, biradar.gourish@gmail.com)\n - Rahul Kumar (@Rahul-D78, rahulparida933@gmail.com)\n - Prabhu Navali (@pnavali, prabhu@aveshasystems.com)\n\n- Upstream Issue: https://github.com/kubeslice/kubeslice-controller/issues/252\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6123c24e-41ce-4335-88d1-dbd0f72e3631\n\n#### Implement Custom Topology Definition for a Slice\n\n- Description: KubeSlice currently uses a full-mesh topology for the slice overlay network, where every cluster connects to every other cluster in the slice. This results in unnecessary tunnel creation and resource consumption. \n This project proposes a topology-aware design, allowing users to define custom connectivity matrices for slices. Users can specify partial meshes. Additionally, the project will support configuring each cluster's VPN deployment type (client/server) to accommodate network constraints such as firewalls or NAT.\n\n- Expected Outcome:\n - Extension of the Slice CRD to support custom topology and VPN role definitions.\n - Logic to establish tunnels based only on the defined connectivity matrix.\n - Support for various deployment topologies (full-mesh, partial mesh, hub-spoke).\n - Sample configurations and documentation on how to define and validate topologies.\n\n- Recommended Skills: \n Go (Golang), Kubernetes CRDs and controllers, VPN networking concepts (client/server), overlay networking.\n\n- Mentor(s):\n - Gourish Biradar (@gourishbiradar, biradar.gourish@gmail.com)\n - Rahul Kumar (@Rahul-D78, rahulparida933@gmail.com)\n - Prabhu Navali (@pnavali, prabhu@aveshasystems.com)\n\n- Upstream Issue: https://github.com/kubeslice/kubeslice-controller/issues/253\n\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/db7a4bc3-3489-4ca9-9d6a-13f27fbee7fc\n \n#### Implement Comprehensive Unit & Integration Testing for kubeslice-cli\n\n- Description: The kubeslice-cli repository currently lacks comprehensive unit and integration tests making it hard to test the changes. This project aims to implement a robust testing framework to ensure the reliability and stability of the CLI tool. The Mentee will write unit tests for existing functions & integration tests for the CLI commands & also set up a continuous integration pipeline to run these tests automatically on every commit and pull request.\n- Expected Outcome:\n - A fully configured testing framework for kubeslice-cli with unit and integration tests covering all critical functionalities.\n - A CI/CD pipeline configuration (e.g., GitHub Actions) that automatically runs the tests on every pull request.\n - Documentation on how to run these tests & add new ones.\n- Recommended Skills: Go (Golang), Go testing frameworks (testify), Kubernetes, CLI, CI/CD (GitHub Actions).\n- Mentor(s):\n - Gourish Biradar (@gourishbiradar, biradar.gourish@gmail.com)\n - Rahul Kumar (@Rahul-D78, rahulparida933@gmail.com)\n - Prabhu Navali (@pnavali, prabhu@aveshasystems.com)\n- Upstream Issue: https://github.com/kubeslice/kubeslice-cli/issues/46\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/617cbe05-da5f-4955-8745-28cce769d511\n\n#### Enhance and Automate End-to-End (E2E) Testing Across the KubeSlice Ecosystem\n\n- Description: The KubeSlice project consists of multiple repositories that work together to provide application connectivity and network services across Kubernetes clusters. Currently, our E2E tests are outdated and need significant improvement. This project aims to automate the E2E testing process by improving the current test suite and implementing new tests where necessary. This will ensure that the entire KubeSlice ecosystem works seamlessly together.\n- Expected Outcome:\n - A comprehensive set of E2E tests covering all critical functionalities of KubeSlice.\n - Integration of the E2E tests into the CI/CD pipeline to run automatically.\n - Clear Documentation for running & extending the E2E tests.\n- Recommended Skills: Go (Golang), Kubernetes, E2E testing (kind, Ginkgo), CI/CD (GitHub Actions).\n- Mentor(s):\n - Gourish Biradar (@gourishbiradar, biradar.gourish@gmail.com)\n - Rahul Kumar (@Rahul-D78, rahulparida933@gmail.com)\n - Prabhu Navali (@pnavali, prabhu@aveshasystems.com)\n- Upstream Issue: https://github.com/kubeslice/kubeslice/issues/56\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/999f25bb-988c-48d5-a547-f353f8bcdf0d\n\n### OpenKruise\n\n#### SidecarSet support setting sidecar resources adaptively \n\n- Description: SidecarSet is an advance workload for sidecar container injection and upgrade. Currently the sidecar container resource must be set explicitely in the sidecar template, however in the cases of traffic proxy, log collection and device emulation etc, it is desirable to to set the resources according to resource of app container. The goal is to support the adaptively setting for sidecar resources and provide best practice for typical use cases.\n- Expected Outcome\n - implementation for adaptively resources setting for sidecar in SidecarSet workload\n - unit and integration tests \n - documentation for the function usage and typical use cases in the OpenKruise website\n- Recommended Skills: Golang, kubernetes operator development\n- Mentors\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n- Upstream Issue: https://github.com/openkruise/kruise/issues/2123\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6226f066-2de6-4417-b985-6cbcab6163d8\n\n#### Promote kruise api version from v1alphal1 to v1beta1\n\n- Description: Many advance workloads in OpenKruise are widely used in production, however the API version of the workload is still in v1alpha1. The goal is to promote the API version of mostly used and mature workload to v1beta1 and optimize the CRD fields for better clarity. \n- Expected Outcome\n - API definition of v1beta1 resources and the implementation for conversion webhook to convert v1alpha1 resource to v1beta1 resource\n - unit and integration tests\n - documentation for the usage of v1beta1 resource in the OpenKruise website\n- Recommended Skills: Golang, kubernetes operator development\n- Mentors\n - Zhang Zhen (@furykerry, furykerry@gmail.com)\n- Upstream Issue: https://github.com/openkruise/kruise/issues/2122\n\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7426f5d7-1879-46cc-a933-880ee790d0eb\n\n#### Bring progressive delivery capability for native kubernetes DaemonSet\n\n- Description: OpenKruise Rollout already support the progressive delivery of OpenKruise advance DaemonSet, however switching workload is not an option for many users. The goal is to utilize the `OnDelete` updateStrategy of native kubernetes workload, and trigger the pod upgrade by deleting desired number of pods per Rollout specification. \n- Expected Outcome\n - implentation of progressive delivery for native kubernetes daemonset, and only basic multi-batch release is required. \n - unit and integration test \n - documentation for the function usage and typical use cases in the OpenKruise website\n- Recommended Skills: Golang, kubernetes operator development\n- Mentors\n - Zhong Tianyun (@AiRanthem, airanthem666@gmail.com)\n- Upstream Issue: https://github.com/openkruise/rollouts/issues/297\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f8a528a7-4473-4ce5-8cb5-9b6e412d93b0\n\n#### Enhance Robustness and Usability of Kruise-Game\n\n- Description: kruise-game is being used by many game companies. It is imperative to build the stability of kruise-game components. With the rapid iteration of project functions, the current test coverage has not met expectations, so we need to add more UT and E2E use cases to ensure that there will be no problems with our basic functions. In addition, in a large-scale cluster environment, kruise-game also needs more indicators to reveal the performance of the current controller.\n- Expected Outcome: \n - Expand End-to-End (E2E) Test Coverage\n - Improve Unit Test (UT) Coverage\n - Enhance Observability via Controller Metrics\n - Improve Logging Contextualization\n- Recommended Skills: Golang, Kubernetes\n- Mentor:\n - Qiuyang Liu (@chrisliu1995, [chrisliu1995@163.com](mailto:chrisliu1995@163.com))\n - Zhongwei Liu (@ringtail, [zhongwei.lzw@alibaba-inc.com](mailto:zhongwei.lzw@alibaba-inc.com))\n- Upstream Issue: https://github.com/openkruise/kruise-game/issues/266\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2994906f-deff-4539-bf6d-e767b5cfcc31\n\n### Kmesh\n\n#### Improving Ipsec's Stability and Ease of Use\n\n- Description:\n Communication encryption is an important functional feature of the Service Mesh to ensure communication security. Kmesh uses IPsec to implement this feature. However, Kmesh lacks the reliability maintenance and ease of use enhancements for Kmesh. Therefore, we should optimize the reliability and ease of use of IPsec in addition to its implementation.\n- Expected Outcome:\n - Reduce IPsec configuration steps according to users' actual usage scenarios. It is best to realize one-click configuration for users.\n - Sorting out Ipsec code and refactoring where it affects stability and performance.\n - UT overlay with enhanced IPSec features\n- Recommended Skills:\n - Golang\n - Some C knowledge about eBPF and IPsec\n - Basic networking knowledge\n- Metor(s):\n - ZhenCheng Li(@LiZhenCheng9527, leezhencheng6@gmail.com),\n - Zhonghu Xu(@hzxuzhonghu, zhhxu@163@gmail.com)\n- Upstream Issue: https://github.com/kmesh-net/kmesh/issues/1457\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a72ca16e-c309-45b3-a2fe-40bdd5e8e754\n\n#### Kmesh Orion replace waypopint\n\n- Description:\n Kmesh, as a high-performance service mesh data plane, does have a performance advantage when compared to other service mesh data planes. However, in high-concurrency scenarios with application-layer protocols such as HTTP, it is held back by the waypoint. Therefore, we developed Orion to replace the waypoint. However, there is still some adaptive functionality development and testing that needs to be done before we can replace it.\n- Expected Outcomes:\n - Testing of Orion's key functions for waypoints such as communication with control surfaces, authorization policy, etc.\n - If there is missing functionality, it needs to be adapted and supplemented.\n - Provides a way to install Orion via Kmeshctl.\n- Recommended Skills:\n - Rust\n - Basic service mesh knowledge\n- Metor(s):\n - Zengzeng Yao(@yaozengzeng, yaozengzeng@huawei.com)\n - Zhonghu Xu(@hzxuzhonghu, zhhxu@163@gmail.com)\n- Upstream Issue: https://github.com/kmesh-net/kmesh/issues/1450\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/532690f7-802d-488e-a5e6-2e4ba532d189\n\n### Kyverno\n\n##### Convert Kyverno Sample Policies to Use New CEL-Based Policy Types\n\n- Description: Kyverno has introduced new CEL-based policy types in the `v1alpha1` API version that provide enhanced expressiveness, better performance, and native Kubernetes integration. These new policy types include ValidatingPolicy, MutatingPolicy, ImageValidatingPolicy, GeneratingPolicy, and DeletingPolicy. The goal of this project is to convert existing sample policies from the traditional Kyverno policy format to the new CEL-based format, ensuring they maintain the same functionality while leveraging the benefits of the new API.\n- Expected Outcome:\n - Convert existing sample policies from traditional Kyverno format to new CEL-based policy types\n - Ensure functional equivalence between old and new policy formats\n - Write tests to validate the conversions and ensure reliability\n - Help users understand how to migrate from traditional policies to CEL-based format\n- Recommended Skills:\n - Go programming language\n - Kubernetes API and admission controllers\n - CEL (Common Expression Language)\n - YAML/JSON configuration\n - Testing and documentation\n- Mentors:\n - Mariam Fahmy (@MariamFahmy98, mariam.fahmy@nirmata.com)\n - Shuting Zhao (@realshuting, shuting@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/13709\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ae18aaf2-374a-4657-8294-a0066b9a11bd\n\n##### Support Namespaced CEL-Based Policies\n\n- Description: Kyverno currently supports cluster-wide CEL-based policy types (ValidatingPolicy, MutatingPolicy, ImageValidatingPolicy, GeneratingPolicy, and DeletingPolicy), but lacks namespaced versions. This creates challenges for namespace owners who need to manage policies within their namespaces without requiring cluster-wide permissions. The goal of this project is to implement namespaced versions of all five CEL-based policy types to provide better RBAC control, security, and lifecycle management for namespace-scoped policy management.\n- Expected Outcome:\n - Implement namespaced versions of all five CEL-based policy types:\n - Ensure proper RBAC integration for namespace-scoped policy management\n - Create comprehensive documentation and examples for namespaced policies\n - Write tests to validate namespaced policy functionality\n- Recommended Skills:\n - Go programming language\n - Kubernetes API and admission controllers\n - CEL (Common Expression Language)\n - Kubernetes RBAC and security models\n - YAML/JSON configuration\n - Testing and documentation\n- Mentors:\n - Charles-Edouard Brétéché (@eddycharly, charled.breteche@gmail.com)\n - Frank Jogeleit (@fjogeleit, frank.jogeleit@nirmata.com)\n - Yugandhar (@yrsuthari, ysuthari@gmail.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/13185\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6ad81eb7-295b-4ec8-b9b4-db20e1f3a346\n\n#### Enhance Kyverno Documentation\n\n- Description: Kyverno has evolved significantly with the introduction of new CEL-based policy types in the `v1alpha1` API version. The current documentation and website need to be updated to reflect these advancements and position Kyverno appropriately in the policy engine landscape. This project aims to enhance Kyverno's documentation, website content, and overall positioning to showcase the new capabilities while maintaining clear guidance for users transitioning from traditional policies to CEL-based formats.\n- Expected Outcome:\n - Update and enhance Kyverno's website to reflect new CEL-based policy capabilities\n - Ensure comprehensive documentation for all new policy types\n - Update Kyverno's positioning in the policy engine ecosystem\n - Update comparison charts and feature matrices\n - Enhance user experience with better navigation and search functionality\n - Update API reference documentation with new policy types\n- Recommended Skills\n - Technical writing and documentation\n - Kubernetes and policy engine knowledge\n - CEL (Common Expression Language) understanding\n - Markdown and documentation tools\n- Mentors:\n - Cortney Nickerson (@CortNick, cortney.nickerson@nirmata.com)\n - Luc Chmielowski (@lucchmielowski, luc.chmielowski@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/13710\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6efc64ce-3fd5-4489-b4c0-846f661ecb6b\n\n#### kube-burner\n\n##### Enhancements around k8s performance testing\n\n- Description:\n We intend to get some help around open issues in the repository and also come up with new use cases and scenarios for performance testing any kubernetes distribution. We love new perspectives and are always open to new ideas alongside what we have as tracked work in github issues.\n- Expected Outcome:\n To knock down some of open critical issues and bring in new perspective to the project. There are no restrictions while working with issues/enhancements.\n- Recommended Skills:\n - Golang\n - Kubernetes\n - Cloud Platforms\n- Mentor(s):\n - Vishnu Challa (@vishnuchalla, vchalla@redhat.com) \n - Raul Sevilla (@rsevilla87, rsevilla@redhat.com)\n- Upstream Issues: (https://github.com/kube-burner/kube-burner/issues)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/bafc9296-3069-432e-b1fc-600b7a6ad590\n\n### kgateway\n\n#### Improve kgateway ecosystem integrations documentation \n:\n- Description:\nThis project aims to create clear, approachable documentation and blog posts that showcase how to integrate kgateway with key CNCF projects such as Argo, Istio, and KServe. These resources will make it easier for users to adopt kgateway in modern cloud-native environments and promote deeper integration across the CNCF ecosystem.\n\n- Expected Outcome:\n- A series of integration guides and tutorials for using kgateway with Argo Rollouts, Istio, and KServe.\n- Contribution of relevant improvements or examples back to the kgateway documentation site\n- Raised issues for any gaps or friction points discovered during testing\n- Demo integrations during kgateway community meetings\n- Fun!\n\n- Recommended Skills:\n- Strong written communication skills\n- Interest in learning and exploring new projects! \n- Basic understanding of GitHub, Markdown, and technical blogging \n- (Bonus) Experience using any of the following: Argo, Istio, KServe\n\n- Mentors: \nNina Polshakova (npolshakova)\nLin Sun (linsun)\n\n- Upstream Issue: \n https://github.com/kgateway-dev/kgateway.dev/issues/327 \n\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1badb86d-1aa1-4879-9399-3bb459f2aa0e\n\n#### kgateway, agentgateway, and observability improvements\n\n- Description:\nThis project focuses on enhancing observability in kgateway’s agentgateway integration by adding support for OpenTelemetry-based tracing, exposing Prometheus-compatible metrics, and configuring access logging. It builds on a previous LFX project that introduced tracing support for kgateway’s AI extproc server, extending those capabilities to support span propagation from agentgateway. \n\nIn addition to adding support for configuring the kgateway control plane to set agentgateway’s tracing configuration, we want to test exporting traces to OpenTelemetry-compatible backends such as the OpenTelemetry Collector and Jaeger, and create user-facing documentation for these integrations. \n\nBeyond emitting basic spans, this project will also document how to enrich traces with authenticated user context derived from RBAC decisions, enabling more fine-grained debugging and attribution.\n\n- Expected Outcome:\n - Translate the existing tracing and access logging APIs in kgateway to enable configuring tracing for the kgateway’s agentgateway integration\n - Create end-to-end (e2e) tests to validate configuration and trace propagation\n - Raise issues for any gaps or friction points discovered during testing\n - Write documentation for plugin developers and end users\n - Writing user-facing documentation and blogs on Otel tracing with agentgateway and kgateway integration with OpenTelemetry-compatible backends\n - Gain hands-on experience with AI providers, OpenTelemetry, tracing platforms, MCP, a2a, Kubernetes, and kgateway while building real observability features!\n - Fun! \n\n- Recommended Skills:\n - Golang\n - Rust\n - Otel\n - Kubernetes\n - Kubernetes Gateway API\n - (Bonus) Familiarity with MCP and/or A2A \n\n- Mentor(s):\nNina Polshakova (npolshakova)\nJoe McGuire (jmcguire98)\n\n- Upstream Issue: https://github.com/kgateway-dev/kgateway/issues/11818 \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0a9d8439-6c3b-49f6-8167-503f05161b43\n\n### Karmada\n\n#### Support TFJob and PyTorchJob in Karmada via Default Resource Interpreters\n\n- Description: Implement default resource interpreters for TFJob and PyTorchJob workloads in Karmada.\n- Expected Outcome: This includes writing the interpreter logic in Golang and Lua, ensuring proper scheduling and propagation of these workloads across member clusters. Additionally, create documentation on how to run TFJob and PyTorchJob on Karmada, and introduce the integration and best practices to the Kubeflow community.\n- Recommended Skills: Golang, Lua, Basic understanding of Karmada, Familiarity with TFJob Job and PyTorchJob workloads.\n- Mentors\n - Yiheng Ci (@lfbear, lfbear@gmail.com)\n - Hongcai Ren (@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/6586\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5b276804-9268-44c8-b339-1699c04397eb\n\n#### Support TrainJob and SparkApplication in Karmada via Default Resource Interpreters\n\n- Description: Develop default resource interpreters for TrainJob and SparkApplication workloads in Karmada.\n- Expected Outcome: The task involves implementing interpreter logic, validating scheduling/propagation, and documenting the process of running these workloads on Karmada. Share the practice and integration details with the Kubeflow and Spark communities.\n- Recommended Skills: Golang, Lua, Basic understanding of Karmada, Familiarity with TrainJob Job and SparkApplication workloads.\n- Mentors\n - Zhuang Zhang (@zhzhuang-zju, m17799853869@163.com)\n - Hongcai Ren (@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/6587\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/10cff3a7-3993-450f-a385-ebbcbf923805\n\n#### Support RayCluster and RayJob in Karmada via Default Resource Interpreters\n\n- Description: Implement default resource interpreters for RayCluster and RayJob workloads in Karmada.\n- Expected Outcome: This includes interpreter development, validation, and comprehensive documentation on deploying and managing Ray workloads with Karmada. Present the integration and usage guide to the KubeRay community.\n- Recommended Skills: Golang, Lua, Basic understanding of Karmada, Familiarity with RayCluster Job and RayJob workloads.\n- Mentors\n - Junhua He (@whitewindmills, jayfantasyhjh@gmail.com)\n - Hongcai Ren (@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/6588\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cf5e8dff-48ec-4ce6-ad92-cfb963f2d6b1\n\n#### Support Volcano Job and Notebook in Karmada via Default Resource Interpreters\n\n- Description: Implement default resource interpreters for Volcano Job and Notebook workloads in Karmada.\n- Expected Outcome: This includes developing interpreter logic in Golang and Lua, ensuring correct scheduling and propagation of these workloads across member clusters. Additionally, create documentation on how to run Volcano Job and Notebook on Karmada, and introduce the integration and best practices to the Volcano and Kubeflow communities.\n- Recommended Skills: Golang, Lua, Basic understanding of Karmada, Familiarity with Volcano Job and Notebook workloads.\n- Mentors\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n - Hongcai Ren (@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/karmada/issues/6589\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1419023b-5f92-49af-a550-8cc25dc85290\n\n### KubeEdge \n\n#### Deep integration of KubeEdge with AMD edge nodes\n\n- Description: AMD chips, with their powerful x86 architecture, exceptional computing performance, and advanced NPUs, demonstrate significant potential in fields such as industrial automation, in-vehicle systems, and high-performance edge computing. Introducing AMD's robust general-purpose and heterogeneous computing capabilities into the KubeEdge ecosystem is crucial for handling increasingly complex and latency-sensitive edge AI applications.However, the deep integration, performance optimization, and best practices between KubeEdge and AMD's high-performance edge platforms—particularly their built-in NPUs and other hardware acceleration units—still require systematic exploration and validation. This project aims to establish a complete link between KubeEdge and AMD edge nodes, building a comprehensive edge computing solution from hardware deployment to NPU acceleration, thereby greatly enriching KubeEdge's hardware ecosystem.\n- Expected Outcome: \n - Debug and support KubeEdge edge nodes running on AMD chips\n - Successfully deploying and managing edge application Pods on AMD-based edge nodes\n - Scheduling and managing AMD NPU resources through KubeEdge to achieve performance acceleration for edge AI inference applications.\n - Implement monitoring and metric collection for nodes, applications, and NPUs\n - Using KubeEdge to achieve the complete platform setup, configuration, and management from the cloud to AMD edge nodes\n - Complete hardware compatibility testing and produce high-quality technical documentation or blogs\n- Recommended Skills: Go, Kubernetes, KubeEdge, Linux, Hardware Integration, AI/ML\n- Mentors:\n - Hongbing Zhang (@HongbingZhang, hongbing.zhang@daocloud.io)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6429 \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/15043686-0866-4d5a-9016-3a6cbfd448fc\n\n#### Industrial Embodied Intelligence Benchmarking Dataset for KubeEdge-Ianvs\n\n- Description: As industrial manufacturing accelerates its digital transformation through advancements in robotics, adaptive production lines, and smart testing systems, cloud-edge collaboration has emerged as a critical enabler for deploying embodied intelligence in complex operational environments. Contemporary industry requirements for embodied intelligence now extend beyond basic task execution to encompass multimodal perception and decision integration, dynamic environment adaptation, and distributed device orchestration. Existing benchmarking frameworks exhibit limitations in evaluating scenario-specific embodied attributes inherent to industrial settings. This initiative leverages the KubeEdge-Ianvs collaborative AI framework, integrating domain-specific test datasets, simulation environments, and quantitative metrics to establish a certified industrial-grade evaluation infrastructure for embodied intelligence systems.\n- Expected Outcome:\n - Develop an industrial-grade embodied intelligence dataset through systematic classification and reorganization of existing resources/ examples\n - Deploy baseline algorithms and introduce metrics to establish performance benchmarks within KubeEdge-Ianvs\n- Recommended Skills: Python, Benchmark, Dataset, Embodied Intelligence\n- Mentors:\n - Zimu Zheng (@MooreZheng, zimu.zheng@huawei.com)\n - Mengzhuo Chen (@IcyFeather233, icyfeather@foxmail.com)\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/197\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c066ac53-5435-4057-a84c-0e0be62e8b65\n\n#### Comprehensive Example Restoration for KubeEdge Ianvs\n\n- Description: Ianvs serves as KubeEdge SIG AI distributed benchmark toolkit. As more and more contributors running, KubeEdge Ianvs now has 25 examples and the number is still increasing. KubeEdge Ianvs then faces mounting usability issues due to dependency evolution and validation mechanisms. As Python versions, third-party libraries, and Ianvs features advance, partial historical examples fail to execute. This has led to surging user-reported Issues from confused contributors, untested PRs breaking core functionality of legacy features, severely outdated documentation misaligning with actual capabilities. Without systematic intervention, the example risks becoming obsolete for edge-AI developers and especially newcomers. We then try to resurrect Ianvs’ usability with comprehensive example restoration.\n- Expected Outcome:\n - Diagnose & fix bugs across examples, including dependency manifests, license scan and runtime configurations.\n - Documentation Modernization, including revamp tutorials with reproducible step-by-step guides, publish developer-focused debugging playbooks for common failures\n - Build a CI pipeline testing examples with GitHub Actions against multiple Python versions, critical Ianvs/upstream updates and block PRs that break validated examples\n- Recommended Skills: Python, Benchmark, KubeEdge-Ianvs, AI/ML\n- Mentors:\n - Zimu Zheng (@MooreZheng, zimu.zheng@huawei.com)\n - Shijing Hu (@hsj576, sjhu21@m.fudan.edu.cn)\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/230\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/82d71e63-2e1e-48d6-8c93-91c9e8bf8d5d\n\n#### Research on Deploying Small Language Models with KubeEdge and Integrating with Enterprise AI Platforms\n\n- Description: KubeEdge, as a native edge computing platform built on the Kubernetes ecosystem, offers capabilities such as reliable cloud-edge communication, edge autonomy, and IoT device integration. However, its ability to support intelligent model execution at the edge has yet to be systematically validated and practiced in real-world scenarios. This research aims to explore the feasibility and performance of deploying and running small language models on edge nodes using KubeEdge\n- Expected Outcome:\n - Verification of KubeEdge's model deployment capability at the edge. Deployment and testing of model engines such as vLLM and llama.cpp on edge nodes, along with providing practical examples and detailed documentation for deploying small language models.\n - Exploration of integration schemes between KubeEdge and the OPEA platform. Connecting KubeEdge with OPEA’s model registry and workflow orchestrator to support automated model distribution and deployment from the cloud to edge nodes.\n- Recommended Skills: KubeEdge, LLM, Golang, Python\n- Mentors:\n - Hongbing Zhang (@HongbingZhang, hongbing.zhang@daocloud.io)\n - Elias Wang (@wbc6080, wangbincheng4@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6428\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2e9d0538-0941-4f10-8c52-9afd6294e16e\n\n#### Device Anomaly Detection Framework Based on KubeEdge\n\n- Description: The current KubeEdge platform represents device states using three statuses: Desired, ObservedDesired, and Reported. The device states displayed on the platform are entirely reliant on the Mapper, which collects and reports data from the device side. However, due to limitations in the Mapper implementation, physical device malfunctions, network delays, and potential network attacks, the device states shown on the platform may not accurately reflect the actual state of the devices. In the KubeEdge platform, if applications depend on device states for decision-making, such inconsistencies in state representation may lead to undesirable outcomes. Therefore, this project aims to design a device state anomaly detection framework for KubeEdge. By exploring the causal relationships among device states, the framework will establish lightweight anomaly detection capabilities and provide a comprehensive toolchain encompassing data collection, model training, real-time anomaly detection, and results visualization.\n- Expected Outcome:\n - A general-purpose device anomaly detection framework that supports user-defined detection algorithms\n - A complete technical design document including model selection, training procedures, and detailed architecture diagrams for both training and online detection components\n - A machine learning model and corresponding anomaly detection algorithm capable of capturing causal relationships among device states, trained and tested using standard frameworks\n - An online anomaly detection module integrated into the KubeEdge device state reporting workflow, enabling real-time analysis through a model inference hook\n- Recommended Skills: KubeEdge, IoT, Machine Learning\n- Mentor(s):\n - Liwei Shen (@meixiezichuan, shenliwei@fudan.edu.cn)\n - Elias Wang (@wbc6080, wangbincheng4@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6312\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8cf4ff37-e638-4b73-a5a1-521806ac8db1\n\n### Kubernetes\n\n#### Improve Kubernetes Reference Docs Generator\n\n- Description: The reference documentation for the Kubernetes API is generated at the end of every release cycle. Due to difficulties with the tools used to do this, and the state of that tool's documentation, intimate knowledge of how the tool works is required and generating the reference docs can only reliably be performed by one specific person. Currently, it is possible for the generator to fail at multiple points in the process. Many of these failures are entirely undocumented and without any error handling.\n- Expected Outcome: A measurable improvement in the usability of the reference docs generator, through some combination of an improvement in documentation, error handling, and code refactoring. It should be possible for other contributors to follow instructions and reliably produce the reference API docs, with solutions to any remaining common failure modes thoroughly documented. \n- Recommended Skills:\n - Go\n - Bash\n - Python\n - Technical Writing\n - Patience when faced with undocumented failure modes\n- Mentor(s):\n - Kat Cosgrove (@katcosgrove, kat.cosgrove@gmail.com)\n - Nate Waddington (@nate-double-u, natew@cncf.io)\n - Xander Grzywinski (@salaxander, xandergrzyw@gmail.com)\n - Rey Lejano (@reylejano, rlejano@gmail.com)\n- Upstream Issue: https://github.com/kubernetes-sigs/reference-docs/issues/398\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/79146277-961a-4f69-af48-4c9ae0e1a7fd\n\n### WasmEdge\n\n#### Pointer alignment checking for WASI host function arguments\n\n- Description: WasmEdge implemented a series of WASI host functions to support the official WASI APIs. There are some arguments of WASI APIs are in pointer types. According to the WASI document, the pointer values are expected to be aligned to the alignment of their pointee type, otherwise the the function shall trap. In this mentorship, the mentee should check all functions of WASI interface in WasmEdge, and implement the alignment checking of pointer type arguments.\n- Expected Outcome:\n - Add the alignment checking to the pointee type of [WASI host functions in WasmEdge](https://github.com/WasmEdge/WasmEdge/blob/master/include/host/wasi/wasifunc.h), according to the [alignment requirement in WASI functions](https://github.com/WebAssembly/WASI/blob/main/legacy/preview1/docs.md#modules).\n - Hand-write some basic WASM tests to prove the correctness of the implementation.\n- Recommended Skills:\n - C/C++\n - WebAssembly\n - GitHub workflows\n- Mentor(s):\n - YiYing He (@q82419 , yiying@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/4280\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a0542cf9-a862-4055-8961-d2aede3d91a6\n\n#### Implement the remaining features of wasmedgeup\n\n- Description: WasmEdge currently offers three installers—v0 (deprecated shell script), v1 (Python-based, Linux/macOS only), and v2 (bash-based, limited functionality). A new cross-platform installer, [wasmedgeup](https://github.com/WasmEdge/wasmedgeup), is being developed to unify installation across Linux, macOS, and Windows, simplifying setup and managing versions, dependencies, and hardware detection. Mentees need to implement these key features include uninstall commands, plugin management, and automatic system capability detection.\n- Expected Outcome:\n - Implement the remaining features listed above in [wasmedgeup](https://github.com/WasmEdge/wasmedgeup).\n - A document describing how to use.\n - A CI workflow for verifying these new features and ensuring that they can be built and tested on Linux (Ubuntu, Fedora), macOS, and Windows.\n- Recommended Skills:\n - Rust\n - GitHub workflows\n - Cross-platform development\n- Mentor(s):\n - Hung-Ying, Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/4283\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/54acdf6e-e53f-4a18-9b4b-8797da503150\n\n#### Rust Coder for Claude Code\n\n- Description:\n This is a continuation of our past two LFX mentorship projects -- the Rust Coder.\n https://www.cncf.io/blog/2025/01/10/rustcoder-ai-assisted-rust-learning/\n https://github.com/cardea-mcp/RustCoder\n Users of Rust Coder, which was originally a chatbot and then an MCP server, have told us that they wanted a modern approach like Claude Code. A new focus would also be to port existing Python / C++ projects to Rust, instead of creating Rust projects from scratch. This new proposed LFX mentorship project will\n 1 Fork or add to the open-source Claude Code project\n 2 Create new workflows to ask the user to import Python / C++ projects, make plans for how to port, and ask the user for preferred Rust crates\n 3 Use MCP to add Rust-specific prompts, knowledge base search tools, web-based documentation import tools etc\n 4 Use open source coding models to evaluate the results\n- Expected Outcome:\n - A Claude Code add-on or fork that is specialized optimized for \"rewriting in Rust\".\n- Recommended Skills:\n - Rust\n - Python or C++\n - Vibe coding tools (e.g., Claude Code, Qwen Coder etc)\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n - Vivian Hu (@alabulei1, vivian@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/4284\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/534539a6-9265-466e-8707-8f228a7e5c3d\n\n#### Support the Responses API in Llama Nexus\n\n- Description:\n The llama nexus project is an API proxy to provide OpenAI-compatible and unified API endpoints for multiple downstream API servers, including LLamaEdge API servers running open-source LLMs.\n\n https://github.com/LlamaEdge/llama-nexus\n\n Currently, the Llama Nexus supports the stateless /chat/completions API endpoint for LLMs. We would like to expand this to support the /responses stateful API from OpenAI as well.\n\n https://platform.openai.com/docs/api-reference/responses\n\n https://platform.openai.com/docs/guides/responses-vs-chat-completions\n\n In particular, we aim to implement support for\n\n MCP\n Code interpreter\n Web search\n File search\n Browser use (optional)\n- Expected Outcome:\n - New features for the Llama Nexus proxy server.\n- Recommended Skills:\n - Rust\n - OpenAI API\n - MCP Rust SDK\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io)\n - Sam Liu (@apepkuss, sam@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/4286\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/31044818-fe9d-478d-b740-5d4c8a4c49c2\n\n### Knative\n\n#### Enhancing the Knative func CLI Experience\n\n- Description: Knative Functions enables you to easily create, build, and deploy stateless, event-driven functions as Knative Services by using the func CLI. With this LFX project, we aim to conduct a comprehensive UX evaluation of the func CLI. The focus will be on identifying usability issues, understanding developer workflows, and gathering structured feedback on CLI interactions. The findings will help improve the CLI's intuitiveness, efficiency, and user satisfaction.\n- Expected Outcome: A detailed analysis report documenting func CLI’s usability findings, including (but not limited to ):\n - Assessment of CLI command organization, structure, and discoverability for new and experienced users\n - Review of help text quality and completeness across all commands\n - Mapping of common developer workflows with identified pain points\n - Evaluation of error handling and the user guidance during failures\n - Comparison with industry best practices for CLI design, with recommendations for closing identified gaps\n- Recommended Skills: Experience with command-line interfaces, familiarity with UX evaluation/research methodologies, knowledge of cloud-native and Knative concepts, strong analytical, technical writing and documentation skills.\n- Mentor(s):\n - Prajjwal Yadav (@prajjwalyd, prajjwalyd@gmail.com)\n - Luke Kingland (@lkingland, kingland@redhat.com)\n - Calum Murray (@Cali0707, cmurray@redhat.com)\n- Upstream Issue: https://github.com/knative/ux/issues/196\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/42557ffb-deb4-4b9f-a0b2-78f7f397216c\n\n### Krkn\n\n#### Implementing the resiliency score feature\n\n- Description: The idea is to define criteria to measure the resiliency score of a cluster after a set of chaos scenarios.\n- Expected Outcome:\n - a page in our documentation website clearly explaining the scoring algorithm implemented and the best practices to leverage it on the user's environment\n - a set of functions in our API library to easily collect data and calculate the score\n - the implementation of the scoring method across all Krkn scenarios, and an update to our telemetry data structures to include the resiliency score to allow the collection by downstream observability systems\n- Mentor(s):\n - Tullio Sebastiani (@tsebastiani, tsebasti@redhat.com) \n - Naga Ravi Chaitanya Elluri (@chaitanyaenr, nelluri@redhat.com)\n - Paige Patton (@paigerube14, ppatton@redhat.com)\n- Upstream Issue: https://github.com/krkn-chaos/krkn/issues/125\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e3a6c68a-d3c5-414d-91a2-3681f4bc4473\n\n\n\n### OpenYurt\n\n#### OpenYurt Docker Extension for Simplified Deployment\n\n- Description:\n OpenYurt is an open-source edge cloud-native platform designed to streamline application management in edge computing scenarios. However, the current installation process can be complex for newcomers, creating a barrier to adoption. This project aims to significantly improve the user experience by creating a Docker Extension for OpenYurt. The extension will enable users to install and configure a complete OpenYurt environment, including the yurt-dashboard, with a single click directly from the Docker Desktop interface. This will dramatically lower the entry barrier, allowing developers and edge computing enthusiasts to quickly set up a local development and testing environment, thereby fostering greater community engagement and accelerating innovation on the platform.\n- Expected Outcome:\n - Docker Extension Development: Develop a functional Docker Extension using the Docker Extension SDK that can be installed in Docker Desktop.\n - One-Click Deployment: Package OpenYurt's core components (yurt-manager, yurt-hub, etc.) and dependencies into the extension to automate the setup of a single-node OpenYurt cluster.\n - Dashboard Integration: Provide seamless access to the Yurt Dashboard directly from the extension's UI within Docker Desktop, for example, through an \"Open Dashboard\" button.\n - User Guide and Documentation: Create comprehensive documentation detailing how to install, use, and troubleshoot the OpenYurt Docker Extension.\n- Recommended Skills:\n - Familiarity with Docker and the Docker Extension SDK.\n - Experience with frontend development (e.g., React/TypeScript, Vue) for building the extension's user interface.\n - Proficiency in shell scripting (Bash) or Golang for automating the installation and configuration scripts.\n - A solid understanding of Kubernetes concepts and the OpenYurt architecture.\n- Mentor(s):\n - Lu Chen (@luc99hen, luc99.en@gmail.com)\n - Bingchang Tang (@zyjhtangtang, bingchang07@gmail.com)\n - Karan karanngi (@karanngi, karann.git@gmail.com)\n- Upstream Issue:\n [https://github.com/openyurtio/openyurt/issues/2422](https://github.com/openyurtio/openyurt/issues/2422)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d100c331-0f18-4728-9aa2-0c77bb486702\n\n### PipeCD\n\n#### Prepare documentation for PipeCD v1 release\n\n- Description: Over time, the [plugin-arch pipecd](https://pipecd.dev/blog/2024/11/28/overview-of-the-plan-for-pluginnable-pipecd/) (some docs we call pipecdv1) has reached the final stages before release. Although most of the features of v0 are retained when moving to v1, some of the documentation and usage need to be updated to match v1. \n- Expected Outcome:\n - Refine pipecd documentation, ensure v0 and v1 coexist in parallel without causing confusion\n - Prepare documentation for pipecd v1\n - Support prepare developer guideline for making pipecd [plugins](https://github.com/pipe-cd/community-plugins/)\n- Recommended Skills:\n - Create docs with [Hugo](https://gohugo.io/documentation/)\n - English skill at professional level\n - Knowledge on CI/CD, GitOps, Cloud vendors (such as GCP, AWS, etc)\n - Golang programming language (to understand the codebase if needed)\n- Mentors:\n - Khanh Tran (@khanhtc1202, khanhtc1202@gmail.com)\n - Shinnosuke Sawada-Dazai (@Warashi, shin@warashi.dev)\n - Yoshiki Fujikane (@ffjlabo, ffjlabo@gmail.com)\n - Tetsuya Kikuchi (@t-kikuc, tkikuchi07f@gmail.com)\n- Upstream Issue: https://github.com/pipe-cd/pipecd/issues/6077\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cd5b3190-26c8-4b71-8ebc-4b83677bd30e\n\n### Harbor\n\n#### Harbor CLI - System Settings and Configuration\n\n- Description: Harbor is a widely adopted container registry, and its initial CLI has been developed by LFX mentees. The goal is to extend this CLI by implementing additional functionalities and workflows that are currently only available in the Web UI. The CLI should be useful for Harbor administrators and users, especially to manage workflows within CI/CD pipelines. We seek a Golang-experienced mentee to enhance the CLI independently.\n\n- Expected Outcome:\n - Extend the Harbor CLI to include essential commands not yet implemented.\n - Add new features to improve Harbor management via the CLI for Harbor Administration, enabling robust workflows in CI/CD environments.\n - Review and test all implemented commands to ensure they work as expected.\n- Recommended Skills: Golang, spf13/cobra, Harbor\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com) \n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n- Upstream Issue: https://github.com/goharbor/harbor-cli/issues/450\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/19eb2e9d-df35-4a19-a0dd-cf42103a9a5d\n\n#### Extend Harbor's Pluggable Scanner API for Runtime Behavior Profiles\n\n- Description: Harbor is a widely adopted container registry. As one of the most widely adopted container registries, it is a critical component in modern software supply chains. This project aims to enhance its security capabilities by extending Harbor's Pluggable Scanner specification to support Runtime Behavior Profiles (also known as a Behavior of Bill, or \"BoB\"). While Software Bill of Materials (SBOMs) describe what an artifact *contains*, a BoB describes how it *behaves* at runtime. By integrating `kubescape-node-agent` as a scanner, Harbor will be able to retrieve, store, and display these runtime profiles for OCI artifacts. This allows software producers to ship secure-by-default configurations and provides consumers with a way to verify runtime behavior, detect anomalies, and report unexpected activity. This feature will create greater trust in artifacts and help users meet emerging compliance requirements, such as the EU's CyberResilience Act, by enabling active breach identification through anomaly detection.\n\n- Expected Outcome:\n * Propose and document the minimally necessary modifications to the Harbor Pluggable Scanner Spec to support the retrieval of runtime profiles.\n * Implement a scanner adapter that integrates `kubescape-node-agent` with Harbor.\n * The adapter must be able to retrieve and process SPDX-compliant Runtime Profiles (SBOBs).\n * Extend Harbor's UI to allow users to view runtime profiles and see potential mismatches between expected and observed behavior.\n * Lay the foundation for interoperability of runtime and supply chain security tooling across the CNCF ecosystem.\n\n- Recommended Skills:\n * Golang\n * REST API Design\n * Kubernetes\n * Containers and OCI Image/Distribution Specifications\n * Familiarity with software supply chain security concepts (SBOM, SPDX)\n\n- Mentor(s):\n * Vadim Bauer (@vad1mo, vb@container-registry.com)\n * Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n\n- Upstream Issue: https://github.com/goharbor/pluggable-scanner-spec/issues/22\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f6cffefc-f326-4313-bc1d-3f44111c2938\n\n#### Harbor Satellite: Q&A and Docs\n\n- Description: As edge computing grows, managing container registries at edge becomes a challenge. As the Harbor satellite project matures and evolves, we need to improve the code quality, the release process and user documentation.\n\n- Expected Outcome:\n - Extend build and release artifacts using Dagger.\n - Perform code reviews and establish a Q&A process\n - Create, Update and Improve documentation for Harbor Satellite.\n - Implement new features.\n\n- Recommended Skills \n - Golang\n - GitHub workflow\n - Dagger\n - Testing \n - Q&A\n - Good writing and communication \n\n\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n\n- Upstream Issue: https://github.com/goharbor/harbor/issues/21959\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/efdf193a-727e-4183-9f12-d72857922e2f\n\n#### Harbor Satellite: Implementing a Eventing System for Satellite\n\n- Description:\n Harbor Satellite is a lightweight, OCI-compliant registry (currently based on Zot) designed to run on edge devices, such as Raspberry Pi or ARM-based hardware. It acts as a local container registry for edge devices and workloads. The satellite autonomously fetches configuration and state, registers with Ground Control, reports its status, and optionally sends system-level events to connected edge systems.\n\n- Expected Outcome:\n - Implement an eventing mechanism to notify edge systems about critical state transitions (e.g., \"state update ready\", \"sync complete\").\n - Improve build and release pipelines.\n - Make the satellite functional on ARM-based edge devices (like Raspberry Pi).\n - Add reliable state and health reporting back to Ground Control.\n - Add e2e tests to validate artifact fetching, status reporting, and eventing.\n\n- Recommended Skills\n - Golang\n - Containers\n - Edge Computing\n - OCI Image/Distribution Spec\n - Webhooks\n - Event-Driven Architecture\n\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n\n- Upstream Issue: https://github.com/goharbor/harbor/issues/21986\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/98096893-507a-4c78-a46a-e7541b441e2d\n\n### Meshery\n\n#### Relationships for AWS services\n\nCNCF - Meshery: Relationships for AWS services (2025 Term 3)\n\n- Description:\nMeshery Models are declarative representations of infrastructure and applications. Within these models, Relationships define how different Components (e.g., Kubernetes resources, Cloud services) interact and depend on each other. These relationships are crucial for visualizing, understanding, and managing complex cloud native systems.\n\nThis internship focuses on significantly expanding the breadth and depth of Meshery Relationships across a wide array of technologies supported by Meshery. As Meshery continues to integrate with more cloud-native technologies (Kubernetes, public clouds, and all CNCF projects), there's a growing need to accurately model the intricate relationships between their components - vital for providing users with comprehensive insights and control over their deployments.\n\n- Recommended Skills: DevOps, systems administration, solutions architecture. Experience with Kubernetes, AWS and its services.\n- Responsibilities:\n - Research and Analyze Technologies: Dive deep into various cloud-native technologies (e.g., different compute services, databases, messaging systems, network services, etc.) to understand their components and how they interconnect.\n - Develop Relationship Definitions: Create and contribute relationship definitions, typically in JSON or YAML format, to the Meshery models. \n - Model Inter-Technology Interactions: Focus particularly on defining relationships between components from different technologies (e.g., how a Kubernetes deployment relates to an AWS RDS instance, or how a Linkerd service interacts with a Prometheus monitoring component).\n - Document New Relationships: Clearly document the newly defined relationships, their purpose, and how they are represented within Meshery designs, contributing to the official Meshery documentation.\n- Expected Outcome:\n - A multitude of new relationships defined both intra and inter AWS services.\n - Policy Contribution: For advanced interns, there may be opportunities to contribute to the Rego policies that evaluate and enforce these relationships.\n- Mentor(s): Mia Grenell (@miacycle, mia.grenell2337@gmail.com), Lee Calcote (@leecalcote, leecalcote@gmail.com), Sangram Rath (@sangramrath, sangram.rath@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/15518\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6c0bb714-9858-43b0-9c04-2f4b14d6c263\n\n#### Relationships for GCP services\n\nCNCF - Meshery: Relationships for GCP services (2025 Term 3)\n\n- Description:\nMeshery Models are declarative representations of infrastructure and applications. Within these models, Relationships define how different Components (e.g., Kubernetes resources, Cloud services) interact and depend on each other. These relationships are crucial for visualizing, understanding, and managing complex cloud native systems.\n\nThis internship focuses on significantly expanding the breadth and depth of Meshery Relationships across a wide array of technologies supported by Meshery. As Meshery continues to integrate with more cloud-native technologies (Kubernetes, public clouds, and all CNCF projects), there's a growing need to accurately model the intricate relationships between their components - vital for providing users with comprehensive insights and control over their deployments.\n\n- Recommended Skills: DevOps, systems administration, solutions architecture. Experience with Kubernetes, GCP and its services.\n- Responsibilities:\n - Research and Analyze Technologies: Dive deep into various cloud-native technologies (e.g., different compute services, databases, messaging systems, network services, etc.) to understand their components and how they interconnect.\n - Develop Relationship Definitions: Create and contribute relationship definitions, typically in JSON or YAML format, to the Meshery models. \n - Model Inter-Technology Interactions: Focus particularly on defining relationships between components from different technologies (e.g., how a Kubernetes deployment relates to an GCP Spanner instance, or how a Linkerd service interacts with a Prometheus monitoring component).\n - Document New Relationships: Clearly document the newly defined relationships, their purpose, and how they are represented within Meshery designs, contributing to the official Meshery documentation.\n- Expected Outcome:\n - A multitude of new relationships defined both intra and inter GCP services.\n - Policy Contribution: For advanced interns, there may be opportunities to contribute to the Rego policies that evaluate and enforce these relationships.\n- Mentor(s): James Horton (hortison, james.horton2337@gmail.com), Lee Calcote (@leecalcote, leecalcote@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/15531\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ed9d4af5-823a-4127-afdf-643c2b623f22\n\n#### Solutions Architecture of Popular Cloud Native Deployments\n\nCNCF - Meshery: Solutions architecture for cloud-native deployments (2025 Term 3)\n\n- Description: Learning paths with hands-on labs are a crucial resource for DevOps engineers and cloud-native practitioners. The Meshery Playground provides a live cluster environment, making it an ideal platform for learning every kind of cloud and cloud native technology. Meshery Docs is in need of comprehensive tutorials and scenarios covering common infrastructure management use cases. Mission is to create and publish a series of hands-on tutorials using Meshery Playground. Each tutorial will include step-by-step guides, live demonstrations, and interactive labs using the Playground allowing learners to apply their knowledge directly without the hassle of any configuration.These tutorials will be reviewed by various project maintainers and then published in guides/tutorials.\n- Expected Outcome:\n - 10+ new solution architectures (designs) published in Meshery Catalog\n - Each design is ideally adjoined with an interactive tutorial (using Meshery Playground), guiding users through infrastructure.\n - Tutorials should vary in complexity, catering to beginners and advanced learners.\n- Recommended Skills: written English, Markdown, Kubernetes, DevOps, and hands-on experience with cloud-native tools\n- Mentor(s): Rian Cteulp (ritzorama, rian.cteulp@gmail.com), Lee Calcote (@leecalcote, leecalcote@gmail.com), Sangram Rath (@sangramrath, sangram.rath@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/15532\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a183c51e-22c6-473b-93f4-6c286993e435\n\n### Kagent\n\n#### Building cloud native agents for Kagent\n\n- Description: Kagent is an open-source framework for DevOps and platform engineers to run AI agents in Kubernetes, automating complex operations and troubleshooting tasks. We have a few agents for kagents (Kubernetes, Istio, Cilium, Argo, Prometheus, Grafana etc) and would love to build more agents for other CNCF graduated or incubation projects so users can use conversation style to chat with the agents to either learn or troubleshooting or operating these projects.\n \n- Expected Outcome: Able to build at least 2-3 agents for CNCF graduated or incubation projects. Able to write a blog for the work and produce associated docs as well.\n \n- Recommended Skills:\n - Python\n - Kubernetes\n - familar with cloud native, Docker and some CNCF graduated or incubation projects\n - Basic understanding of AI agents and LLMs.\n - Understand how open source contribution works, familar with GitHub.\n \n- Mentor(s):\n - Lin Sun(@linsun, linsun@solo.io) & Eitan Yarmush(@EItanya, eitan.yarmush@solo.io) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n \n- Upstream Issue:\n - https://github.com/kagent-dev/kagent/issues/662\n - https://github.com/kagent-dev/kagent/issues/664\n\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cda38f44-e4b4-4f86-8b5a-a89bc08ac34a\n" }, { "path": "programs/lfx-mentorship/2025/03-Sep-Nov/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n- Upstream Issue:\n\n```\n\n---\n\n## Proposed Project ideas\n\n" }, { "path": "programs/lfx-mentorship/2026/01-Mar-May/README.md", "content": "# Term 01 - 2026 March - May\n\nStatus: Accepting Applications\n\nMentorship duration - three months (full-time schedule)\n\n### Timeline\n\n| **Activity** | **Date** |\n|-------------------------------------|--------------------------------------------------------------------------|\n| **Project Proposals Open** | Wednesday, January 7 – Tuesday, January 20, 2026 |\n| **Mentee Applications Open** | Monday, January 26 – Tuesday, February 10, 2026, 11AM PST (19:00 UTC) |\n| **Application Review Period** | Wednesday, February 11 – Tuesday, February 24, 2026, 11AM PST (19:00 UTC)|\n| **Selection Notifications** | Thursday, February 26, 2026 |\n| **Mentorship Program Begins** | Monday, March 2, 2026 |\n| **Mentorship Kick Off Call** | Tuesday, March 3, 2026, Times TBD (will be multiple timezone options) |\n| **Midterm Mentee Evaluations Due** | Tuesday, April 14, 2026, 11AM PDT (18:00 UTC) |\n| **First Stipend Payments** | Wednesday, April 15, 2026 |\n| **Final Mentee Evaluations Due** | Tuesday, May 26, 2026, 11AM PDT (18:00 UTC) |\n| **Second Stipend Payments** | Wednesday, May 27, 2026 |\n| **Last Day of Term** | Friday, May 29, 2026 |\n\n### Project instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2026/01-Mar-May/project_ideas.md, by January 20, 2026. Please limit proposals to 4-5 projects per CNCF project.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n## Table of Contents\n\n- [Antrea](#antrea)\n - [Compare Antrea BPF generation for PacketCapture to tcpdump / libpcap](#compare-antrea-bpf-generation-for-packetcapture-to-tcpdump-libpcap)\n- [Cilium](#cilium)\n - [Cilium Project Pillar Pages](#cilium-project-pillar-pages)\n- [Drasi](#drasi)\n - [Drasi for IoT: MQTT Integration and Real-Time Sensor Monitoring](#drasi-for-iot-mqtt-integration-and-real-time-sensor-monitoring)\n- [etcd](#etcd)\n - [Dive deep into etcd by contributing to the self-Assessment of etcd](#dive-deep-into-etcd-by-contributing-to-the-self-assessment-of-etcd)\n- [Fluid](#fluid)\n - [Extend Cache Runtime Interface to Support Full Data Lifecycle and In-Place Operations](#extend-cache-runtime-interface-to-support-full-data-lifecycle-and-in-place-operations)\n - [Unify and Modernize Fluid’s Unit Testing Framework and enhance testing coverage](#unify-and-modernize-fluids-unit-testing-framework-and-enhance-testing-coverage)\n - [Design and implement a CLI tool to help easily use Fluid](#design-and-implement-a-cli-tool-to-help-easily-use-fluid)\n- [Harbor](#harbor)\n - [Harbor CLI](#harbor-cli)\n - [Harbor Satellite](#harbor-satellite)\n- [Jaeger](#jaeger)\n - [AI-Powered Trace Analysis with Local LLM Support](#ai-powered-trace-analysis-with-local-llm-support)\n - [Upgrading Core Routing and State Management in Jaeger UI](#upgrading-core-routing-and-state-management-in-jaeger-ui)\n- [Karmada](#karmada)\n - [Enhance Karmada's Quick Start Experience and Incorporate macOS Support](#enhance-karmadas-quick-start-experience-and-incorporate-macos-support)\n - [OmniControl for Karmada Dashboard](#omnicontrol-for-karmada-dashboard)\n - [Protect Karmada Component Flags from Unexpected Changes](#protect-karmada-component-flags-from-unexpected-changes)\n- [kgateway](#kgateway)\n - [Add support for Chaos Engineering/Fault Injection](#add-support-for-chaos-engineeringfault-injection)\n - [Ecosystem Integrations & Tutorials for kgateway's AI Gateway](#ecosystem-integrations-tutorials-for-kgateways-ai-gateway)\n - [Modernize and improve kgateway end-to-end testing](#modernize-and-improve-kgateway-end-to-end-testing)\n- [Kmesh](#kmesh)\n - [Kmesh supports multi-clusters](#kmesh-supports-multi-clusters)\n - [Optimize long connection load balance and support more load balance algorithm](#optimize-long-connection-load-balance-and-support-more-load-balance-algorithm)\n- [Knative](#knative)\n - [Enhancing the Knative Educational Game with Advanced EDA Patterns and Web Deployment](#enhancing-the-knative-educational-game-with-advanced-eda-patterns-and-web-deployment)\n- [krkn - Chaos](#krkn---chaos)\n - [Enhancing Krkn-AI Result Analysis with Interactive Visualization and Insights](#enhancing-krkn-ai-result-analysis-with-interactive-visualization-and-insights)\n - [Natural Language–Based Chaos Scenario Discovery](#natural-languagebased-chaos-scenario-discovery)\n- [kube-burner](#kube-burner)\n - [kube-burner](#kube-burner)\n- [KubeEdge](#kubeedge)\n - [Batch Enable/Disable of EdgeHub on Edge Nodes via kubeedge/keadm](#batch-enabledisable-of-edgehub-on-edge-nodes-via-kubeedgekeadm)\n - [Cloud-Edge Simulation Benchmark for LLM Speculative Decoding in KubeEdge-Ianvs](#cloud-edge-simulation-benchmark-for-llm-speculative-decoding-in-kubeedge-ianvs)\n - [Comprehensive Example Restoration for KubeEdge Ianvs](#comprehensive-example-restoration-for-kubeedge-ianvs)\n - [Enable and Verify KubeEdge Support on RISC-V Architecture](#enable-and-verify-kubeedge-support-on-risc-v-architecture)\n- [Kubernetes](#kubernetes)\n - [#Add OpenTelemetry support](#add-opentelemetry-support)\n - [Cluster API Provider AWS (CAPA)](#cluster-api-provider-aws-capa)\n - [Kubespray](#kubespray)\n - [Headlamp](#headlamp-1)\n - [Add Cluster API to Headlamp: Cluster Lifecycle Management UI](#add-cluster-api-to-headlamp-cluster-lifecycle-management-ui)\n - [Add Kubeflow to Headlamp: Machine Learning Workflow Management UI](#add-kubeflow-to-headlamp-machine-learning-workflow-management-ui)\n - [Add Strimzi to Headlamp: Kubernetes Kafka Management UI](#add-strimzi-to-headlamp-kubernetes-kafka-management-ui)\n - [Polish Knative support in Headlamp: Serverless Workload Management UI](#polish-knative-support-in-headlamp-serverless-workload-management-ui)\n - [Kubernetes SIG Docs – Localization Subproject](#kubernetes-sig-docs-localization-subproject)\n- [KubeStellar](#kubestellar)\n - [Documentation and Self-Service Enablement Specialist](#documentation-and-self-service-enablement-specialist)\n - [Integration and Ecosystem Development Specialist](#integration-and-ecosystem-development-specialist)\n- [Kyverno](#kyverno)\n - [DevRel](#devrel)\n - [Test Enhancements - Kyverno CLI Tests - envtest, fake client](#test-enhancements---kyverno-cli-tests---envtest-fake-client)\n - [Test Enhancements - Testing Framework / Toolset for integration tests](#test-enhancements---testing-framework-toolset-for-integration-tests)\n- [LitmusChaos](#litmuschaos)\n - [Add Prometheus Metrics to LitmusChaos Control Plane Service](#add-prometheus-metrics-to-litmuschaos-control-plane-service)\n- [Meshery](#meshery)\n - [Adapter for AI and LLMs](#adapter-for-ai-and-llms)\n - [Graph Database Integration](#graph-database-integration)\n - [Migration of docs.meshery.io from Jekyll to Hugo](#migration-of-docsmesheryio-from-jekyll-to-hugo)\n - [Relationships for AWS services](#relationships-for-aws-services)\n - [Workflow Engine in Meshery](#workflow-engine-in-meshery)\n- [OpenCost](#opencost)\n - [OpenCost UI Revamp](#opencost-ui-revamp)\n- [OpenKruise](#openkruise)\n - [KruiseGame Cloud-Hosted Version Development](#kruisegame-cloud-hosted-version-development)\n - [OpenKruise: Progressive Configmap Inplace Reloading](#openkruise-progressive-configmap-inplace-reloading)\n - [OpenKruise: Promote API Version to v1beta1 part 2](#openkruise-promote-api-version-to-v1beta1-part-2)\n - [OpenKruise: Rolling update for agent sandbox warm pool](#openkruise-rolling-update-for-agent-sandbox-warm-pool)\n- [OpenTelemetry](#opentelemetry)\n - [Tooling for detecting impact of behavioral changes in Go libraries](#tooling-for-detecting-impact-of-behavioral-changes-in-go-libraries)\n- [OpenYurt](#openyurt)\n - [Implement Label-Driven Automated Installation and Uninstallation of YurtHub on Edge Nodes](#implement-label-driven-automated-installation-and-uninstallation-of-yurthub-on-edge-nodes)\n- [PipeCD](#pipecd)\n - [Amazon ECS plugin for Pipedv1](#amazon-ecs-plugin-for-pipedv1)\n\n - [Community Building and Social Media Growth for PipeCD](#community-building-and-social-media-growth-for-pipecd)\n - [Multi-cluster Kubernetes plugin for Pipedv1](#multi-cluster-kubernetes-plugin-for-pipedv1)\n- [Prometheus](#prometheus)\n - [Improving Documentation for Prometheus and OpenTelemetry Interoperability](#improving-documentation-for-prometheus-and-opentelemetry-interoperability)\n - [Start scraping immediately on startup without waiting for WAL replay to finish](#start-scraping-immediately-on-startup-without-waiting-for-wal-replay-to-finish)\n- [urunc](#urunc)\n - [Create a dashboard and a notification system for CI testing in `urunc`](#create-a-dashboard-and-a-notification-system-for-ci-testing-in-urunc)\n\n - [Investigate missing custom OCI Annotations in urunc containers](#investigate-missing-custom-oci-annotations-in-urunc-containers)\n - [Optimizing Rootfs Handling with block-based snapshotters in `urunc`](#optimizing-rootfs-handling-with-block-based-snapshotters-in-urunc)\n- [Volcano](#volcano)\n - [Add Volcano to Headlamp: Job and Queue Management UI](#add-volcano-to-headlamp-job-and-queue-management-ui)\n - [E2E Test Suite for Volcano Agent Scheduling](#e2e-test-suite-for-volcano-agent-scheduling)\n - [E2E Test Suite for Volcano-global](#e2e-test-suite-for-volcano-global)\n - [Volcano Documentation & Website Revamp with Docusaurus](#volcano-documentation-website-revamp-with-docusaurus)\n- [Volcano/AgentCube](#volcanoagentcube)\n - [Establishing agentCube's authentication and authorisation capabilities](#establishing-agentcubes-authentication-and-authorisation-capabilities)\n- [volcano/kthena](#volcanokthena)\n - [E2E Test Suite for Kthena](#e2e-test-suite-for-kthena)\n - [Optimising Kthena's autoscaler](#optimising-kthenas-autoscaler)\n- [WasmEdge](#wasmedge)\n - [Enable JIT mode support for per-function compilation](#enable-jit-mode-support-for-per-function-compilation)\n\n - [Extend sub-command of WasmEdge CLI tool](#extend-sub-command-of-wasmedge-cli-tool)\n - [Module instance dependency tree in WASM store](#module-instance-dependency-tree-in-wasm-store)\n## Accepted Projects\n\n### Antrea\n\n#### Compare Antrea BPF generation for PacketCapture to tcpdump / libpcap\n\nCNCF - Antrea: Compare PacketCapture BPF generation vs tcpdump/libpcap (2026 Term 1)\n\n- Description: Antrea's [PacketCapture feature](https://github.com/antrea-io/antrea/blob/main/docs/packetcapture-guide.md) includes custom BPF code generation for packet filters defined in the PacketCapture CRD. The code is currently tested using manually-generated test cases, which is tedious, error-prone, and limits testing coverage. Given that the code attempts to mimic the BPF generation done by tcpdump, we should improve the testing approach by: 1) using AI to generate comprehensive test inputs, 2) using tcpdump to generate reference BPF code for the inputs, 3) comparing our generated BPF with the tcpdump reference, 4) analyzing any differences to determine if our BPF is incorrect or equivalent, 5) updating our BPF generation to match tcpdump when possible, and 6) committing all test cases to run in CI.\n- Expected Outcome: A comprehensive test suite for the PacketCapture BPF generation code that uses tcpdump-generated BPF as a reference. The test suite should be integrated into CI and should increase testing coverage compared to the current manually-generated test cases. Any discrepancies between Antrea's BPF generation and tcpdump's should be analyzed and resolved, with the BPF generation code updated as needed to match tcpdump's output when appropriate.\n- Recommended Skills: Golang, familiarity with BPF (Berkeley Packet Filter), basic understanding of packet filtering and tcpdump/libpcap. We encourage using AI tools to generate test cases and improve the BPF code generation, but we expect careful review of generated artifacts before submitting them for review.\n- Mentor(s):\n - Antonin Bas (@antoninbas, antonin.bas@gmail.com)\n - Hang Yan (@hangyan, hang.yan@hotmail.com)\n- Upstream Issue: https://github.com/antrea-io/antrea/issues/7701\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/39be2843-94f8-4ac6-aa0a-3537631aca86\n\n\n### Cilium\n\n#### Cilium Project Pillar Pages\n\nCNCF - Cilium: Cilium Project Pillar Pages (2026 Term 1)\n\n- Description: cilium.io could benefit from SEO pillar pages that capture higher level problems that people will search for. Each page should deep dive into a comprehensive overview of the topic and contain high quality architectural images and diagrams that will also be discovered in search. These pages will capture high-intent search traffic and guide users from \"Curious\" to \"Installed.\"\n- Expected Outcome: 8 pillar pages with content and images deployed on the website\n- Recommended Skills: Markdown, Figma, Writing\n- Mentor(s):\n - Bill Mulligan (@xmulligan, bill@isovalent.com)\n- Upstream Issue: https://github.com/cilium/cilium.io/issues/841\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/854310e3-e1ac-472c-945f-97bb16bc1aca\n\n\n### Drasi\n\n#### Drasi for IoT: MQTT Integration and Real-Time Sensor Monitoring\n\nCNCF - Drasi: IoT: MQTT integration and real-time sensor monitoring (2026 Term 1)\n\n- Description: Drasi is a Data Change Processing platform that enables developers to detect and react to meaningful data changes using declarative Cypher queries. Drasi excels at complex change detection with unique features like `drasi.trueFor()` (detecting conditions that persist over time) and absence-of-change detection (alerting when expected events don't occur). However, it currently lacks native connectivity to IoT protocols.\n\n Drasi Lib provides Drasi's powerful graph-aware decision engine as an embeddable Rust library that can run completely offline on constrained hardware—enabling edge computing scenarios where logic runs directly on sensors and gateways. IoT applications fundamentally need to detect state transitions, but developers typically must write boilerplate code and manage state persistence manually. Drasi's diff-engine handles state management and change computation automatically, emitting events only when meaningful changes occur.\n\n MQTT (Message Queuing Telemetry Transport) is the de-facto standard protocol for IoT, used by AWS IoT Core, Azure IoT Hub, and virtually every IoT deployment. Adding MQTT support to Drasi Lib will unlock the entire IoT ecosystem for Drasi users.\n\n In this project, the mentee will build a suite of lightweight Rust crates that enable Drasi Lib to communicate with MQTT brokers. They will create connectors to ingest sensor data (MQTT Source), execute local actions (Shell Reaction), and close the control loop (MQTT Reaction). Finally, they will demonstrate the complete stack with a demo showcasing Drasi's unique temporal capabilities for IoT.\n\n The mentee will gain hands-on experience with async Rust (tokio), IoT protocols (MQTT), stream processing concepts, and graph-based data modeling.\n\n- Expected Outcome:\n - Build MQTT Source Plugin - A new Rust crate that enables Drasi to ingest data from MQTT brokers\n - Build Shell/Command Reaction - A new Rust crate that enables Drasi to execute local system commands based on query results\n - Build MQTT Reaction Plugin - A new Rust crate that enables Drasi to publish alerts/commands to MQTT topics\n - Create IoT Demo Scenario - A complete, runnable demonstration showing Drasi's power for IoT use cases\n - Create Documentation & Tutorial - Comprehensive guide for IoT developers to adopt Drasi\n - (Stretch Goal) Build InfluxDB Source - Enables Drasi to ingest from InfluxDB, unlocking Telegraf's 200+ input plugins for IoT\n- Recommended Skills:\n - Rust (intermediate level: ownership, traits, async/await with tokio)\n - Basic understanding of IoT concepts (MQTT protocol, pub/sub patterns)\n - Git and GitHub workflow\n - (Helpful) Docker and Docker Compose for testing\n - (Helpful) Basic understanding of graph concepts or Cypher query language\n - (Helpful) Experience with message brokers (MQTT, Kafka, etc.)\n- Mentor(s):\n - Aman Singh (@amansinghoriginal, singh.amandeep@microsoft.com) - Primary\n - Allen Jones (@agentofreality, Jones.Allen@microsoft.com)\n- Upstream Issue: https://github.com/drasi-project/drasi-core/issues/155\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/febb9f7b-8516-41b5-8815-770d333ac978\n\n\n### etcd\n\n#### Dive deep into etcd by contributing to the self-Assessment of etcd\n\nCNCF - etcd: Contribute to etcd Self-Assessment (2026 Term 1)\n\n- Description:\n This project continues the work initiated in the [etcd - technical scope of the assessment](https://docs.google.com/document/d/1RTXffyDJ8hLoHl_Mo-frQheRQ-8QIVQJ6mqAw69zcP4/edit?pli=1&tab=t.0). The goal is to dive deep into etcd's architecture in depth by completing and publishing the self-assessment for SIG-Security review. The project has two key components: (1) collaborating with mentors, project maintainers, and Special Interest Groups (SIGs) to investigate etcd and kube-apiserver internals, particularly the lifecycle of requests and consensus mechanisms, and (2) updating and enhancing the [etcd.io website](https://etcd.io/) documentation by creating new pages, refining existing content, and publishing blog posts to ensure the documentation reflects current architecture and best practices.\n Whether you're a new contributor, already active in the community, or simply curious about etcd, we welcome you to join this project!\n\n- Expected Outcome:\n - Complete the etcd self-assessment draft currently in progress in this [document](https://docs.google.com/document/d/1RTXffyDJ8hLoHl_Mo-frQheRQ-8QIVQJ6mqAw69zcP4/edit?pli=1&tab=t.0) and prepare it for review by SIG-Security and etcd maintainers.\n - Publish the finalized self-assessment in the SIG-Security repository (see [example format](https://github.com/kubernetes/sig-security/blob/main/sig-security-assessments/cluster-api/self-assessment.md)).\n - Develop comprehensive understanding of etcd internals including read and write flows, Raft consensus algorithm, high availability mechanisms, data stores, and data flow diagrams within Kubernetes environments.\n - Update the etcd.io website with improved documentation, new pages covering architectural insights, and blog posts highlighting key findings from the assessment work.\n - Coordinate a full SIG-Security review process.\n - Actively participate in project SIG meetings, communication channels, and SIG Security discussions.\n\n- Recommended Skills:\n - Golang\n - Understanding of distributed systems (etcd, kube-apiserver) and systems architecture\n - Cybersecurity knowledge\n - Open Source Mindset\n - Familiarity with Git and contributing via pull requests\n - Participation in project SIG meetings, SIG communication channels\n\n- Mentors:\n - Ronald Ngounou (@ronaldngounou, ronald.ngounou@yahoo.com)\n - Siyuan Zhang (@siyuanfoundation, physicsbug@gmail.com)\n - Carol Valencia (@krol3, valencia0.carol@gmail.com)\n- Upstream Issue:\n - https://github.com/etcd-io/etcd/issues/21159\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/90bcea22-62eb-4e81-aa0f-89b517b2a620\n\n\n### Fluid\n\n#### Extend Cache Runtime Interface to Support Full Data Lifecycle and In-Place Operations\n\nCNCF - Fluid: Extend cache runtime interface for full data lifecycle (2026 Term 1)\n\n- Description：Fluid’s existing Generic Cache Runtime interface will be extended to support the complete lifecycle of data operations, including data loading, data processing workflows, and cache-aware data mutations. Additionally, the interface will be enhanced to enable in-place cache upgrades and in-place cache rebuilds—allowing runtime updates and recovery without disrupting workloads or requiring dataset re-provisioning.\n- Expected Outcomes:\n - Extended Cache Runtime interface covering data load, data operation lifecycle, and state transitions.\n - Working reference adapters for Curvine and Alluxio\n - Support for in-place upgrade (e.g., engine version update) and in-place cache rebuild (e.g., after node failure or config change).\n- Recommended Skills: Fluid, Go, kubernetes operator development\n- Mentor(s):\n - Tongyu Guo (@Syspretor，[guotongyu.gty@alibaba-inc.com](mailto:guotongyu.gty@alibaba-inc.com))\n - Yang Che (@cheyang, [cheyang52@gmail.com](mailto:cheyang52@gmail.com))\n- Upstream Issues: https://github.com/fluid-cloudnative/fluid/issues/5412\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/44b75328-8f4b-48f0-a4d5-c8c6d5e86a0a\n\n#### Unify and Modernize Fluid’s Unit Testing Framework and enhance testing coverage\n\nCNCF - Fluid: Modernize unit testing framework and increase UT coverage (2026 Term 1)\n\n- Description: To enhance code quality, maintainability, and developer experience, Fluid plans to migrate its unit testing framework from Testify to Ginkgo + Gomega—a more expressive and behavior-driven testing stack widely adopted in the Go ecosystem. Concurrently, we aim to significantly improve unit test (UT) coverage, raising it from the current 57% to at least 75%, thereby reducing regression risks and strengthening overall system reliability\n- Expected Outcome: \n - Deliver comprehensive migration guidelines, coding best practices, and hands-on team training for Ginkgo + Gomega adoption.\n - Achieve a measurable increase in unit test coverage—from 57% to 75%—across core modules of the Fluid codebase.\n- Recommended Skills: Fluid, Go, unit testing frameworks (gomonkey, ginkgo, gomega, testify)\n- Mentor(s):\n - Zhihao Xu (@TrafalgarZZZ， [trafalgarz@outlook.com](mailto:trafalgarz@outlook.com))\n - Yang Che (@cheyang, [cheyang52@gmail.com](mailto:cheyang52@gmail.com))\n- Upstream Issues: https://github.com/fluid-cloudnative/fluid/issues/5407\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/daf54f56-a7e6-48a8-ab9f-45915d05a203\n\n#### Design and implement a CLI tool to help easily use Fluid\n\nCNCF - Fluid: Design and implement a CLI tool for Fluid (2026 Term 1)\n\n- Description: Fluid manages Kubernetes resources (Statefulsets, PersistentVolumeClaims & PersistentVolume, etc.) under two Fluid custom resources CR called `Dataset` and `Runtime`. Given a pair of Dataset and Runtime CR, users may want to inspect the underlying resources, check their status and diagnose which part is going wrong. A CLI tool (e.g. a kubectl plugin) for Fluid would be a straightforward way for Fluid's users to easily get such information.\n\n- Expected Outcome:\n - Design and implement a CLI tool for Fluid\n - Support `inspect` subcommand: list resource status given a Fluid Dataset CR.\n - Support `diagnose` subcommand: collect related information (e.g. logs, pod status, etc.) to help diagnose what's going wrong.\n - Implement a framework to diagnose Fluid with LLM/AI. (The collected information can be put into the context of an AI inference request)\n\n- Recommended Skills: Fluid, Go, CLI tool development, LangChain(or other alternative LLM frameworks)\n\n- Mentor(s):\n - Zhihao Xu (@TrafalgarZZZ， [trafalgarz@outlook.com](mailto:trafalgarz@outlook.com))\n - Yang Che (@cheyang, [cheyang52@gmail.com](mailto:cheyang52@gmail.com))\n\n- Upstream Issues: https://github.com/fluid-cloudnative/fluid/issues/5567\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/26709fdd-cf31-4643-ba12-88c0a47530ca\n\n\n### Harbor\n\n#### Harbor CLI\n\nCNCF - Harbor: Harbor CLI (2026 Term 1)\n\n- Description: Harbor CLI is the official command-line interface for Harbor container registry. This project focuses on improving CLI user experience by porting the remaining complex commands such as job service dashboard and audit logs streaming, and enhancing the release pipeline for simplicity and security.\n- Expected Outcome:\n - Implement job service dashboard commands in CLI\n - Add audit logs streaming functionality\n - Improve and secure the release pipeline\n - Enhance overall CLI usability\n- Recommended Skills: Golang, spf13/cobra\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n- Upstream Issue: https://github.com/goharbor/harbor-cli/issues\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/89a4b97d-77c7-4b57-907b-6bc746389b87\n\n\n#### Harbor Satellite\n\nCNCF - Harbor: Harbor Satellite (2026 Term 1)\n\n- Description: Harbor Satellite is a lightweight OCI-compliant registry designed for edge devices. This project focuses on implementing SPIFFE/SPIRE-based authentication for satellite identity management, improving the release pipeline and developer workflow, and ensuring cloud-agnostic compatibility across Kubernetes, Docker, VMs, and bare metal environments.\n- Expected Outcome:\n - Implement SPIFFE/SPIRE authentication for satellite identity\n - Improve release pipeline and developer workflow\n - Validate and test deployment across Kubernetes, Docker, VMs, and bare metal\n - Ensure edge/IoT compatibility and stability\n- Recommended Skills: Golang, Containers, SPIFFE/SPIRE, Edge Computing, OCI Spec\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n- Upstream Issue: https://github.com/container-registry/harbor-satellite/issues\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6e2de11e-5baf-4c55-b3ea-4bec95e16fc2\n\n\n#### Harbor Satellite - Hardware-Backed Zero-Trust Device Identity via PARSEC\n\nCNCF - Harbor: Harbor Satellite: HW-backed zero-trust device identity via PARSEC (2026 Term 1)\n\nSpecial late project. Application window will be open til Tuesday, Feb 17, 2026 at 11AM Pacific Time.\n\n- Description: Harbor Satellite provides software-based config encryption and device fingerprinting for edge registries. This project hardens the security model by integrating CNCF PARSEC to enable hardware-backed zero-trust provisioning (ZTP), X.509 device certificates, and device identity. Mentees will implement a secure backend toward a hardware root of trust to enable device attestation via PARSEC's platform-agnostic API, hardware-sealed config encryption with graceful software fallback, and verifiable device identity that Ground Control can cryptographically validate. The work extends the existing SPIFFE/SPIRE authentication with hardware root-of-trust, advancing Harbor Satellite toward a fully zero-trust edge registry with hardware-attested device enrollment.\n- Expected Outcome:\n - Integrate CNCF PARSEC for hardware-backed device attestation via its platform-agnostic API\n - Implement hardware-sealed config encryption with graceful software fallback for non-hardware environments\n - Enable verifiable device identity with X.509 certificates that Ground Control can cryptographically validate\n - Extend the existing SPIFFE/SPIRE authentication with hardware root-of-trust\n - Implement zero-touch provisioning (ZTP) with hardware-attested device enrollment\n- Recommended Skills: Golang, Containers, PARSEC, SPIFFE/SPIRE, Edge Computing, Cryptography, X.509/PKI\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n- Upstream Issue: https://github.com/container-registry/harbor-satellite/issues/327\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b0ef2748-ab96-4c81-b824-14a400c29b5c\n\n\n### Jaeger\n\n#### AI-Powered Trace Analysis with Local LLM Support\n\nCNCF - Jaeger: AI-Powered Trace Analysis with Local LLM Support (2026 Term 1)\n\n- Description: Jaeger is a widely used distributed tracing platform. This project aims to integrate Small Language Models (SLMs) and Large Language Models (LLMs) into the Jaeger ecosystem to provide intelligent trace analysis. Key features include natural language search mapping (mapping English queries to Jaeger's internal search parameters), contextual analysis, and summarization (\"Explain this Span\" or \"Explain this trace\"). The project involves backend integration using Go and LangChainGo, and frontend integration within the Jaeger React UI.\n- Expected Outcome: A working \"Natural Language Search\" input that populates the Jaeger search form, contextual \"Explain\" buttons for errors and spans, a robust backend implementation using langchaingo supporting local models (e.g., Ollama) via YAML config, and comprehensive documentation.\n- Recommended Skills: Backend: Strong Go (Golang) experience. Architecture: Understanding of OpenTelemetry Collector architecture. AI/LLM: Familiarity with LangChain and prompt engineering for SLMs. Frontend: React.js experience.\n- Mentor(s):\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/7832\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/27ef67ba-24a4-4683-872e-d56bcc11d66a\n\n#### Upgrading Core Routing and State Management in Jaeger UI\n\nCNCF - Jaeger: Upgrade core routing and state management in Jaeger UI (2026 Term 1)\n\n- Description: This project focuses on modernizing the Jaeger-UI by upgrading its foundational routing and state management libraries. The primary goals are to migrate from legacy react-router patterns to React Router v7 and replace the deprecated history package and older Redux integration patterns with modern standards like redux-first-history. This refactoring will improve long-term maintainability, enhance performance, and simplify the code for one of the industry's most critical observability tools.\n- Expected Outcome: A fully migrated Jaeger-UI running on React Router v7, removal of deprecated history v4/v5 dependencies, refactored functional components using modern hooks (useNavigate, useParams), and a robust test suite ensuring no regressions in trace visualization or search functionality.\n- Recommended Skills: JavaScript/TypeScript & React: Deep familiarity with hooks and component lifecycles. State Management: Experience with Redux. Routing Knowledge: Understanding of SPAs and browser history APIs. Testing: Experience with React Testing Library or similar.\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n- Upstream Issue: https://github.com/jaegertracing/jaeger-ui/issues/3313\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d13df7c9-06d3-4589-bef8-c13e5c79c2a2\n\n\n### Karmada\n\n#### Enhance Karmada's Quick Start Experience and Incorporate macOS Support\n\nCNCF - Karmada: Enhance quick start experience and add macOS support (2026 Term 1)\n\n- 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.\nAlthough 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.\n- Expected Outcome:\n - 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.\n - 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.\n - Revise existing outdated scenarios on Killercoda and develop valuable new scenarios to guide users through current features. This includes:\n - Extracting common functions from various scenarios to reduce code duplication.\n - Updating the course information of existing scenarios by correcting outdated content and optimizing the material to enhance learning outcomes.\n - Adding new scenarios, such as:\n - A tutorial on FHPA usage.\n - An application-level failover guide.\n - Multi-component workload scheduling (support for workloads common in AI and big data).\n- Recommended Skills:\n - Go programming language\n - Familiarity with macOS\n - Bash/shell scripting\n - CI/CD systems (e.g., GitHub Actions)\n - Documentation tools and best practices\n- Mentor(s): \n - Zhuang Zhang (@zhzhuang-zju, m17799853869@163.com)\n - Hongcai Ren (@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/community/issues/170#issuecomment-3736732294\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/28f6a413-4190-40bd-9226-cdce5767e210\n\n#### OmniControl for Karmada Dashboard\n\nCNCF - Karmada: OmniControl for Karmada Dashboard (2026 Term 1)\n\n- 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.\nFor example:\n1. 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.\n2. 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.\nTherefore, 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.\n- Expected Outcome:\n - Comprehensive design and API documentation\n - Topology visualization of Karmada core resources and Kubernetes resources ([Karmada architecture diagram](https://karmada.io/docs/core-concepts/architecture/))\n - 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)\n - Member-cluster resource integration: users can view details of Kubernetes resources (including workloads, configs, and services) with the same UX\n - A demo showcasing abnormal resource distribution cases (e.g., insufficient GPU resources; one example is sufficient)\n- Recommended Skills:\n - Go\n - Kubernetes\n - React\n - CI/CD systems (GitHub Actions)\n - Documentation tools and best practices\n- Mentor(s): \n - Wenjiang Ding (@warjiang, 1096409085@qq.com)\n - Hongcai Ren (@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/dashboard/issues/227\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2fc906da-cc46-4606-8b8d-600b47ff0a95\n\n#### Protect Karmada Component Flags from Unexpected Changes\n\nCNCF - Karmada: Protect component flags from unexpected changes (2026 Term 1)\n\n- 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.\n- Expected Outcome: \n - Comprehensive flag documentation for all Karmada components (controller-manager, scheduler, karmada-search, webhook, aggregated-apiserver, descheduler, metrics-adapter, scheduler-estimator)\n - Automated flag extraction and documentation generation tool\n - CI/CD pipeline integration to detect and alert on flag changes\n - Documentation of flag lifecycle management (deprecation, removal)\n- Recommended Skills: \n - Go programming language\n - Kubernetes and its flag management patterns\n - Bash/shell scripting\n - CI/CD systems (GitHub Actions)\n - Documentation tools and best practices\n- Mentor(s):\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n - Hongcai Ren (@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/community/issues/170#issuecomment-3728029454\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/cb8a5f0e-fdd4-4e6d-b937-b98b2c80381e\n\n\n### kgateway\n\n#### Add support for Chaos Engineering/Fault Injection\n\nCNCF - kgateway: Add Chaos Engineering / fault injection support (2026 Term 1)\n\n- Description: This project focuses on adding fault injection support in kgateway, enabling platform operators and developers to test system resiliency under controlled failure scenarios. Fault injection allows teams to proactively identify weaknesses by introducing network latency, service errors, or resource constraints. This project will involve designing a configuration API for specifying fault injection rules, implementing support in the kgateway plugin framework, integrating with Envoy’s native fault injection capabilities, and creating documentation and examples to demonstrate practical use cases in Kubernetes environments.\n\nExpected Outcome:\n- Create a design doc outlining the proposed API for fault injection and present at a community meeting\n- Implement the fault injection plugin in kgateway, leveraging Envoy capabilities\n- Develop e2e tests to validate fault injection scenarios\n- Write developer-facing documentation with example configurations\n- Create blogs and tutorials demonstrating how to use Chaos Engineering in kgateway\n- Demo fault injection features during kgateway community meetings\n\nRecommended Skills:\n- Go\n- Kubernetes\n- Kubernetes Gateway API\n- Envoy\n\nMentor(s):\n- Primary Mentor: Omar Hammami (@puertomontt, omar.hammami@solo.io)\n- Secondary Mentor: Tim Flannagan (@timflannagan, tim.flannagan@solo.io)\n\n- Upstream Issue: https://github.com/kgateway-dev/kgateway/issues/11188\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b8acc432-094a-431a-877a-97f209893672\n\n#### Ecosystem Integrations & Tutorials for kgateway's AI Gateway\n\nCNCF - kgateway: Ecosystem integrations & tutorials for AI Gateway (2026 Term 1)\n\n- Description: This project focuses on creating clear, approachable, and practical documentation that shows how to integrate kgateway’s AI Gateway (agentgateway) with popular AI tools, developer UIs, and other CNCF ecosystem projects. Its aim is to make kgateway’s documentation more practical, discoverable, and reflective of real ecosystem usage, so users can better understand what’s possible and how kgateway fits into the broader AI and cloud-native landscape.\n\nExamples of integrations and tutorials include:\n- Open WebUI / OpenAI Codex / Claude Code: Step-by-step guides showing how to connect agentgateway to interactive UIs for testing, demos, and common integration patterns\n- Demonstrate how agentgateway fits into the CNCF ecosystem by integrating with tools such as:\n\t- Argo Rollouts: Update the Argo Rollout Gateway API guides with the latest agentgateway example config. Create docs using Argo Rollouts with AgentgatewayBackends for LLM providers and MCP servers. \n - KServe: Using agentgateway as an ingress for model serving, enabling rate limiting, authentication, and observability\n - Knative: Add a guide for setting up kgateway with agentgateway as a custom ingress gateway\n\n- Expected Outcome:\n- A series of integration guides and tutorials demonstrating how to use kgateway with AI developer tools and CNCF ecosystem projects\n- New examples, improvements, and documentation pages contributed to the kgateway documentation site\n- GitHub issues opened for usability gaps, missing documentation, and friction points discovered during hands-on testing\n- Live or recorded demo integrations presented during kgateway community meetings\n- Fun! 🎉\n\n- Recommended Skills:\n- Strong written communication skills\n- Interest in learning and exploring new projects! \n- Basic understanding of GitHub, Markdown, and technical blogging \n- (Bonus) Experience using any of the following: Open WebUI, OpenAI Codex, Claude Code\n- (Bonus) Experience with CNCF projects like Argo Rollouts, KServe and Knative \n\n- Mentor(s):\n - Primary Mentor: Nina Polshakova (@npolshakova, ninapolshakova@gmail.com)\n - Secondary Mentor: Art Berger (@artberger, art.berger@solo.io)\n\n- Upstream Issue: https://github.com/kgateway-dev/kgateway.dev/issues/606\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1c354620-3475-474a-9641-a0a93f6961cf\n\n#### Modernize and improve kgateway end-to-end testing\n\nCNCF - kgateway: Modernize and improve end-to-end testing (2026 Term 1)\n\n- Description: Kgateway has a large number of end-to-end (e2e) tests that functionally test the full end-to-end flow of various routing and policy features present for both supported dataplane proxies, Envoy and agentgateway.\n\n However, these tests have been implemented with a custom e2e framework which is starting to show some cracks, notably around the speed of execution and general obtuseness of the framework.\n\n This project will contain two main phases:\n 1. Analyze the gaps of the current custom e2e framework and work with kgateway maintainers to decide whether or not it is worth migrating to an alternative solution\n 2. Depending on the outcome of phase 1, identify a set of e2e tests to either migrate to the new framework or improve the execution of in the current framework\n\n This project will provide exposure to a wide range of features in kgateway as well as real-world experience with ensuring the kgateway project is providing rock solid reliability for its users!\n\n- Expected Outcome:\n - An approved design doc with a decision on whether to use the existing custom E2E framework vs. using an alternative approach\n - A set of e2e tests that have been migrated or modernized that will run as part of the kgateway CI pipeline\n - A well-defined pattern that can be followed for e2e tests that have not been worked on as part of this project\n\n- Recommended Skills:\n - Go\n - Kubernetes\n - Kubernetes Gateway API\n - End-to-end testing experience\n\n- Mentor(s):\n - Primary Mentor: Seth Heidkamp (@sheidkamp, seth.heidkamp@solo.io)\n - Secondary Mentor: Lawrence Gadban (@lgadban, lawrence.gadban@solo.io)\n\n- Upstream Issue: https://github.com/kgateway-dev/kgateway/issues/13351\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4343c10e-7c14-416f-b26b-6094312aa397\n\n\n### Kmesh\n\n#### Kmesh supports multi-clusters\n\nCNCF - Kmesh: Support multi-clusters (2026 Term 1)\n\n- Description: Kmesh, as a high-performance service mesh data plane, is now only supported for use in a single cluster. However, now that multi-cluster support for istiod has been realized, we are able to move forward with the multi-cluster adaptation of Kmesh to support the use of Kmesh in multi-cluster environments. Adaptation to the current multi-cluster production environment with LLM and large data.\n- Expected Outcome:\n - 1.Code for implementing the Kmesh multi-cluster feature\n - 1.1. Adapting to the Istio Multi-Cluster Function API\n - 1.2. Traffic Management in multi-cluster scenarios\n - 1.3. Use IPsec to ensure the security of node communication.\n - 2.userguide doc\n - 2.1. proposal\n - 2.2. userguide\n - 3.e2e test\n - 3.1. Unit Test of Feature Function\n - 3.2. E2E test code\n- Recommended Skills: go, docker , kind, service mesh\n- Mentor(s):\n - Mentor Name:\n - zhonghu xu(@hzxuzhonghu, zhhxu2011@gmail.com),\n - changye wu(@nlgwcy, wuchangye@huawei.com),\n- Upstream Issue: https://github.com/kmesh-net/kmesh/issues/1570\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/78522dca-df54-4fc6-a9f2-1ae05af77789\n\n#### Optimize long connection load balance and support more load balance algorithm\n\nCNCF - Kmesh: Optimize long connection load balancing (2026 Term 1)\n\n- Description: Kmesh employs eBPF for load balancing. However, at present it only supports short-lived connections and offers a limited range of load balancing algorithms. Consequently, we aim to support a broader range of load balancing capabilities.\n- Expected Outcome:\n - 1.Load balancing with load-dependent connections via eBPF.\n - 2.Support as many load balancing algorithms as possible\n - 2.1 Sticky Round Robin\n - 2.2 Weighted Round Robin\n - 2.3 ...\n - 3.Userguide and Proposal\n - 4.Unit Test and E2E test\n- Recommended Skills: go, docker , kind, service mesh\n- Mentor(s):\n - ZhenCheng Li(@LiZhenCheng9527, lizhencheng6@huawei.com),\n- Upstream Issue: https://github.com/kmesh-net/kmesh/issues/1571\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2df8e950-a1cc-4c2b-9cbe-15574ce001ad\n\n\n### Knative\n\n#### Enhancing the Knative Educational Game with Advanced EDA Patterns and Web Deployment\n\nCNCF - Knative: Enhance Knative Educational Game & web deployment (2026 Term 1)\n\n- Description: Knative provides a powerful event-driven platform, but learning its concepts, especially brokers and EDA patterns, can be challenging for beginners. The Knative Educational Game aims to simplify this learning curve through interactive gameplay that visually and conceptually demonstrates Knative components and event-driven patterns. \n\n An overview of the project was presented at the [KubeCon NA 2024](https://youtu.be/TTBKh6F4v-g?si=MRmx6a2YJsl7y0Q-), and several technical sketches, gameplay patterns, and level designs were created and implemented during the [LFX Mentorship of Spring 2025](https://github.com/knative-extensions/educational-game/blob/main/Levels/brainstorm.md).\n\n This project serves as the continuation of that work and is divided into two main parts:\n - The first part focuses on expanding and enhancing the game by implementing existing level designs, introducing advanced EDA patterns (like Outbox and DataRef patterns), designing assets as needed, and improving interactivity.\n - The second part focuses on deploying the game to the web, making it easily accessible for learners to try and share.\n\n- Expected Outcome:\n - A fully implemented and web-deployed Knative Educational Game by completing previously designed levels, and newly added EDA patterns (DataRef and Outbox).\n - Improved learning experience through interactive animations, sounds, and clear visualizations that make Knative Eventing concepts and real-world patterns easier to understand.\n - A Netlify hosted web deployment integrated into the Knative website.\n\n- Recommended Skills: Godot, Game Development, Event Driven Architecture, Graphic Design.\n\n- Mentor(s):\n - Ankita Jana (@ankitajana21 , ankitajana60@gmail.com)\n - Prajjwal Yadav (@prajjwalyd, prajjwalyd@gmail.com)\n\n- Upstream Issue: https://github.com/knative-extensions/educational-game/issues/52\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/414b7749-fe19-4874-a260-b6017c2c3242\n\n\n### krkn - Chaos\n\n#### Enhancing Krkn-AI Result Analysis with Interactive Visualization and Insights\n\nCNCF - krkn - Chaos: Krkn-AI Result Analysis with Visualization and Insights (2026 Term 1)\n\n- Description: [Krkn-AI](https://github.com/krkn-chaos/krkn-ai) generates rich but complex experiment outputs (JSON, CSV, YAML, graphs, and tables) capturing fitness scores, SLOs, health checks, and other metrics, which can be difficult for engineers to interpret and compare across experiments. Although recent work using LLMs to produce high-level textual summaries is helpful, text alone limits deeper exploration. This feature change proposes building an interactive analysis and visualization layer for Krkn-AI that transforms raw chaos experiment data into intuitive, explorable visual representations, enabling users to quickly understand system behavior, detect anomalies, and focus on the most impactful failure signals.\n- Expected Outcome: The outcome is to deliver a simple web-based GUI or generated report built from Krkn-AI result artifacts (JSON, CSV, YAML), featuring interactive visualizations for key metrics such as fitness scores, SLOs, and health checks, along with clear highlighting of important or abnormal results to guide users’ attention.\n- Recommended Skills: Python, Data Analysis and Visualization tools (e.g: pandas, matplotlib), Kubernetes (Basics)\n- Mentor(s):\n - Rahul Shetty (@rh-rahulshetty , rashetty@redhat.com)\n - Naga Ravi Chaitanya Elluri (@chaitanyaenr , nelluri@redhat.com)\n- Upstream Issue: https://github.com/krkn-chaos/krkn-ai/issues/74\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3a44c772-0447-4094-a5d3-dac1d41c3ab4\n\n\n#### Natural Language–Based Chaos Scenario Discovery\n\nCNCF - krkn - Chaos: Natural language chaos scenario discovery in krknctl (2026 Term 1)\n\n- Description: The objective of this internship task is to design and implement a feature of the\n[`[krknctl](https://github.com/krkn-chaos/krknctl)`](https://github.com/krkn-chaos/krknctl) tool that enables users to explore the project’s functionality by submitting queries in **natural language**.\nThe tool will analyze the user’s request and Identify the most relevant **chaos scenario**, if any.\n\n- Expected Outcome:\n - A **deterministic and lightweight solution** for natural language scenario discovery.\n - Improved robustness to vocabulary, phrasing, and semantic variations in user queries.\n - A measurable and extensible evaluation framework to support future improvements.\n - Clear documentation enabling future contributors to iterate on or extend the approach.\n- Recommended Skills:\n - Python and Go programming\n - Basic knowledge of **Natural Language Processing (NLP)**\n - Experience with **machine learning models for text classification or similarity**\n - Familiarity with **Docker** and containerized applications\n - Ability to write clean, testable, and well-documented code\n- Mentor(s):\n - Paige Patton (@paigerube14, ppatton@redhat.com)\n - Naga Ravi Chaitanya Elluri (@chaitanyaenr, nelluri@redhat.com)\n - Tullio Sebastiani (@tsebastiani, tsebasti@redhat.com)\n- Upstream Issue: https://github.com/krkn-chaos/krkn/issues/1051\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4550c85f-2451-47bd-9873-94b60f9cf701\n\n\n### kube-burner\n\n#### Enhancements around k8s performance testing\n\nCNCF - kube-burner: Enhancements around Kubernetes performance testing (2026 Term 1)\n\n- Description:\n We intend to get some help around open issues in the repository and also come up with new use cases and scenarios for performance testing any kubernetes distribution. We love new perspectives and are always open to new ideas alongside what we have as tracked work in github issues. \n\n For the purpose of this mentorship program term, we have created an umbrella issue that outlines some of the critical enhancements to the project.\n- Expected Outcome:\n To knock down some of open critical issues and bring in new perspective to the project. There are no restrictions while working with issues/enhancements.\n- Recommended Skills:\n - Golang\n - Kubernetes\n - Cloud Platforms\n- Mentor(s):\n - Vishnu Challa (@vishnuchalla, vchalla@redhat.com) \n - Raul Sevilla (@rsevilla87, rsevilla@redhat.com)\n- Upstream Issues: (https://github.com/kube-burner/kube-burner/issues/1079)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/8f651e4b-a0bf-468a-ab2b-a8167bd85e87\n\n\n### KubeEdge\n\n#### Batch Enable/Disable of EdgeHub on Edge Nodes via kubeedge/keadm\n\nCNCF - KubeEdge: Keadm: Batch enable/disable EdgeHub on edge nodes (2026 Term 1)\n\n- Description: In bandwidth limited environments, as the cluster size expands, communication between cloud and edge nodes in KubeEdge consumes a significant amount of network resources, which may interfere with upper layer business applications. To alleviate this issue, it is necessary to implement batch enable or disable the EdgeHub edge node feature in keadm. Administrators can temporarily take edge nodes offline by turning off the EdgeHub switch, thereby releasing the bandwidth required for critical services. This feature should support adding subcommands in keadm for implementation.\n- Expected Outcome: A keadm extension that provides commands or APIs to batch enable/disable the EdgeHub switch on specified edge nodes.\n- Recommended Skills: Golang, KubeEdge\n- Mentor(s):\n - Zhijia Yang (@luomengY, 2938893385@qq.com)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6609\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e7dd489f-a50e-4dd7-aad2-174112862118\n\n#### Cloud-Edge Simulation Benchmark for LLM Speculative Decoding in KubeEdge-Ianvs\n\nCNCF - KubeEdge: Ianvs: Cloud-edge benchmark for LLM speculative decoding (2026 Term 1)\n\n- Description: \n LLM inference acceleration is increasingly important for cloud-edge collaborative AI deployments. Speculative decoding can improve end-to-end generation speed by using a lightweight draft model to propose token candidates and a larger target model to verify them, but its real-world gains depend heavily on cloud-edge constraints such as network latency, bandwidth limits, and heterogeneous compute. \n Ianvs provides a unified benchmarking framework, and KubeEdge scenarios often require evaluating AI workloads under cloud-edge conditions. This project proposes a single-host cloud-edge simulation benchmark in Ianvs to evaluate speculative decoding for LLM inference. The benchmark will simulate edge (draft) and cloud (verify) roles as separate processes, inject configurable network constraints, and report standardized throughput and latency metrics, enabling reproducible comparison between baseline decoding and speculative decoding under different cloud-edge budgets.\n- Expected Outcome: \n - An Ianvs benchmark test case for cloud-edge speculative decoding (PyTorch + HuggingFace).\n - A single-host simulation runner that emulates edge/cloud roles and configurable network constraints (e.g., latency, bandwidth).\n - Benchmark reports comparing baseline vs speculative decoding with key metrics (e.g., TTFT, end-to-end latency, tokens/s), and reproducible configs/scripts.\n- Recommended Skills: Python, PyTorch, HuggingFace Transformers, LLM inference/decoding, benchmarking & performance profiling, KubeEdge/Ianvs basics\n- Mentor(s):\n - Shijing Hu (@hsj576, sjhu21@m.fudan.edu.cn)\n - Zimu Zheng (@MooreZheng, zimu.zheng@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/304\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fe439c9b-819f-43c3-b42d-b9b0c0b7afb0\n\n#### Comprehensive Example Restoration for KubeEdge Ianvs\n\nCNCF - KubeEdge: Ianvs: Comprehensive example restoration (2026 Term 1)\n\n- Description: Ianvs serves as the KubeEdge SIG AI distributed benchmark toolkit. As more and more contributors running, KubeEdge Ianvs now has 25 examples, and the number is still increasing. KubeEdge Ianvs then faces mounting usability issues due to dependency evolution and validation mechanisms. As Python versions, third-party libraries, and Ianvs features advance, partial historical examples fail to execute. This has led to surging user-reported Issues from confused contributors, untested PRs breaking core functionality of legacy features, and severely outdated documentation misaligning with actual capabilities. Without systematic intervention, the example risks becoming obsolete for edge-AI developers and especially newcomers. We then try to resurrect Ianvs’ usability with a comprehensive example restoration.\n- Expected Outcome: \n - Diagnose & fix bugs across examples, including dependency manifests, license scan, and runtime configurations.\n - Documentation Modernization, including revamp tutorials with reproducible step-by-step guides, publish developer-focused debugging playbooks for common failures. Write and upload the corresponding blog to the KubeEdge Website.\n - Advanced: Build a CI pipeline testing examples with GitHub Actions against multiple Python versions, critical Ianvs/upstream updates, and block PRs that break validated examples\n - Optional: Preparing KubeEdge SIG AI speaking and marketing materials for open-source community events like KCD Days 2026 (in Beijing, thus writing and speaking skills in Mandarin would be a plus).\n- Recommended Skills: Python, Benchmark, KubeEdge-Ianvs, AI/ML\n- Mentor(s):\n - Zimu Zheng (@MooreZheng, zimu.zheng@huawei.com)\n - Shijing Hu (@hsj576, sjhu21@m.fudan.edu.cn)\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/230\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9826762a-9960-4310-9d94-8d626b387a1c\n\n#### Enable and Verify KubeEdge Support on RISC-V Architecture \n\nCNCF - KubeEdge: Enable and verify KubeEdge support on RISC-V (2026 Term 1)\n\n- Description: With the rapid growth of the RISC-V ecosystem, an increasing number of eage computing devices and IoT boards are adopting RISC-V. In very early versions of KubeEgde, we briefly verified compatibility with RISC-V. However, this has not been continuously validated in recent releases. As the codebase has evolved significantly, we need to re-establish and solidify support for this architecture to ensure KubeEdge can run seamlessly on the next generation of open hardware.\n- Expected Outcome:\n - Deploy and run KubeEdge on actual RISC-V devices. Fix identified issues and submit PRs.\n - Generate official release assets (binaries) and multi-arch images for RISC-V.\n - Output a guide as a blog or docs about how to run KubeEdge on RISC-V to the kubeedge/website.\n - (optional) Explore how to add a basic verification step for RISC-V in KubeEdge GitHub Actions CI.\n- Recommended Skills: KubeEdge, Operation System\n- Mentor(s):\n - Hongbing Zhang (@HongbingZhang, hongbing.zhang@daocloud.io)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6614\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5f891584-5ffa-4f7c-87ca-765962d2d467\n\n\n### Kubernetes\n\n#### Cluster API Provider AWS (CAPA)\n\n##### Add OpenTelemetry support\n\nCNCF - Kubernetes: CAPA: Add OpenTelemetry support (2026 Term 1)\n\n- Description: Cluster API Provider AWS (CAPA) enables the creation of Kubernetes clusters in AWS with Cluster API. With increasing adoption of Cluster API (CAPI) in general and of CAPA we want to improve the supportability of CAPA, especially for production environments. The first part of this is to add telemetry/tracing using OpenTelemetry so that we can understand and visualize the flow of reconciliation within the provider. This will enable the project and its end users to understand the behavior of reconciliation (including API services called) and will help diagnose issues and performance problems.\n- Expected Outcome: An implementation of OpenTelemetry in CAPA with associated documentation that has been released in a new version of CAPA.\n- Recommended Skills: Golang, Kubernetes, AWS\n- Mentor(s):\n - Richard Case (@richardcase, richmcase@gmail.com)\n - Daniel Lipovetsky (@dlipovetsky, daniel.lipovetsky@gmail.com )\n- Upstream Issue: https://github.com/kubernetes-sigs/cluster-api-provider-aws/issues/2178\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e60d11ff-bf0a-47d6-a873-0583428c8cb3\n\n\n#### Cluster API Provider AWS (CAPA)\n\n##### Improve AMI Publication and Maintenance\n\nCNCF - Kubernetes: CAPA: Improve AMI publication and maintenance (2026 Term 1)\n\n- Description: Cluster API Provider AWS (CAPA) enables the creation of Kubernetes clusters in AWS with Cluster API. CAPA allows you create EKS and non-EKS based Kubernetes clusters. When creating a non-EKS cluster we must use AMIs for the nodes in the cluster. The project publishes some AMIs for non-production use. However, the process for publishing the AMIs needs improvment. Firstly we want to fully automate the publication of new AMIs when there is a new Kubernetes version available. Secondly, we need to implement the \"AMI Publication Policy\" for the project which will involve automated house keeping of AMIs. And thirdly we want to add back support for base operating systems that where temporarily dropped.\n- Expected Outcome: Automated AMI publication and deletion inline with the projects policy. Support for additional operating systems.\n- Recommended Skills: AWS, GitHub Actions, Packer, Ansible, Kubernetes\n- Mentor(s): \n - Richard Case (@richardcase, )\n- Upstream Issue: \n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/396fa725-9739-4f83-ac99-314ef1952e35\n\n\n#### Kubespray\n\n##### Automate building OS images for supported/CI tested distribution\n\nCNCF - Kubernetes: Kubespray: Automate OS image pipeline for CI (2026 Term 1)\n\n- Description: This feature request aims to automate the building and publishing of OS images that are used in Kubespray CI testing. Currently, these images (defined in `test-infra/image-builder/roles/kubevirt-images/defaults/main.yml`) must be manually created and pushed by maintainers. Automating this process would reduce manual work, eliminate bottlenecks when maintainers are unavailable, and could include automatic cleanup of outdated or unused images, while still retaining images needed for older supported release branches. \n- Expected Outcome: A CI job (likely post-merge and possibly periodic) that automatically:\n\t1.\tBuilds the required Kubespray OS images used in CI for tested distributions.\n\t2.\tPushes these built images to the appropriate registry.\n\t3.\tCleans up old or no longer needed images but retains those required for supported release branches.\nThis workflow should remove the need for maintainers to manually create and manage these images.\n- Recommended Skills: Ansible, GitLab CI, Python\n- Mentor(s):\n - ChengHao Yang (@tico88612, tico88612@gmail.com)\n - Kay Yan (@yankay, yankaycom@gmail.com)\n - Max Gautier (@VannTen, mg@max.gautier.name)\n- Upstream Issue: https://github.com/kubernetes-sigs/kubespray/issues/12383\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d90c31a1-4027-4602-a318-48459008d3a7\n\n\n#### Headlamp\n\n##### Add Kubeflow to Headlamp: Machine Learning Workflow Management UI\n\nCNCF - Headlamp: Add Kubeflow to Headlamp: ML workflow management UI (2026 Term 1)\n\n- Description:\n Build a Headlamp plugin to surface Kubeflow resources (Pipelines, Katib, PipelineRuns, Notebooks, TFJob/PyTorchJob/TrainJob, Spark) so operators and ML engineers can discover, monitor, and manage ML workloads alongside standard K8s resources. Link to Kubeflow UIs when deeper functionality is needed.\n\n- Expected Outcome:\n - New Kubeflow sidebar with cross-namespace lists for Pipelines (Experiments, Runs), Katib experiments, Notebook servers, Training and Spark jobs.\n - Detail pages per resource showing metadata, status, metrics, logs and common actions (start Run, open Jupyter, view best hyperparams).\n - Links/embed to Kubeflow Central Dashboard or Pipelines UI for advanced tasks.\n - Headlamp Map integration: show relations to Deployments/Pods, Argo workflows, Spark driver/executors.\n - Metrics via Prometheus or /metrics: basic charts for experiment objectives and pod resource use.\n - Polished UX: icons, pagination, filtering, error handling.\n - Outreach: README/User Guide and a demo blog post with screenshots.\n\n- Recommended Skills:\n - TypeScript + React\n - (Optional) Kubernetes fundamentals.\n - (Optional) Knowledge of Kubeflow and its sub-projects (Pipelines, Katib, etc.).\n - (Optional) Basic understanding of Prometheus metrics.\n\n- Mentor(s):\n - Rene Dudfield (@illume, renedudfield@microsoft.com)\n - Adwait Godbole (@adwait-godbole, adwaitngodbole@gmail.com)\n - Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n - Ashu Ghildiyal (@ashu8912, ashu.ghildiyal@microsoft.com)\n - Tarek Abouzeid (@tarekabouzeid, tarek.abouzeid91@gmail.com)\n\n- Upstream Issue: \n - https://github.com/kubernetes-sigs/headlamp/issues/3710\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/abe20383-80fd-496c-8a5a-453fcb732f55\n\n\n##### Add Strimzi to Headlamp: Kubernetes Kafka Management UI\n\nCNCF - Headlamp: Add Strimzi to Headlamp: Kubernetes Kafka management UI (2026 Term 1)\n\n- Description:\n Strimzi is a Kubernetes Operator for running Apache Kafka. This project builds a Headlamp plugin that adds a **Strimzi** section to Headlamp, surfacing Strimzi CRDs so operators can **view and manage Kafka clusters, topics, users, and connectors** from the Headlamp UI. The plugin follows Headlamp UX patterns with list and detail views, links between related resources, and optional metrics embedding.\n\n- Expected Outcome:\n - Plugin exposes key Strimzi CRDs: Kafka, KafkaTopic, KafkaUser, KafkaConnect, and KafkaConnector.\n - List views, with summary columns (name, namespace, brokers, partitions, replication, status).\n - Detail pages, showing config, status conditions, sub-resources (broker pods, connectors), and basic actions (create/edit topic, regenerate user creds).\n - Relational navigation, cluster → topics/users; topic → cluster.\n - Consistent Headlamp UX, icons, tables, detail layouts, Map view enhancements.\n - Structured config display (collapsible sections/YAML toggle), humanized statuses, validated forms for mutating actions.\n - README with prerequisites and limitations; blog post demoing usage.\n\n- Recommended Skills:\n - TypeScript and React\n - (Optional) Familiarity with Kubernetes CRDs and Operators\n - (Optional) Knowledge of Apache Kafka concepts\n - (Optional) UX design sensibilities\n\n- Mentor(s):\n - Rene Dudfield (@illume, renedudfield@microsoft.com)\n - Jakub Scholz (@scholzj, github@scholzj.com)\n - Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n - Ashu Ghildiyal (@ashu8912, ashu.ghildiyal@microsoft.com)\n\n- Upstream Issue: \n https://github.com/headlamp-k8s/plugins/issues/488\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2f08a480-7e37-46f0-ab29-f3d18669dd17\n\n\n##### Add Cluster API to Headlamp: Cluster Lifecycle Management UI\n\nCNCF - Headlamp: Add Cluster API to Headlamp: Cluster lifecycle management UI (2026 Term 1)\n\n- Description:\n Cluster API (CAPI) provides declarative APIs and tooling to provision, upgrade, and operate Kubernetes clusters. This project continues an existing Headlamp plugin to deliver first-class UI support for CAPI resources (Clusters, Machines, MachineDeployments, KubeadmControlPlanes). The plugin will let operators discover, inspect, and manage cluster lifecycle objects in Headlamp, visualizing hierarchical relationships and closing gaps in the plugin.\n\n- Expected Outcome:\n - Sidebar and Map: List key CAPI CRs in the sidebar and Map view; show Clusters with Machines, MachineSets/Deployments, and control planes. \n - Resource details: Dedicated pages with CAPI-specific fields (conditions, infra refs, provider info, control plane refs, node pools, cluster membership, provider status).\n - UI integration: Map visualization, sidebar icons, on-hover \"Glance\" tooltips. \n - Robustness and tests: Fix runtime errors, human-friendly fields (e.g., \"2d5h\"), add automated tests. \n - Polish and delivery: Refined tables, icons, clickable \"Controlled by\" links; packaged in Headlamp’s plugin repo with install and developer docs; Kubernetes Blog post showcasing benefits.\n\n- Recommended Skills:\n - TypeScript + React\n - (Optional) Headlamp UI/plugin development, or other open source development\n - (Optional) Kubernetes fundamentals (CRDs, controllers, RBAC)\n - (Optional) Familiarity with Cluster API concepts (Cluster, Machine, MachineDeployment, etc.)\n\n- Mentor(s):\n - Matt.Boersma (@mboersma, Matt.Boersma@microsoft.com)\n - Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n - Rene Dudfield (@illume, renedudfield@microsoft.com)\n - Ashu Ghildiyal (@ashu8912, ashu.ghildiyal@microsoft.com)\n\n- Upstream Issue: \n https://github.com/headlamp-k8s/plugins/issues/485\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/250e2884-e196-4788-b8dd-fe9c5edb237d\n\n\n##### Polish Knative support in Headlamp: Serverless Workload Management UI\n\nCNCF - Headlamp: Polish Knative support in Headlamp: Serverless workload management UI (2026 Term 1)\n\n- Description: \n Knative enables serverless on Kubernetes (scale-to-zero, traffic splitting). This project finishes and polishes a Headlamp plugin so operators can **view, inspect, and manage Knative Services, Revisions, Configurations, and Routes** from Headlamp, complementing the `kn` CLI. Builds on an existing plugin.\n\n- Expected Outcome:\n - Fully functional Knative plugin: in the Headlamp repo with a \"Knative\" sidebar. List KServices across namespaces with key columns (name, URL, traffic %, latest revision status) matching existing tools.\n - Service detail pages: showing URL, traffic split, concurrency/scaling, conditions; UI actions to adjust traffic, edit config/env/concurrency, and trigger redeploys via forms/modals with feedback and RBAC checks.\n - Related resources: list/link Revisions, Configurations, HTTPRoute/Knative Route; optional read-only revision/config views.\n - Headlamp-consistent UX: Map/metrics integration, bug fixes, basic tests, packaged metadata, ArtifactHub releases, README, and a kubernetes blog post with a short demo.\n\n- Recommended Skills:\n - TypeScript and React\n - (Optional) **Kubernetes and Knative** – understanding concepts like Knative Service, Revision, traffic splitting, autoscaling, and how they are represented in \"CRDs\"\n - (Optional) Design and UX\n\n- Mentor(s):\n - Kahiro Okina (@kahirokunn, okinakahiro@gmail.com)\n - Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n - Rene Dudfield (@illume, renedudfield@microsoft.com)\n - Ashu Ghildiyal (@ashu8912, ashu.ghildiyal@microsoft.com)\n\n- Upstream Issue: \n https://github.com/headlamp-k8s/plugins/issues/486\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b6178852-f18d-41e2-b352-c839b8570eae\n\n\n#### Kubernetes SIG Docs – Localization Subproject\n\n##### AI-Era Localization Automation for SIG Docs Contributors & Reviewers\n\nCNCF - Kubernetes: SIG Docs Localization: AI-era localization automation (2026 Term 1)\n\n- Description:\n\nThis project focuses on improving localization workflows in Kubernetes SIG Docs by strengthening visibility, prioritization, and traceability across English and localized documentation. The enhanced workflows will benefit to reducing review burden and coordination costs that arise in environments where upstream content changes and subsequent localization efforts occur asynchronously. The project also explores practical approaches to achieving measurable productivity gains by adopting AI-assisted tools within established human workflows.\n\nMentees work with mentors in SIG Docs localization to improve existing localization review and coordination processes, such as label-based coordination and review signals implemented through Prow/CI. The project focuses on the following core areas: improving traceability between frequently changing English content and localized documentation, continuously tracking and notifying review priorities for translation updates, and maintaining visibility into localization coverage and prioritization based on document importance. All outcomes are designed to integrate naturally into existing SIG Docs GitHub workflows and practices while preserving and supporting human-led review and decision-making.\n\n- Expected Outcome:\n - Reusable Prow/CI automation prototypes\n - Review-assist jobs and bots designed to be reusable across SIG Docs localization workflows.\n\n - Extensible architecture\n - Clear separation between core workflow logic and language-specific rules.\n\n - Best practices documentation\n - Guidance on improving localization workflows through supportive tooling and operational practices, while preserving human review, contributor growth, and community sustainability.\n\n- Recommended Skills:\n - Basic understanding of Kubernetes documentation structure and contribution flow.\n - Git/GitHub workflows (issues, pull requests, review comments).\n - Familiarity with at least one programming or scripting language for automation (e.g., Go, Python, JavaScript).\n - Experience contributing to documentation localization (translation, review, or L10n process improvements).\n - Curious about improving productivity on documentation and localization through tools (e.g., linters, AI-assisted tools), workflows, and process improvements.\n\n- Mentor(s)\n - Ian Y. Choi (@ianychoi, ianyrchoi@gmail.com)\n - Wonyong Hwang (@wonyongg, kakaohwy@gmail.com)\n - Eunjeong Park (@Eundms, eunjeongpark.eundms@gmail.com)\n - Seokho Son (@seokho-son, shsongist@gmail.com)\n- Upstream Issue: https://github.com/kubernetes/website/issues/54075\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c71fdb2a-8e77-447d-ae8b-3e977e0fd86a\n\n\n### KubeStellar\n\n#### Documentation and Self-Service Enablement Specialist\n\nCNCF - KubeStellar: Documentation and self-service enablement specialist (2026 Term 1)\n\n- Description: : KubeStellar is a Kubernetes-native multi-cluster synchronization platform. This project focuses on creating a frictionless onboarding experience, enabling first-time users to deploy KubeStellar end-to-end in under 30 minutes using only self-service documentation. The work includes deployment audits, Quickstart optimization, interactive tutorials, video guides, and structured troubleshooting, use-case, and migration documentation to improve adoption and reduce support overhead. \n- Expected Outcome: A validated ≤30-minute Quickstart guide, an interactive hands-on tutorial with automated checks, a 5–7 module video series, a 20-issue troubleshooting guide, 5 production-ready use-case patterns, 3 migration guides from common multi-cluster setups, and measurable onboarding success (≤30 min time-to-first-success, ≥4/5 user satisfaction). \n- Recommended Skills: Kubernetes deployment and troubleshooting, strong technical writing, Markdown-based documentation tools (Docusaurus/Nextra), user-centric documentation design video, DevOps or DevRel background a plus\n- Mentor(s): \n - Saumya Kumar (@oksaumya, saumyakr2006@gmail.com)\n - Nupur Shivani (@Nupurshivani, nupurjha.me@gmail.com)\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n- Upstream Issue: https://github.com/kubestellar/kubestellar/issues/3521\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7a1357be-6d84-439a-8cad-4f9b90d491c9\n\n#### Integration and Ecosystem Development Specialist\n\nCNCF - KubeStellar: Integration and ecosystem development specialist (2026 Term 1)\n\n- Description: Reduce adoption friction by building integrations between KubeStellar and popular Kubernetes ecosystem tools. The mentee will survey early users to identify integration priorities, design integration architectures, develop working integrations with tools like GitOps platforms, Terraform, CI/CD systems, or monitoring solutions, create comprehensive documentation and examples, and validate integrations with real users. This program emphasizes software development, API integration, understanding ecosystem tools, and creating seamless user experiences.\n\n- Expected Outcome: 2 production-ready integrations with popular Kubernetes tools, Integration documentation with clear setup guides for each, 2 demo videos demonstrating integration value and setup, Sample implementations and templates for common scenarios, 3 users actively adopting each integration, Submissions to relevant tool marketplaces where applicable, Integration maintenance guide for ongoing support, User feedback on integration quality and usefulness, User engagement: 6 GitHub issues filed by integration users, 4 PRs or PR reviews contributed by integration users\n\n- Recommended Skills: Strong programming skills (Go preferred), Experience with GitOps/CI/CD/infrastructure tools, API integration and software development experience, Understanding of Kubernetes ecosystem and tooling, Technical documentation writing, Open source contribution experience helpful\n\n- Mentor(s): \n - Andy Anderson (@clubanderson, andy@clubanderson.com) \n - Naman Jain (@naman9271, namanjain9271@gmail.com)\n - Onkar Shelke (@onkar717, onkarwork2234@gmail.com)\n \n- Upstream Issue: https://github.com/kubestellar/kubestellar/issues/3501\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1cf30f20-dea9-42ae-a115-2747d6755d9c\n\n\n### Kyverno\n\n#### DevRel\n\nCNCF - Kyverno: DevRel (junior) mentorship (2026 Term 1)\n\n- Description: \n Option 1: General Junior DevRel Mentorship\n\n This mentorship is designed for a junior Developer Relations or community-focused contributor who wants hands-on experience supporting a fast-growing open source project in the cloud native ecosystem. The mentee will work closely with the Kyverno maintainers and community to improve the overall developer and end-user experience through better documentation, tutorials, example content, and community-facing resources.\n\n The mentee will contribute upstream to Kyverno by helping create clear getting-started guides, improving existing documentation, supporting educational content such as blogs or walkthroughs, and assisting with community enablement initiatives. The mentorship focuses on foundational DevRel skills including technical communication, open source contribution workflows, user empathy, and translating complex technical concepts into approachable learning materials, while building a visible portfolio of real-world open source contributions. \n\n Option 2: Concise Version of the CEL-Focused Mentorship (1–2 Paragraphs)\n This mentorship offers a junior DevRel contributor the opportunity to work directly with the Kyverno community to support the adoption of Kyverno’s new CEL-based policy capabilities. The mentee will help create and refine documentation, tutorials, and example content that make it easier for new users to get started with CEL policies and for existing users to migrate from traditional policy types to CEL policies.\n\n Working upstream with Kyverno maintainers, the mentee will gain hands-on experience with Kubernetes policy, developer education, and open source collaboration, while learning core DevRel skills such as technical storytelling, community-focused documentation, and content-driven adoption.\n\n- Recommended Skills: \n - Technical communication\n - Documentation and content creation\n - Kubernetes policy knowledge\n\n- Mentor(s): \n - Cortney Nickerson (@CortNick, cortney.nickerson@nirmata.com)\n - Mariam Fahmy (@MariamFahmy98, mariamfahmy66@gmail.com)\n\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/14726\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5c1581e3-04c2-40ed-ab50-b888e02f973f\n\n\n#### Test Enhancements - Kyverno CLI Tests - envtest, fake client\n\nCNCF - Kyverno: Test enhancements: Kyverno CLI tests with envtest/fake client (2026 Term 1)\n\n- Description: The Kyverno CLI should be flexible enough to perform real variable substitutions when CEL libraries are used in policies, in addition to static substitutions. This enhancement would enable comprehensive policy testing without requiring a real Kubernetes cluster, significantly speeding up development and CI/CD pipelines.\n\n- Recommended Skills: \n - Golang\n - Kubebernetes\n - Cobra\n - fake client\n - envTest\n\n- Mentor(s): Shuting Zhao (@realshuting, shuting@nirmata.com)\n\n- Upstream Issue: \n - https://github.com/kyverno/kyverno/issues/14629\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/206776e3-e3c2-4418-8536-2ce9642302eb\n\n\n#### Test Enhancements - Testing Framework / Toolset for integration tests\n\nCNCF - Kyverno: Test enhancements: integration test framework/toolset (2026 Term 1)\n\n- Description: Currently Kyverno uses Chainsaw as the primary testing tool, which executes end-to-end tests on a real cluster. While this provides a large test coverage, it takes a long time to be executed and is also used to test very basic/simple cases. This project is about creating a framework to allow and simplify the creation of integration tests on the code level, without spinning up an actual cluster. This allows easier and faster testing locally as well as in our CI pipelines.\n\n- Recommended Skills: \n - Go tests\n - CLI \n- Mentor(s): \n - Frank Jogeleit (@fjogeleit, frank.jogeleit@nirmata.com)\n - Ammar Yasser (@aerosouund, ammar.yasser@nirmata.com)\n\n- Upstream Issue: \n - https://github.com/kyverno/kyverno/issues/14725\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/72445950-34e9-4e80-82ef-251882464336\n\n\n### LitmusChaos\n\n#### Add Prometheus Metrics to LitmusChaos Control Plane Service \n\nCNCF - LitmusChaos: Add Prometheus Metrics to Control Plane Service (2026 Term 1)\n\n- Description: Expose service health, API observability and experiment execution data as prometheus metrics in the chaos manager/litmusportal server\n- Expected Outcome: Public Grafana dashboard for LitmusChaos observability\n- Recommended Skills: Golang, Kubernetes, Prometheus, Chaos Engineering\n- Mentor(s):\n - Shubham Chaudhary (@ispeakc0de, shubham.chaudhary@harness.io)\n - Adarsh Kumar (@Adarshkumar14, adarsh.kumar@harness.io)\n- Upstream Issue: https://github.com/litmuschaos/litmus/issues/5338\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9e3e1e1c-e04b-401e-8eba-edc5894fdf9f\n\n\n### Meshery\n\n#### Adapter for AI and LLMs\n\nCNCF - Meshery: Adapter for AI and LLMs (2026 Term 1)\n\n- Description: Meshery is the open-source cloud native manager that empowers platform engineers to design and operate infrastructure. As infrastructure complexity grows, the need for intelligent assistance becomes critical. This project focuses on developing and enhancing a dedicated AI Adapter and AI Connections for Meshery. This adapter serves as the bridge between Meshery’s core orchestration engine and various Large Language Models (LLMs). The goal is to enable \"Natural Language to Infrastructure\" capabilities, allowing users to describe their architectural intent (e.g., \"Deploy a highly available Kubernetes cluster on AWS with Prometheus monitoring\") and have Meshery auto-generate the visual topology and configuration manifests. The intern will work on decoupling the AI logic from the core platform, allowing users to \"Bring Your Own Model\" (BYOM)—supporting both cloud-based providers (OpenAI, Anthropic) and local inference runners (Ollama, LocalAI).\n- Recommended Skills:\n - Proficiency in Golang (Go) is essential, as Meshery’s backend is written in Go.\n - Familiarity with MCP Servers, REST APIs, LLM APIs (OpenAI, Vertex AI), local inference servers (Ollama).\n - Basic understanding of Kubernetes, Docker, and Infrastructure-as-Code (IaC) concepts.\n - Experience with REST, GraphQL, and gRPC.\n - Nice to have: Experience with React (for frontend integration in Meshery UI).\n- Responsibilities:\n - Co-design and implement the interface for the AI Adapter in Go to communicate with the Meshery Server.\n - Implement support for connecting to local LLMs (via Ollama) to ensure data privacy for users who cannot send infrastructure data to the public cloud.\n - Improve the \"System Prompt\" and context-window management to feed the LLM relevant data regarding Meshery Models (schema definitions) so the AI generates valid infrastructure configurations.\n - Write unit and integration tests to ensure the reliability of the adapter.\n - Create user guides on how to configure the adapter with different AI providers.\n- Expected Outcome:\n - A fully functional AI Adapter (or Connection) integrated into the Meshery ecosystem.\n - Demonstrable capability for users to swap between at least two different LLM providers (e.g., OpenAI vs. a local Llama 3 model).\n - Implementation of a feature where natural language queries result in a rendered design.\n - Merged pull requests (PRs) including code, tests, and documentation.\n Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Rian Cteulp (@ritzorama, rian.cteulp@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/17097\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a1320a25-58eb-48d6-ab0d-3c78a0e410cb\n\n\n#### Graph Database Integration\n\nCNCF - Meshery: Graph Database Integration (2026 Term 1)\n\n- Description: Meshery's *MeshSync* component acts as the real-time discovery engine, maintaining an up-to-date snapshot of all managed infrastructure. Currently, mapping the complex relationships between these resources (e.g., a Service selecting Pods which are mounted to PVCs) relies on relational or in-memory lookups that can become inefficient at scale. This project involves integrating a dedicated graph database (or an embedded graph processing library) into Meshery's architecture. The goal is to ingest discovered Kubernetes resources as \"nodes\" and their associations (OwnerReferences, Label Selectors, Annotations) as \"edges.\" This shift will enable highly efficient traversal and querying of infrastructure data, powering more advanced capabilities like topology visualization, impact analysis, and dependency mapping.\n- Recommended Skills:\n - Strong proficiency in Golang as both MeshSync and Meshery's Kubernetes operator are written in Go.\n - Understanding of openCypher, graph theory and Graph Databases (e.g., NebulaGraph, or embedded Go graph libraries like `gonum` or `cayley`).\n - Strong familiarity with Kubernetes Controllers, Informers, and the Object Model (GVK/GVR).\n - Experience and competency with GraphQL\n- Responsibilities:\n - Refactor the MeshSync ingestion layer to map incoming Kubernetes objects to graph nodes and generate edges based on semantic relationships (e.g., `Service` -> `Pod`).\n - Integrate Meshery Relationships as first-class citizens in the graph schema to represent higher-level associations.\n - Implement the storage interface in the Meshery Operator to persist these graph structures efficiently.\n - Develop new GraphQL resolvers in the Meshery Server that utilize graph traversal queries to fetch topology data.\n- Expected Outcome:\n - Fully-functional datastores of discovered cluster data into a graph structure.\n - Benchmarks demonstrating improved performance for complex relationship queries compared to the existing relational implementation.\n - Successful rendering of the infrastructure topology in Meshery UI using data fetched from the new graph backend.\n - Comprehensive documentation covering the new graph schema and query patterns.\nMentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), James Horton (@hortison, james.horton2337@gmail.com)\nIssue: https://github.com/meshery/meshery/issues/17098\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/90c028e7-967c-4240-aab9-9169742ecb8c\n\n\n#### Migration of docs.meshery.io from Jekyll to Hugo\n\nCNCF - Meshery: Migration of docs.meshery.io from Jekyll to Hugo (2026 Term 1)\n\n- Description: The Meshery documentation [docs.meshery.io](https://docs.meshery.io) is a critical resource for users and contributors. Currently built using Jekyll, the site faces limitations in build speed, scalability, and long-term maintainability. Hugo, a modern static site generator, offers significantly faster build times, better content organization, and an improved developer experience. This internship focuses on migrating the entire [docs.meshery.io](https://docs.meshery.io) site from Jekyll to the Hugo framework, using docs.layer5.io (already implemented in Hugo) as a reference architecture. The migration will involve porting all documentation content, assets, layouts, and configuration while preserving URLs, SEO, contributor workflows, and existing auto-generated documentation files.\n- Expected Outcome: \n 1. Revamp of documentation set information architecture. Alignment with Diataxis framework.\n 2. Updated contributor docs.\n 3. All self-documenting aspects accounted for:\n 1. Compatibility tests of Meshery Adapters.\n 2. End-to-end tests of Meshery UI.\n 3. Integration of Meshery Catalog and all designs.\n 4. Publication of community discussion forum activity per category.\n 5. Integration of Meshery Models (Integrations)\n- Recommended Skills: Static site generators (Jekyll and Hugo), Markdown, HTML/CSS, Git/GitHub workflows, documentation engineering, basic Go templating (Hugo), CI/CD familiarity.\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Kate Suttons (@suttonskate, kate.suttons2337@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/17095\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c235efc7-da60-4eb2-814f-5aa8e1ac903e\n\n\n#### Relationships for AWS services\n\nCNCF - Meshery: Relationships for AWS services (2026 Term 1)\n\n- Description: Meshery Models are declarative representations of infrastructure and applications. Within these models, Relationships define how different Components (e.g., Kubernetes resources, Cloud services) interact and depend on each other. These relationships are crucial for visualizing, understanding, and managing complex cloud native systems. This internship focuses on significantly expanding the breadth and depth of Meshery Relationships across a wide array of technologies supported by Meshery. As Meshery continues to integrate with more cloud-native technologies (Kubernetes, public clouds, and all CNCF projects), there's a growing need to accurately model the intricate relationships between their components - vital for providing users with comprehensive insights and control over their deployments.\n- Recommended Skills: DevOps, systems administration, solutions architecture. Experience with Kubernetes, AWS and its services.\n- Responsibilities:\n - Research and Analyze Technologies: Dive deep into various cloud-native technologies (e.g., different compute services, databases, messaging systems, network services, etc.) to understand their components and how they interconnect.\n - Develop Relationship Definitions: Create and contribute relationship definitions, typically in JSON or YAML format, to the Meshery models. \n - Model Inter-Technology Interactions: Focus particularly on defining relationships between components from different technologies (e.g., how a Kubernetes deployment relates to an AWS RDS instance, or how a Linkerd service interacts with a Prometheus monitoring component).\n - Document New Relationships: Clearly document the newly defined relationships, their purpose, and how they are represented within Meshery designs, contributing to the official Meshery documentation.\n- Expected Outcome:\n - A multitude of new relationships defined both intra and inter AWS services.\n - Policy Contribution: For advanced interns, there may be opportunities to contribute to the Rego policies that evaluate and enforce these relationships.\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Sangram Rath (@sangramrath, sangram.rath@gmail.com)\n- Issue: https://github.com/meshery/meshery/issues/17096\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/546491c9-c046-44e0-82de-2d9cc09b13d4\n\n\n#### Workflow Engine in Meshery\n\nCNCF - Meshery: Workflow engine integration (2026 Term 1)\n\nDescription: Integrate a new architectural component into Meshery: a workflow engine, using Temporal. This project involves shifting Meshery off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.\nRecommended Skills: Golang, Temporal, ReactJS\nMentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), Marcus Ringblom (@marblom007, marcus.ringblom@gmail.com)\nIssue: https://github.com/meshery/meshery/issues/17099\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e5a8af13-9891-4ca5-8dca-b0151a4345fb\n\n\n### OpenCost\n\n#### OpenCost UI Revamp\n\nCNCF - OpenCost: OpenCost UI Revamp (2026 Term 1)\n\n- Description: OpenCost has helped a lot of people save a lot of money on their infrastructure. We like to think that this has contributed to things like engineering headcounts not getting reduced, small businesses and startups surviving longer, and so on. The OpenCost UI is a key part of this - it lets people visualize their spend, find inefficiencies, and so on. It's time to uplevel the OpenCost UI to enable the next generation of savings!\n- Expected Outcome: We would like all pages of the OpenCost app to be implemented in Carbon or similar modern design system. We would like dashboarding functionality and a unified color scheme. All implementations should be delivered with unit and end-to-end tests. All existing functionality of the UI should be present in the revamped design.\n- Recommended Skills: React, UX Design, Frontend Development, APIs, Carbon Design System\n- Mentors \n - Alex Meijer (@ameijer, alexander.meijer@ibm.com)\n - Warwick Peatey (@peatey, warwick.peatey@ibm.com)\n- Upstream Issue: https://github.com/opencost/opencost-ui/issues/155\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ee1610ae-5850-4aa2-b3aa-edf39fded503\n\n\n### OpenKruise\n\n#### KruiseGame Cloud-Hosted Version Development\n\nCNCF - OpenKruise: KruiseGame cloud-hosted version development (2026 Term 1)\n\n- Description: OKG has attracted many large game companies to embrace cloud-native transformation. However, for many small and medium-sized game companies, they are not familiar with the container and Kubernetes ecosystem. Due to their smaller team sizes, they have relatively weak infrastructure management capabilities. To democratize cloud-native technology for more game companies, OKG plans to launch a cloud-hosted version. Users can deploy the runtime environment with one click and complete game service integration based on the official SDK. This will reduce the complexity of using infrastructure for game companies and adapt to multi-cloud environments.\n\n- Expected Outcome:\n - Cloud Provider Abstraction Layer Design and Implementation\n - One-Click Deployment Tool/CLI Development\n - Official Game Service SDK Development\n - Multi-Cloud Environment Adaptation (AWS, Alibaba Cloud, etc.)\n - Simplified Configuration Management System\n - Comprehensive Documentation and Integration Guides\n\n- Recommended Skills:\n - Golang\n - Kubernetes\n - Cloud Provider SDKs (AWS/Alibaba Cloud)\n - Infrastructure as Code (Terraform/Pulumi)\n\n- Mentor:\n - Qiuyang Liu (@chrisliu1995, [chrisliu1995@163.com](mailto:chrisliu1995@163.com))\n - Zhongwei Liu (@ringtail, [zhongwei.lzw@alibaba-inc.com](mailto:zhongwei.lzw@alibaba-inc.com))\n\n- Upstream Issue:\n - https://github.com/openkruise/kruise-game/issues/304\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d1e7cffe-6363-4439-8715-33019490da7f\n\n\n#### OpenKruise: Progressive Configmap Inplace Reloading\n\nCNCF - OpenKruise: Progressive ConfigMap inplace reloading (2026 Term 1)\n\n- Description: Native kubernetes configmap can reload dynamically but lack progressive rollout capability. OpenKruise community had comes up with the [design of new workload](https://github.com/openkruise/kruise/pull/1948) for configmap rolling update, and the [initial implementation](https://github.com/openkruise/kruise/pull/2149) has been running in one end user environment. However the current implementation is not generic enough and had many limitations. The goal is to complete the implementation in a more generic way and to support many configuration reloading strategies.\n- Expected Outcome:\n 1. The code for dynamic configmap rollout controller (ConfigMapSet)\n 2. Unit and integration tests\n 3. Documentation for the usage of ConfigMapSet\n- Recommended Skills: Golang, kubernetes operator development\n- Mentor(s):\n - Yuxing Yuan(@ABNER-1, abner199709@gmail.com)\n - Hao Wu(@Placeboy, psychoogopher@gmail.com) \n- Upstream Issue:\n - https://github.com/openkruise/kruise/issues/2288\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/174fea66-b624-4642-8b07-5910176bee0d\n\n\n#### OpenKruise: Promote API Version to v1beta1 part 2\n\nCNCF - OpenKruise: Promote API version to v1beta1 (part 2) (2026 Term 1)\n\n- Description: Many advance workloads in OpenKruise are widely used in production, however the API version of the workload is still in v1alpha1. The goal is to promote the API version of mostly used and mature workload to v1beta1 and optimize the CRD fields for better clarity. This is a follow-up of [previous project](https://mentorship.lfx.linuxfoundation.org/project/7426f5d7-1879-46cc-a933-880ee790d0eb), and target API is the advance operation and resilience policy.\n- Expected Outcome:\n 1. API definition of v1beta1 resources and the implementation for conversion webhook to convert v1alpha1 resource to v1beta1 resource\n 2. Unit and integration tests\n 3. Documentation for the usage of v1beta1 resource in the OpenKruise website\n- Recommended Skills: Golang, kubernetes operator development\n- Mentor(s):\n - Zhang Zhen (@furykerry, furykerry@gmail.com)\n - Zhong Tianyun (@AiRanthem, airanthem666@gmail.com)\n- Upstream Issue:\n - https://github.com/openkruise/kruise/issues/2287\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b2d7982d-47c2-4adc-93b0-98f260106e86\n\n\n#### OpenKruise: Rolling update for agent sandbox warm pool\n\nCNCF - OpenKruise: Rolling update for agent sandbox warm pool (2026 Term 1)\n\n- Description: OpenKruise Agents is a new sub-project of OpenKruise for agent sandbox lifecycle management. Warm pool is a key technology of OpenKruise Agents to ensure the fast sandbox provision. However existing warm pool lacks rolling update capability which makes the warm pool hard to maintain. The goal is to design and implement the basic rolling update capability for SandboxSet, the CRD for sandbox warm pool.\n- Expected Outcome:\n 1. The code for warm pool rolling update in SandboxSet\n 2. Unit and integration tests\n 3. Documentation for the usage of rolling update in SandboxSet\n- Recommended Skills: Golang, kubernetes operator development\n- Mentor(s):\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n - Zhang Jinghui (@sivanzcw, sivanzcwzhang@gmail.com)\n- Upstream Issue:\n - https://github.com/openkruise/agents/issues/76\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fdfeb5fd-0636-4f9a-a196-adc1ce3b7835\n\n\n### OpenTelemetry\n\n#### Tooling for detecting impact of behavioral changes in Go libraries\n\nCNCF - OpenTelemetry: Tooling for detecting impact of behavioral changes in Go lib (2026 Term 1)\n\n- Description:\n Maintenance of a stable Go library often involves value-judgement calls regarding what changes can impact downstream consumers. While some existing tooling like [apidiff](https://pkg.go.dev/golang.org/x/exp/apidiff) can go some way towards preventing breakage, these tools work purely in terms of API-level breakage such as changing the type of a symbol. Inspired by [tooling in other language ecosystems such as Rust](https://github.com/rust-lang/crater) this proposal sets out to build a tool that can give statistical information about the impact of any change on downstream consumers by running the build pipelines and test suites of dependents before and after a particular change. This would empower maintainers to make better informed choices about changes and foster an ecosystem. We think this is specially important for the OpenTelemetry project since the OpenTelemetry Go modules and the OpenTelemetry Collector modules are foundational modules used within the CNCF on other projects (e.g Kubernetes, Jaeger) as well as outside of it. The intent is to build a tool that could be used as well by other CNCF projects since Go is the *lingua franca* of the foundation, enabling all projects to have a flourishing ecosystem.\n- Expected Outcome:\n We would like to have a tool written in Go that is able to (i) gather all publicly-listed dependencies of a module, (ii) safely run the test suite of dependencies for a given version of the code and (iii) compare two test suites and provide a statistical summary of the differences between the two to help in decision-making.\n- Recommended Skills: \n - Working Golang skills including testing and building Go code\n - Working knowledge of CI/CD systems\n - Containerization and securely running untrusted code\n- Mentor(s):\n - Pablo Baeyens (@mx-psi, pbaeyens31+github@gmail.com)\n - Damien Mathieu (@dmathieu, damien.mathieu@elastic.co)\n- Upstream Issue: https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/1528\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5f537fc2-548b-487a-99ed-c61f7e8bcd47\n\n\n### OpenYurt\n\n#### Implement Label-Driven Automated Installation and Uninstallation of YurtHub on Edge Nodes\n\nCNCF - OpenYurt: Label-driven install/uninstall of YurtHub on edge nodes (2026 Term 1)\n\n- Description:\n Currently, in OpenYurt, the core component YurtHub—which acts as a transparent proxy between edge node system components (e.g., kubelet, CNI, CoreDNS, kube-proxy) and the Kubernetes API server—is deployed as a systemd service on each edge node. The installation is performed exclusively via the community-provided tool YurtAdm during node joining.\n This approach imposes a significant limitation: users must use YurtAdm to onboard nodes, making it impossible to install YurtHub on existing Kubernetes nodes that were not initially provisioned with YurtAdm. To improve flexibility and user experience, the community aims to support a label-driven, declarative installation mechanism:\n - When a specific label (e.g., openyurt.io/is-edge-worker=true) is added to a node, YurtHub should be automatically installed and started on that node.\n - Conversely, when the label is removed, YurtHub should be gracefully uninstalled and its resources cleaned up.\n This enhancement will enable seamless integration of OpenYurt into existing Kubernetes clusters without requiring re-onboarding of nodes.\n\n- Expected Outcome:\n - Design and implement a controller/operator that watches for node labels and triggers YurtHub lifecycle operations.\n - Develop an installation/uninstallation mechanism that:\n - Installs YurtHub as a systemd service.\n - Ensures idempotency and handles failures gracefully.\n - Cleans up all YurtHub-related files, configurations, and services upon label removal.\n - Ensure compatibility with existing YurtAdm-based deployments.\n - Provide comprehensive documentation, including:\n - User guide for enabling label-driven YurtHub management.\n - Design rationale and architecture diagram.\n - Add e2e tests covering both installation and uninstallation scenarios in a real cluster environment.\n\n- Recommended Skills:\n - Strong proficiency in Go programming language.\n - Solid understanding of Kubernetes architecture, especially node lifecycle, kubelet, and API machinery.\n - Experience with Kubernetes controllers/operators (client-go, controller-runtime).\n - Familiarity with systemd and Linux system service management (for interacting with systemd during install/uninstall).\n - Knowledge of OpenYurt architecture (especially YurtHub and YurtAdm) is a plus but not mandatory.\n - Experience writing unit and e2e tests for Kubernetes components.\n - Good communication and documentation skills.\n\n- Mentor(s):\n - Rambohe (@rambohe-ch, rambohe.ch@gmail.com)\n - Bingchang Tang (@zyjhtangtang, bingchang07@gmail.com)\n - Lu Chen (@luc99hen, luc99.en@gmail.com)\n- Upstream Issue:\n https://github.com/openyurtio/openyurt/issues/2494\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d92d9590-63ea-4551-93b7-047f32ae2b17\n\n\n### PipeCD\n\n#### Amazon ECS plugin for Pipedv1\n\nCNCF - PipeCD: Amazon ECS plugin for Pipedv1 (2026 Term 1)\n\n- Description: PipeCD v1 - the new version based on a plugin architecture (ref: [PipeCD plugin-arch overview blog](https://pipecd.dev/blog/2024/11/28/overview-of-the-plan-for-pluginnable-pipecd/)), has released an alpha version, and we are rapidly adding features supported in v0. We need to develop a plugin for PipeCD v1 to support [Amazon ECS](https://aws.amazon.com/ecs) deployment.\n- Expected Outcome:\n - ECS plugin for PipeCD\n - Possible update plugin SDK while develop the plugin\n - Possible update docs how to develop PipeCD plugin\n - Blog about how to develop a PipeCD plugin on [https://pipecd.dev/blog/](https://pipecd.dev/blog/)\n- Recommended Skills:\n - Golang\n - Amazon ECS\n - GitOps\n - Continuous Delivery (CD)\n- Mentor(s):\n - Khanh Tran (@khanhtc1202, khanhtc1202@gmail.com)\n - Shinnosuke Sawada-Dazai (@Warashi, shin@warashi.dev)\n- Upstream Issue:\n - https://github.com/pipe-cd/pipecd/issues/6443\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2d9f66f5-4c10-435c-98f9-160e7caa0989\n\n\n#### Community Building and Social Media Growth for PipeCD\n\nCNCF - PipeCD: Community building and social media growth (2026 Term 1)\n\n- Description: The release of PipeCD v1 introduced a plugin-based architecture that enables deployments on any platform. This is a significant evolution in the project's capabilities, but community awareness and adoption haven't kept pace with the technical progress. This project focuses on growing PipeCD's community through consistent content creation across developer platforms, producing technical content around the v1 release, improving documentation for users and contributors, and engaging with the community through demos and discussions. The mentee will work closely with maintainers to translate PipeCD's technical strengths into accessible content that drives adoption and contributions.\n\n- Expected Outcome: Established social media presence for PipeCD across key developer platforms, along with technical content covering v1 features, plugin development, and real-world deployment patterns. Demo content including video walkthroughs and livestreams that make the project easier to adopt. Improved contributor documentation and onboarding materials, with active community engagement through GitHub Discussions and other channels. At least one CNCF talk or meetup presentation delivered.\n- Recommended Skills:\n - Technical writing and documentation\n - Experience with Git, CI/CD, GitOps, and deployment workflows\n - Content creation (written and video) and social media\n - Public speaking and community engagement\n- Mentor(s):\n - Eeshaan Sawant (@EeshaanSA, eeshaans1@gmail.com)\n - Khanh Tran (@khanhtc1202, khanhtc1202@gmail.com)\n\n- Upstream Issue: https://github.com/pipe-cd/pipecd/issues/6441\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/59990960-32be-4bb7-937f-4c749c02e715\n\n\n#### Multi-cluster Kubernetes plugin for Pipedv1\n\nCNCF - PipeCD: Multi-cluster Kubernetes plugin for Pipedv1 (2026 Term 1)\n\n- Description: PipeCD v1 - the new version based on a plugin architecture (ref: [PipeCD plugin-arch overview blog](https://pipecd.dev/blog/2024/11/28/overview-of-the-plan-for-pluginnable-pipecd/)), has released an alpha version, and we are rapidly adding features supported in v0. With a better architecture, support for multi-cluster Kubernetes deployments is a natural extension. This project will focus on developing the Piped v1 plugin to support multi-cluster Kubernetes deployments.\n\n- Expected Outcome:\n - Multi-cluster Kubernetes plugin for PipeCD\n - Possible update plugin SDK while develop the plugin\n - Possible update docs how to develop PipeCD plugin\n - Blog about how to develop a PipeCD plugin on [https://pipecd.dev/blog/](https://pipecd.dev/blog/)\n- Recommended Skills:\n - Golang\n - Kubernetes\n - GitOps\n - Continuous Delivery (CD)\n- Mentor(s):\n - Khanh Tran (@khanhtc1202, khanhtc1202@gmail.com)\n - Shinnosuke Sawada-Dazai (@Warashi, shin@warashi.dev)\n- Upstream Issue:\n - https://github.com/pipe-cd/pipecd/issues/6446\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d1c5f444-3679-4102-b0a8-dd66e225dc65\n\n\n### Prometheus\n\n#### Improving Documentation for Prometheus and OpenTelemetry Interoperability\n\nCNCF - Prometheus: Improve docs for Prometheus & OpenTelemetry interoperability (2026 Term 1)\n\n- Description:\n Prometheus and OpenTelemetry are commonly deployed together, yet many users struggle to understand how the two systems interoperate — especially around concepts such as resource attributes, label mapping, attribute promotion, and recommended integration patterns.\n\n [Prior UX research](https://opentelemetry.io/blog/2025/ux-research-prometheus-otel/) identified documentation gaps as a primary source of confusion, and [ongoing community discussions](https://opentelemetry.io/blog/2026/slack-community-insights/) continue to surface similar questions. While both projects provide extensive documentation, guidance is often fragmented, highly technical, or lacks practical end-to-end explanations for real-world usage.\n\n This mentorship focuses on improving the clarity, usability, and consistency of documentation that explains how Prometheus and OpenTelemetry work together. The mentee will analyze existing documentation across both projects, identify high-impact gaps or friction points, and collaborate with mentors to design and deliver meaningful documentation improvements upstream.\n\n The project is intentionally exploratory and iterative. Part of the mentorship is learning how to evaluate documentation quality, prioritize improvements, and define ways to measure the impact of documentation changes made during the program.\n- Expected Outcome:\n - Review and audit existing Prometheus and OpenTelemetry documentation related to interoperability.\n - Define a prioritized documentation improvement plan together with the mentors.\n - Produce and submit documentation improvements upstream in one or both projects. These may include conceptual explanations, practical guides, examples, diagrams, and cross-project references.\n - Establish basic criteria or methods to evaluate documentation effectiveness during the mentorship.\n- Recommended Skills:\n - Prior experience with technical writing or clear motivation to pursue a Tech Writing career.\n - Familiarity with Git and contributing via pull requests.\n- Mentor(s):\n - Arthur Silva Sens (@arthursens, arthursens2005@gmail.com)\n - Tiffany Hrabusa (@tiffany76, tiffany.hrabusa@gmail.com)\n - Victoria Nduka (@nwanduka, ndukavictoria7@gmail.com)\n- Upstream Issue: https://github.com/prometheus/prometheus/issues/17823\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b703834b-9250-4413-b056-76a8ad885ea2\n\n#### Start scraping immediately on startup without waiting for WAL replay to finish\n\nCNCF - Prometheus: Start scraping immediately on startup without waiting for WAL replay to finish (2026 Term 1)\n\n- Description:\n When a large Prometheus is running in HA mode (i.e. 2 identical Prometheus scraping same targets) and it needs to be restarted (for upgrades, etc), there can be a temporary gap in queries when the second Prometheus is restarting. This is because the first Prometheus did not scrape any metrics when it was restarting (this is the gap), and when second Prometheus is restarting, only the first Prometheus is serving queries.\n\n To mitigate this, we want to start scraping targets as soon as Prometheus starts up, without waiting for it to complete the WAL replay and restore the old in-memory state. However, querying is still only enabled after WAL replay is over, but there won't be gaps in scraped data anymore.\n\n This project includes careful designing of low level technical challenges, including ensuring the correct handling of WAL records and seamlessly stitching together the new scraped data and the data restored from WAL without a lot of memory overhead.\n- Expected Outcome:\n - Design the correct handling of WAL records where the series information lines up between the old WAL and newly scraped data.\n - Design a low overhead method to stitch together the scraped data and the data restored from WAL.\n - Production ready PR with comprehensive test coverage. Ideally we will do the review iterations and merge the PR within this timeline.\n- Recommended Skills:\n - Basic understanding of Go.\n - Comfortable diving deep into low level system code.\n - Familiarity with unit testing.\n- Mentor(s):\n - Ganesh Vernekar (@codesome, ganeshvern@gmail.com)\n - Bryan Boreham (@bboreham, bjboreham@gmail.com)\n- Upstream Issue: https://github.com/prometheus/prometheus/issues/17058\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/dc27a939-6bb8-470c-8250-9f2d2ddfd64c\n\n\n### urunc\n\n#### Create a dashboard and a notification system for CI testing in `urunc`\n\nCNCF - urunc: Dashboard and notification system for CI testing (2026 Term 1)\n\n- Description:\n\nGitHub Actions provides detailed views of CI workflows at the repository level,\nbut it can be difficult for maintainers to quickly track the overall status of\nrecurring workflows, such as nightly tests, over time. Important\ninformation, like historical failures or trends, often requires manual\ninspection of individual workflow runs.\n\nThis work aims to improve CI observability for `urunc` by creating a\ncentralized dashboard that presents an aggregated view of its nightly (and\nother CI) test workflows. The dashboard will provide maintainers with a clear\noverview of recent runs, success and failure states, and relevant metadata in a\nsingle place.\n\nIn addition to visualization, this work includes the design and implementation of a\nnotification mechanism that alerts maintainers when tests fail. This\nwill help ensure that regressions are noticed quickly and addressed in a timely\nmanner, improving overall project reliability.\n\n- Expected Outcome:\n - Design and implementation of a dashboard summarizing nightly (and CI) test results.\n - Clear visualization of workflow status and execution history.\n - Implementation of a notification system for nightly test failures.\n - Documentation describing the dashboard, notification setup, and maintenance.\n\n- Recommended Skills:\n - Basic understanding of CI/CD, GitHub Actions and GitHub API.\n - Experience with a suitable programming language (e.g., Go, Python, JavaScript)\n\n- Mentor(s):\n - Charalampos Mainas (@cmainas, cmainas@nubificus.co.uk)\n - Panagiotis Mavrikos (@panosmaurikos, pmavrikos@nubificus.co.uk)\n\n- Upstream Issue: https://github.com/urunc-dev/urunc/issues/106\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6d6e52c9-d4a0-4d0d-a3d8-f289935d9906\n\n\n#### Investigate missing custom OCI Annotations in urunc containers\n\nCNCF - urunc: Investigate missing custom OCI annotations in urunc containers (2026 Term 1)\n\n- Description:\n\nIn order to pass sandbox-specific configuration, such as the guest type,\nmonitor type, rootfs information and others, `urunc` relies on a set of [custom\nOCI annotations](https://urunc.io/package/#annotations). However, these\nannotations are missing from the container's configuration in\nnon-Kubernetes-deployments. To work around this issue, a `urunc.json` file\ncontaining the same information is currently injected into the container’s\nroot filesystem. This works aims to investigate the OCI image build and runtime\nflow to understand where and why these custom annotations are dropped or\nignored in non-Kubernetes setups.\n\n- Expected Outcome:\n - A clear summary of the investigation, including where and why the custom\n annotations are lost.\n - A proposed solution enabling `urunc` to correctly consume its custom OCI\n annotations.\n - Alternatively, the design and implementation of a cleaner mechanism than\n injecting a file into the container’s root filesystem.\n\n- Recommended Skills:\n - Go\n - Familiarity with container tools (docker, nerdctl, skopeo etc.)\n - Familiarity with container runtimes (containerd, runc, urunc)\n - familiarity with the OCI specification\n- Mentor(s):\n - Charalampos Mainas (@cmainas, cmainas@nubificus.co.uk)\n - Anastassios Nanos (@ananos, ananos@nubificus.co.uk)\n- Upstream Issue: https://github.com/urunc-dev/urunc/issues/12\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f1fb6914-eab7-481b-85ce-78f095ad4989\n\n\n#### Optimizing Rootfs Handling with block-based snapshotters in `urunc`\n\nCNCF - urunc: Optimize rootfs handling with block-based snapshotters (2026 Term 1)\n\n- Description:\n\nWhen `urunc` is used together with a block-based snapshotter, it can take\nadvantage of block-device backed container root filesystem and pass it\ndirectly to the sandbox as a disk image. This approach avoids filesystem\nconversion and enables efficient access to the container root filesystem.\n\nHowever, in order to spawn the sandbox, urunc requires access to the guest\nkernel and the initrd (if present). Since these files are part of the\ncontainer rootfs, `urunc` must first extract and store them elsewhere before\nattaching the block-based root filesystem to the sandbox. As a result, this\nprocess introduces unnecessary file copies and additional I/O overhead.\n\nA more efficient approach is to leverage read-only (view) snapshots. Instead of\ncopying files, `urunc` could request a read-only snapshot of the container root\nfilesystem and mount it separately. The kernel binary and other required\nartifacts could then be read directly from this snapshot without modifying or\nduplicating data. Since view snapshots simply redirect read requests to the\nunderlying snapshot layers, this approach is expected to introduce little to no\nadditional storage overhead while simplifying the runtime flow.\n\n- Expected Outcome:\n - A document explaining block-based snapshots in containerd, along with the\n respective APIs to snapshot creation and management.\n - An implementation in `urunc` that requests and mounts a read-only snapshot\n of the container root filesystem.\n - Evaluation of performance, storage overhead, and limitations of the\n snapshot-based approach.\n\n- Recommended Skills:\n - Go\n - Familiarity with containerd\n - Familiarity with Linux filesystems and block devices\n- Mentor(s):\n - Charalampos Mainas (@cmainas, cmainas@nubificus.co.uk)\n - Anastassios Nanos (@ananos, ananos@nubificus.co.uk)\n- Upstream Issue: https://github.com/urunc-dev/urunc/issues/43\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/59a4a90b-fc38-4aae-a712-b622eab55d61\n### Volcano\n\n#### Add Volcano to Headlamp: Job and Queue Management UI\n\nCNCF - Volcano: Add Volcano to Headlamp: Job & Queue Management UI (2026 Term 1)\n\n- Description:\n Volcano is a batch scheduling system for Kubernetes. This project will create a Headlamp plugin that adds first-class UI support for Volcano resources and workflows. The plugin will help users discover, inspect, and manage Volcano objects (e.g., queues, jobs, podgroups) directly inside Headlamp, making batch/HPC-style scheduling easier to operate from a Kubernetes UI. The idea is aligned with maintainer interest in a Volcano-focused Headlamp plugin. \n\n- Expected Outcome:\n - A working Headlamp plugin that can list and display key Volcano CRDs (e.g., Queue, Job, PodGroup) with meaningful status and relationships. Relevant Volcano related metrics displayed (on map and overview/detail pages).\n - Detail pages for Volcano resources with common actions (where appropriate) such as viewing events, related pods, and logs.\n - UX that fits Headlamp’s plugin patterns (navigation, list/detail views, and resource integration) and is packaged in a way consistent with the Headlamp plugin ecosystem. [1](https://github.com/headlamp-k8s/plugins), [2](https://headlamp.dev/docs/latest/development/plugins/)\n - Documentation covering installation, development workflow, and how to test against a cluster with Volcano installed.\n - Blog post on Kubernetes Blog about the project\n\n- Recommended Skills:\n - TypeScript + React \n - (Optional) Headlamp UI/plugin development, or other open source development\n - (Optional) Kubernetes fundamentals (CRDs, controllers, RBAC)\n - (Optional) Familiarity with Volcano concepts (queues, batch scheduling semantics)\n\n- Mentor(s):\n - Santhosh Nagaraj (@yolossn, sannagaraj@microsoft.com)\n - Rene Dudfield (@illume, renedudfield@microsoft.com)\n - Ashu Ghildiyal (@ashu8912, ashu.ghildiyal@microsoft.com)\n - Jesse Stutler (@JesseStutler, jessestutler97@gmail.com)\n\n- Upstream Issue:\n https://github.com/kubernetes-sigs/headlamp/issues/4359\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6d823c50-31c8-4b43-8479-203a0a4685f7\n\n\n#### E2E Test Suite for Volcano Agent Scheduling\n\nCNCF - Volcano: E2E test suite for Volcano agent scheduling (2026 Term 1)\n\n- Description: Volcano has introduced Agent Scheduling feature that supports fast scheduling for AI agent workloads. This includes ShardingController for shard management, agent scheduler for agent workloads scheduling, and enhanced existing Volcano batch scheduler with sharding support to coordinated scheduling with agent scheduler. To ensure correctness and stability of this new scheduling mechanism, we need to build a comprehensive end-to-end (e2e) test suite. Test cases should cover key scenarios including shard creation, node assignment across shards, agent scheduler scheduling in different sharding modes, etc.\n\n- Expected Outcome:\n - A comprehensive e2e test suite using Ginkgo framework covering all agent scheduling scenarios.\n - Test cases for ShardingController: shard creation, node assignment, node addition/removal, configuration changes, and node stability across shards. \n - Test cases for Agent Scheduler: scheduling in no-sharding, hard-sharding, and soft-sharding modes, shard reconfiguration, and multi-worker scenarios.\n - Test cases for Volcano scheduler with sharding: validation of allocate, preempt, reclaim, and backfill actions under different sharding configurations.\n - Integration with CI/CD workflows for automated testing.\n - Comprehensive documentation including test design, coverage reports, and guidelines for extending tests.\n- Recommended Skills:\n - Strong understanding of Kubernetes concepts and Volcano scheduler architecture.\n - Familiarity with Volcano agent scheduling design and shard management mechanisms.\n - Proficiency in writing e2e test cases using Ginkgo testing framework.\n - Experience with Go programming language.\n - Knowledge of kubectl and Kubernetes testing best practices.\n - Experience with CI/CD workflows and test automation.\n- Mentor(s):\n - Jesse Stutler (@JesseStutler, jessestutler97@gmail.com)\n - Qi Min (@qi-min, qim_34@163.com)\n- Upstream Issue:\n - https://github.com/volcano-sh/volcano/issues/4881\n - https://github.com/volcano-sh/volcano/issues/4882\n - https://github.com/volcano-sh/volcano/issues/4883\n- Background:\n - https://github.com/volcano-sh/volcano/issues/4722\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b350f84f-3fdd-4062-81a9-d4875044ed7b\n\n\n#### E2E Test Suite for Volcano-global\n\nCNCF - Volcano: E2E test suite for Volcano-global (2026 Term 1)\n\n- Description: Volcano-global is a multi-cluster scheduling project designed for cross-cluster resource management. \nCurrently, the project lacks a comprehensive end-to-end (e2e) test suite to ensure stability across complex multi-cluster environments. \nThis project aims to build a reproducible e2e test framework using Ginkgo and Kind, ensure each feature of Volcano-global is covered by test cases.\n- Expected Outcome:\n - A functional e2e test framework integrated with GitHub Actions workflows.\n - Scripts for automated deployment of Volcano-global and bootstrapping of Karmada multi-cluster environments.\n - Test cases covering key scenarios: resource quota & priority, cross-cluster vcjob scheduling, data dependency aware scheduling, and hyperjob scheduling.\n - Comprehensive documentation, including test design docs and guidelines for extending e2e tests in the future.\n- Recommended Skills:\n - Familiarity with Kubernetes concepts.\n - Understanding of Karmada and Volcano-global.\n - Ability to write e2e test cases using testing frameworks like Ginkgo.\n - Proficiency with kind and kubectl.\n - Experience with writing Workflows (CI/CD) and Makefiles.\n- Mentor(s):\n - Jesse Stutler (@JesseStutler, jessestutler97@gmail.com)\n - FanXu (@fx147, 1473623795@qq.com)\n- Upstream Issue:\n - https://github.com/volcano-sh/volcano-global/issues/35\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f0658f64-42f9-4301-8c2c-9ad7d3328638\n\n\n#### Volcano Documentation & Website Revamp with Docusaurus\n\nCNCF - Volcano: Volcano documentation & website revamp with Docusaurus (2026 Term 1)\n\n- Description: The Volcano project currently uses Hugo for building its official website. However, current Hugo version of the website is pretty old and lacks modern features and flexibility, \nespecially it is difficult to extend styles such as secondary menus, and there are problems such as invalid rendering of new markdown syntax. Docusaurus is a modern documentation framework that provides better support for versioning, localization, and theming.\nThis mentorship focuses on modernizing the Volcano website by migrating it to Docusaurus, improving documentation structure, maintainability, and overall user experience. \nThe project will involve replicating and enhancing the existing theme, restructuring documentation, improving navigation, and aligning the site with CNCF documentation best practices. \nThe mentorship will also explore long-term maintainability and contributor-friendliness of the documentation workflow, especially to ensure that the documentation in the Volcano website is automatically synchronized with the documentation in Volcano's other code repos, \nusing some automated tools like agents to keep the Volcano website up-to-date.\n- Expected Outcome:\n - Successful migration of the Volcano website from Hugo to Docusaurus\n - Improved documentation structure, navigation, and UX\n - A maintainable and contributor-friendly documentation setup\n - Clear contribution guidelines for future documentation updates\n - Automated synchronization of documentation between the Volcano website and other code repositories.\n- Recommended Skills:\n - Basic knowledge of JavaScript/TypeScript\n - Familiarity with React (preferred)\n - Experience with static site generators (Docusaurus/Hugo preferred)\n - Markdown and documentation best practices\n - Git and GitHub workflow\n - Basic understanding of Kubernetes and Volcano concepts\n- Mentor(s):\n - Jesse Stutler (@JesseStutler, jessestutler97@gmail.com)\n - Kuldeep (@de6p, de6p97@gmail.com)\n- Upstream Issue:\n - https://github.com/volcano-sh/website/issues/398\n - https://github.com/volcano-sh/website/issues/427\n - https://github.com/volcano-sh/website/issues/425\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7243aae3-dfab-4d20-a453-b6daa513544b\n\n\n### Volcano/AgentCube\n\n#### Establishing agentCube's authentication and authorisation capabilities\n\nCNCF - Volcano: AgentCube: Establish authentication and authorization (2026 Term 1)\n\n- Description: AgentCube is a proposed subproject in the Volcano community. It is designed to extend Volcano's capabilities to natively support and manage AI Agent workloads. At present, agentCube lacks authentication and authorisation capabilities. Therefore, it is hoped that basic authentication and authorisation capabilities for request identities can be established.\n- Expected Outcome:\n - 1. The ability to authenticate and authorise requests. Such as Token, JWT, OAuth, Cookie...\n - 2. Documentation containing the proposal and user guide\n - 3. Unit test and E2E test for the feature\n- Recommended Skills: go, kind, docker, authorization and authentication\n- Mentor(s):\n - Zengzeng Yao(@YaoZengzeng, yaozengzeng@huawei.com), \n - Zhonghu xu(@hzxuzhonghu, zhhxu2011@gmail.com),\n- Upstream Issue: https://github.com/volcano-sh/agentcube/issues/156\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/02f3c9db-9462-47df-986c-47cd7c0a2a2a\n\n\n### volcano/kthena\n\n#### E2E Test Suite for Kthena\n\nCNCF - Volcano: Kthena: E2E test suite (2026 Term 1)\n\n- Description: kthena now has components such as router, ModelServing controller, etc. However, it lacks necessary e2e test coverage.\n- Expected Outcome:\n - 1.E2E Test of modelserving Router and modelBooster.\n - 2.Write an E2E test for each of the three on GitHub workflows. Run them separately.\n - 3.Developer Guide of How to run and expend E2E test \n- Recommended Skills: go, kind, docker\n- Mentor(s):\n - Zengzeng Yao(@YaoZengzeng, yaozengzeng@huawei.com), \n - ZhenCheng Li(@LiZhenCheng9527, lizhencheng6@huawei.com),\n- Upstream Issue: https://github.com/volcano-sh/kthena/issues/662\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0b781423-cf4b-4a3c-b714-13f7350c1e63\n\n\n#### Optimising Kthena's autoscaler\n\nCNCF - Volcano: Kthena: Optimize autoscaler with HPA/KEDA integration (2026 Term 1)\n\n- Description: Kthena already possesses an autoscaler, but lacks ecosystem integration with peripherals such as HPA and KEDA. Consequently, users may harbour reservations when employing it. Therefore, there is a desire to optimise Kthena's autoscaler.\n- Expected outcome:\n - 1.The ecological integration of HPA and KEDA.\n - 2.Scaling capability of replicas for servingGroup and role\n - 3.Transition of HPA configuration\n - 4.UserGuide and Proposal\n - 5.Unit test and e2e test for the new feature\n- Recommended Skills: go, kind, docker, HPA\n- Mentor(s):\n - ZhenCheng Li(@LiZhenCheng9527, lizhencheng6@huawei.com),\n - Zhonghu xu(@hzxuzhonghu, zhhxu2011@gmail.com),\n- Upstream Issue: https://github.com/volcano-sh/kthena/issues/663\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4127a1fe-a8cb-45fe-931f-2a31eb5ca57c\n\n\n### WasmEdge\n\n#### Enable JIT mode support for per-function compilation\n\nCNCF - WasmEdge: Enable JIT mode support for per-function compilation (2026 Term 1)\n\n- Description: WasmEdge's JIT mode attempts to compile the entire module before execution, which also includes compiling unused functions in the specific workload. To reduce compilation time and improve performance, we aim to enable compilation on a per-function basis, focusing only on those functions actually used in the workload.\n- Expected Outcome:\n - A series of test cases that verify the behavior and demonstrate the difference between entire module compilation and per-function basis compilation.\n - A series of PRs that implement the per-function compilation behavior.\n - An option to control the behavior between entire module and per-function compilation.\n - A document explaining how the new approach works and how to use it.\n- Recommended Skills:\n - C++\n - WebAssembly\n - LLVM\n - JIT\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n - Shen-Ta Hsieh (@ibmibmibm, beststeve@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/4516\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/59fd2575-e4ac-4526-8866-bda78d760533\n\n\n#### Extend sub-command of WasmEdge CLI tool\n\nCNCF - WasmEdge: Extend WasmEdge CLI sub-commands (2026 Term 1)\n\n- Description: WasmEdge command line tool currently supports only the sub-command about run and compile the WASM files. As a WebAssembly runtime tool, it's welcome to have more functions about verifying the WASM files. In this mentorship, we expect the mentee to plan and implement the functionality of WasmEdge command line tool about parsing, validating, and instantiating WASM files, which developers can do with WasmEdge C API.\n- Expected Outcome:\n - Extend the sub-commands for WasmEdge CLI tool contains not only `parse`, `validate`, or `instantiate`, etc.\n - Provide the test cases to verify your implementation.\n - Use WasmEdge C API to trigger the WasmEdge CLI tools for further test cases.\n- Recommended Skills:\n - C/C++\n - WebAssembly\n - GitHub workflows\n- Mentor(s):\n - YiYing He (@q82419, yiying@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/4513\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5a701778-f5eb-493b-a8f9-d9a146ccefe6\n\n\n#### Module instance dependency tree in WASM store\n\nCNCF - WasmEdge: Module instance dependency tree in WASM store (2026 Term 1)\n\n- Description: It's common that there are several modules and linking when running a WebAssemly program. WasmEdge provides the APIs to handle the cases about loading and importing the WASM binaries and register the module instances into store in runtime. But in some complicated cases, the dependencies between module instances occurs. There may be requests to unregister and delete the module instances in store to release the space. In that case, the dependency of module instances should be considered to prevent from causing crash after deleting a module instance. In this mentorship, we expect the mentee to implement the dependency tree and the methodology to handle the module deletion in WasmEdge runtime.\n- Expected Outcome:\n - Implement the module instance dependency tree and the maintainance methodology.\n - Design the multiple module instances test cases to verify the implementation.\n- Recommended Skills:\n - C/C++\n - WebAssembly\n - GitHub workflows\n- Mentor(s):\n - YiYing He (@q82419, yiying@secondstate.io)\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/4514\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/53085238-2bfa-4d26-99d6-2b797e693d08\n\n" }, { "path": "programs/lfx-mentorship/2026/01-Mar-May/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n- Upstream Issue:\n\n```\n\n---\n\n## Proposed Project ideas\n" }, { "path": "programs/lfx-mentorship/2026/02-Jun-Aug/README.md", "content": "# Term 02 - 2026 June - August\n\nStatus: Planning\n\nMentorship duration - three months (full-time schedule)\n\n### Timeline\n\n| Activity | Dates (2026) |\n|--------------|------------------|\n| Project Proposals Open | Wed, Apr 1 – Tue, Apr 28, 2026, 11:00 AM PDT (18:00 UTC) |\n| Mentee Applications Open | Tuesday, May 5 – Tue, May 19, 2026, 11:00 AM PDT (18:00 UTC) |\n| Application Review Period (2 weeks) | Wed, May 20 – Tue, Jun 2, 2026, 11:00 AM PDT (18:00 UTC) |\n| Selection Notifications | Wed, Jun 3, 2026 *(notifications may take a few days to reach all mentees) |\n| Mentorship Program Begins | Mon, Jun 8, 2026 |\n| Midterm Mentee Evaluations | Tue, Jul 21, 2026, 11:00 AM PDT (18:00 UTC) |\n| First Stipend Payments | Wed, Jul 22, 2026 |\n| Final Mentee Evaluations | Tue, Aug 25, 2026, 11:00 AM PDT (18:00 UTC) |\n| Second Stipend Payments | Wed, Aug 26, 2026 |\n| Last Day of Term | Mon, Aug 31, 2026 |\n\n\n### Project instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2026/02-Jun-Aug/project_ideas.md, by April 28, 2026. Please limit proposals to 4-5 projects per CNCF project.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n## Table of Contents\n\n- [Chaos Mesh](#chaos-mesh)\n - [Refactor PodChaos and NetworkChaos E2E Tests into Gherkin-based BDD Scenarios](#refactor-podchaos-and-networkchaos-e2e-tests-into-gherkin-based-bdd-scenarios)\n - [Runtime Fact Checker for Chaos Mesh Experiments](#runtime-fact-checker-for-chaos-mesh-experiments)\n- [Harbor](#harbor)\n - [Harbor CLI: Bubbletea v2 TUI Refactor and OIDC Device-Flow Login](#harbor-cli-bubbletea-v2-tui-refactor-and-oidc-device-flow-login)\n - [Harbor Satellite: Ground Control CLI and Kubernetes Fleet Operator](#harbor-satellite-ground-control-cli-and-kubernetes-fleet-operator)\n- [Jaeger](#jaeger)\n - [AI-Powered Trace Analysis: Phase 2 - Self-Service \"Skills\" Framework](#ai-powered-trace-analysis-phase-2---self-service-skills-framework)\n - [Jaeger for GenAI Observability: Specialized Trace Visualization](#jaeger-for-genai-observability-specialized-trace-visualization)\n- [Karmada](#karmada)\n - [Build Karmada Agent Skills](#build-karmada-agent-skills)\n- [kgateway](#kgateway)\n - [Documentation improvements for OIDC and JWT IdPs integrations](#documentation-improvements-for-oidc-and-jwt-idps-integrations)\n- [Kmesh](#kmesh)\n - [Integrating Kmesh into Headlamp UI](#integrating-kmesh-into-headlamp-ui)\n- [krkn - Chaos](#krkn---chaos)\n - [Automated Documentation Sync Bot for Krkn-Chaos Projects](#automated-documentation-sync-bot-for-krkn-chaos-projects)\n - [Dynamic Cluster-Aware Configuration Generation for Krkn-AI](#dynamic-cluster-aware-configuration-generation-for-krkn-ai)\n- [Kuadrant](#kuadrant)\n - [Implement AccessPolicy CRD for tool-level authorization in the Kuadrant agentic gateway](#implement-accesspolicy-crd-for-tool-level-authorization-in-the-kuadrant-agentic-gateway)\n - [Investigate and prototype A2A protocol support in the Kuadrant agentic gateway project](#investigate-and-prototype-a2a-protocol-support-in-the-kuadrant-agentic-gateway-project)\n - [Investigate native Envoy MCP filter as replacement for ext-proc parsing in the Kuadrant agentic gateway](#investigate-native-envoy-mcp-filter-as-replacement-for-ext-proc-parsing-in-the-kuadrant-agentic-gateway)\n - [Transform Kuadrant Policy YAML Editors into Interactive Form Views](#transform-kuadrant-policy-yaml-editors-into-interactive-form-views)\n- [KubeEdge](#kubeedge)\n - [Building an Edge-Cloud Collaborative Framework for Embodied AI Applications with KubeEdge](#building-an-edge-cloud-collaborative-framework-for-embodied-ai-applications-with-kubeedge)\n - [Comprehensive Example Restoration for KubeEdge Ianvs: Phase III](#comprehensive-example-restoration-for-kubeedge-ianvs-phase-iii)\n - [Enabling Edge-Native Inference for Lightweight Large Language Models with KubeEdge](#enabling-edge-native-inference-for-lightweight-large-language-models-with-kubeedge)\n - [Exploring AI PCs as KubeEdge-Managed Edge Nodes for Intelligent Workload Orchestration](#exploring-ai-pcs-as-kubeedge-managed-edge-nodes-for-intelligent-workload-orchestration)\n - [Exploring Alternatives to iptableManager: Optimizing Edge-Cloud Request Forwarding via Apiserver Redirection to cloudcore](#exploring-alternatives-to-iptablemanager-optimizing-edge-cloud-request-forwarding-via-apiserver-redirection-to-cloudcore)\n- [Kubernetes](#kubernetes)\n - [SIG Node / node-readiness-controller](#sig-node-node-readiness-controller)\n - [Advanced Observability: Per-Rule Metrics and Headlamp Plugin](#advanced-observability-per-rule-metrics-and-headlamp-plugin)\n - [Scalability Testing and Release Reliability](#scalability-testing-and-release-reliability)\n- [Kubescape](#kubescape)\n - [CEL rule engine support and Rego-to-CEL control migration](#cel-rule-engine-support-and-rego-to-cel-control-migration)\n - [In-cluster, GitOps-native SecurityException CRD for Kubescape, with Headlamp plugin support](#in-cluster-gitops-native-securityexception-crd-for-kubescape-with-headlamp-plugin-support)\n- [KubeStellar](#kubestellar)\n - [AI-driven bug discovery and remediation architect for KubeStellar Console](#ai-driven-bug-discovery-and-remediation-architect-for-kubestellar-console)\n - [AI-driven operational knowledge base and mission control testing for KubeStellar Console](#ai-driven-operational-knowledge-base-and-mission-control-testing-for-kubestellar-console)\n - [AI-driven test coverage architect for KubeStellar Console](#ai-driven-test-coverage-architect-for-kubestellar-console)\n- [KubeVela](#kubevela)\n - [LRU Cache Eviction for the Native Helm Provider](#lru-cache-eviction-for-the-native-helm-provider)\n - [Native Secret-Sourced HTTP Headers and CRD-Based Config Management with Server-Side Validation](#native-secret-sourced-http-headers-and-crd-based-config-management-with-server-side-validation)\n- [Kyverno](#kyverno)\n - [Address findings from the Kyverno CNCF TAG Security & Compliance and General Technical Review assessments](#address-findings-from-the-kyverno-cncf-tag-security-compliance-and-general-technical-review-assessments)\n - [Kyverno Technical Outcomes](#kyverno-technical-outcomes)\n- [Lima](#lima)\n - [Improve Windows support (host and guest)](#improve-windows-support-host-and-guest)\n- [Microcks](#microcks)\n - [Microcks-CLI v2 - IDE (Vs code) Integration and Local Dev Loop Enhancement](#microcks-cli-v2---ide-vs-code-integration-and-local-dev-loop-enhancement)\n- [OpenEverest](#openeverest)\n - [Plugin Developer Playground: Interactive UI Schema Editor with Live Preview](#plugin-developer-playground-interactive-ui-schema-editor-with-live-preview)\n - [Transform everestctl into a Powerful Database Management CLI](#transform-everestctl-into-a-powerful-database-management-cli)\n- [OpenKruise](#openkruise)\n - [Build Document Agent for OpenKruise Website](#build-document-agent-for-openkruise-website)\n - [Dynamic Volume Mounting for JuiceFS and Ceph in OpenKruise Agents](#dynamic-volume-mounting-for-juicefs-and-ceph-in-openkruise-agents)\n - [Lightweight and Continuous Load Testing for OpenKruise Agents Using Kwok](#lightweight-and-continuous-load-testing-for-openkruise-agents-using-kwok)\n- [OpenTelemetry](#opentelemetry)\n - [Expanding Go Compile-Time Instrumentation Support and Improving otelc Tooling](#expanding-go-compile-time-instrumentation-support-and-improving-otelc-tooling)\n - [UX Research & Information Architecture: How Users Discover and Use OpenTelemetry Instrumentation Information](#ux-research-information-architecture-how-users-discover-and-use-opentelemetry-instrumentation-information)\n- [PipeCD](#pipecd)\n - [Plugin Development Book, Docs DX, and Adoption Growth](#plugin-development-book-docs-dx-and-adoption-growth)\n- [urunc](#urunc)\n - [Extensive evaluation of urunc's sandboxing execution model](#extensive-evaluation-of-uruncs-sandboxing-execution-model)\n - [Improve lifecycle management of sandbox monitors](#improve-lifecycle-management-of-sandbox-monitors)\n - [Improving DNS and localhost based networking compatibility for urunc across CNIs](#improving-dns-and-localhost-based-networking-compatibility-for-urunc-across-cnis)\n - [Integration of urunc's sandbox execution with Argo](#integration-of-uruncs-sandbox-execution-with-argo)\n- [Volcano](#volcano)\n - [Scheduler Management, Observability & Log Explorer UI](#scheduler-management-observability-log-explorer-ui)\n - [Support Namespace-scoped Queue in Volcano](#support-namespace-scoped-queue-in-volcano)\n- [WasmEdge](#wasmedge)\n - [Memory alignment in WASM instructions](#memory-alignment-in-wasm-instructions)\n\n## Accepted Projects\n\n### Chaos Mesh\n\n#### Refactor PodChaos and NetworkChaos E2E Tests into Gherkin-based BDD Scenarios\n\nCNCF - Chaos Mesh: Refactor PodChaos & NetworkChaos E2E Tests into Gherkin BDD (2026 Term 2)\n\n- Description: Chaos Mesh has an existing Go-based E2E test suite for validating chaos behavior on Kubernetes. The current tests are effective, but many scenarios mix test intent, fixture setup, Chaos Mesh custom resource creation, probing logic, assertions, and cleanup in Go code. This makes the E2E suite harder to read and extend, especially for new contributors who need to understand both the user-facing chaos behavior and the underlying Kubernetes test implementation at the same time. This project will introduce a Gherkin + Godog based BDD layer for selected Chaos Mesh E2E tests. The mentee will migrate the existing PodChaos and NetworkChaos E2E tests into executable Gherkin feature files backed by reusable Go step definitions. The new feature files should preserve Chaos Mesh-specific behavior and network/pod verification details, rather than hiding them behind overly broad user-story wording.\n- Expected Outcome:\n - A Godog-based BDD test layer that can run Chaos Mesh E2E scenarios from Gherkin feature files\n - Gherkin feature files for all existing PodChaos E2E scenarios\n - Gherkin feature files for all existing NetworkChaos E2E scenarios\n - Reusable Go step definitions for common E2E operations such as preparing workloads, applying Chaos Mesh custom resources, probing pod/network behavior, checking expected failure or delay, and verifying recovery\n - Integration with the existing E2E development workflow, with exact command and CI integration decided during implementation\n - Documentation explaining the Gherkin scenario style, step definition conventions, and migration guidance for other Chaos Mesh E2E tests\n- Recommended Skills: Go, Kubernetes, Kubernetes E2E testing, Ginkgo/Gomega, Gherkin, Godog, Chaos Mesh usage, test refactoring\n- Mentor(s):\n - Yue Yang (@g1eny0ung, g1enyy0ung@gmail.com)\n - Zhiqiang ZHOU (@STRRL, im@strrl.dev)\n - Andrewmatilde (@Andrewmatilde, davis6813585853062@gmail.com)\n- Upstream Issue: https://github.com/chaos-mesh/chaos-mesh/issues/4902\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/383fa84a-116a-414e-94e9-4e050fc5b6a8\n\n#### Runtime Fact Checker for Chaos Mesh Experiments\n\nCNCF - Chaos Mesh: Runtime Fact Checker for Experiments (2026 Term 2)\n\n- Description: Chaos Mesh can report the lifecycle and status of a chaos experiment, but users often still need to manually verify whether the real runtime behavior matches the intended chaos behavior. For example, a user may want to know whether a PodChaos experiment actually affected the selected pods, whether a DNSChaos experiment actually changed DNS responses, or whether a NetworkChaos experiment actually changed connectivity or latency between workloads. This project will build a runtime fact checker for Chaos Mesh experiments. The first version should be a standalone CLI prototype where users specify one Chaos Mesh custom resource to check. The tool will collect runtime evidence from Kubernetes resources, Chaos Mesh status, events, and active probes when needed, then compare the observed behavior with the expected behavior implied by the Chaos CR. Core matching logic should be implemented by deterministic collectors, probes, and rules. LLM support, if added, should only summarize or explain collected facts; it should not be the source of truth for the verdict.\n- Expected Outcome:\n - A standalone CLI prototype for checking one specified Chaos Mesh experiment\n - Runtime fact checking support for PodChaos, DNSChaos, and NetworkChaos\n - Evidence collectors for Kubernetes resources, Chaos Mesh CR spec/status, events, pod/container lifecycle, and target matching\n - Active probes for DNSChaos and NetworkChaos, because Kubernetes status alone cannot prove DNS or network behavior\n - A verdict model with at least matched, mismatched, inconclusive, and unsupported states\n - Human-readable reports that explain observed facts, expected behavior, verdict, and uncertainty\n - Structured JSON output for future integration with CI, Chaos Dashboard, or a Kubernetes report CRD\n - Documentation covering usage, supported chaos types, limitations, and future integration paths\n- Recommended Skills: Go, Kubernetes, Kubernetes client-go/controller-runtime, Chaos Mesh custom resources, networking basics, DNS basics, CLI development, testing\n- Mentor(s):\n - Yue Yang (@g1eny0ung, g1enyy0ung@gmail.com)\n - Zhiqiang ZHOU (@STRRL, im@strrl.dev)\n - Andrewmatilde (@Andrewmatilde, davis6813585853062@gmail.com)\n- Upstream Issue: https://github.com/chaos-mesh/chaos-mesh/issues/4903\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3ee1332b-7cdb-4b63-ba02-a4e6a8d67897\n\n### Harbor\n\n#### Harbor CLI: Bubbletea v2 TUI Refactor and OIDC Device-Flow Login\n\nCNCF - Harbor: Bubbletea v2 TUI Refactor and OIDC Device-Flow Login (2026 Term 2)\n\n- Description: Harbor CLI needs two foundational improvements this term. First, migrate the TUI from Bubbletea v1 to v2 and refactor the fragmented list/table/selection models into a unified `loadingtablelist` abstraction with consistent loading, pagination, and error states across all commands. Second, replace static credentials with an OAuth 2.0 Device Authorization Grant (RFC 8628) and OIDC login flow so users and CI/CD pipelines can authenticate against Harbor through their identity provider without long-lived secrets.\n- Expected Outcome:\n - Bubbletea v2 upgrade and unified `loadingtablelist` model adopted across all list-style commands\n - `harbor login --sso` device-code flow plus a non-interactive CI/CD path with short-lived tokens\n - Encrypted local token storage with automatic refresh and provider-agnostic OIDC config\n - Tests for TUI state transitions and a mock OIDC provider covering device flow and refresh\n - Updated docs covering the new TUI patterns and OIDC setup for common providers\n- Recommended Skills: Golang, Charmbracelet Bubbletea, OAuth 2.0 / OIDC, spf13/cobra, testing\n- Mentor(s):\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n- Upstream Issue: https://github.com/goharbor/harbor-cli/issues/821\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/007ce352-4c84-441c-9665-5f2fdc4ffb42\n\n#### Harbor Satellite: Ground Control CLI and Kubernetes Fleet Operator\n\nCNCF - Harbor: Satellite Ground Control CLI and Kubernetes Fleet Operator (2026 Term 2)\n\n- Description: Harbor Satellite needs first-class fleet management on top of the new Swagger-first Ground Control API. The mentee will build a `groundctl` CLI generated from the OpenAPI spec covering satellite lifecycle, user management, and a GitOps-style `apply -f` workflow, and pair it with a lightweight Kubernetes operator that manages Satellite instances as custom resources so fleets can be driven through ArgoCD or Flux on edge clusters (k3s, RKE2, microk8s).\n- Expected Outcome:\n - Finalized Ground Control OpenAPI spec and generated Go client\n - `groundctl` CLI for satellite lifecycle (register, list, inspect, update-config, delete), users, and `apply -f` GitOps mode\n - `Satellite` CRD plus controller reconciling against Ground Control and deploying via the existing Helm chart\n - Status subresource reporting registration, sync, and cache health back to the cluster\n - End-to-end tests on kind/k3d deploying multiple satellites via CRD; CLI and operator docs with ArgoCD/Flux examples\n- Recommended Skills: Golang, OpenAPI/Swagger, spf13/cobra, Kubernetes (CRDs, controller-runtime, kubebuilder), Helm, GitOps\n- Mentor(s):\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n - Vadim Bauer (@vad1mo, vb@container-registry.com)\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n- Upstream Issue: https://github.com/container-registry/harbor-satellite/issues/375\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/0d89fb23-337d-45a1-a108-23424efa2bf8\n\n### Jaeger\n\n#### AI-Powered Trace Analysis: Phase 2 - Self-Service \"Skills\" Framework\n\nCNCF - Jaeger: AI-Powered Trace Analysis Phase 2 - Skills Framework (2026 Term 2)\n\n- **Description:** Jaeger is the industry-standard platform for distributed tracing. As microservice architectures grow complex, finding root causes in massive trace data becomes increasingly difficult. While Phase 1 of this initiative established a baseline AI assistant for natural language search, the system currently relies on hard-coded capabilities. This project (Phase 2\\) aims to transform the Jaeger AI agent from a static chatbot into an extensible, user-programmable platform. The primary objective is to implement a \"Self-Service Skills\" framework, architecturally similar to \"Claude Code Skills.\" This will allow end-users to teach the Jaeger AI new debugging workflows (e.g., \"Analyze Critical Path\" or \"Detect N+1 Queries\") by simply adding configuration files containing system prompts and logic rules, without needing to recompile the Jaeger binary. The applicant will build this extension within the Jaeger v2 (OpenTelemetry-based) architecture, utilizing **LangChainGo** to orchestrate interactions with Language Models (SLMs/LLMs). This project bridges the gap between generic AI reasoning and domain-specific observability expertise.\n- **Expected Outcome:**\n - **Skills Engine Implementation:** An approach compatible with our [BYOA (bring your own agent)](https://docs.google.com/document/d/1qD0OpyRfq-JbO6MCB5gmVxsdPcpPhxz1R_pPnKDdYOg/edit?tab=t.0#heading=h.qgr5ifum0a9m) direction that dynamically discovers, validates, and loads user-defined \"Skills\" (prompts and tool definitions) from configuration.\n - **Smart Analysis Features:** A polished implementation of Natural Language Search and Contextual Trace Explanation that intelligently leverages these loaded skills.\n - **Local-First Support:** Verified compatibility with local model runners (e.g., Ollama, Llama.cpp) to ensure deterministic performance without sending data to public clouds.\n - **UI Integration:** Enhancements to the Jaeger React UI to expose these AI capabilities and visualize the \"reasoning steps\" taken by the agent.\n - **Documentation:** A complete guide for users on \"How to Author Custom AI Skills for Jaeger.\"\n- **Learning Opportunities:**\n - **Agentic AI Architecture:** Learn to design stateful AI agents in Go that utilize \"Tool Calling\" and \"Reasoning Loops\" rather than simple text generation.\n - **OpenTelemetry Internals:** Gain deep familiarity with the OpenTelemetry Collector architecture, as Jaeger v2 is built directly on top of it.\n - **Cloud-Native Engineering:** Experience contributing to a graduated CNCF project, including navigating code reviews, writing design docs (RFDs), and adhering to open-source best practices.\n - **Full-Stack Development:** Practical experience bridging a complex Go backend with a modern React frontend.\n- **Recommended Skills:**\n - **Languages:** Strong proficiency in **Go (Golang)** is required. Experience with **TypeScript/React** is highly recommended.\n - **AI/LLM:** Familiarity with LLM concepts (Prompt Engineering, RAG, Function Calling) and frameworks like LangChain.\n - **Domain Knowledge:** Basic understanding of distributed systems, observability, or debugging workflows is beneficial.\n- **Mentors:**\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/8440\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4f36fd67-e77b-4c40-91be-1d3150ad34f9\n\n#### Jaeger for GenAI Observability: Specialized Trace Visualization\n\nCNCF - Jaeger: Jaeger for GenAI Observability: Specialized Trace Visualization (2026 Term 2)\n\n- Description: Distributed tracing is essential for GenAI observability, but observing AI Agents differs fundamentally from observing microservices. While microservice traces focus on network latency and error codes, AI traces focus on the \"reasoning process.\" The current Jaeger UI displays traces in a standard waterfall timeline, making it difficult to distinguish between logical \"Tool Calls\" and technical operations, and nearly impossible to read multi-paragraph prompts or view generated images. This project aims to transform the Jaeger UI into a first-class GenAI observability tool. When Jaeger detects a trace containing GenAI-specific metadata (following OpenTelemetry semantic conventions), it should automatically adapt its presentation to prioritize the \"Agentic Flow.\"\n- Expected Outcome:\n - Automatic \"GenAI Mode\" detection: detect `gen_ai.*` attributes and offer/switch to a specialized visualization mode\n - Agentic hierarchy with iconography: use distinct icons to differentiate span types (e.g., \"brain\" for LLM calls, \"wrench\" for tool calls, \"database\" for RAG retrieval)\n - Rich-media side panel leveraging ADR-0006 side-panel capability, with Markdown support for prompts and completions, pretty-printed JSON for tool inputs/outputs, and direct rendering of images/audio previews\n - Simplified \"logical\" view: toggle to hide infrastructure-level noise and reveal a clean, high-level reasoning flow\n - More compact table view of multiple traces on the Search page\n- Recommended Skills: React, TypeScript, Ant Design components, OpenTelemetry Semantic Conventions (specifically for GenAI), basic knowledge of LLM application patterns (prompting, RAG, tool use)\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/8401\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/46a525b2-568b-4aff-8156-459c8600c759\n\n### Karmada\n\n#### Build Karmada Agent Skills\n\nCNCF - Karmada: Build Agent Skills (2026 Term 2)\n\n- Description: Karmada is a multi-cluster orchestration system, but AI coding agents still lack a Karmada-specific skill set. Without a dedicated skill repository, agents often need to search scattered documentation, infer policy structure from incomplete context, and may produce incorrect `PropagationPolicy`, `OverridePolicy`, or troubleshooting guidance. This project aims to build the Karmada skill set for AI coding agents. The design follows mature multi-skill repository patterns, with a shared knowledge base, focused workflow skills, and deterministic helpers for schema-sensitive tasks.\n- Expected Outcome:\n - A shared knowledge base for policy APIs, policy patterns, troubleshooting cases, component guides, and reusable examples.\n - Initial skills:\n - karmada-knowledge\n - karmada-create-policy\n - karmada-audit-policy\n - karmada-explain-placement\n - karmada-debug-propagation\n - karmada-search\n - karmada-controller-manager\n - Deterministic helper scripts, fixtures, and example scenarios for policy generation, policy review, placement explanation, propagation debugging, and multi-country cluster management.\n - Contributor documentation for adding new skills, examples, and knowledge files under hack/agent-skills/.\n- Recommended Skills:\n - Kubernetes and multi-cluster orchestration concepts\n - Familiarity with Karmada policies and components\n - YAML and Markdown authoring\n - Python or Go for helper scripts\n - Bash/shell scripting\n - CI/testing for open-source repositories\n - Experience using AI coding agents or designing agent skills\n- Mentor(s):\n - Zhen Chang (@XiShanYongYe-Chang, changzhen5@huawei.com)\n - Hongcai Ren (@RainbowMango, qdurenhongcai@gmail.com)\n- Upstream Issue: https://github.com/karmada-io/community/issues/190#issuecomment-4248950867\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/12821d1d-9528-4cf3-ac3c-d57a6b585599\n\n### kgateway\n\n#### Documentation improvements for OIDC and JWT IdPs integrations\n\nCNCF - kgateway: Documentation improvements for OIDC and JWT IdPs integrations (2026 Term 2)\n\n- Description: The goal of this project is to test and document common \nJWT validation scenarios (e.g., JWKS, multiple issuers, and claim-based validation)\nand demonstrate kgateway integration with multiple OAuth identity providers.\n\n- Expected Outcome: \n - Design a repeatable documentation pattern for identity providers\n - A set of documentation guides for integrating kgateway with popular IdPs\n - A det of documentation guides covering common JWT validation scenarios\n - Working, reproducible configuration examples (YAML manifests) that users can directly apply\n\n- Recommended Skills:\n - Technical writing\n - Kubernetes\n - Understanding of authentication/authorization concepts (JWT, OAuth2, etc.)\n - Git \n\n- Mentor(s):\n - Art Berger (@artberger, art.berger@solo.io) \n - Nina Polshakova (@npolshakova, ninapolshakova@gmail.com)\n\n- Upstream Issue: https://github.com/kgateway-dev/kgateway.dev/issues/725\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/13040ac0-7b51-48c1-bcd9-8e4e0cf4a905\n\n### Kmesh\n\n#### Integrating Kmesh into Headlamp UI\n\nCNCF - Kmesh: Integrating Kmesh into Headlamp UI (2026 Term 2)\n\n- Description: [Headlamp](https://headlamp.dev) is an open-source, extensible Kubernetes web UI offering easy cluster management, multi-cluster support, RBAC, and a plugin system for adding custom functionality. Users who work with Kmesh today have to switch back and forth between Headlamp (for general Kubernetes resource management) and CLI tools / `kubectl` (for Kmesh-specific inspection), which creates a fragmented workflow and a poor user experience. There is currently no simple visual way to view Kmesh resources, inspect waypoints and related components, understand overall mesh status, or troubleshoot issues quickly from within an interface users already use. This project proposes building a Headlamp plugin for Kmesh that brings Kmesh resources directly into the Headlamp UI, providing lightweight visibility of Kmesh resources alongside other Kubernetes resources. The full-featured Kmesh dashboard remains the place for advanced operations; the Headlamp plugin focuses on reducing context switching and improving ease of use for day-to-day workflows.\n- Expected Outcome:\n - A Headlamp plugin (TypeScript/React) that registers Kmesh CRDs and surfaces them as first-class resources in the Headlamp UI.\n - List and detail views for core Kmesh resources (e.g., waypoints and eBPF map)\n - Visual indicators of mesh status: per-resource health, readiness, and recent Events; cluster-level summary of Kmesh components.\n - Inspection helpers: pretty-printed YAML, related-pod views, and quick links to associated workloads/services.\n - Documentation (README, screenshots, install guide) and a published plugin (Helm/manifest or Headlamp plugin registry entry).\n - Unit/component tests for the plugin and an end-to-end smoke test against a kind/minikube cluster running Kmesh.\n- Recommended Skills:\n - Kubernetes (CRDs, RBAC, kubectl)\n - React / Next.js\n - TypeScript\n - Familiarity with Kmesh (or service mesh concepts in general)\n - Headlamp UI\n- Mentor(s):\n - Yash Israni (yashisrani, imailyash57@gmail.com),\n - Jayesh Savaliya (jayesh9747, savaliyajayesh2405@gmail.com)\n- Upstream Issue: https://github.com/kmesh-net/kmesh/issues/1658\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c5b8d1fa-b75a-4f88-a63b-e6487dc7e39b\n\n### krkn - Chaos\n\n#### Automated Documentation Sync Bot for Krkn-Chaos Projects\n\nCNCF - krkn-chaos: Automated Documentation Sync Bot for Krkn-Chaos Projects (2026 Term 2)\n\n- Description: The krkn-chaos/website repository hosts the unified documentation for the entire krkn-chaos ecosystem (krkn, krkn-hub, krknctl, krkn-ai, krkn-operator, cerberus, etc.) as a Hugo/Docsy site deployed at krkn-chaos.dev. Currently, when changes are made to any of these upstream projects — such as adding a new scenario, modifying configuration options, or updating CLI flags — someone must manually open a PR against the website repo to update the corresponding docs. This is tedious, easy to forget, and often leads to documentation drift where the docs no longer match the actual tool behavior. This issue proposes building a bot or GitHub Action-based workflow that detects documentation-impacting changes in upstream krkn-chaos repositories and automatically creates a draft PR on the website repo with the relevant documentation updates. The bot would analyze the scope of the change (e.g., new config fields, updated parameters, new scenario) and generate or update the corresponding Hugo content files, following the existing content structure and conventions (tabbed scenario layouts, parameter tables, etc.).\n- Expected Outcome: \n - Build a GitHub Action or bot that triggers on merged PRs in upstream krkn-chaos repos and automatically creates draft documentation PRs on the website repository following existing Hugo/Docsy content conventions.\n - Support common change types including new or updated config fields, CLI flag changes, new chaos scenarios, and modified parameter tables.\n - Enable interactive refinement of generated documentation PRs through review comments, similar to code review bots like CodeRabbit.\n\n- Recommended Skills: Python, GitHub Actions/Workflows, Hugo static site basics, LLM, Agent development\n- Mentor(s):\n - Rahul Shetty (@rh-rahulshetty , rashetty@redhat.com)\n - Naga Ravi Chaitanya Elluri (@chaitanyaenr , nelluri@redhat.com)\n - Darshan Jain (@ddjain , darjain@redhat.com)\n- Upstream Issue: https://github.com/krkn-chaos/website/issues/320\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5b44929d-7570-43a7-80ea-474062b813fb\n\n#### Dynamic Cluster-Aware Configuration Generation for Krkn-AI\n\nCNCF - krkn-chaos: Dynamic Cluster-Aware Configuration Generation for Krkn-AI (2026 Term 2)\n\n- Description: Krkn-AI's [discover command](https://krkn-chaos.dev/docs/krkn_ai/discover/) connects to a Kubernetes/OpenShift cluster and generates a static configuration file by enumerating cluster components (namespaces, pods, services, PVCs, nodes). While useful, the generated config still requires significant manual work before it can actually be used. Health check URLs are commented-out placeholders, the fitness function defaults to a single hardcoded PromQL query, and scenario selection is static regardless of what exists in the cluster. This issue proposes enhancing discover to produce a dynamic, cluster-aware configuration that is closer to runnable out-of-the-box. By inspecting routes, ingresses, services, and available Prometheus metrics during discovery, we can auto-populate health check URLs, suggest relevant fitness function queries scoped to discovered namespaces, and intelligently enable only the scenarios that apply to the discovered infrastructure.\n- Expected Outcome: \n - Auto-discover OpenShift Routes, Kubernetes Ingresses, and Services to populate health check URLs in the generated configuration.\n - Query Prometheus for available metrics to suggest namespace-scoped fitness function queries instead of hardcoded defaults.\n - Intelligently enable chaos scenarios based on discovered cluster components (e.g., PVC, VMI, network interfaces).\n\n- Recommended Skills: Python, Kubernetes/OpenShift (client libraries, API concepts like Routes, Ingresses, Services), Prometheus/PromQL basics\n- Mentor(s):\n - Rahul Shetty (@rh-rahulshetty , rashetty@redhat.com)\n - Naga Ravi Chaitanya Elluri (@chaitanyaenr , nelluri@redhat.com)\n- Upstream Issue: https://github.com/krkn-chaos/krkn-ai/issues/188\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b89f3736-7588-4e64-9040-1235ed77155a\n\n### Kuadrant\n\n#### Implement AccessPolicy CRD for tool-level authorization in the Kuadrant agentic gateway\n\nCNCF - Kuadrant: Implement AccessPolicy CRD for tool-level authorization (2026 Term 2)\n\n- Description: Kuadrant's MCP Gateway is an Envoy-based gateway for Model Context Protocol (MCP) servers. It currently handles authentication and coarse-grained authorization via AuthPolicy/Authorino, but has no built-in mechanism for tool-level authorization, e.g., allowing agent A to call `add` and `subtract` on a math server while agent B can only call `subtract`. The kube-agentic-networking SIG is defining a standard AccessPolicy CRD for exactly this. MCP Gateway is well-positioned to implement it because its ext_proc already parses MCP request bodies and exposes tool metadata via headers (`x-mcp-method`, `x-mcp-toolname`, `x-mcp-servername`). This project will design how AccessPolicy maps to Kuadrant's AuthPolicy/Authorino, then build an experimental implementation covering CRD definition, a controller that translates tool-level authorization rules into Authorino configuration, identity model integration (starting with OIDC), `tools/list` response filtering so callers only see tools they're authorized to use, and CEL-based authorization expressions. The mentee will work closely with mentors on the design doc, pair on implementation decisions, and engage with both the Kuadrant and kube-agentic-networking communities.\n- Expected Outcome:\n - Design document covering AccessPolicy-to-AuthPolicy/Authorino mapping, body parsing strategy (ext_proc vs Envoy MCP filter), identity model choices, `tools/list` filtering, and CEL-based authorization\n - AccessPolicy CRD with status conditions and CEL validation rules\n - Controller that watches AccessPolicy resources and generates/updates AuthPolicy resources with authorization rules based on `x-mcp-toolname` headers\n - OIDC identity source support, with consideration for ServiceAccount and SPIFFE identity types\n - `tools/list` response filtering so callers only see tools they are authorized to invoke\n - CEL-based authorization rule support (e.g., `request.mcp.tool_name.startsWith(\"read_\")`)\n - E2E tests covering allow/deny scenarios for tool-level access control\n - Documentation guide in `docs/guides/`\n- Recommended Skills:\n - Go (required)\n - Kubernetes basics (required)\n - Networking background or familiarity with HTTP/REST protocols\n - Interest in AI/agentic networking and protocols (MCP, A2A, others)\n- Mentor(s):\n - David Martin (@david-martin, davmarti@redhat.com)\n - Guilherme Cassolato (@guicassolato, guicassolato@gmail.com)\n- Upstream Issue: https://github.com/Kuadrant/mcp-gateway/issues/804\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d6231715-be24-40f0-b2a5-1b66652eb835\n\n#### Investigate and prototype A2A protocol support in the Kuadrant agentic gateway project\n\nCNCF - Kuadrant: Prototype A2A protocol support in the agentic gateway (2026 Term 2)\n\n- Description: Kuadrant's MCP Gateway is an Envoy-based gateway for Model Context Protocol (MCP) servers that provides routing, policy enforcement, and tool federation. As the agentic ecosystem grows, we're looking to extend the gateway's capabilities beyond MCP to support other agentic protocols. The A2A (Agent-to-Agent) protocol is an emerging standard for inter-agent communication with capabilities like long-running tasks, streaming, and agent discovery via agent cards. This project will investigate how A2A support can be added to the gateway alongside MCP, then build a proof-of-concept demonstrating federated agent discovery and A2A request routing through the gateway. The mentee will work closely with mentors throughout — collaborating on the design doc, pairing on implementation decisions, and spiking on specific pieces as needed to validate assumptions early. They will also engage with the broader Kuadrant community through PR reviews, design discussions, and community calls.\n- Expected Outcome:\n - Analysis of the A2A protocol with a gap assessment comparing A2A and MCP traffic patterns (request/response vs long-running tasks, push notifications, multi-modal artifacts)\n - Design document covering A2A routing through ext_proc, federated agent card serving in the broker, session handling implications, and CRD design\n - Federated agent card endpoint in the broker that aggregates upstream A2A agent cards\n - A2A request routing through the Envoy ext_proc path, with appropriate header handling and policy enforcement\n - CRD design (new resource or MCPServerRegistration extension) for registering A2A agents with the gateway controller\n - E2E tests demonstrating A2A agent discovery and task execution through the gateway\n- Recommended Skills:\n - Go (required)\n - Kubernetes basics (required)\n - Networking background or familiarity with HTTP/REST protocols\n - Interest in AI/agentic networking and protocols (MCP, A2A, others)\n- Mentor(s):\n - David Martin (@david-martin, davmarti@redhat.com)\n - Craig Brookes (@maleck13, cbrookes@redhat.com)\n- Upstream Issue: https://github.com/Kuadrant/mcp-gateway/issues/766\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/530ba5e1-d3ac-4cbc-bad1-824683e97d1a\n\n#### Investigate native Envoy MCP filter as replacement for ext-proc parsing in the Kuadrant agentic gateway\n\nCNCF - Kuadrant: Native Envoy MCP filter as replacement for ext-proc parsing (2026 Term 2)\n\n- Description: Kuadrant's MCP Gateway uses an Envoy external processor (ext_proc) to parse MCP JSON-RPC requests, extract metadata, rewrite request bodies, and route tool calls to backend MCP servers. This works but adds latency via a gRPC hop per request and requires maintaining custom MCP protocol parsing logic. Envoy has been rapidly adding native MCP support, as of v1.38, the Envoy MCP filter can parse MCP messages, populate dynamic metadata for downstream RBAC/ext_authz filters, handle session management, support SSE and Streamable HTTP transport, and aggregate multiple backend MCP servers. A previous investigation rejected the Envoy MCP filter due to missing body modification support, limited method coverage, and no aggregation, but the filter has since evolved considerably. This project will perform a fresh evaluation, produce a design document mapping each ext_proc responsibility to native Envoy capabilities, identify gaps (particularly around request body rewriting for tool prefix stripping and dynamic metadata consumption by Authorino), build a proof-of-concept demonstrating the native filter approach, and propose an incremental migration path. The mentee will work closely with mentors on the design, validate assumptions through prototyping with standalone Envoy, and engage with both the Kuadrant and Envoy communities.\n- Expected Outcome:\n - Design document covering capability mapping of each ext_proc responsibility to Envoy MCP filter features, body modification strategy, dynamic metadata vs header trade-offs for Authorino integration, federation/aggregation comparison, session management analysis, and Istio version dependency chain\n - Proof-of-concept demonstrating Envoy MCP filter parsing requests and populating metadata, downstream authorization consuming that metadata, and tool routing to multiple backends\n - Clear identification of what still requires custom code after migration\n - Proposed target architecture and incremental migration plan\n - E2E tests validating the prototype against existing test scenarios\n - Documentation of Istio version requirements and feature gates needed\n- Recommended Skills:\n - Go (required)\n - Kubernetes basics (required)\n - Networking background or familiarity with HTTP/REST and Envoy proxy\n - Interest in AI/agentic networking and protocols (MCP, A2A, others)\n- Mentor(s):\n - David Martin (@david-martin, davmarti@redhat.com)\n - TBD (@tbd, tbd@email)\n- Upstream Issue: https://github.com/Kuadrant/mcp-gateway/issues/809\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/1acff18b-c4da-4166-9a79-ceb8a8ad112b\n\n#### Transform Kuadrant Policy YAML Editors into Interactive Form Views\n\nCNCF - Kuadrant: Transform Policy YAML Editors into Interactive Form Views (2026 Term 2)\n\n- Description: The Kuadrant Console Plugin provides a web interface for managing API gateway policies in OpenShift, but currently relies heavily on YAML editing for most policy types. While DNSPolicy and TLSPolicy already have user-friendly form-based interfaces with dual Form/YAML views, validation, and guided workflows, the remaining core policies (RateLimitPolicy, TokenRateLimitPolicy, AuthPolicy, Plan, and OIDC) still require users to manually write YAML. This creates a steep learning curve and error-prone configuration experience. This project aims to bring RateLimitPolicy, TokenRateLimitPolicy, AuthPolicy, Plan, and OIDC policies to feature parity with the existing DNS and TLS form implementations. Form designs will be provided by the Kuadrant team. The mentee will implement these designs as PatternFly-based form interfaces following the established patterns from the DNS and TLS policy forms. These forms will allow users to configure policies through validated form fields while maintaining the flexibility to switch to YAML view for advanced use cases. The forms must support both creation and editing of policies, include proper field validation, handle complex nested structures (such as rate limit configurations and authentication rules), and synchronize seamlessly between form and YAML representations using the same patterns already proven in the DNS and TLS implementations.\n\n- Expected Outcome:\n - Form-based creation and editing interfaces for RateLimitPolicy, TokenRateLimitPolicy, AuthPolicy, Plan, and OIDC policies implemented using the same patterns, components, and structure as the existing DNSPolicy and TLSPolicy forms\n - Dual view toggle (Form View / YAML View) with bidirectional synchronization using js-yaml for all five policy types\n - Field validation following the established validation pattern covering required fields, numeric constraints, conditional dependencies, and Kubernetes resource naming conventions\n - PatternFly component integration matching existing forms: expandable sections for complex nested configurations, validated text inputs, dropdowns for enum fields, and reuse of gateway selection components\n - Policy-specific form fields for: rate limit units and counters (RateLimitPolicy), token-based rate limiting (TokenRateLimitPolicy), authentication strategies and credentials (AuthPolicy), plan tiers and quotas (Plan), and OIDC provider configurations (OIDC)\n - Error handling using the existing error modal and inline validation message patterns\n - Internationalization support for all form labels and validation messages using i18next following the existing localization structure\n - Both create (`/~new`) and edit (`/:name/edit`) routes for each policy type matching the DNS/TLS routing pattern\n - Unit and component tests covering form validation, YAML synchronization, and error states following the established testing patterns\n\n- Recommended Skills: TypeScript, React, PatternFly framework, Kubernetes concepts (CRDs, policies, gateways), OpenShift Console SDK, dynamic plugin development, YAML parsing, form state management\n\n- Mentor(s):\n - Rachel Lawton (@R-Lawton, rlawton@redhat.com)\n - Emma Roche (@emmaaroche, eroche@redhat.com)\n\n- Upstream Issue: https://github.com/Kuadrant/kuadrant-console-plugin/issues/378\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/02638e62-0bba-40d9-bf8e-345b8ca46930\n\n### KubeEdge\n\n#### Building an Edge-Cloud Collaborative Framework for Embodied AI Applications with KubeEdge\n\nCNCF - KubeEdge: Edge-Cloud Collaborative Framework for Embodied AI Applications (2026 Term 2)\n\n- Description: This project aims to explore how KubeEdge can support real-world embodied AI applications, where intelligent devices such as robots, inspection systems, or autonomous mobile platforms need to perceive, process, and respond in edge environments.\nThe mentee will select a representative embodied AI scenario and build an end-to-end edge-cloud collaboration solution with KubeEdge. The solution should cover device or data source access, edge-side data processing, lightweight AI inference, cloud-edge synchronization, and system behavior under unstable network conditions.\nThrough this project, the community will gain a reproducible reference implementation that demonstrates how KubeEdge can be used as the infrastructure foundation for embodied AI workloads.\n- Expected Outcome:\n - Select a specific scenario related to embodied intelligence.\n - Set up the KubeEdge edge-cloud environment: complete the deployment and configuration of CloudCore and EdgeCore, enable edge node access, and verify status synchronization and basic communication capabilities.\n - Implement a closed loop for device access and edge AI inference: complete device or data source access, data collection, device status modeling, deployment of edge-side AI inference services, and inference result reporting.\n - Verify edge-cloud collaboration and edge autonomy: implement cloud-side model delivery, configuration updates, and data aggregation, and verify continuous edge operation and recovery synchronization under weak network or disconnected scenarios.\n - Provide reproducible engineering assets and evaluation documents, including architecture diagrams, KubeEdge configuration files, deployment and validation scripts, sample data, running instructions, and performance and reliability evaluation reports.\n- Recommended Skills: Kubernetes, KubeEdge, Go, Python, Edge Computing, Edge AI\n- Mentor(s):\n - Hongbing Zhang (@HongbingZhang, hongbing.zhang@daocloud.io)\n - Chen Su (@ghosind, ghosind@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6755\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/6cc78cc8-721d-4ea9-9cbf-59f31fd02f25\n\n#### Comprehensive Example Restoration for KubeEdge Ianvs: Phase III\n\nCNCF - KubeEdge: Comprehensive Example Restoration for Ianvs: Phase III (2026 Term 2)\n\n- Description: Ianvs serves as the KubeEdge SIG AI distributed benchmark toolkit. As more and more contributors running, KubeEdge Ianvs now has up to 30 examples, and the number is still increasing. KubeEdge Ianvs then faces mounting usability issues due to dependency evolution and validation mechanisms. As Python versions, third-party libraries, and Ianvs features advance, partial historical examples fail to execute. This has led to surging user-reported Issues from confused contributors, untested PRs breaking core functionality of legacy features, and severely outdated documentation misaligning with actual capabilities. Without systematic intervention, the example risks becoming obsolete for edge-AI developers and especially newcomers. We then try to resurrect Ianvs’ usability with a comprehensive example restoration.\n- Expected Outcome:\n - Diagnose & fix bugs across examples, including dependency manifests, license scan, and runtime configurations.\n - Documentation Modernization, including revamp tutorials with reproducible step-by-step guides, publish developer-focused debugging playbooks for common failures. Write and upload the corresponding blog to the KubeEdge Website.\n - Advanced: Build a CI pipeline testing examples with GitHub Actions against multiple Python versions, critical Ianvs/upstream updates, and block PRs that break validated examples\n- Recommended Skills: Python, Benchmark, KubeEdge-Ianvs, AI/ML\n- Mentor(s):\n - Zimu Zheng (@MooreZheng, zimu.zheng@huawei.com)\n - hsj576 (@hsj576, sjhu21@m.fudan.edu.cn)\n- Upstream Issue: https://github.com/kubeedge/ianvs/issues/230\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/123576ab-9c3a-4c63-a1b0-4f35c41845f2\n\n#### Enabling Edge-Native Inference for Lightweight Large Language Models with KubeEdge\n\nCNCF - KubeEdge: Edge-Native Inference for Lightweight LLMs (2026 Term 2)\n\n- Description: This project focuses on validating KubeEdge as an edge-native infrastructure for lightweight large language model inference. As more AI services move from the cloud to edge devices, lightweight LLMs provide a practical way to reduce latency, protect data privacy, and support local intelligence under limited resources.\nThe mentee will deploy one or more lightweight LLMs on KubeEdge edge nodes and evaluate the complete workflow, including model packaging, workload scheduling, service exposure, lifecycle management, and performance measurement.\nThe project is expected to produce a practical reference for running generative AI workloads on edge nodes managed by KubeEdge.\n- Expected Outcome:\n - Successfully deploy and run one or more small-parameter large models on KubeEdge edge nodes, and complete end-to-end inference workflow validation.\n - Explore deployment methods and best practices for managing lightweight model services based on KubeEdge.\n - Evaluate basic performance on edge devices, including startup time, memory usage, inference latency, and runtime stability.\n - Fix issues discovered during validation, and submit PRs to KubeEdge or related example repositories when necessary.\n - Publish a blog or document to kubeedge/website introducing how to deploy and run small-parameter large models based on KubeEdge.\n - Optional: complete example validation with a lightweight scenario, such as local Q&A, document summarization, or lightweight multimodal inference.\n- Recommended Skills: Kubernetes, KubeEdge, Python, Go, LLM Inference, Edge AI, Model Deployment\n- Mentor(s):\n - Chuanhao Jin (@DoisLONG, 15221580643@163.com)\n - Chen Su (@ghosind, ghosind@gmail.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6756\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/4e2c706d-5a79-4816-acd8-8d5ca643a88a\n\n#### Exploring AI PCs as KubeEdge-Managed Edge Nodes for Intelligent Workload Orchestration\n\nCNCF - KubeEdge: AI PCs as Managed Edge Nodes for Workload Orchestration (2026 Term 2)\n\n- Description: This project explores how AI PCs can be integrated into the KubeEdge ecosystem as a new type of edge node. With built-in heterogeneous computing capabilities such as CPUs, GPUs, and NPUs, AI PCs are becoming suitable platforms for local AI inference, privacy-sensitive applications, and low-latency intelligent services.\nThe mentee will connect one or more AI PCs to KubeEdge, deploy representative AI workloads, and explore resource monitoring and workload orchestration patterns for AI PC environments.\nThe project will summarize practical experience and provide reference documentation for using KubeEdge to manage AI PCs as edge computing infrastructure.\n- Expected Outcome:\n - Connect one or more AI PCs to KubeEdge as edge nodes and verify their basic management capabilities.\n - Deploy and run representative AI workloads on AI PCs through KubeEdge, such as lightweight large model inference, vision models, or multimodal services.\n - Explore monitoring methods for local resources and AI-related metrics on AI PCs, such as CPU/GPU/NPU utilization, memory usage, and inference service health status.\n - Summarize best practices for workload deployment, resource management, and edge-cloud collaboration for AI PCs.\n - Fix issues discovered during validation, and submit PRs to KubeEdge, example repositories, or related documentation when necessary.\n - Publish a blog or document to kubeedge/website introducing how to use AI PCs together with KubeEdge.\n - Optional: explore an example scenario combining cloud-side collaboration and device-side inference, focusing on low-latency or privacy-sensitive tasks.\n- Recommended Skills: Kubernetes, KubeEdge, Edge AI, AI PC, Heterogeneous Computing, Resource Monitoring, Python, Go\n- Mentor(s):\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n - Hongbing Zhang (@HongbingZhang, hongbing.zhang@daocloud.io)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6757\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/39438a1c-0d94-41d6-9363-d5901f85cae8\n\n#### Exploring Alternatives to iptableManager: Optimizing Edge-Cloud Request Forwarding via Apiserver Redirection to cloudcore\n\nCNCF - KubeEdge: Alternatives to iptableManager via Apiserver Redirection (2026 Term 2)\n\n- Description: Currently, in KubeEdge, the cloudstream component utilizes iptables to redirect requests from the apiserver intended for the edge node's KubeletEndpoint to port 10003 of the cloudcore to which that edge node is connected. The request is then routed through cloudstream to edgestream, ultimately accessing the KubeletEndpoint port on the edged. This requires the iptableManager to use iptables for interception and forwarding every 10 seconds. Since this mechanism depends on iptables, a proposal has been made to explore whether it's possible to have the Apiserver redirect to cloudcore directly, thereby replacing the iptableManager.\n- Expected Outcome:\n - Submit a design proposal.\n - Complete the feature development and ultimately meet the requirements for merging the code into the main repository.\n- Recommended Skills: Go, Kubernetes, Client-go\n- Mentor(s):\n - Zhijia Yang (@luomengY, 2938893385@qq.com)\n - Shelley Bao (@Shelley-BaoYue, baoyue2@huawei.com)\n- Upstream Issue: https://github.com/kubeedge/kubeedge/issues/6754\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9838c889-671f-4b1e-a17f-d1a4c4f9279e\n\n### Kubernetes\n\n#### SIG Node / node-readiness-controller\n\n##### Advanced Observability: Per-Rule Metrics and Headlamp Plugin\n\nCNCF - Kubernetes: Per-Rule Metrics and Headlamp Plugin for node-readiness-controller (2026 Term 2)\n\n- Description: As clusters grow, understanding why a node is not \"Ready\" becomes complex. This project aims to improve visibility into the `node-readiness-controller`'s operations by enhancing its Prometheus metrics and providing a visual interface. The mentee will extend the internal metrics system to expose granular data for individual `NodeReadinessRule` objects and taint states. Additionally, the mentee will develop a plugin for Headlamp (the extensible Kubernetes UI) to visualize these readiness rules, showing real-time “node-availability” status and failure reasons directly in the dashboard.\n- Expected Outcome: New Prometheus metrics (e.g., rule evaluation duration, per-rule pass/fail counts); a functional Headlamp plugin for the project; and a pre-configured Grafana dashboard template.\n- Recommended Skills: Go, Prometheus, TypeScript/React (for the Headlamp plugin).\n- Mentor(s):\n - Avinesh Tripathi (@AvineshTripathi, avineshtripathi1@gmail.com)\n - Karthik K N (@Karthik-K-N, karthikkn1997@gmail.com)\n - Ajay Sundar Karuppasamy (@ajaysundark, ajaysundar.k@gmail.com)\n- Upstream Issue: [sigs.k8s.io/node-readiness-controller#182](https://github.com/kubernetes-sigs/node-readiness-controller/issues/182)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/2d006047-8e79-446f-97f5-ceec8e52ea00\n\n##### Scalability Testing and Release Reliability\n\nCNCF - Kubernetes: Scalability Testing & Release Reliability (2026 Term 2)\n\n- Description: For a controller that manages node readiness, reliable performance at scale is critical. This project aims to improve the project's test framework across three key areas: building a comprehensive scale-test suite using `kwok` to simulate clusters with 1,000+ nodes, hardening the release pipeline to automate versioning and promotion to [`registry.k8s.io`](https://registry.k8s.io), and refactoring the E2E test suite in `test/e2e` to be environment-agnostic and more reliable.\n- Expected Outcome: A scalable test harness using `kwok`; automated Prow job configurations; and a benchmark report detailing the controller's performance limits.\n- Recommended Skills: Kubernetes, Prow, kwok, Go, Shell scripting.\n- Mentor(s):\n - Karthik K N (@Karthik-K-N, karthikkn1997@gmail.com)\n - Priyanka Saggu (@Priyankasaggu11929, priyankasaggu11929@gmail.com)\n - Ajay Sundar Karuppasamy (@ajaysundark, ajaysundar.k@gmail.com)\n- Upstream Issue: [sigs.k8s.io/node-readiness-controller#151](https://github.com/kubernetes-sigs/node-readiness-controller/issues/151)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/052329cb-9237-4950-90b2-78461302f8af\n\n### Kubescape\n\n#### CEL rule engine support and Rego-to-CEL control migration\n\nCNCF - Kubescape: CEL rule engine support and Rego-to-CEL control migration (2026 Term 2)\n\n- Description: Kubescape evaluates compliance controls using OPA/Rego today, while Kubernetes has shipped native `ValidatingAdmissionPolicy` / `MutatingAdmissionPolicy` resources that use CEL expressions. The [`kubescape/cel-admission-library`](https://github.com/kubescape/cel-admission-library) project already ships a growing set of Kubescape controls as VAP resources, but Kubescape cannot evaluate them locally — so a resource passing `kubescape scan` may still fail the cluster's admission controller. This project adds a native CEL evaluation engine to Kubescape (running alongside Rego), using the same `ValidatingAdmissionPolicy` YAML format and `google/cel-go` library that Kubernetes uses internally. With the same rule expression evaluated in both places, Kubescape becomes directly comparable to — and competitive with — Kyverno for teams wanting a single policy language across CI, runtime scanning, and admission enforcement. A sample of existing Rego controls are then converted to CEL as proof-of-concept, validating the conversion pattern end-to-end.\n- Expected Outcome:\n - New `CELLanguage` rule type dispatched from the existing `runOPAOnSingleRule()` extension point in `core/pkg/opaprocessor/processorhandler.go`.\n - `runCELOnK8s()` implementation: loads `ValidatingAdmissionPolicy` YAML from `cel-admission-library`, evaluates with `google/cel-go` in a VAP-compatible environment (`object`, `params`, stubbed `request`), maps violations to `reporthandling.RuleResponse`.\n - Equivalence guarantee documented: for `object`-scoped rules, `kubescape scan` and the cluster admission controller produce identical results. Known gap (`authorizer`, `request.userInfo`) documented.\n - 10–20 existing regolibrary (Rego) controls converted to CEL and contributed to `cel-admission-library` as `ValidatingAdmissionPolicy` resources, with a conversion guide for future contributors.\n - Unit and integration tests; end-to-end verification showing a converted control evaluated identically by Kubescape and a live VAP on a real cluster.\n- Recommended Skills: Go, Kubernetes (CEL, ValidatingAdmissionPolicy, client-go), familiarity with OPA/Rego a plus.\n- Mentor(s):\n - Matthias Bertschy (@matthyx, matthias.bertschy@gmail.com) - primary\n - Ben Hirschberg (@slashben, ben@armosec.io)\n- Upstream Issue: [kubescape/kubescape#2001](https://github.com/kubescape/kubescape/issues/2001)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/01e645f6-b673-4b8e-8874-a446bb79c501\n\n#### In-cluster, GitOps-native SecurityException CRD for Kubescape, with Headlamp plugin support\n\nCNCF - Kubescape: GitOps-native SecurityException CRD with Headlamp plugin support (2026 Term 2)\n\n- Description: Kubescape today has no declarative, in-cluster mechanism for posture/compliance exceptions — they only come from JSON files or the ARMO cloud API, which blocks GitOps-native workflows and air-gapped clusters. A design for a `SecurityException` / `ClusterSecurityException` CRD (group `kubescape.io/v1`) already exists and covers both vulnerability and posture exceptions in a single resource with OpenVEX-compatible fields, label/namespace/image selectors, CEL validation, and Kubernetes Events for observability. The kubevuln (vulnerability) side is being implemented by the maintainers; this project focuses on the kubescape (posture) side, the operator rescan integration, and surfacing exceptions in the Kubescape Headlamp plugin so users can view and manage them from the UI.\n- Expected Outcome:\n - New `CRDExceptionsGetter` implementing `IExceptionsGetter` in kubescape, wrapping the existing getter and merging CRD posture entries (`SecurityException → armotypes.PostureExceptionPolicy`).\n - Match-field conversion: `resources`, `objectSelector`, and `namespaceSelector` mapped to `PortalDesignator` attributes; cloud-vs-CRD precedence per the design (cloud wins on overlap).\n - `expiresAt` evaluated at scan time; scan-time Kubernetes Events emitted on matched SecurityException resources.\n - Operator `SecurityExceptionWatchHandler` watching both kinds with a debounced `CooldownQueue`, dispatching rescans on changes.\n - CRD manifests with CEL validation rules merged into the Helm chart.\n - Headlamp plugin additions: list/view `SecurityException` and `ClusterSecurityException` resources, show matched findings/events, and a guided form to create new exceptions from a failing control or CVE on a workload.\n - Unit + integration tests for the Go side, plugin tests for the UI, and end-to-end verification against a running cluster.\n- Recommended Skills: Go, Kubernetes (controllers, CRDs, client-go / controller-runtime, dynamic client), TypeScript/React (for the Headlamp plugin).\n- Mentor(s):\n - Matthias Bertschy (@matthyx, matthias.bertschy@gmail.com) - primary\n - Ben Hirschberg (@slashben, ben@armosec.io)\n- Upstream Issue: [kubescape/kubescape#1982](https://github.com/kubescape/kubescape/issues/1982)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/207232a3-a41f-481b-bd8d-4838dcf1f37c\n\n### KubeStellar\n\n#### AI-driven bug discovery and remediation architect for KubeStellar Console\n\nCNCF - KubeStellar: AI-driven bug discovery and remediation architect for Console (2026 Term 2)\n\n- Description: The KubeStellar Console (console.kubestellar.io) has GA4 error tracking that surfaces JavaScript errors, failed API calls, and rendering failures in production — but no one systematically triages or investigates them. Common issues include undefined data guards causing crashes, stale WebSocket state showing outdated cluster data, chunk load failures on deployments, and silent error swallowing that hides failures behind blank cards. This project takes a novel approach: the mentee acts as a bug discovery architect, designing investigation strategies, analyzing production error data, and directing an AI coding agent (an advanced AI coding agent) to audit code paths, identify defects, and propose validated fixes with regression tests. The mentee is evaluated on bugs found, bugs fixed, reduction in production error rates, and quality of the automated bug-hunting workflows they create — not on lines of code manually written. Critically, the mentee builds autonomous GitHub Actions workflows that continuously find and fix bugs after the mentorship ends. This includes a weekly automated bug sweep that uses an AI agent to scan the codebase for new error patterns, unsafe access, and missing guards — auto-filing issues for each finding. A GA4 error regression workflow compares error rates week-over-week and auto-files issues when a category spikes. An auto-triage workflow triggers an AI agent to investigate new GA4 errors, reproduce them, and propose fix PRs. The mentee also builds a public Console Quality Dashboard tracking error trends, bug fix rates, and open issues, and presents findings at KubeStellar community calls at midpoint and end of term. Note: this program is independent from the companion \"test coverage architect\" program — this role focuses exclusively on production error analysis, bug discovery, GA4 data, and quality dashboards. It does not involve test infrastructure, coverage metrics, or CI pipeline work. The two programs have separate mentees, separate deliverables, and no overlapping scope. Prerequisite: access to and license for an advanced AI coding agent capable of autonomous multi-file code generation.\n- Expected Outcome: Triage and root-cause analysis of all existing GA4 errors, >=25 bugs discovered/filed/fixed with regression tests, >=50% reduction in production GA4 error rate, weekly automated bug sweep GitHub Actions workflow using AI agent to scan for error patterns and auto-file issues, GA4 error regression workflow that auto-detects week-over-week spikes, auto-triage workflow that investigates new errors and proposes fix PRs via AI agent, public Console Quality Dashboard tracking error trends and bug fix rates, improved error states across all card types (blank cards replaced with actionable messages), documented bug-hunting playbook for future contributors, 2 community call presentations (midpoint + final).\n- Recommended Skills: Analytical mindset for error triage and root cause analysis, basic familiarity with React/TypeScript and web error handling, experience using advanced AI coding agents, familiarity with GitHub Actions and browser developer tools, understanding of Kubernetes concepts helpful but not required.\n- Mentor(s):\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n - Ghanshyam Singh (@ghanshyam2005singh, ghanshyam2005singh@gmail.com)\n- Upstream Issue: https://github.com/kubestellar/console/issues/4190\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fa8a2bf8-3dba-4ce5-a0b1-ba9ee116a919\n\n#### AI-driven operational knowledge base and mission control testing for KubeStellar Console\n\nCNCF - KubeStellar: AI-driven operational KB and mission control testing for Console (2026 Term 2)\n\n- Description: KubeStellar Console's mission control feature uses an AI assistant backed by a knowledge base (console-kb) to help users perform operational tasks — installations, upgrades, troubleshooting, and multi-cluster sync fixes. The knowledge base needs comprehensive, validated operational content, and the full mission control pipeline (user question → KB lookup → command generation → cluster execution) needs end-to-end testing to ensure generated commands actually work. The mentee acts as an operational knowledge architect, using an AI coding agent (an advanced AI coding agent) to generate runbooks, installers, YAML templates, and troubleshooting fixes, then tests the complete mission control execution loop against real clusters. Critically, the mentee builds autonomous GitHub Actions workflows that nightly re-validate all KB operational content against live clusters, auto-filing issues when content goes stale, commands fail, or prerequisites change. The mentee also builds a feedback loop tracking which user queries return no results or bad results, auto-generating drafts for missing content. The mentee presents their findings at KubeStellar community calls at midpoint and end of term. Note: this program is independent from the companion \"test coverage architect\" and \"bug discovery\" programs — this role focuses exclusively on operational knowledge content, mission control pipeline validation, and KB coverage. It does not involve UI test infrastructure, coverage metrics, production error analysis, or GA4 data. The three programs have separate mentees, separate deliverables, and no overlapping scope. Prerequisite: access to and license for an advanced AI coding agent capable of autonomous multi-file code generation.\n- Expected Outcome: Runbooks covering all common operations (install, upgrade, rollback, disaster recovery, multi-cluster sync failures), library of validated YAML templates and fixes for known issues, end-to-end mission control pipeline tests (user query → KB → command generation → successful cluster execution), nightly GitHub Actions workflow that re-validates all KB content against live clusters and auto-files issues on failures, KB gap analysis with auto-generated drafts for missing content, >=90% of KB operational content validated as working on current KubeStellar versions, documented KB contribution guide for future contributors, 2 community call presentations (midpoint + final).\n- Recommended Skills: Familiarity with Kubernetes operations (kubectl, helm, YAML), technical writing ability for operational documentation, experience using advanced AI coding agents, familiarity with GitHub Actions and CI/CD, understanding of multi-cluster Kubernetes concepts helpful but not required.\n- Mentor(s):\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n- Upstream Issue: https://github.com/kubestellar/console/issues/4196\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a0fbeeef-f240-4c9f-8941-24a9c861001a\n\n#### AI-driven test coverage architect for KubeStellar Console\n\nCNCF - KubeStellar: AI-driven test coverage architect for KubeStellar Console (2026 Term 2)\n\n- Description: The KubeStellar Console (console.kubestellar.io) is the web dashboard for the KubeStellar multi-cluster platform. It currently has minimal automated test coverage — Playwright E2E tests exist but are flaky and not CI-blocking, and component-level tests are sparse. UI regressions, broken cards, and auth flow failures are caught manually or not at all. This project takes a novel approach: the mentee acts as a test architect, defining coverage goals, test plans, and acceptance criteria, then directs an AI coding agent (an advanced AI coding agent) to generate, iterate on, and validate the test suite. The mentee is evaluated on test design quality, coverage achieved, and bugs discovered — not on lines of code manually written. Work includes designing test matrices (browsers, screen sizes, demo vs live mode, error states), building Playwright E2E and Vitest component tests, stabilizing flaky tests to become CI-blocking, and — critically — building autonomous GitHub Actions workflows that continuously improve test coverage after the mentorship ends. This includes a workflow that detects untested new components in PRs and auto-generates test PRs via AI agent, a nightly test health workflow that detects flaky tests and auto-files issues, and a coverage regression gate that blocks PRs dropping below threshold. The mentee presents their testing strategy and results at KubeStellar community calls at midpoint and end of term. Note: this program is independent from the companion \"bug discovery and remediation\" program — this role focuses exclusively on test infrastructure, coverage automation, and CI pipelines. It does not involve production error analysis, GA4 data, or bug triage. The two programs have separate mentees, separate deliverables, and no overlapping scope. Prerequisite: access to and license for an advanced AI coding agent capable of autonomous multi-file code generation.\n- Expected Outcome: Playwright E2E tests covering 15-20 core user flows, Vitest component tests for all 30+ card types, test matrix covering 3 browsers x 2 screen sizes x 2 modes (demo/live), all E2E tests stable enough to be CI-blocking, coverage dashboard with >=70% target, >=15 bugs discovered and filed, GitHub Actions workflow that auto-generates tests for new untested components via AI agent, nightly test health workflow that detects flaky tests and auto-files issues, coverage regression gate blocking PRs that drop coverage, documented test authoring guide for future contributors, 2 community call presentations (midpoint + final).\n- Recommended Skills: Test design and quality assurance principles, basic familiarity with React/TypeScript, experience using advanced AI coding agents, familiarity with GitHub Actions, understanding of Kubernetes concepts helpful but not required.\n- Mentor(s):\n - Andy Anderson (@clubanderson, andy@clubanderson.com)\n - Arpit Srivastava (@Arpit529Srivastava, arpitsrivastava529@gmail.com)\n- Upstream Issue: https://github.com/kubestellar/console/issues/4189\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/390bbb3a-e49d-4c1d-8b45-331f34a26e51\n\n### KubeVela\n\n#### LRU Cache Eviction for the Native Helm Provider\n\nCNCF - KubeVela: LRU Cache Eviction for the Native Helm Provider (2026 Term 2)\n\n- Description: 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.\n- Expected Outcome:\n - Generic `LRUByteStore` package in `pkg/utils/cache/` built on `hashicorp/golang-lru/v2`, with per-entry TTL, byte accounting, byte-pressure eviction on `Put`, lazy TTL check on `Get`, and a periodic background sweep\n - Helm provider migration from in-memory parsed `*chart.Chart` objects to compressed `.tgz` bytes (~20–25× memory reduction), with `chartutil.Save` / `loader.LoadArchive` encapsulated in the provider so the cache remains opaque\n - New controller flags `--helm-cache-max-bytes` (default 256MB) and `--helm-cache-sweep-interval` (default 60s), wired through Helm chart values; immutable-version TTL extended from 24h to 30d\n - Prometheus metrics fed by `OnEvicted` callbacks: cache hits, misses (by reason: expired/evicted/absent), and current cache bytes\n - Ginkgo/Gomega test suite covering TTL expiry, byte-pressure eviction order, oversized entries, concurrent access, OnEvict callback correctness, and clean goroutine shutdown\n - Migration of existing usages and documentation/sizing guidance for operators\n- Recommended Skills:\n - Go (idiomatic Go, structs, interfaces, generics, `sync` primitives)\n - Kubernetes (controllers, reconcile loops, controller-runtime)\n - Helm (chart fetching, OCI/repo sources, `chartutil`, `loader`)\n - Caching concepts (LRU vs LFU, TTL, byte accounting, eviction triggers)\n - Testing in Go (Ginkgo/Gomega, table-driven tests, race detection)\n - Git and GitHub workflow (PRs, code review, rebasing)\n - Curiosity and follow-through on open-ended design problems\n - Async communication and open-source etiquette\n - Clear technical writing for design docs and user-facing documentation\n- Mentor(s):\n - Ayush Kumar (@roguepikachu, ayushshyamkumar888@gmail.com)\n - Vishal Kumar (@vishal210893, vishal210893@gmail.com)\n- Upstream Issue: https://github.com/kubevela/kubevela/issues/7106\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/e103d436-d906-413c-ae93-8aa4bffff377\n\n#### Native Secret-Sourced HTTP Headers and CRD-Based Config Management with Server-Side Validation\n\nCNCF - KubeVela: Secret-Sourced HTTP Headers and CRD-Based Config Management (2026 Term 2)\n\n- Description: 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 `ConfigTemplate`s as labeled ConfigMaps (`config-template-*` prefix) and `Config`s 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.\n- Expected Outcome:\n - New `HeaderFromSecret` field on the `Request` struct in `pkg/providers/http/http.go` (kubevela/workflow), with native Secret resolution inside `runHTTP()` mirroring the existing `getTransport()` TLS pattern\n - Updated `request.cue` definition in kubevela/kubevela exposing `headerFromSecret` as a parameter, with namespace defaulting to `context.namespace`\n - New `config.oam.dev/v1alpha1` API group with `ConfigTemplate` and `Config` CRDs, DeepCopy, and scheme registration\n - `ConfigTemplateReconciler` that parses CUE templates and writes the generated OpenAPI schema to `status.schema`\n - `ConfigReconciler` that materializes `Config` CRDs into Secrets with `ownerRef`s for garbage collection, with dual-read fallback to legacy `config-template-*` ConfigMaps\n - Validating admission webhooks for both kinds, enforcing CUE schema validation, custom `template.validation.$returns` checks, CUE template syntax, and mutual exclusivity of `properties` and `propertiesFrom`\n - Updated `vela` CLI (`config-template apply/list/show/delete`, `config create/list/delete`) and workflow `config` provider operating on the new CRDs, with graceful fallback to the legacy code path\n - Comprehensive Go unit tests, envtest controller tests, webhook tests, and end-to-end tests with a mock echo server (HTTP) and live cluster (Config CRDs)\n - Backward-compatibility tests confirming legacy ConfigMap templates and Secret-based configs continue to work\n - Documentation: usage examples for `headerFromSecret`, migration guidance for the new Config API, and CRD reference\n- Recommended Skills:\n - Go (idiomatic Go, structs, interfaces, error handling, `net/http`, `context`)\n - Kubernetes (Secrets, ConfigMaps, namespaces, RBAC, declarative API model)\n - CRDs, controllers, and admission webhooks (controller-runtime / Kubebuilder)\n - CUE — or willingness to learn quickly\n - Go testing (`testing`, table-driven tests, Ginkgo/Gomega, envtest)\n - Git and GitHub workflow (PRs, code review, rebasing)\n - Strong written communication and async collaboration\n - Interest in platform engineering, application delivery, and Kubernetes-native API design\n- Mentor(s):\n - Chaitanya Reddy Onteddu (@Chaitanyareddy0702, chaitanyareddy0702@gmail.com)\n - Jerrin Francis (@jerrinfrancis, jerrinfrancis7@gmail.com)\n- Upstream Issues:\n - https://github.com/kubevela/kubevela/issues/7104\n - https://github.com/kubevela/kubevela/issues/7105\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/5af163e9-b465-45d5-8f14-c18421e66e07\n\n### Kyverno\n\n#### Address findings from the Kyverno CNCF TAG Security & Compliance and General Technical Review assessments\n\nCNCF - Kyverno: Address findings from CNCF TAG Security & GTR assessments (2026 Term 2)\n\n- Description: Kyverno recently completed two CNCF assessments: a security assessment by the CNCF TAG Security & Compliance group and a General Technical Review by the CNCF TOC Project Reviews subproject. Together they produced a set of findings spanning documentation, threat modeling, network policies, global context cache bounds, API server authentication, SAST tooling, API stability and non-goals, UX/adopter research, webhook cert issuance/rotation guidance, \"safe-mode\" / temporary disable patterns, SLOs/SLIs and alerting/runbooks, dependency lifecycle and SCA workflows, third-party notices, and the security response process. The findings are tracked in umbrella issues for each assessment. In this mentorship, the mentee will work through the open findings from **both** the TAG Security & Compliance assessment and the General Technical Review, propose and implement fixes across the Kyverno codebase, docs, and Helm charts, and help close out both assessments. Work includes implementing cache bounds for the Global Context, restricting Global Context access in namespaced policies, adding API server request authentication for the admission webhook, generating sample/network-policy templates and a CLI command to produce a Kyverno NetworkPolicy, integrating SAST tooling (e.g. semgrep, Nancy) into CI, updating the threat model and architecture diagrams, documenting core CRDs/API stability, webhook cert rotation, safe-mode/incident playbooks, SLOs/SLIs and reference dashboards, the SCA/dependency lifecycle workflow, and improving the security documentation on kyverno.io.\n- Expected Outcome:\n - Resolve the open findings tracked in [kyverno/kyverno#15335](https://github.com/kyverno/kyverno/issues/15335) (TAG Security & Compliance assessment) and [kyverno/kyverno#15473](https://github.com/kyverno/kyverno/issues/15473) (General Technical Review assessment).\n - Implement Global Context cache bounds and access restrictions for namespaced policies (kyverno/kyverno#15359).\n - Add admission webhook authentication of requests from the API server.\n - Refresh the threat model (including CLI and other deployment options) and the architecture diagram to separate logical and physical components.\n - Document core CRDs/APIs and per-API-group stability policy, webhook cert issuance/rotation guidance, recommended \"temporary disable\" / safe-mode patterns, SLOs/SLIs with reference dashboards/runbooks, and the end-to-end dependency/SCA workflow.\n - Update the Kyverno security documentation: fix the audits page links, document risks of external data lookups, link to published security advisories, and link the current security response process.\n - Add tests covering the new behaviors and document the changes in the Kyverno docs site.\n- Recommended Skills:\n - Go\n - Kubernetes (admission controllers, CRDs, NetworkPolicy, client-go / controller-runtime)\n - Familiarity with security concepts (threat modeling, SAST, webhook authentication)\n - Technical writing\n - Git workflows\n- Mentor(s):\n - Shuting Zhao (@realshuting, shutingz@nirmata.com)\n - Cortney Nickerson (@CortNick, cortney.nickerson@nirmata.com)\n- Upstream Issue: \n - https://github.com/kyverno/kyverno/issues/15999\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3ca9c0e6-475d-4db6-87bd-fcab072ab7b0\n\n#### Kyverno Technical Outcomes\n\nCNCF - Kyverno: Technical Outcomes (2026 Term 2)\n\n- Description:\nOn the Kyverno website, we want to introduce and document a set of technical outcomes that users can achieve by adopting Kyverno. These outcomes should group together Kyverno’s policy capabilities (validate, mutate, generate, verify images, cleanup) into clear, high-level goals that resonate with platform engineers, security teams, and developers.\n\nRather than focusing on individual features, this work will highlight what teams can accomplish with Kyverno in real-world environments.\n\nProposed technical outcomes include:\n* Secure-by-Default Kubernetes – Enforce security and compliance policies across clusters automatically\n* Policy-Driven Platform Engineering – Enable golden paths and self-service infrastructure using policy as code\n* Automated Governance & Compliance – Continuously audit, report, and enforce organizational standards\n* Software Supply Chain Security – Verify images, enforce provenance, and reduce risk in CI/CD pipelines\n* Kubernetes Configuration Automation – Use mutation and generation to reduce manual configuration overhead\n* Multi-Cluster Policy Management – Apply consistent governance across distributed and multi-cloud environments\n* AI & Agent Governance – Apply policy controls to AI workloads and agent-driven infrastructure workflows\n\nEach outcome should connect Kyverno capabilities to real-world use cases, supported by artifacts from the community such as blog posts, talks, policy examples, and reference architectures.\n\n- Expected Outcome:\n * A new section of the Kyverno website dedicated to Technical Outcomes, where each outcome includes:\n * A clear description of the problem space and desired outcome\n * Mapping to Kyverno capabilities and policy types\n * Links to supporting resources (blogs, videos, talks, GitHub examples, policy libraries)\n * Optional diagrams or visual flows illustrating how Kyverno enables the outcome\n\nThis section should serve as:\n* A learning and onboarding resource for new users\n* A messaging bridge between technical features and business value\n* A foundation for future content, including case studies, solution briefs, and AI-driven policy generation experiences\n\n- Recommended Skills:\n * Technical writing and storytelling\n * Basic understanding of Kubernetes and cloud-native concepts\n * Familiarity with policy-as-code and/or security/compliance workflows (helpful but not required)\n * Willingness to learn Kyverno concepts and ecosystem\n * Experience with documentation or developer-focused content\n\n- Mentor(s):\n - Cortney Nickerson (@CortNick, cortney.nickerson@nirmata.com)\n - Shuting Zhao (@realshuting, shutingz@nirmata.com)\n- Upstream Issue: https://github.com/kyverno/kyverno/issues/15990\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/a37b94f5-b609-48be-9c5c-68825b3b7a73\n\n### Lima\n\n#### Improve Windows support (host and guest)\n\nCNCF - Lima: Improve Windows support (host and guest) (2026 Term 2)\n\n- Description: Lima launches Linux virtual machines with automatic file sharing and port forwarding (similar to WSL2). Currently, Lima supports Linux, macOS, and FreeBSD as guest operating systems. The primary goal of this project is to expand this capability by adding support for Windows guests. Furthermore, the project aims to improve the stability and user experience of running Lima on Windows hosts. This will be achieved by removing dependencies like `cygpath.exe`, researching and developing a native Hyper-V(or a [HCS](https://learn.microsoft.com/en-us/virtualization/api/hcs/overview)) driver to provide optimized, native virtualization on Windows hosts.\n\n- Expected Outcome:\n - Primary:\n - The ability to successfully launch and run Windows guest virtual machines using `limactl start template:windows` using the QEMU driver on any host.\n - Deliver a seamless installation experience on Windows hosts by automating configurations and eliminating the need for [manual setup notes](https://github.com/microsoft/winget-pkgs/pull/356038/changes#diff-9c16ba1b4e8cfc88d634b6cc436e0041d2201ac93e1d4fcd78fca09e0667ca3aR29)\n - Complete removal of the `cygpath.exe` dependency.\n - Secondary (if time permits):\n - Investigate and decide between Hyper-V and HCS for the native driver: HCS is the basis of WSL2 and may be available in Windows 11 Home Edition, while Hyper-V is only available in Pro/Enterprise editions. Research availability and integration feasibility.\n - Potentially integrate the chosen driver (Hyper-V or HCS) as an [external VM driver](https://lima-vm.io/docs/dev/drivers/).\n - Tertiary Goals (if time permits): Upgrade the existing WSL2 driver to drop image restrictions and allow users to run multiple instances, as well as exploring a simple graphical interface (`limagui.exe`) to launch virtual machines.\n\n- Recommended Skills: Go, QEMU, Hyper-V, Windows Developer Environment, Systems programming\n\n- Mentor(s):\n - Akihiro Suda (@AkihiroSuda, suda.kyoto@gmail.com)\n - Ansuman Sahoo (@unsuman, anshumansahoo500@gmail.com)\n\n- Upstream Issues: https://github.com/lima-vm/lima/issues/4907\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/f8bb0ffd-0c84-4cb9-8b66-ea63be76b6e2\n\n### Microcks\n\n#### Microcks-CLI v2 - IDE (Vs code) Integration and Local Dev Loop Enhancement\n\nCNCF - Microcks: CLI v2 - VS Code Integration and Local Dev Loop Enhancement (2026 Term 2)\n\n- Description: The Microcks CLI (microcks-cli, written in Go) is a key part of Microcks' CI/CD story - it lets developers trigger contract tests and import artifacts from the command line and in GitHub Actions. This project goes into the developer experience layer. Today, developers must navigate to the Microcks web UI in a browser to see test results, check mock status, and diagnose import errors. There is no IDE integration, no offline validation mode, and no way to get mock results inline with the code being tested. This project builds three focused improvements that bring Microcks into the editor and the local dev loop: a VS Code extension, a local dry-run mode powered by Testcontainers, and an updated GitHub Actions output format that annotates PRs with per-operation pass/fail results.\n- Expected Outcome:\n - A VS Code extension (microcks-vscode) published to the VS Code Marketplace that connects to a running Microcks instance and shows: loaded services, mock operation status, recent test run results, and importer job logs - all inline in the editor sidebar (Like postman, thunder client)\n - A microcks test --dry-run flag in the CLI that uses Testcontainers (the Microcks uber image) to spin up an ephemeral local Microcks instance, import the specified artifact, run the contract test, report results, and tear down - with no external Microcks server required\n - A demo video and documentation page on microcks.io showing the full local-to-CI workflow\n- Recommended Skills:\n - GO\n - VS Code Extension API (TypeScript)\n - Testcontainers\n - basic understanding of CLI UX and Docker\n- Mentor(s):\n - Laurent Broudoux (@lbroudoux, laurent.broudoux@gmail.com)\n - Yacine Kheddache (@yada, yacine@microcks.io)\n - Harshvardhan Parmar (@Harsh4902, harshparmar4902@gmail.com)\n- Upstream Issue: https://github.com/microcks/microcks-cli/issues/255\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/7e8b57e3-0f43-4298-b079-ba9d671b68d8\n\n### OpenEverest\n\n#### Plugin Developer Playground: Interactive UI Schema Editor with Live Preview\n\nCNCF - OpenEverest: Plugin Developer Playground: Interactive UI Schema Editor (2026 Term 2)\n\n- Description: OpenEverest is an open-source cloud-native database platform that helps developers deploy and manage PostgreSQL, MySQL, MongoDB, and other databases on Kubernetes. In V2 it uses a plugin architecture where database providers define their UI through declarative YAML schemas (UISchema in Provider CRD). Currently, plugin developers have no integrated tool for developing and testing these schemas — the only way to see the rendered result is to deploy a full Provider CRD into a running Kubernetes cluster, making the development cycle slow and error-prone. This project aims to build a Plugin Developer Playground — a page inside OpenEverest where plugin developers can write UISchema YAML, see the rendered form in real time, validate the schema structure, inspect the post-processed API payload, and save/share schemas, all without deploying to a cluster. The mentee must solve the CSP compatibility problem by either choosing a CSP-compliant code editor or proposing an isolation architecture (e.g., sandboxed iframe) that keeps the main application's strict security posture intact.\n\n- Expected Outcome:\n - Split-pane YAML editor with syntax highlighting and live form preview using the existing `UIGenerator` component\n - Real-time schema validation: YAML parsing errors and structural validation against the `TopologyUISchemas` type, with inline error markers in the editor\n - Live form rendering with stepper navigation through schema sections and topology switching\n - Dynamic field support: existing API provider fields load real data from the running OpenEverest instance; new/unknown provider types can be mocked\n - Output panel displaying the JSON payload after form data post-processing\n - CSP-compliant solution\n - Unit tests for core logic (schema validation, persistence, mock data injection) and component tests for key panels\n - Plugin developer guide for using the playground and the UISchema format\n\n- Recommended Skills: React, TypeScript, MUI, YAML, Content Security Policy, REST/gRPC APIs, familiarity with Kubernetes CRDs helpful but not required\n\n- Mentor(s):\n - Iaroslavna Soloveva (@solovevayaroslavna, iaroslavna.soloveva@solanica.io)\n - Sergey Pronin (@spron-in, sp@solanica.io)\n\n- Upstream Issue: https://github.com/openeverest/openeverest/issues/2059\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/713b073e-adb4-4d46-95b5-474b8e4c64d9\n\n#### Transform everestctl into a Powerful Database Management CLI\n\nCNCF - OpenEverest: Transform everestctl into a Powerful Database Management CLI (2026 Term 2)\n\n- Description: OpenEverest is an open-source cloud-native database platform that helps developers deploy and manage PostgreSQL, MySQL, MongoDB, and other databases on Kubernetes. Currently, `everestctl` serves primarily as an installation tool for deploying and deleting OpenEverest itself. However, users increasingly need a powerful command-line interface to manage their databases, clusters, and integrations directly from the terminal. This project aims to transform `everestctl` from a basic deployment tool into a comprehensive CLI for managing OpenEverest resources. The mentee will design and implement a modern, user-friendly CLI experience that allows users to provision databases, manage Kubernetes clusters, interact with OpenEverest plugins, and automate database operations — all without leaving their terminal. The project will involve working with Go, Kubernetes APIs, OpenEverest's plugin architecture, and modern CLI frameworks like Cobra.\n\n- Expected Outcome:\n - Core database management commands: `everestctl db list`, `create`, `delete`, `get`, `logs` for PostgreSQL, MySQL, and MongoDB\n - Cluster management: `everestctl cluster list`, `register`, `status` for managing Kubernetes clusters\n - Plugin integration: `everestctl plugin list`, `install`, `configure` for OpenEverest plugins\n - Shell completion scripts (bash, zsh, fish)\n - Unit and integration tests with >80% coverage\n - Comprehensive documentation with usage examples\n\n- Recommended Skills: Go, Kubernetes (CRDs, operators, client-go), Cobra CLI framework, REST/gRPC APIs, database fundamentals (PostgreSQL/MySQL/MongoDB), Git/GitHub workflow\n\n- Mentor(s):\n - Sergey Pronin (@spron-in, sp@solanica.io)\n - Diogo Recharte (@recharte, diogo.recharte@solanica.io)\n\n- Upstream Issue: https://github.com/openeverest/openeverest/issues/1818\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/42dff370-4958-4ec4-959c-4aaf6740698c\n\n### OpenKruise\n\n#### Build Document Agent for OpenKruise Website\n\nCNCF - OpenKruise: Build Document Agent for OpenKruise Website (2026 Term 2)\n\n- Description: The OpenKruise ecosystem comprises multiple rapidly evolving projects, each with its own documentation, blogs, and resources scattered across repositories. Maintaining up-to-date, coherent documentation is challenging. This project aims to build an intelligent document agent for the OpenKruise website that automates the collection, synchronization, and quality evaluation of documentation, blog posts, and other technical resources. The agent will leverage modern context engineering techniques (skills, MCP, RAG, AGENTS.md) to ensure content freshness, consistency, and discoverability across the entire OpenKruise project portfolio.\n\n- Expected Outcome:\n - Agentic harness infrastructure for the OpenKruise website, including AGENTS.md configuration and specialized tools for documentation management\n - Automated GitHub Actions workflows to regularly collect, update, and evaluate documentation, blogs, and resources from all OpenKruise projects and Internet\n - Refreshed and standardized documentation structure with improved navigation and cross-referencing\n - Updated blog archive with consistent formatting and metadata enrichment\n\n- Recommended Skills:\n - Go programming\n - Kubernetes fundamentals (CRDs, controllers, RBAC)\n - Context Engineering techniques (skills, MCP, RAG, AGENTS.md)\n - GitHub Actions workflow development and shell scripting\n - Technical writing and documentation best practices\n\n- Mentor(s):\n - Zhang Zhen (@furykerry, furykerry@gmail.com)\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n\n- Upstream Issue: https://github.com/openkruise/openkruise.io/issues/316\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c2c4ac27-70f0-41da-8969-7b22e3f21c68\n\n#### Dynamic Volume Mounting for JuiceFS and Ceph in OpenKruise Agents\n\nCNCF - OpenKruise: Dynamic Volume Mounting for JuiceFS and Ceph in Agents (2026 Term 2)\n\n- Description: Dynamic volume mounting enables data persistence and sharing for pooled sandbox pods without relying on CSI plugins. This capability is essential for Agent workloads such as OpenClaw and Hermes, which need to save workspace data and share skills across sandboxes. Currently, OpenKruise Agents lacks support for open-source storage solutions like JuiceFS and Ceph, limiting adoption in on-premises environments. This project aims to integrate these storage backends by implementing CSI-plugin sidecars compatible with the Agent runtime and modifying the sandbox controller to support generic CSI volume mounting.\n\n- Expected Outcome:\n - CSI-plugin sidecars for JuiceFS and Ceph that integrate seamlessly with the Agent runtime in OpenKruise Agents\n - Sandbox controller enhancements to enable mounting of generic CSI volumes\n - E2E tests covering core SandboxClaim flows involving JuiceFS and Ceph storage\n - Comprehensive user-facing documentation published on the OpenKruise website and repository\n\n- Recommended Skills:\n - Go programming\n - Kubernetes (CRDs, controllers, RBAC)\n - Familiarity with CSI plugins (particularly JuiceFS and Ceph)\n - E2E testing frameworks (Ginkgo)\n\n- Mentor(s):\n - Kai Shi (@BH4AWS, bh4aws@gmail.com)\n - Zhang Zhen (@furykerry, furykerry@gmail.com)\n\n- Upstream Issue: https://github.com/openkruise/agents/issues/314\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/76a279ba-ffb9-4e4e-baa9-e36a7fd9852a\n\n#### Lightweight and Continuous Load Testing for OpenKruise Agents Using Kwok\n\nCNCF - OpenKruise: Lightweight and Continuous Load Testing for Agents Using Kwok (2026 Term 2)\n\n- Description: Rapid, large-scale sandbox provisioning is critical for agentic workloads. OpenKruise Agents has optimized this through techniques like pooling and efficient sandbox discovery. To prevent performance regressions, continuous testing at scale is essential. This project will build a lightweight, resource-efficient load testing framework using Kwok to evaluate OpenKruise Agents' performance at scale (e.g., 100,000 sandboxes). Additionally, it will establish an automated workflow to regularly execute load tests and report performance metrics, ensuring consistent validation of provisioning capabilities.\n\n- Expected Outcome:\n - A scalable load testing framework capable of evaluating OpenKruise Agents' performance with up to 100,000 sandboxes\n - GitHub Actions workflows and scripts to automate regular load testing and generate performance reports\n - Sandbox controller optimizations to facilitate lightweight load testing scenarios\n - Performance baseline documentation and regression detection mechanisms\n\n- Recommended Skills:\n - Go programming\n - Kubernetes (CRDs, controllers, RBAC)\n - Familiarity with Kwok for cluster simulation\n - GitHub Actions workflow development and shell scripting\n\n- Mentor(s):\n - Zhong Tianyun (@AiRanthem, airanthem666@gmail.com)\n - Zhao Mingshan (@zmberg, berg.zms@gmail.com)\n\n- Upstream Issue: https://github.com/openkruise/agents/issues/314\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/fe38c553-a066-44b0-8192-f5a5bee5074b\n\n### OpenTelemetry\n\n#### Expanding Go Compile-Time Instrumentation Support and Improving otelc Tooling\n\nCNCF - OpenTelemetry: Expanding Go Compile-Time Instrumentation and otelc Tooling (2026 Term 2)\n\n- Description: The [OpenTelemetry Go Compile Instrumentation](https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation) project provides `otelc`, a compile-time auto-instrumentation tool for Go applications. It injects OpenTelemetry instrumentation during the Go build process without requiring manual source-code changes in the target application. As the project moves toward its v1.0 release and continues feature-parity work with mature compile-time instrumentation efforts such as [Orchestrion](https://github.com/DataDog/orchestrion) and [Loongsuite](https://github.com/alibaba/loongsuite-go-agent), the next phase is to broaden real-world library coverage while hardening the tooling and contributor workflow needed to maintain those integrations over time. This mentorship focuses on adding several mentor-approved integrations from the project roadmap and backlog, such as messaging, database/cache, logging, Kubernetes client, or GenAI SDK libraries, while improving `otelc` whenever the integration work exposes gaps in rule authoring, hook implementation, testing, or debugging. The mentee will also document the science behind compile-time instrumentation: how Go symbols and versions are matched, how hooks are injected, how OpenTelemetry semantic conventions are applied, and how compatibility is verified across library releases.\n- Expected Outcome:\n - Add `otelc` instrumentation support for 3-4 widely used Go libraries selected with mentors from the project roadmap/backlog, depending on complexity and project priorities.\n - For each new integration, implement instrumentation rules and hook code, define supported version ranges, and follow the relevant OpenTelemetry semantic conventions.\n - Add meaningful unit, integration, and/or end-to-end tests that verify the instrumented application builds and emits the expected telemetry.\n - Improve the instrumentation tooling or contributor workflow as needed during the work, for example rule validation, hook scaffolding, latest-library compatibility checks, integration layout, or debugging output.\n - Write documentation, examples, and demos that explain how to use the new integrations and how future contributors can build similar ones.\n- Recommended Skills:\n - Go\n - OpenTelemetry concepts and semantic conventions, or willingness to learn\n - Understanding of Go AST/DST, code transformation, or compiler/build tooling, or willingness to learn\n - Testing and debugging Go applications\n - Familiarity with Git and GitHub workflows\n- Mentor(s):\n - Kemal Akkoyun (@kakkoyun, kakkoyun@gmail.com)\n - Dario Castañé (@darccio, d@rio.hn)\n- Acknowledgement: Initial project framing was drafted with help from Azhar Momin (@amazingakai).\n- Upstream Issue: https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation/issues/446\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/3e530f5c-12f3-4321-836a-39de799a4d15\n\n#### UX Research & Information Architecture: How Users Discover and Use OpenTelemetry Instrumentation Information\n\nCNCF - OpenTelemetry: UX Research & IA for Ecosystem Explorer (2026 Term 2)\n\n- Description: The [Ecosystem Explorer](https://explorer.opentelemetry.io) helps users discover and get detailed documentation around various OpenTelemetry components. As the project expands to more ecosystems (Python, JavaScript, GenAI), information density will increase significantly, requiring patterns and approaches tailored to more than just the initial Java Agent use case. This mentorship involves conducting UX research to understand how users actually want to consume and use this information, covering: how users currently find information about components or instrumentation (LLMs, GitHub, docs, vendor sites, trial and error); what questions they are trying to answer (what telemetry will I get, how do I configure it, what changed between versions); what personas exist (app developers instrumenting code, platform engineers running collectors, SREs debugging production); how similar tools present dense technical information (npm registry, crates.io, Go pkg site, Docker Hub); and how LLMs are being used in this area and what the experience has been with them. The research will inform how we structure information, what features to prioritize, and how to present complex telemetry data in an accessible way.\n- Expected Outcome:\n - User Interviews Report: Summarized findings from 3-5 user interviews covering different user types and key tasks\n - Competitive Analysis Report: Findings from reviewing 2-3 similar tools (e.g., package registries, API documentation sites) on how they present component information\n - Information Architecture Recommendations: Proposed structure for presenting a specific type of component data (e.g., \"instrumentation\" or \"collector components\")\n - Wireframes/mockups (stretch goal): Visual concepts for key user flows\n- Recommended Skills: UX research (user interviews, synthesis), information architecture, competitive/comparative analysis, technical writing, wireframing or prototyping tools (helpful), familiarity with developer tools or documentation sites\n- Mentor(s):\n - Jay DeLuca (@jaydeluca, jay.deluca@grafana.com)\n - Andrej Kiripolsky (@AndrejKiri, andrej.kiripolsky@grafana.com)\n - Amy Super (@amy-super, amy.super@grafana.com)\n- Upstream Issue: https://github.com/open-telemetry/opentelemetry-ecosystem-explorer/issues/309\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9e72750b-a515-4cef-86c8-0ffcdcd39298\n\n### PipeCD\n\n#### Plugin Development Book, Docs DX, and Adoption Growth\n\nCNCF - PipeCD: Plugin Development Book, Docs DX, and Adoption Growth (2026 Term 2)\n\n- Description: PipeCD v1 introduced a plugin-based architecture enabling deployments on any platform. While the technical capabilities have evolved significantly, resources for building plugins are currently only available in Japanese. This project focuses on translating and expanding the existing [PipeCD Plugin Development Book](https://zenn.dev/warashi/books/try-and-learn-pipecd-plugin) into English and hosting it within PipeCD's docs, making plugin development accessible to the global contributor community.\nAs part of the project, [examples of pipedv1 will also be created](https://github.com/pipe-cd/pipecd/issues/6266) practical, real-world deployment patterns built around PipeCD's new plugin architecture to help adopters get started.\nAlongside this, the mentee will improve documentation experience for contributors and adopters, produce technical content (blogs, articles and walkthrough videos) tied to the book chapters, and grow community awareness through talks and outreach.\n\n- Expected Outcome: English Plugin Development Book published within PipeCD docs, v1 examples completed, improved contributor and adopter onboarding experience, better docs usability and content discoverability, walkthrough videos (2–4) and blog posts tied to book chapters, and measurable community and social media growth.\n\n- Recommended Skills:\n - Technical writing and documentation\n - Community Management\n - Familiarity with Go and PipeCD's plugin architecture\n - Experience with Git, CI/CD, GitOps, and deployment workflows\n - Content creation (written and video) and social media\n - Public speaking and community engagement\n\n- Mentor(s):\n - Eeshaan Sawant (@eeshaanSA, eeshaans1@gmail.com)\n - Khanh Tran (@khanhtc1202, khanhtc1202@gmail.com)\n\n- Upstream Issue(s):\n - [pipe-cd/pipecd#6679](https://github.com/pipe-cd/pipecd/issues/6679)\n - [pipe-cd/pipecd#6266](https://github.com/pipe-cd/pipecd/issues/6266)\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/c6a906e7-e912-4443-a66d-a496cd0a74ea\n\n### urunc\n\n#### Extensive evaluation of urunc's sandboxing execution model\n\nCNCF - urunc: Extensive evaluation of urunc's sandboxing execution model (2026 Term 2)\n\n- Description:\n\nAccording to urunc's execution model, the application executes inside a\nVM-based or software-based sandbox. While this model strengthens isolation\nboundaries, it can introduce performance overhead and additional resource\nconsumption compared to standard containers. Over the past years, evaluations\nof urunc have focused primarily on spawn time and container density and less\non other aspects, such as CPU and memory usage, storage overhead I/O\nperformance and network latency.\n\nAs a result, it is necessary to conduct a thorough performance evaluation of\nurunc across multiple metrics. The evaluation should span across\nmicrobenchmarks, macrobenchmarks, and representative real-world workloads.\nApart from the evaluation itself, it is also important to create a reproducible\nbenchmarking suite, with all scripts, tools and documentation, so that anyone\ncan extend and reproduce the experiments across different environments and\nversions.\n\n- Expected Outcome:\n - A comprehensive evaluation report covering startup latency, CPU and memory\n consumption, storage overhead, I/O throughput, and network performance\n across multiple sandboxes (monitor / guest combinations).\n - A reproducible evaluation suite, including all scripts, tools,\n configurations and documentation required to repeat and extend the\n benchmarks.\n - A blogpost summarizing the methodology and the findings of the evaluation.\n\n- Recommended Skills:\n - Good understanding of benchmarking methodologies and tools (e.g. fio, perf)\n - Experience with scripting (e.g. Bash, Python) for automation of benchmarks.\n - Basic understanding of virtualization and container runtimes concepts.\n - Familiarity with Kubernetes.\n\n- Mentor(s):\n - Charalampos Mainas (@cmainas, cmainas@nubificus.co.uk)\n - Anastassios Nanos (@ananos, ananos@nubificus.co.uk)\n - Anastasia Mallikopoulou (@amallikopoulou, amallik@nubificus.co.uk)\n\n- Upstream Issue: https://github.com/urunc-dev/urunc/issues/574\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/b4c74c69-7df6-45da-8727-2bca27ed1e8e\n\n#### Improve lifecycle management of sandbox monitors\n\nCNCF - urunc: Improve lifecycle management of sandbox monitors (2026 Term 2)\n\n- Description:\n\nCurrently, urunc launches sandbox monitors, such as Firecracker and QEMU\nthrough command-line invocations. This approach offers limited control over the\nsandbox lifecycle once the process is started. On the other hand, most\nmonitors expose remote management interfaces, typically through a socket-based\nAPI.\n\nThese interfaces provide access to the same operations currently performed via\nCLI, but also enable further control over the sandbox lifecycle. In particular,\nthey allow more fine-grained lifecycle management of the sandbox, including\nquerying and monitoring its state, performing device hotplug and unplug\noperations and interacting with the guest.\n\nThis project aims to extend urunc's sandbox integration layer to support remote\nmanagement interfaces and to explore each monitor's capabilities in order to\nextend the functionalities of urunc sandboxed containers.\n\n- Expected Outcome:\n - A design document describing the updated architecture and workflow for\n spawning and managing sandbox monitors in urunc.\n - Implementation of the necessary changes in urunc to manage sandbox monitors\n through their respective APIs.\n\n- Recommended Skills:\n - Basic understanding of container runtimes and OCI concepts.\n - Good understanding of Linux systems programming (IPC, process management, etc.)\n - Experience with Go.\n - Familiarity with virtual machine monitors.\n\n- Mentor(s):\n - Charalampos Mainas (@cmainas, cmainas@nubificus.co.uk)\n - Anastassios Nanos (@ananos, ananos@nubificus.co.uk)\n\n- Upstream Issue: https://github.com/urunc-dev/urunc/issues/112\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/02b6f81b-a96d-4fc5-894d-3da12a3564bf\n\n#### Improving DNS and localhost based networking compatibility for urunc across CNIs\n\nCNCF - urunc: DNS and localhost networking compatibility across CNIs (2026 Term 2)\n\n- Description:\n\nIn a standard container setup, the container shares the network namespace with\nits host environment, meaning localhost inside the container refers to the same\nloopback interface as the host's network namespace. Many CNI plugins and\ncontainer networking services rely on this assumption. For instance, Docker\nsets up an internal DNS server listening on localhost within each container's\nnetwork namespace and configures `/etc/resolv.conf` accordingly. Similarly,\nservice meshes (e.g., Istio, Linkerd) inject sidecar proxies that listen on\nlocalhost, and certain CNI plugins expose health checks or metrics endpoints on\nthe loopback interface.\n \n In urunc, however, workloads execute inside a sandboxed environment\nwith its own isolated network stack. As a result,\nlocalhost inside the sandbox does not refer to the host's network namespace\nloopback interface but to the sandbox's own. This breaks any service that\nrelies on localhost-based communication between the container and host-level\ncomponents.\n\nThis project aims to investigate and implement mechanisms to bridge localhost\ncommunication between the host network namespace and the sandbox. The mentee\nwill survey the landscape of CNI plugins and networking services that rely on\nlocalhost, categorize the different communication patterns, and design a\nsolution that restores compatibility while preserving the\nisolation guarantees that urunc provides.\n\n- Expected Outcome:\n - A survey and categorization of CNI plugins and networking services that\n rely on localhost communication, documenting the specific patterns and\n assumptions each makes.\n - A design proposal of one or more mechanisms to bridge localhost traffic\n between the host network namespace and the sandbox.\n - Implementation of the proposed solution in urunc, with DNS resolution as\n the primary use case.\n - Evaluation of the new mechanism.\n\n- Recommended Skills:\n - Good understanding of Linux networking concepts (network namespaces,\n loopback interfaces, DNS resolution).\n - Basic understanding of container networking (CNI plugin model,\n bridge/overlay networks).\n - Experience with low-level networking tools (iptables, tc, eBPF).\n\n- Mentor(s):\n - Charalampos Mainas (@cmainas, cmainas@nubificus.co.uk)\n - Anastassios Nanos (@ananos, ananos@nubificus.co.uk)\n\n- Upstream Issue: https://github.com/urunc-dev/urunc/issues/574\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/d11f903e-4d6f-49af-80d8-8fe0d728bce2\n\n#### Integration of urunc's sandbox execution with Argo\n\nCNCF - urunc: Integration of urunc's sandbox execution with Argo (2026 Term 2)\n\n- Description:\n\nWhile urunc has successfully enabled the use of unikernels and single\napplication kernels within Kubernetes environments, its integration with other\nCNCF projects has been less seamless. A notable example is Argo, a widely\nadopted platform for defining and managing workflows, complex pipelines, and\ndistributed applications on Kubernetes.\n\nIn urunc's execution model, untrusted components of a deployment run inside\nsandboxed environments as unikernels or single-application kernels, while\ntrusted components run as standard containers. Although this separation enables\nfine-grained workload isolation, it introduces friction in deployments like Argo,\nsince it breaks pod-level assumptions (e.g. shared networking, storage).\n\nThis project aims to bridge that gap between Argo deployments and urunc's sandboxed\nexecution model by enabling compatibility at the runtime and workflow\nlevels. The expected outcome is that users can easily choose which parts of\ntheir Argo deployment run in isolated urunc sandboxes.\n\n- Expected Outcome:\n - A document describing the architecture of Argo and the execution model of\n urunc, including a clear breakdown of the main incompatibilities.\n - A working integration with the necessary changes required in urunc and its\n components.\n - A tutorial showing how to deploy and run Argo workflows using urunc,\n including setup, configuration, and example use cases.\n\n- Recommended Skills:\n - Good understanding of Kubernetes.\n - Familiarity with Argo and its architecture.\n - Basic understanding of container runtimes and OCI concepts.\n - Experience with Go.\n\n- Mentor(s):\n - Charalampos Mainas (@cmainas, cmainas@nubificus.co.uk)\n - Panagiotis Mavrikos (@panosmaurikos, pmavrikos@nubificus.co.uk)\n - Anastassios Nanos (@ananos, ananos@nubificus.co.uk)\n\n- Upstream Issue: https://github.com/urunc-dev/urunc/issues/573\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/793f9d3c-179b-4e93-8f7a-2ef17caa1324\n\n### Volcano\n\n#### Scheduler Management, Observability & Log Explorer UI\n\nCNCF - Volcano: Scheduler Management, Observability & Log Explorer UI (2026 Term 2)\n\n- Description: Volcano's scheduler has no presence in the dashboard today. Three critical operator workflows are missing: \n(1) Configuration — the entire scheduling policy (6 actions, 22 plugins, per-plugin toggles and arguments) lives in a raw Kubernetes ConfigMap edited only via `kubectl`, with no validation or UI; \n(2) Observability — Volcano exposes rich Prometheus metrics (scheduling latency, preemption counts, unschedulable job/task counts) that the dashboard never queries, leaving operators dependent on a separate Grafana stack; \n(3) Logs — debugging scheduling issues requires `kubectl logs` against pods in `volcano-system`; the dashboard has no log viewing capability at all. This project adds a `/scheduler` section with three tabs: a Config tab that reads and writes the `volcano-scheduler-configmap` as a structured form, a Metrics tab that proxies and visualizes the scheduler's Prometheus `/metrics` endpoint, and a Logs tab that streams live logs from any Volcano system component (`volcano-scheduler`, `volcano-controller-manager`, `volcano-webhook-manager`, `volcano-agent`) — all backed by new tRPC procedures using the existing `CoreV1Api` client in `packages/trpc/server/utils/k8s.ts`.\n- Expected Outcome:\n - Config tab: draggable action pipeline editor, plugin tier editor with per-plugin `enabled` toggles and typed argument fields, live YAML diff preview, and a Save button that patches the ConfigMap via `CoreV1Api.patchNamespacedConfigMap`.\n - Metrics tab: stat cards for unschedulable jobs/tasks and total preemptions; line chart for e2e and per-plugin scheduling latency; bar chart for per-action latency — all from a new `getMetrics` tRPC procedure querying the scheduler's `/metrics` endpoint.\n - Logs tab: component selector dropdown (`scheduler`, `controller-manager`, `webhook-manager`, `agent`), `tailLines` control, keyword filter/highlight, and real-time log streaming via `CoreV1Api.readNamespacedPodLog` with a Server-Sent Events or polling transport.\n - Updated RBAC in `deployment/volcano-dashboard.yaml` for ConfigMap `get`/`update` and Pod logs in `volcano-system`.\n - Tests and user-facing documentation.\n- Recommended Skills: TypeScript, React, Next.js, tRPC, Zod, Kubernetes API (`@kubernetes/client-node`), Prometheus metrics parsing, YAML (`js-yaml`), Server-Sent Events or streaming APIs\n- Mentor(s):\n - Jesse Stutler (@JesseStutler, jessestutler97@gmail.com)\n - Kuldeep (@de6p, de6p97@gmail.com)\n\n- Upstream Issue: https://github.com/volcano-sh/dashboard/issues/197\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/ec54f49d-258f-49b9-9baf-c2c516fbe186\n\n#### Support Namespace-scoped Queue in Volcano\n\nCNCF - Volcano: Support Namespace-scoped Queue in Volcano (2026 Term 2)\n\n- Description: Volcano's `Queue` is a cluster-scoped resource, which means only cluster admins can create or update it. This is a barrier for multi-tenant scenarios, where tenants usually only own their own namespaces and want to leverage Volcano's queue capabilities (resource sharing, capability/guarantee/deserved, hierarchy, etc.) for their own workloads without requesting changes from a cluster admin. This project adds a namespace-scoped `NamespaceQueue` to Volcano. A `NamespaceQueue` is derived from a cluster-scoped `Queue` and behaves consistently with it, so tenants can create and use queues within their own namespace and associate `PodGroup`/`Job` with a `NamespaceQueue` exactly as they would with a cluster `Queue`. The existing cluster `Queue` semantics and APIs remain unchanged for users who do not opt in.\n\n- Expected Outcome:\n - A namespace-scoped `NamespaceQueue` CRD derived from cluster-scoped `Queue`, with consistent semantics for fields such as `capability`, `guarantee`, `deserved`, and hierarchy.\n - Tenants can create and manage `NamespaceQueue` within their own namespace without cluster-admin permission.\n - `PodGroup`/`Job` can reference a `NamespaceQueue` and be scheduled with the same behavior as referencing a cluster `Queue`.\n - Resource accounting, status, and events for `NamespaceQueue` work end-to-end through Volcano's existing queue management path.\n - Compatibility with the existing cluster `Queue` and the `scheduling.volcano.sh/queue-name` annotation, with a clear migration story for existing users.\n - E2E tests covering core `NamespaceQueue` flows, including negative cases.\n - User-facing documentation on the Volcano website and the repository.\n\n- Recommended Skills:\n - Go\n - Kubernetes (CRDs, controllers, RBAC)\n - Familiarity with Volcano (scheduler, queue, PodGroup/Job)\n - E2E testing (Ginkgo)\n - GitHub workflow and shell scripting\n\n- Mentor(s):\n - Jesse Stutler (@JesseStutler, jessestutler97@gmail.com)\n - Hajnal Máté (@hajnalmt, hajnalmt@gmail.com) \n - João Azevedo (@devzizu, jazevedo960@gmail.com)\n\n- Upstream Issue: https://github.com/volcano-sh/volcano/issues/5251\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/9e582ac4-4e12-4fcc-a1cd-27855d79730a\n\n### WasmEdge\n\n#### Memory alignment in WASM instructions\n\nCNCF - WasmEdge: Memory alignment in WASM instructions (2026 Term 2)\n\n- Description: Although WasmEdge checked the memory alignment when accessing the memory instances in WASI functions, the same situation occurs for instructions which would access the addresses on memory instances. For the pointer types, the offset for load/store from/to memory instances should be aligned as 4 in WASM32. In this mentorship, the mentee should collect all the possible situations for alignment checking in WASM instructions, and resolve the related issues.\n- Expected Outcome:\n - Fix the memory alignment checking when accessing the memory instances.\n - Add some WASM binary tests for verifying the implementation.\n - Fix the issues: WasmEdge2694, WasmEdge2733, WasmEdge2881\n- Recommended Skills:\n - C++\n - WebAssembly\n - Git workflows\n- Mentor(s):\n - YiYing He (@q82419 , yiying@secondstate.io )\n - Hung-Ying, Tai (@hydai , hydai@secondstate.io )\n- Upstream Issue: https://github.com/WasmEdge/WasmEdge/issues/4820\n- LFX URL: https://mentorship.lfx.linuxfoundation.org/project/64753a7f-5823-4909-86ac-9d36bd6b7323\n" }, { "path": "programs/lfx-mentorship/2026/02-Jun-Aug/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n- Upstream Issue:\n\n```\n\n---\n\n## Proposed Project ideas\n" }, { "path": "programs/lfx-mentorship/2026/03-Sep-Nov/README.md", "content": "# Term 03 - 2026 September - November\n\nStatus: Planning\n\nMentorship duration - three months (full-time schedule)\n\n### Timeline\n\n| Activity | Dates (2026) |\n|--------------|------------------|\n| Project Proposals Open | Wed, Jul 1 – Tue, Jul 28, 18:00 UTC |\n| Mentee Candidate Info Sessions | Tue, Jul 21, Times TBD (will be multiple timezone options) |\n| Mentee Applications Open | Mon, Aug 3 – Tue, Aug 18, 18:00 UTC |\n| Application Review Period (2 weeks) | Wed, Aug 19 – Tue, Sep 1, 18:00 UTC |\n| Selection Notifications | Wed, Sep 2 – Fri, Sep 4 *(notifications may take a few days to reach all mentees)* |\n| Mentorship Program Begins | Mon, Sep 7 |\n| Mentorship Kick Off Call | Tue, Sep 8, Times TBD (will be multiple timezone options) |\n| Midterm Mentee Evaluations | Tue, Oct 20, 18:00 UTC |\n| First Stipend Payments | Wed, Oct 21 |\n| Final Mentee Evaluations | Tue, Nov 24, 18:00 UTC |\n| Second Stipend Payments | Wed, Nov 25 |\n| Last Day of Term | Fri, Nov 27 |\n\n\n### Project instructions\n\nProject maintainers and potential mentors are welcome to propose their mentoring project ideas via submitting a PR to GitHub here https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2026/03-Sep-Nov/project_ideas.md, by July 28, 2026. Please limit proposals to 4-5 projects per CNCF project.\n\n### Application instructions\n\nMentee application instructions can be found on the [Program Guidelines](https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#program-guidelines) page.\n\n---\n\n\n" }, { "path": "programs/lfx-mentorship/2026/03-Sep-Nov/project_ideas.md", "content": "## Template\n\n```\n### CNCF Project Name\n\n#### Mentorship project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Mentor(s):\n - Mentor Name (@mentor_github, mentor@email.addy) - please use the same email address as you use on the LFX Mentorship Platform at https://mentorship.lfx.linuxfoundation.org\n- Upstream Issue:\n\n```\n\n---\n\n\n## Proposed Project ideas\n" }, { "path": "programs/lfx-mentorship/README.md", "content": "# LFX Mentorship by The Linux Foundation\n\n[LFX Mentorship](https://lfx.linuxfoundation.org/tools/mentorship/) (previously known as Community Bridge) is a platform developed by the Linux Foundation, which accelerates the adoption, innovation, and sustainability of open source software.\n\nLFX Mentorship is actively used by the Cloud Native Computing Foundation as a mentorship platform across the CNCF projects.\n\n- [LFX Mentorship](#lfx-mentorship)\n - [Program Cycles and Archive data](#program-cycles-and-archive-data)\n - [Current cycle](#current-cycle)\n - [Program Maintainers](#program-maintainers)\n - [Communication](#communication)\n - [Program Guidelines](#program-guidelines)\n - [How to apply?](#how-to-apply)\n - [Projects](#projects)\n - [Mentors](#mentors)\n - [Mentees](#mentees)\n - [Eligibility](#eligibility)\n - [Mentee selection process](#mentee-selection-process)\n - [Stipends](#stipends)\n\n## Program Cycles and Archive data\n\n| Year | Term | Status | Announcement | Details |\n|------|------------------|-----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------|\n| 2025 | Term 2: Jun-Aug | In progress | | [2025 Term 2: Jun-Aug](2025/02-Jun-Aug/README.md) |\n| 2025 | Term 1: Mar-May | Completed | | [2025 Term 1: Mar-May](2025/01-Mar-May/README.md) |\n| 2024 | Term 3: Sep-Nov | Completed | | [2024 Term 3: Sep-Nov](2024/03-Sep-Nov/README.md) |\n| 2024 | Term 2: Jun-Aug | Completed | [Congratulations to 45 CNCF Term 2 2024 LFX Program mentees!](https://www.cncf.io/blog/2024/09/27/congratulations-to-45-cncf-term-1-2024-lfx-program-mentees/) | [2024 Term 2: Jun-Aug](2024/02-Jun-Aug/README.md) |\n| 2024 | Term 1: Mar-May | Completed | [CNCF celebrates successful mentees from LFX Program Term 1 2024!](https://www.cncf.io/blog/2024/06/19/cncf-celebrates-successful-mentees-from-lfx-program-term-1-2024/) | [2024 Term 1: Mar-May](2024/01-Mar-May/README.md) |\n| 2023 | Term 3: Sep-Nov | Completed | [LFX Program’s CNCF mentees have successfully finished Term 3!](https://www.cncf.io/blog/2023/12/14/lfx-programs-cncf-mentees-have-successfully-finished-term-3/) | [2023 Term 3: Sep-Nov](2023/03-Sep-Nov/README.md) |\n| | Term 2: Jun-Aug | Completed | [36 CNCF term 2 LFX mentees have successfully completed the program!](https://www.cncf.io/blog/2023/09/12/36-cncf-term-2-lfx-mentees-have-successfully-completed-the-program/) | [2023 Term 2: Jun-Aug](2023/02-Jun-Aug/README.md) |\n| | Term 1: Mar-May | Completed | [Congratulations to 57 CNCF Term 1 LFX Program Mentees!](https://www.cncf.io/blog/2023/06/09/congratulations-to-57-cncf-term-1-lfx-program-mentees/) | [2023 Term 1: Mar-May](2023/01-Mar-May/README.md) |\n| 2022 | Term 3: Sept-Nov | Completed | [Congratulations to 24 CNCF fall term LFX Program mentees! ](https://www.cncf.io/blog/2022/12/08/congratulations-to-24-cncf-fall-term-lfx-program-mentees/) | [2022 Term 3: Sept-Nov](2022/03-Sept-Nov/README.md) |\n| | Summer | Completed | [Congratulations to the 27 Summer LFX Program CNCF interns!](https://www.cncf.io/blog/2022/10/03/congratulations-to-the-27-summer-lfx-program-cncf-interns/) | [Summer'2022](2022/02-Summer/README.md) |\n| | Spring | Completed | [CNCF congratulates 36 successful interns with Spring Term LFX Program!](https://www.cncf.io/blog/2022/07/07/cncf-congratulates-36-successful-interns-with-spring-term-lfx-program/) | [Spring'2022](2022/01-Spring/README.md) |\n| 2021 | Fall | Completed | [CNCF LFX projects are open for Fall 2021 – Apply by August 22nd!](https://www.cncf.io/blog/2021/08/16/cncf-lfx-projects-are-open-for-fall-2021-apply-by-august-22nd) | [Fall'2021](2021/03-Fall/README.md) |\n| | Summer | Completed | [CNCF LFX Projects are Open for Summer 2021 – Apply by May 17th!](https://www.cncf.io/blog/2021/05/04/cncf-lfx-projects-are-open-for-summer-2021-apply-by-may-17th) | [Summer'2021](2021/02-Summer/README.md) |\n| | Spring | Completed | [CNCF LFX Projects are Open for Spring Term 2021! Apply Now for a Mentorship Opportunity!](https://www.cncf.io/blog/2021/02/03/cncf-lfx-projects-are-open-for-spring-term-2021-apply-now-for-a-mentorship-opportunity/) | [Spring'2021](2021/01-Spring/README.md) |\n| 2020 | Q3-Q4 | Completed | [CNCF will participate in CommunityBridge Mentorships for Q3 and Q4 2020](https://www.cncf.io/blog/2020/09/04/cncf-will-participate-in-communitybridge-mentorships-for-q3-and-q4-2020/) | [Q3-Q4'2020](2020/q3-q4/README.md) |\n| | Q2 | Completed | [21 CNCF interns graduate from the Q2 2020 Linux Foundation CommunityBridge Program](https://www.cncf.io/blog/2020/08/13/21-cncf-interns-graduate-from-the-q2-2020-linux-foundation-communitybridge-program/) | [Q2'2020](2020/q2/README.md) |\n| | Q1 | Completed | [Seven CNCF interns graduate from the 2020 Linux Foundation CommunityBridge Program](https://www.cncf.io/blog/2020/04/15/seven-cncf-interns-graduate-from-the-2020-linux-foundation-communitybridge-program/) | [Q1'2020](2020/q1/README.md) |\n| 2019 | Pilot | Completed | [CNCF hosts three student internships for Kubernetes and CoreDNS projects through Linux Foundation’s CommunityBridge](https://www.cncf.io/blog/2019/08/22/cncf-hosts-three-student-internships-for-kubernetes-and-coredns-projects-through-linux-foundations-communitybridge/) | [2019](2019/README.md) |\n\n### Current cycle\n\nThe current cycle is [01-Mar-May 2025](2025/01-Mar-May/README.md).\n\n## Program Maintainers\n\n- Nate W. ([@nate-double-u](https://github.com/nate-double-u))\n\n## Program Guidelines\n\nPlease see the program-wide guidelines on the [LFX Mentorship website](https://docs.linuxfoundation.org/lfx/mentorship).\n\n### How to apply?\n\n#### Projects\n\nProject maintainers and mentors are requested to submit the ideas using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\nCNCF will select the projects that will participate in the LFX mentorship round and they will appear on the LFX Mentorship Platform website after the selection.\n\n#### Mentors\n\nIf you are a mentor and your project will be selected to participate in the LFX Mentorship program, you'll have to apply as a mentor on the LFX Mentorship website. Please see the [LFX Mentorship guidelines](https://docs.linuxfoundation.org/lfx/mentorship/mentor-guide) for more details.\n\n#### Mentees\n\nIf you are a mentee and your desired project will be selected to participate in the LFX Mentorship program, you'll have to apply as a mentee on the LFX Mentorship website. Please see the [LFX Mentorship guidelines](https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide) for more details.\n\nInformation on the application process is covered at the [LFX Mentorship documentation website](https://docs.linuxfoundation.org/lfx/mentorship/mentees/apply-to-a-project). Please note that once you've applied, your application moves to the pending state until a mentor will pick it up. There is no need to reapply (you'll see an error if you'll try to reapply).\n\nThe stipend guides and amounts are listed [here](https://docs.linuxfoundation.org/lfx/mentorship/mentee-stipends).\n\n##### Eligibility\n\n**Please see the full eligibility criteria in the [LFX Mentorship documentation](https://docs.linuxfoundation.org/lfx/mentorship/mentees)**.\n\n### Mentee selection process\n\nMentors are responsible for selecting and matching mentees to their projects.\n\n* Mentees must be chosen based on who is the best fit for the project. In addition to technical skills and qualifications, the person's ability to work well with others is a valid factor. Only if two candidates are equally qualified may a mentor use diversity-related considerations as a tie-breaker.\n\n* A mentor must not participate in selection of the mentee for a particular mentorship if there is a conflict of interest. A conflict of interest exists if a family member, member of the same household, close personal friend, or romantic partner has applied for the mentorship, or if there is any other reason why the mentor could not be deemed impartial in the selection process.\n\nMentee candidates are required to provide cover letters (Statement of Purpose) while applying, so mentors may review them. In addition, mentors may also interview the candidates to understand their level of qualification before making the final decision.\n\nIf you are a mentee, please note that you'll be asked to provide the Statement of Purpose letter after the mentor's selection. Please be patient.\n\n### Stipends\n\nThe LFX Mentorship stipend policy is described here - .\n\n## Communication\n\nIf you have any questions or issues with the LFX Mentorship platform/website itself, payments, etc., contact the [LFX Mentorship support team](https://support.linuxfoundation.org/) directly.\n\nFor CNCF-specific questions:\n\n- Use the [CNCF mentoring discussions board](https://github.com/cncf/mentoring/discussions)\n- Write to mentoring@cncf.io **only for questions that _can not_ be asked publicly**\n\n> [!IMPORTANT]\n> **_Do not_ directly message program maintainers or project mentors**.\n\n" }, { "path": "programs/outreachy/README.md", "content": "# Outreachy\n\nCNCF supports participating in the [Outreachy](https://www.outreachy.org/) program for the\nhosted projects. For example, Kubernetes has been participating in the\nOutreachy program for a few years in a row -\n.\n\n## Mentees\n\n| Year | Mentee | Project |\n| --------------- | ----------------------------------------------------- | ------------- |\n| 2017 | Ellen Korbes | Kubernetes |\n| 2017 | Yolande Amante | Kubernetes |\n| Dec'17 - Mar'18 | [Kara de la Marck](https://www.twitter.com/KaraMarck) | Jaeger |\n| 2018 | Eduar Tua | Kubernetes |\n| May'18 - Aug'18 | [Prakriti Bansal](https://www.twitter.com/PikkiBot) | Jaeger |\n| Dec'18 - Mar'19 | [Gaby Soria](https://www.twitter.com/gabrielasoriag) | Jaeger |\n| 2019 | Vishakha Nihore | Kubernetes |\n| Dec'20 - Mar'21 | Ashmita Bohara | Jaeger |\n| 2021 | Harshita Srinivas | OpenTelemetry |\n" }, { "path": "programs/summerofcode/2017.md", "content": "# 2017\n\nCNCF particpated as a mentoring organisation for [Google Summer of Code 2017](https://summerofcode.withgoogle.com/archive/2017/organizations/6018829461225472/).\n\nThe list of official project ideas for GSoC 2017 are listed below.\n\n## Project Ideas\n\n### Kubernetes\n\n#### Improve ThirdPartyResources\n\n* Description: ThirdPartyResources were added some time ago, but the implementation has languished with multiple outstanding capabilities that are missing. They did not complete the list of requirements for graduating to beta (kubernetes/kubernetes#22768).\n* Recommended Skills: golang\n* Mentor(s): Stefan Schimanski (@sttts)\n* Issue: https://github.com/kubernetes/features/issues/95\n\n#### Code metrics infrastructure, measure, report in CI\n\n* Description: The Kubernetes code base grows every day. Reviews mostly concentrate on functionality and architecture, less on code hygiene like test coverage, cyclomatic complexity, linting etc. The goal of this project is to find better ways to support developers and reviewers by making these metrics more visible on new pull-requests. Ideas are to extend our github bots to post a green-yellow-red traffic light for certain measurements or to add new merge gates e.g. if test coverage goes down without being acknowledged by reviewers. \n* Recommended Skills: golang\n* Mentor(s): Stefan Schimanski (@sttts)\n* Issue:\n\n#### Prototype ssh based replacement for kubctl-exec\n\n* Description: Kubectl exec is implemented with a proprietary protocol. The communication is not end-to-end encrypted. This project is about prototyping the integration of an on-demand SSH server in the kubelet and tunneling of the connection through the apiserver.\n* Recommended Skills: golang\n* Mentor(s): Stefan Schimanski (@sttts)\n* Issue: https://github.com/kubernetes/kubernetes/issues/42950\n\n#### Bazel rules for generated code\n\n* Description: Bazel is Google's internal build tool with more than a decade of history internally, recently OpenSource'ed. It is well suited for big code bases and complex build dependency graphs. Today Kubernetes uses a large GNU make based build system mixed with a lot of bash scripting, which is slow, error prone and more and more unmaintainable. Early work has been done already to compile Kubernetes and to run tests with Bazel. A big next step is to integrate the various code generators that are heavily used in Kubernetes. The goal is better maintainability and much faster turn around cycles for developers and our CI infrastructure.\n* Recommended Skills: golang, interest in build systems, able to read existing Makefiles and bash code\n* Mentor(s): Stefan Schimanski (@sttts)\n* Issue:\n\n#### Create and implement a Data Model to standardize Kubernetes logs\n\n* Description: To perform operations in large kubernetes clusters, where microservices-based applications can be composed of a considerable number of pods, well-structured logs are required. A Data Model that can help find the right field in the right log and tag it (i.e. app name) is required. This way the logs can be easily processed, correlated and queried so the troubleshooting becomes much easier and the time to find root causes for problems gets dramatically reduced. An example implementation can be done with Fluentd ElasticSearch and Kibana\n* Recommended Skills: knowledge on Kubernetes internals, basic Ruby coding skills, knowledge on JSON / YAML\n* Mentor(s): Peter Portante, Tushar Katarki, Miguel Pérez Colino (backup)\n* Issue:\n\n#### Develop a set of Jupyter Notebooks for the Python Client\n\n* Description: The Kubernetes python client is currently in incubation. Jupyter is the new interactive python interface, it has a web accessible UI and several key features to discovery Python modules as well as interact directly with a shell. In this project, the student will learn the Kubernetes API by using the Python client and develop a set of Notebooks that highlight the Kubernetes primitives. These will all be interactive notebooks that can be run as a Kubernetes applications.\n* Recommended Skills: Python\n* Mentor(s): Sebastien Goasguen\n* Issue: [https://github.com/kubernetes-incubator/client-python/issues/127](https://github.com/kubernetes-incubator/client-python/issues/127)\n\n#### Improve kompose support for docker bundles\n\n* Description: Kompose is a Kubernetes incubator project that translates docker-compose application description into a set of Kubernetes manifests. As docker-compose evolves and new versions are avaialable, kompose needs to keep up. In this project, the student will learn the docker bundle format, evaluate its current use and development state, then improve the kompose bundle support. The student will also participate in the support of docker-compose v3 format.\n* Recommended Skills: Golang\n* Mentor(s): Sebastien Goasguen\n* Issue: [https://github.com/kubernetes-incubator/kompose/issues/390](https://github.com/kubernetes-incubator/kompose/issues/390)\n\n#### Develop advanced Charts for Helm\n\n* Description: Helm is the package manager for Kubernetes. Application packaged by Helm are called Charts, there are currently over 50 charts in the repository. This project aims at learning Helm and Charts and contributing to Charts development. The student will focus on advanced applications pipelines that use multiple charts as dependencies.\n* Recommended Skills: Golang, Kubernetes, Bash\n* Mentor(s): Sebastien Goasguen\n* Issue: [https://github.com/kubernetes/charts/issues/694](https://github.com/kubernetes/charts/issues/694)\n\n#### TODO\n\n### Fluentd\n\nFluentd is an open source data collector for unified logging layer: http://www.fluentd.org/\n\n#### Fluentd Monitoring Dashboard\n* Description: [Fluentd](http://fluentd.org) as a log collector and aggregator, runs as a service in background, for hence having graphical built-in monitoring capabilities is a must for all scenarios. This project aims to implement a web based dashboard that reports the Fluentd internals from different stages of the data cycle: collection, parsing, filtering, buffering and outputs.\n* Recommended Skills: Ruby, API, CSS, Bootstrap and Javascript\n* Mentor(s): Eduardo Silva (@edsiper)\n* Issue: https://github.com/fluent/fluentd/issues/1475\n\n#### Fluent Bit: plugins development and extend golang interface\n* Description: [Fluent Bit](http://fluentbit.io) is a log forwarder that can be integrated with Fluentd or work in standalone mode for log handling. This project aims to extend the number of plugins available to perform data collection, filtering and outputs.\n* Recommended Skills: C, TCP, Sockets, Golang and Linux.\n* Mentor(s): Eduardo Silva (@edsiper)\n* Issue: https://github.com/fluent/fluent-bit/issues/194\n\n### Prometheus\n\nPrometheus is an open-source systems monitoring and alerting toolkit: https://prometheus.io/\n\n#### Add option to log slow queries and recording rules\n* Description: Having something like PostgreSQL's log_min_duration_statement would be useful to debug performance problems. It would be great to collect detailed query information, like how many chunks were necessary to compute the result and how many had to be loaded from disk.\n* Recommended Skills: golang\n* Mentor(s): Ben Kochie (@SuperQ)\n* Issue: https://github.com/prometheus/prometheus/issues/1315\n\n#### General purpose rule/alert testing tool\n* Description: Write a wrapper that turns (https://github.com/prometheus/prometheus/blob/master/promql/test.go) into a general-purpose rule/alert testing tool.\n* Recommended Skills: golang\n* Mentor(s): Ben Kochie (@SuperQ)\n* Issue: https://github.com/prometheus/prometheus/issues/1695\n\n### linkerd\n\nlinkerd is a resilient service mesh for cloud native apps: https://linkerd.io/\n\n#### Adopt OpenTracing in linkerd\n* Description: Add opentracing support in linkerd.\n* Recommended Skills: Scala\n* Mentor(s): Oliver Gould (@olix0r), Andrew Seigner (@siggy)\n* Issue: https://github.com/linkerd/linkerd/issues/1079\n\n#### QUIC Netty codec\n* Description: Build a QUIC Netty codec.\n* Recommended Skills: Java, Netty, UNIX Networking\n* Mentor(s): Oliver Gould (@olix0r)\n* Issue: https://github.com/linkerd/linkerd/issues/1078\n\n#### Redis protocol support\n* Description: Add redis protocol support.\n* Recommended Skills: Scala, Finagle, Redis\n* Mentor(s): Oliver Gould (@olix0r), Alex Leong (@adleong)\n* Issue: https://github.com/linkerd/linkerd/issues/1077\n\n#### MySQL protocol support\n* Description: Add mysql protocol support.\n* Recommended Skills: Scala, Finagle, MySQL\n* Mentor(s): Oliver Gould (@olix0r), Alex Leong (@adleong)\n* Issue: https://github.com/linkerd/linkerd/issues/1080\n\n### OpenTracing\n\n[OpenTracing](http://opentracing.io/) is an open standard for distributed tracing. A trace tells the story of a transaction or workflow as it propagates through a (potentially distributed) system. OpenTracing makes it easy for developers to add (or switch) tracing implementations, by offering a vendor-neutral APIs that popular platforms can bind to.\n\nWith v1.0 of OpenTracing complete, we are now in the process of intrumenting major web frameworks, services, and networking/controlflow libraries. See [Instrumenting Frameworks](http://opentracing.io/documentation/pages/instrumentation/instrumenting-frameworks.html) for more information.\n\nIn addition to the following projects, students may choose an equivalent framework, library, or service, provided it is widely used and Open Source.\n\n#### OpenTracing adaptor for AWS X-Ray \n* Description: X-Ray is a distributed tracing service provided by AWS. X-Ray intrumentation does not currently conform to OpenTracing, it provides a similar (but proprietary) API. Make X-Ray vendor-neutral by building an OpenTracing/X-Ray adaptor, so that it can be plugged in to the OpenTracing ecosystem.\n* Recommended Skills: golang\n* Mentor(s): Ben Sigelman (@bensigelman)\n\n#### OpenTracing Instrumentation for Nginx, HAProxy, or other Load Balancers\n* Description: Load Balancers and Gateways provide a variety of important services, and are present in almost every distributed system. Instrumentation at this layer is often the best first step towards tracing an entire system. Add intrumentation to Nginx, HAProxy, or equilvant gateway service via an OpenTracing plugin. See [Envoy](https://lyft.github.io/envoy/docs/intro/arch_overview/tracing.html) as an example.\n* Recommended Skills: C++, nginx \n* Mentor(s): Paul Draper (@pauldraper)\n\n#### Add \"net/rpc\" and \"database/sql\" support for Golang\n* Description: Instrumented wrappers for the io functionality in Golang's stdlib, such as net/rpc and database/sql, is critical. So far, only net/http has been instrumented. \n* Recommended Skills: golang\n* Mentor(s): Paul Draper (@pauldraper)\n* Issue: https://github.com/opentracing-contrib/go-stdlib/issues/8\n\n#### go-restful + OpenTracing\n* Description: Instrument go-restful (https://github.com/emicklei/go-restful), a wildly used Golang REST web services framework, with OpenTracing.\n* Recommended Skills: golang\n* Mentor(s): Wu Sheng (@wu-sheng)\n\n### gRPC\n[gRPC](grpc.io) is fast and efficient open source RPC framework.\n\n#### gRPC C Core:\n\n* Port gRPC to one of the major BSD platforms ([FreeBSD](https://freebsd.org), [NetBSD](https://netbsd.org), and [OpenBSD](https://openbsd.org)) and create packages for them. Add [kqueue](https://www.freebsd.org/cgi/man.cgi?query=kqueue) support in the process.\n* Required skills: C programming language, BSD operating system.\n* Likely Mentors: [Craig Tiller](https://github.com/ctiller),\n [Nicolas Noble](https://github.com/nicolasnoble),\n [Vijay Pai](https://github.com/vjpai).\n\n* Fix gRPC C-core's URI parser. The current parser does not qualify as a standard parser according to [RFC3986]( https://tools.ietf.org/html/rfc3986). Write test suites to verify this and make changes necessary to make the URI parser compliant.\n* Required skills: C programming language, HTTP standard compliance.\n* Likely mentors: [Craig Tiller](https://github.com/ctiller).\n\n* HPACK compression efficiency evaluation - Figure out how to benchmark gRPC's compression efficiency (both in terms of bytes on the wire and cpu cycles). Implement benchmarks. Potentially extend this to other full-stack gRPC implementations (Java and Go).\n* Required skills: C programming language, software performance benchmarking, potentially Java and Go.\n* Likely mentors: [Craig Tiller](https://github.com/ctiller).\n\n\n#### gRPC Python:\n\n* Port gRPC Python to [PyPy](http://pypy.org). Investigate the state of [Cython support](http://docs.cython.org/src/userguide/pypy.html) to do this or potentially explore [cffi](https://cffi.readthedocs.org/en/latest/).\n* Required skills: Python programming language, PyPy Python interpreter.\n* Likely mentors: [Nathaniel Manista](https://github.com/nathanielmanistaatgoogle), [Masood Malekghassemi](https://github.com/soltanmm).\n\n* Develop and test Python 3.5 Support for gRPC. Make necessary changes to port gRPC and package it for supported platforms.\n* Required skills: Python programming language, Python 3.5 interpreter.\n* Likely mentors: [Nathaniel Manista](https://github.com/nathanielmanistaatgoogle), [Masood Malekghassemi](https://github.com/soltanmm).\n \n#### gRPC Ruby/Java:\n\n* [jRuby](http://jruby.org) support for gRPC. Develop a jRuby wrapper for gRPC based on grpc-java and ensure that it is API compatible with the existing Ruby implementation and passes all tests.\n* Required skills: Java programming language, Ruby programming language.\n* Likely mentors: [Michael Lumish](https://github.com/murgatroid99), [Eric Anderson](https://github.com/ejona86).\n\n#### gRPC Wire Protocol:\n\n* Develop a [Wireshark](https://wireshark.org) plugin for the gRPC protocol. Provide documentation and tutorials for this plugin.\n* Bonus: consider set-up and use with mobile clients.\n* Required skills: Wireshark software.\n* Likely mentors: [Nicolas Noble](https://github.com/nicolasnoble).\n\n#### gRPC Web:\n\n* Implement a reusable Web UI form to invoke gRPC end-points with preconfigured or discovery based protobuf definition.\n* Required skills: JS/HTML/CSS\n* Likely mentors: [Wenbo Zhu](https://github.com/wenbozhu).\n\n\n### CoreDNS\n\nCoreDNS is a DNS server that chains middleware.\n\n#### DNSSEC\n\n* Develop/extend the DNSSEC middleware to be able to do on-the-fly-signing and exchanging\n key material with the registrar - in essence implementing zero-touch DNSSEC.\n* Required skills: DNSSEC, cryptography, Go\n* Mentors: [Miek Gieben](https://github.com/miekg).\n\n#### dnstap Middleware\n\n* Develop a middleware that can use [dnstap](http://dnstap.info/) for DNS data exchange\n* Required skills: dnstap, Go\n* Mentors: [John Belamaric](https://github.com/johnbelamaric), [Miek Gieben](https://github.com/miekg).\n\n#### etcd3 Support\n\n* Develop a middleware that supports [etcd3 API](https://coreos.com/etcd/docs/latest/v2/api_v3.html) See also https://github.com/coredns/coredns/issues/341\n* Required skills: Go\n* Mentors: [John Belamaric](https://github.com/johnbelamaric)\n\n### CRI - Container Runtime Interface\n\n[CRI](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html) is one of the key features of Kubernetes. It is designed to decouple container runtime (e.g. [Docker](https://github.com/docker/docker)) from kubelet by defining a imperative interface for runtimes to follow. Less overhead, less effort and cleaner code base for users to integrate container runtimes into Kubernetes.\n\n#### CRI + Frakti + Unikernels\n\nThe goal of this task is to integrate Unikernels as Kubernetes runtime by using Frakti project.\n\n[Frakti](https://github.com/kubernetes/frakti) is an official Kubernetes sub-project which is a well-designed CRI implementation for hypervisor-based runtimes. It now support hypervisor container as well as mixed container runtimes (e.g. Docker + HyperContainer)on same node.\n\n[Unikernels](http://unikernel.org/) are specialised, single-address-space machine images constructed by using library operating systems. You can consider it as a virtual machine but only has a special OS compiled with your applications binaries. Unikernels are considered as the future infrastructure of [IoT](https://en.wikipedia.org/wiki/Internet_of_things) and cloud system.\n\n* Develop a build-in `unikshim` for Frakti to manage Unikernels workloads to serve Kubernetes. Hypervisor manager like libvirt (or QEMU, or even KVM) need to be installed to manage those Unikernels machines and the `unikshim` will be able to communicate with this manager to control the lifecycle of those workloads.\n* Required skills: Golang, Operating System knowledge.\n* Mentors: [Pengfei Ni](http://github.com/feiskyer), [Harry Zhang](https://github.com/resouer).\n* Issue: https://github.com/kubernetes/frakti/issues/99\n" }, { "path": "programs/summerofcode/2018.md", "content": "# 2018\nWe have been accepted as a [mentoring organisation](https://summerofcode.withgoogle.com/organizations/6453865516367872/) for Google Summer of Code 2018.\n\n### Students\n\nThe list of official project ideas is published below.\n\nYou can also take a look at the list of project ideas published for [GSoC 2017](/2017.md).\n\n### Mentors\n\nAdd your ideas to the README list below.\n\n## Project Ideas\n\n### Kubernetes\n\nPlease visit the [Kubernetes GSoC page](https://git.k8s.io/community/mentoring/google-summer-of-code.md) for general information.\n\n#### OpenAPI spec references in CustomResourceDefinitions\n* Description: CustomResourceDefinitions (CRDs) often reuse Kubernetes types and embed them, e.g. a PodSpec. Today a CRD has to copy the whole OpenAPI spec for that type. For types like PodSpec these can be huge. The idea here is to define a Kubernetes OpenAPI universe which allows to point from a CRD to the spec of other types in the universe, e.g. the mentioned PodSpec.\nThis project includes conceptual work of defining such a universe with the current, published OpenAPI spec in mind, to come up with a design for how and when to resolve the new references, to write a proposal for all that and of course to code the feature within the apiextensions-apiserver.\n* Recommended Skills: Golang, OpenAPI\n* Mentor(s): Dr. Stefan Schimanski (@sttts), Mehdy Bohlool (@mbohlool)\n* Issue: https://github.com/kubernetes/kubernetes/issues/54579\n\n#### Client-go semantic versioning\n* Description: The client-go library is vendored by many 3rdparty projects. We version it with semantic version numbers like 5.0.0, 5.0.1, 5.0.2, 6.0.0. On each release we increase the major version. We don't have any tooling in place that warns about incompatible changes when changes are merged into the Kubernetes code-base.\nThis project is about changing this by developing and applying a tool to each Kubernetes code change that looks at the changed Go code and whether it breaks any Golang interfaces. This also involves the definition which parts of client-go and other libraries are actual interfaces we promise to preserve. Finally, this project includes the integration into our test infrastructure.\n* Recommended Skills: Golang, Go parser, Go language specification and semantics, CI\n* Mentor(s): Dr. Stefan Schimanski (@sttts), Chao Xu (@caesarxuchao)\n\n#### Batch scheduling & resource sharing for data processing/ML workloads\n* Description: Investigate kube-arbitrator, adapt one well known batch type of application running on Kubernetes (Apache Spark/Tensorflow/others) to use dynamic resource sharing, produce an example that simulates real-world use-cases with shared multi-tenant clusters and do performance benchmarking. The final deliverables here are examples of one or more batch applications on Kubernetes running using dynamic resource sharing, and performance benchmarking. \n* Recommended Skill(s): Golang\n* Mentor(s): Klaus Ma (@k82cn), Anirudh Ramanathan (@foxish), @ynli\n* Issue: https://github.com/kubernetes/features/issues/269\n\n#### Strategic Merge Patch support for CustomResourceDefinitions\n* Description: Strategic Merge Patches are a data format of the HTTP Patch operation against Kubernetes objects. They allow to control how maps and slices are modified, either via tags in the patches or via tags on the Go types. CustomResources are no native Go types in Kubernetes which breaks Strategic Merge Patch. This topic is about adding Strategic Merge Patch support for `runtime.Unstructured` and to create an API to define the default merge strategies for JSON paths within CustomResources.\n* Recommended Skill(s): Golang, Algorithms\n* Mentors(s): Dr. Stefan Schimanski (@sttts)\n* Issue: https://github.com/kubernetes/kubernetes/issues/56348 and https://github.com/kubernetes/kubernetes/pull/58064\n\n#### OpenTracing support\n* Description: In order to troubleshoot Kubernetes latencies it would be great to have tracing support. Metrics are great for alerting, to know if something is wrong, but by design are not meant to trace the execution of single requests. Tracing support would allow troubleshooting high latency requests in order to find performance improvement opportunities more easily and quickly.\nThis project involves evaluating tracing solutions as well as implementing support for the Kubernetes API handlers.\n* Recommended skills: Kubernetes, OpenTracing\n* Mentor(s): Dr. Stefan Schimanski (@sttts), Frederic Branczyk (@brancz)\n* Issue: https://github.com/kubernetes/kubernetes/issues/26507\n\n### Containerd\n\n#### KataContainers support for containerd/cri-containerd\n* Description: [KataContainers](https://katacontainers.io) is a OCI container runtime which leverages hypervisor-based isolation for Linux container stack. [cri-containerd](https://github.com/containerd/cri-containerd) is a Kubernetes CRI implementation for [containerd](https://github.com/containerd/containerd), the core part of Docker. This topic aims at integrating KataContainers as a underlying runtime of containerd and serve Kubernetes CRI. In which case, users of Kubernetes will be able to enjoy security and multi-tenancy brought by KataConainers as well as native Linux container experience brought by containerd.\n\n[Update]: The preliminary design doc of this project [can be found here](https://docs.google.com/document/d/1znUEfsl-J5WGVpRGZEFQtD-kNwqhFSvRSKly7cS7d8M/).\n\n* Recommended Skill(s): Golang, Linux Operating System\n* Mentors(s): Harry Zhang (@resouer), Lantao Liu (@Random-Liu), Jiangshan Lai (@laijs)\n\n\n### Prometheus\n\nPrometheus is an open-source systems monitoring and alerting toolkit: https://prometheus.io/\n\nPrometheus ideas:\n\n#### Streaming APIs\n* Description: Currently the HTTP API sends all the data in one go and that has the chance overwhelm prometheus. To guard against this, there are limits set in Prometheus. Make APIs streaming where data is retrieved and sent in chunks rather than at once.\n* Recommended Skills: golang\n* Mentor(s): Frederic Branczyk (@brancz), Goutham V (@gouthamve)\n* Issue: https://github.com/prometheus/prometheus/issues/3690\n\n#### Refactor the APIs for better readability and less maintenance overhead\n* Description: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n* Recommended Skills: golang\n* Mentor(s): Krasi Georgiev (@krasi-georgiev)\n* Issue: https://github.com/prometheus/prometheus/issues/3416\n\n\n#### Add option to log slow queries\n* Description: Having something like PostgreSQL's log_min_duration_statement would be useful to debug performance problems. It would be great to collect detailed query information, like how many chunks were necessary to compute the result and how many had to be loaded from disk. Further having detailed stats like the number of series/samples/blocks touched would be great.\n* Recommended Skills: golang\n* Mentor(s): Ben Kochie (@SuperQ), Goutham V (@gouthamve)\n* Issue: https://github.com/prometheus/prometheus/issues/1315\n\n#### Building a full integration testing environment and benchmarks\n* Description: We're not really excellent in the correctness / bug-free-ness department yet, partially because certain key components either lack tests or you'd have to run them in a real-world scenario for a while to discover certain bugs. I'm especially looking at our under-tested service discovery mechanisms here that require e.g. a Zookeeper or Consul as a dependency to test them for real. It'd be cool to have a test environment that runs a Prometheus release end-to-end (with different SD mechanisms) for a while and checks the results (evaluated expressions, alerts, etc.) for sanity.\n* Recommended Skills: golang, infrastructure management\n* Mentor(s): Brian Brazil (@brian-brazil), Conor Broderick (@Conorbro)\n* Issue: https://github.com/prometheus/prometheus/issues/3689\n\n#### Features that aid in building and testing alerting expressions\n* Description: One of the most annoying (but important) things when using Prometheus is making sure that your alerting expressions are correct (semantically, syntactically, and referring to existing template variables). It would be great to be able to assist the user with that. This would be both frontend and backend / tooling work.\n* Recommended Skills: golang, javascript\n* Mentor(s): Julius Volz (@juliusv)\n* Issue: https://github.com/prometheus/prometheus/issues/1154 https://github.com/prometheus/prometheus/issues/1695 https://github.com/prometheus/prometheus/issues/1220 https://github.com/prometheus/prometheus/issues/1219\n\n#### Tracing in Prometheus and Alertmanager\n* Description: We can use open-tracing to trace several things in both prometheus and alertmanager, for example, prometheus query tracing.\n* Recommended Skills: golang\n* Mentor(s): Frederic Branczyk (@brancz), Tom Wilkie (@tomwilkie)\n\n#### Persist “for” state for alerts\n* Description: Currently if Prometheus restarts, we lose the 'for' state for firing alerts. While this isn't an issue for short for clauses, it presents a problem for clauses that are in the hours to days range. It'd be good to persist this state in some way, so that alerts don't have to start again from scratch. We probably don't want to count the time the prometheus server is down against the 'for' clause.\n* Recommended Skills: golang\n* Mentor(s): Goutham V (@gouthamve), Brian Brazil (@brian-brazil)\n* Issue: https://github.com/prometheus/prometheus/issues/422\n\n#### Remote read should handle down or misbehaving backends gracefully\n* Description: If a remote backend is erroring, then the whole query fails. We need to make sure that doesn't happen and at least partial data is returned.\n* Recommended Skills: golang\n* Mentor(s): Goutham V (@gouthamve), Brian Brazil (@brian-brazil), Tom Wilkie (@tomwilkie)\n* Issue: https://github.com/prometheus/prometheus/issues/2573 https://github.com/prometheus/prometheus/issues/2972\n\nAlertmanager ideas:\n\n#### Optimize Alert Ingest Path\n* Description: While benchmarking & profiling Alertmanager it quickly became obvious, that the ingest path blocks _a lot_ and can be optimised.\n* Recommended Skills: golang\n* Mentor(s): Frederic Branczyk (@brancz)\n* Issue: https://github.com/prometheus/alertmanager/issues/1201\n\n#### Improve Alert Indexing\n* Description: Currently there are various maps to improve access to certain alerts, but very scattered across the code base and seemingly unrelated. We can have a lot of improvement if we move to something similar to the TSDB reverse index.\n* Recommended Skills: golang\n* Mentor(s): Frederic Branczyk (@brancz)\n* Issue: https://github.com/prometheus/alertmanager/issues/1202\n\nTSDB ideas:\n\n#### Isolation\n* Description: Currently the writes and reads are not isolated and sometimes during reads we see partial write data.\n* Recommended Skills: golang, databases\n* Mentor(s): Fabian Reinartz (@fabxc), Brian Brazil (@brian-brazil), Goutham V (@gouthamve)\n* Issue: https://github.com/prometheus/tsdb/issues/260\n\n#### Label Values Composite Index\n* Description: We can have faster queries and new APIs if we can have a composite index for multiple index names rather than just one.\n* Recommended Skills: golang, databases\n* Mentor(s): Goutham V (@gouthamve), Fabian Reinartz (@fabxc)\n* Issue: https://github.com/prometheus/tsdb/issues/26\n\nKubernetes + Prometheus ideas:\n\n#### Kubernetes Pod Exporter\n* Description: A cAdvisor replacement to collect container metrics. Would be dependant on the cri-o metrics endpoint.\n* Recommended Skills: golang\n* Mentor(s): Frederic Branczyk (@brancz)\n\n#### Prometheus Metrics Server\n* Description: Prometheus backed implementation of the resource metrics API in Kubernetes.\n* Recommended Skills: golang\n* Mentor(s): Frederic Branczyk (@brancz)\n\nMisc. ideas:\n\n#### Prometheus Outalator\n* Description: A full-fledged outlator fully integrated with the Alertmanager. https://landing.google.com/sre/book/chapters/tracking-outages.html\n* Recommended Skills: golang, javascript\n* Mentor(s): Frederic Branczyk (@brancz), Brian Brazil (@brian-brazil), Richard Hartmann (@RichiH)\n\n### Envoy\n\n#### Replace evbuffer buffer implementation with custom rewrite\n* Description: Currently Envoy uses a buffer implementation based on libevent evbuffer. This\n implementation has a number of shortcomings. We would like to do a custom C++14 rewrite.\n* Required skills: C/C++\n* Mentor(s): Lyft networking team\n\n#### Add more fuzzing\n* Description: Envoy is only now getting fuzz testing support. By this summer the coverage will\n be limited. We would love someone to come and increase the fuzz coverage.\n* Required skills: C/C++\n* Mentor(s): Lyft networking team and consulting with Google Envoy team.\n\n### CoreDNS\n\nCoreDNS is a DNS server that chains plugins .\n\n#### DNSSEC\n\n* Develop/extend the DNSSEC plugin be able to exchange key material with the registrar - in essence\n implementing zero-touch DNSSEC.\n* Required skills: DNSSEC, cryptography, Go\n* Mentors: [Miek Gieben](https://github.com/miekg).\n\n#### etcd3 Support\n\n* Develop a plugin that supports [etcd3 API](https://coreos.com/etcd/docs/latest/v2/api_v3.html) See also https://github.com/coredns/coredns/issues/341\n* Required skills: Go\n* Mentors: [John Belamaric](https://github.com/johnbelamaric)\n\n#### Autoscaling Secondary DNS in Kubernetes\n\n* This is more complicated than it sounds. When a primary zone changes, the secondary servers are notified.\nIf CoreDNS is running as a set of autoscaling Pods in Kubernetes, only one of the CoreDNS instances will\nreceive the NOTIFY message through the load balancer. It is necessary for that CoreDNS Pod to understand\nhow to relay that message to other CoreDNS Pods. This should be done without a direct reliance on the Kubernetes\nAPI as it can be useful in non-Kubernetes deployments as well, so it is necessary to define a mechanism whereby\nCoreDNS instances may discovery one another.\n* Required skills: Go\n* Mentors: [John Belamaric](https://github.com/johnbelamaric)\n\n#### Conditional Name Server Identifier\n\n* Description: Currently CoreDNS supports DNS Name Server Identifier (NSID) to allow a DNS server to self-identify itself. In a distributed system collision may occur, so a mechanism is needed to allow a server to conditionally declare its identity. There a several ways to achieve this goal. One way is to ask a name server to wait until its precedence already declares (e.g., `server-1`), before assigning a non-conflict identity to itself (e.g., `server-2`). Another way is to extract the identity from another source, e.g., the timestamp of the server on the cloud, or a lock from K-V store like zookeeper or etcd.\n* Recommended Skills: Golang\n* Mentors: [Yong Tang](https://github.com/yongtang)\n\n### Rook\n\nRook is an open source storage orchestrator for cloud-native environments: https://rook.io/\n\n#### Rook issues for first time contributors\n\n* Description: Contributing to a major open source project can be difficult to figure out where to start.\nBeyond learning what the project does, you need to learn the code base, how to build and test your code, how to get your changes approved, and more.\nThe \"help wanted\" issues are scoped to a manageable effort for first time contributors.\nA perfect place to jump in and contribute to an open source project!\n* Issue Link: [Rook Help Wanted](https://github.com/rook/rook/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22)\n* Diffuculty: Easy\n* Recommended Skills: Golang, Kubernetes, [Ceph](https://ceph.com/), Linux\n* Mentors: [Jared Watts](https://github.com/jbw976) and [Travis Nielsen](https://github.com/travisn)\n\n#### Improve management experience with rich progress, status and error messaging\n\n* Description: When a user creates a storage cluster, resource pool, or other object using `kubectl`, the current experience is not ideal.\nSince these operations can be time consuming and can also fail, the user would greatly benefit by having a richer experience such as early validation, progress updates, meaningful status and helpful messaging.\n* Issue Link: [Rook #1539](https://github.com/rook/rook/issues/1539)\n* Diffuculty: Easy\n* Recommended Skills: Golang, Kubernetes\n* Mentors: [Jared Watts](https://github.com/jbw976) and [Travis Nielsen](https://github.com/travisn)\n\n#### Add Network File System (NFS) as a Rook storage backend\n\n* Description: We want to expand the set of storage backends that Rook can deploy and orchestrate in cloud-native environments.\n[Network File System (NFS)](https://help.ubuntu.com/lts/serverguide/network-file-system.html) would bring value to users by providing access to shared storage over the network.\nThis project would require you to write Go code to interact with Linux OS and the Kubernetes API to deploy and configure containers running the NFS daemon.\n* Issue Link: [Rook #1551](https://github.com/rook/rook/issues/1551)\n* Diffuculty: Medium\n* Recommended Skills: Golang, Kubernetes, Linux\n* Mentors: [Jared Watts](https://github.com/jbw976) and [Travis Nielsen](https://github.com/travisn)\n\n#### Support for volume snapshots and backup policy\n\n* Description: A user of a Kubernetes cluster with Rook should be able to create, manage and backup snapshots of their data that is managed by a Rook storage backend.\nPolicies should be defined to help configure snapshot and backup schedules, included data, retention, etc.\nThis is a challenging but exciting project that could tremendously help users by helping ensure their valuable data is reliably protected and backed up.\nThis project also has potential to interact with and take a leadership position in the greater Kubernetes community.\n* Issue Link: [Rook #1552](https://github.com/rook/rook/issues/1552)\n* Diffuculty: Hard\n* Recommended Skills: Golang, Kubernetes, [Ceph](https://ceph.com/)\n* Mentors: [Jared Watts](https://github.com/jbw976) and [Travis Nielsen](https://github.com/travisn)\n\n### The Update Framework\n\nA framework for securing software update systems -\n[website](https://theupdateframework.com/) and [GitHub\nrepo](https://github.com/theupdateframework/tuf).\n\n#### Key rotation and explicit self-revocation\n\n* Description: Generalize the mechanism of key rotation.\n Rotation is the process by which a role uses their old key to invalidate\n their old key and transfer trust in the old key to a new key. Performing a\n key rotation does not require parties that delegated trust to the old key to\n change their delegation to the new key. Conceptually, the rotation process\n says if you trusted key X (or threshold of keys X_0, ... X_n), now instead\n trust key Y (or threshold of keys Y_0, ... Y_n). Rotation of a key may be\n performed any number of times, transferring trust from X to Y, then from Y to\n Z, etc.\n* Task Link: [TAP 8](https://github.com/theupdateframework/taps/blob/master/tap8.md)\n* Difficulty: Medium\n* Recommended Skills: Python\n* Mentors: [Justin Cappos](https://github.com/JustinCappos),\n [Vladimir Diaz](https://github.com/vladimir.v.diaz), and\n [Sebastien Awwad](https://github.com/awwad)\n\n#### Multi-role delegations\n\n* Description: Allow a target/glob pattern to be delegated to a combination of\n roles on a repository, all of whom must sign the same hashes and length of\n the target. This is done by adding the AND relation to delegations.\n* Task Link: [TAP 3](https://github.com/theupdateframework/taps/blob/master/tap3.md)\n* Difficulty: Medium\n* Recommended Skills: Python\n* Mentors: [Justin Cappos](https://github.com/JustinCappos),\n [Vladimir Diaz](https://github.com/vladimir.v.diaz), and\n [Sebastien Awwad](https://github.com/awwad)\n\n#### Setting URLs for roles in the Root metadata file\n\n* Description: Allow each top-level role in the root metadata file to be\n optionally associated with a list of URLs. This allows the implementation of\n at least two interesting uses cases. First, it enables a user to associate a\n remote repository with a different root of trust, even if the user does not\n control this repository. This allows the user to, for example, restrict trust\n in a community repository to a single project. Second, it enables repository\n administrators to use mirrors in a safe and limited way. Specifically,\n administrators can instruct TUF clients to always download some metadata\n files from the original repository, and others from mirrors, so that clients\n are always informed of the latest versions of metadata and, thus, targets.\n* Task Link: [TAP 5](https://github.com/theupdateframework/taps/blob/master/tap5.md)\n* Difficulty: Medium\n* Recommended Skills: Python\n* Mentors: [Justin Cappos](https://github.com/JustinCappos),\n [Vladimir Diaz](https://github.com/vladimir.v.diaz), and\n [Sebastien Awwad](https://github.com/awwad)" }, { "path": "programs/summerofcode/2019.md", "content": "2019\n====\n\nCNCF GSoC 2019 is done. Please, see the report on the [CNCF\nBlog](https://www.cncf.io/blog/2019/08/23/cncf-joins-google-summer-of-code-2019-with-17-interns-projects-for-containerd-coredns-kubernetes-opa-prometheus-rook-and-more/).\n\nProject Ideas\n-------------\n\nList of Participating Projects for 2019:\n- [Kubernetes](#kubernetes)\n- [Prometheus](#prometheus)\n- [Open Policy Agent](#open-policy-agent-opa)\n- [CoreDNS](#coredns)\n- [TiKV](#tikv)\n- [Rook](#rook)\n- [Linkerd and Envoy](#linkerd-and-envoy)\n- [Virtual Kubelet](#virtual-kubelet)\n- [Linkerd](#linkerd)\n- [rkt](#rkt)\n- [containerd](#containerd)\n- [Falco](#falco)\n- [Cortex](#cortex)\n\n### Kubernetes\n\nPlease visit the [Kubernetes GSoC page](https://git.k8s.io/community/mentoring/google-summer-of-code.md) for general information.\n\n**Communication**:\n\nFor any questions or comments, please reach out to us on the #gsoc-apps channel on the [Kubernetes slack](http://slack.k8s.io/).\nPlease don't use DMs or personal emails unless strictly necessary.\n\n#### Integrate kube-batch with pytorch-operator/mxnet-operator\n\n-\tDescription: [kube-batch](https://github.com/kubernetes-sigs/kube-batch) is a batch scheduler for kubernetes by features for batch workload, e.g. coscheduling/gang-scheduling, faire-sharing; the train job of MxNet and Pytorch have requirements to those features. This idea is to integrate kube-batch to support gang-scheduling/coscheduling and other batch features in related operators.\n-\tRecommended Skills: golang, kubernetes, kubeflow\n-\tMentor(s): Klaus Ma (@k82cn)\n-\tIssue: https://github.com/kubeflow/mxnet-operator/issues/16 , https://github.com/kubeflow/pytorch-operator/issues/129\n\n#### Implement volume snapshotting support into the external Manila provisioner\n\n-\tDescription: The external OpenStack Manila provisioner lack ability to take a snapshot of the volumes and turn the snapshots to persistent volumes using container orchestrator API. The goal is to implement the missing feature in the Manila (CSI) provisioner.\n-\tRecommended Skills: Golang, Kubernetes, Ceph, OpenStack\n-\tMentor(s): Tomas Smetana (@tsmetana)\n-\tIssue: https://github.com/kubernetes/cloud-provider-openstack/issues/453\n\n#### Enable full e2e tests for external Azure cloud provider\n\n-\tDescription: The external Azure cloud provider has added its initial e2e tests, but it’s still not running the full e2e tests today. The goal is to add the missing tests and publish them on the testgrid.\n-\tRecommended Skills: Golang, Kubernetes, Azure\n-\tMentor(s): Pengfei Ni (@feiskyer)\n-\tIssue: https://github.com/kubernetes/cloud-provider-azure/issues/4\n\n#### CSI driver for AzureDisk\n\n-\tDescription: External driver for AzureDisk would be implemented as new CSI driver. The goal is:\n - mirror the current functions from in-tree driver\n - implement new features for CSI driver, e.g. snapshot, helm chart support\n - setup unit tests, sanity tests, e2e tests as well as documentation for them.\n-\tRecommended Skills: Golang, Kubernetes, Azure\n-\tMentor(s): Andy Zhang (@andyzhangx)\n-\tIssue: https://github.com/kubernetes/org/issues/344\n\n#### CSI driver for AzureFile\n\n-\tDescription: External driver for AzureFile would be implemented as new CSI driver. The goal is:\n - mirror the current functions from in-tree driver\n - implement new features for CSI driver, e.g. snapshot, helm chart support\n - setup unit tests, sanity tests, e2e tests as well as documentation for them.\n-\tRecommended Skills: Golang, Kubernetes, Azure\n-\tMentor(s): Andy Zhang (@andyzhangx)\n-\tIssue: https://github.com/kubernetes/org/issues/344\n\n#### CSI driver for Blobfuse\n\n-\tDescription: External driver for Blobfuse would be implemented as new CSI driver. The goal is:\n - mirror the current functions from in-tree driver\n - implement new features for CSI driver, e.g. snapshot, helm chart support\n - setup unit tests, sanity tests, e2e tests as well as documentation for them.\n-\tRecommended Skills: Golang, Kubernetes, Azure\n-\tMentor(s): Andy Zhang (@andyzhangx)\n-\tIssue: https://github.com/kubernetes/org/issues/344\n\n#### Add support for Custom Resource Definitions to the Dashboard\n\n- Description: Kubernetes Dashboard has no support for Custom Resource Definitions yet. The goal is to provide support for them as it was done for Third Party Resources in the past. Users should be able to perform at least the basic operations on the resources they have defined.\n- Recommended Skills: Kubernetes, Golang, TypeScript, Angular\n- Mentor(s): Marcin Maciaszczyk (@maciaszczykm), Sebastian Florek (@floreks)\n- Issue: https://github.com/kubernetes/dashboard/issues/2493\n\n#### Add plugin mechanism to the Dashboard\n\n- Description: We would like to introduce a plugin mechanism to the Kubernetes Dashboard. The goal is to define the plugin framework architecture, scope, how it could enhance the Dashboard UI and utilize third party APIs to extend its functionality.\n- Recommended Skills: Kubernetes, Golang, TypeScript, Angular\n- Mentor(s): Marcin Maciaszczyk (@maciaszczykm), Sebastian Florek (@floreks)\n- Issue: https://github.com/kubernetes/dashboard/issues/1832\n\n#### Run GPU sharing workloads with Kubernetes + Kubeflow\n\n- Description: We would like to introduce a Kubernetes native way to run jobs which could share GPU and isolation capability by leveraging Kubernetes scheduling and Device Plugin extensibility, together with [kubeflow/arena](https://github.com/kubeflow/arena).\n- Recommended Skills: Kubernetes, Golang, basic Machine Learning training experience\n- Mentors: Harry Zhang (@resouer), Kai Zhang (@wsxiaozhang), Jian He (@jian-he)\n- Issue: https://github.com/kubernetes/kubernetes/issues/52757\n\n#### Kubernetes with hardware devices topology awareness at node level\n\n- Description: We would like to propose a improvement on current Kubernetes topology manager to become aware of generic hardware device topology at node level, so Deep Learning training can be improved significantly due to data inter-connection between NVIDIA GPU devices on the node.\n- Recommended Skills: Kubernetes, Golang, basic Machine Learning training experience\n- Mentors: Harry Zhang (@resouer), Kai Zhang (@wsxiaozhang), Jian He (@jian-he)\n- Issue(s): https://github.com/kubernetes/kubernetes/issues/49964, https://github.com/kubernetes/enhancements/issues/693\n\n### Prometheus\n\nPrometheus is an open-source systems monitoring and alerting toolkit: https://prometheus.io/\n\nPrometheus ideas:\n\n#### Benchmarks for TSDB\n\n-\tDescription: The TSDB module used in Prometheus doesn’t have proper benchmarks yet, which means we cannot see the potential impact of the changes we are introducing. The idea is to build some automated benchmarking which can be added to the CI pipeline.\n-\tRecommended Skills: CI, Golang, Kubernetes\n-\tMentor(s): Krasi Georgiev (@krasi-georgiev)\n-\tIssue: https://github.com/prometheus/tsdb/issues/235\n\n#### Postings Compression\n\n-\tPostings is a lists of numbers which are references to series that contain a given label pair. They are used as a reference table to get the requested series. The project is to research and implement some compression.\n-\tRecommended Skills: Golang, Compression algorithms\n-\tMentor(s): Goutham Veeramachaneni (@gouthamve) / Krasi Georgiev (@krasi-georgiev)\n-\tIssue: https://github.com/prometheus/tsdb/issues/234\n\n#### Allow index files larger than 64GB.\n\n-\tThis would require some code refactoring on how the index file is saved to disk using varints.\n-\tRecommended Skills: Golang\n-\tMentor(s): Goutham Veeramachaneni (@gouthamve) / Krasi Georgiev (@krasi-georgiev)\n-\tIssue: https://github.com/prometheus/tsdb/issues/561\n\n#### Continue the work on high priority issues in Prombench\n\n-\tDescription: Since we finished Prombench there have been few requests to add scalability tests, add more tests with the race enabled and fix the other high priority issues.\n-\tRecommended Skills: CI, Golang, Kubernetes, Grafana\n-\tMentor(s): Krasi Georgiev (@krasi-georgiev)\n-\tIssue: https://github.com/prometheus/prombench/issues - the High priority ones should be addressed first.\n\n#### Continue the work on low hanging issues in Prombench\n\n-\tDescription: Work needs to be done to check whether Prow can be replaced by Github actions, getting metrics without any gaps and other `low hanging fruit` labeled issues.\n-\tRecommended Skills: CI, Docker, Kubernetes, Grafana\n-\tMentor(s): Krasi Georgiev (@krasi-georgiev)\n-\tIssue: https://github.com/prometheus/prombench/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22low+hanging+fruit%22\n\n#### Persist Retroactive Rule Reevaluations \n\n-\tDescription: Right now one of the biggest issues with recording rules is that data is only available since the rule was created. Which means any dashboards that use the recording rule will not have data prior to the recording rules create time. We can already reevaluate queries on old data, but we should be able to persist that for a certain window from [Oldest, Now).\n-\tRecommended Skills: Golang\n-\tMentor(s): Ganesh Vernekar (@codesome), Goutham Veeramachaneni (@gouthamve)\n-\tIssue: https://github.com/prometheus/prometheus/issues/11.\n\n#### Optimize queries using regex matchers for set lookups \n\n-\tDescription: A common use case for regex matchers is to use them to query all series matching a set of label values, e.g. `up{instance=~\"foo|bar|baz\"}`. Grafana's template variables feature is a big user of that pattern. We could catch and split it into 3 different matchers, each selecting the three cases. This would make the templated queries produced by Grafana much faster.\n-\tRecommended Skills: Golang\n-\tMentor(s): Goutham Veeramachaneni (@gouthamve)\n-\tIssue: https://github.com/prometheus/prometheus/issues/2651.\n\n#### Package for bulk imports\n\n-\tDescription: Currently if you want to migrate to Prometheus, the only way is to leave all the monitoring data from the old tool behind and start fresh. This project aims to add a package to help generate Prometheus TSDB blocks out of old data and bulk import into Prometheus.\n-\tRecommended Skills: Golang\n-\tMentor(s): Ganesh Vernekar (@codesome)\n-\tIssue: https://github.com/prometheus/prometheus/issues/535.\n\n### Open Policy Agent (OPA)\n\nOPA is a domain-agnostic policy engine that embodies \"policy as code\": https://www.openpolicyagent.org/\n\n#### IntelliJ plugin to experiment with and visualize policy evaluation\n\n- Description: OPA features a high-level declarative language that lets you express policies like \"user X can perform operation Y on resource Z\" or \"all images deployed in Kubernetes must come from an internal registry and be scanned for vulnerabilities\". The language supports many features: unit testing, dry running, tracing, etc. While users can access these features via the command-line, IDE integrations greatly improve the policy authoring experience. The idea is to port functionality that we have inside of [VS Code](https://github.com/tsandall/vscode-opa) to IntelliJ. This would significantly improve the authoring experience for people that use IntelliJ on a day-to-day basis.\n- Recommended Skills: Java, IntelliJ (not required, but nice to have)\n- Mentor(s): Torin Sandall (@tsandall)\n- Issue: https://github.com/open-policy-agent/opa/issues/1085\n\n#### Interactive website detailing OPA integrations\n- Description: OPA has been integrated with 20+ cloud-native systems to provide rich, context-aware policy support, e.g. Kubernetes, Istio, Envoy, Linkerd, Terraform, Ceph, Minio. Today there is no authoritative guide for users to understand what those integrations are, how they work, or how to get started. This project involves designing and implementing an interactive web portal that helps users understand the integrations available with OPA. It will be data-driven, so that new integrations can easily be added to the portal, and each entry will include code-snippets, videos, blog posts, github-repos, tutorials, reviews, and overall status.\n- Recommended Skills: Frontend HTML/CSS/JavaScript, Backend Node/Python/Go/etc.\n- Mentor(s): Tim Hinrichs (@timothyhinrichs) and Torin Sandall (@tsandall)\n- Issue: https://github.com/open-policy-agent/opa/issues/1194\n\n#### Integration with IPTables\n- Description: One common use of policy is to set up IP packet filter rules in the Linux kernel. The policy dictates what to do with different kinds of packets. There have been several requests in the past to use OPA policies to control IPTables, but no one has come forth with an integration. This project involves designing the layout of IPTable rules using OPA's policy language, implementing the algorithms that generate IPTables from that layout, and writing the code that populates the generated IPTables rules into Linux.\n- Recommended Skills: Go and Linux\n- Mentor(s): Reinaldo Penno (@repenno) and Tim Hinrichs (@timothyhinrichs)\n- Issue: https://github.com/open-policy-agent/opa/issues/1195\n\n### CoreDNS\n\nCoreDNS is a fast and flexible DNS server. It has a focus of service discovery in a hybrid environment and is the default DNS server in Kubernetes (since 1.13+): https://github.com/coredns/coredns\n\n#### Support source-IP based query block/allow\n\n-\tDescription: When CoreDNS serves DNS queries publicly or inside Kubernetes clusters, the source IP of the incoming DNS query is an important identity. For security considerations, only certain queries (from specific source-IP or CIDR block) should be allowed to prevent the server from being attacked. The goal of this project is to support a firewall-like source-IP based block/allow mechanism for CoreDNS.\n-\tRecommended Skills: Golang\n-\tMentor(s): Yong Tang (@yongtang)\n\n#### Support Google Cloud DNS backend\n\n-\tDescription: CoreDNS is able to serve DNS with cloud vendors (such as AWS) as the backend. The feature is very much useful in a hybrid environment where cloud-vendor specific service endpoints need to be exposed to clusters managed by Kubernetes. The goal of this project is to support Google Cloud DNS (similar to already supported [route53 plugin](https://github.com/coredns/coredns/tree/master/plugin/route53)) as a backend for CoreDNS.\n-\tRecommended Skills: Golang, Google Cloud\n-\tMentor(s): Yong Tang (@yongtang)\n\n#### Support Azure DNS backend\n\n-\tDescription: CoreDNS is able to serve DNS with cloud vendors (such as AWS) as the backend. The feature is very much useful in a hybrid environment where cloud-vendor specific service endpoints need to be exposed to clusters managed by Kubernetes. The goal of this project is to support Azure DNS (similar to already supported [route53 plugin](https://github.com/coredns/coredns/tree/master/plugin/route53)) as a backend for CoreDNS.\n-\tRecommended Skills: Golang, Microsoft Azure\n-\tMentor(s): Yong Tang (@yongtang)\n\n### TiKV\n\nTiKV is an open-source distributed transactional Key-Value database. [https://tikv.org](https://tikv.org).\n\n#### Migrate to tower-grpc\n\n- Description: We use grpc-rs which wraps C gRPC, and we want to work better with Rust community and use a pure Rust gRPC. The goal for this section is to use tower-grpc to replace our current grpc-rs.\n- Recommended Skills: Rust, gRPC\n- Mentor(s): JianJun Li (@busyjay), Nick Cameron (@nrc)\n- Issue: https://github.com/tikv/tikv/issues/3951\n\n#### Introduce other storage engines\n\n- Description: TiKV uses RocksDB as its storage engine, but RocksDB is not suitable for all workloads. The goal for this section is to use other storage engines to satisfy different workloads.\n- Recommended Skills: Rust, RocksDB\n- Mentor(s): Nick Cameron (@nrc), Yi Wu (@yiwu-arbug)\n- Issue: https://github.com/tikv/tikv/issues/4184\n\n\n#### Build TiKV clients in different languages\n\n- Description: TiKV now only contains an official Go client, we need more. The goal for this section is to build TiKV client with other languages like C++, Java, Rust, etc.\n- Recommended Skills: C++/Java/Rust, gRPC\n- Mentor(s): Ana Hobden (@hoverbear), JianJun Li (@busyjay)\n- Issue: https://github.com/tikv/tikv/issues/4185\n\n#### Auto-tune RocksDB\n\n- Description: TiKV heavily depends on RocksDB, but RocksDB has many configurations and it is hard to choose proper values in production. The goal for this section is to auto-tune RocksDB in real time for different workloads.\n- Recommended Skills: Rust, RocksDB\n- Mentor(s): Yi Wu (@yiwu-arbug)\n- Issue: https://github.com/tikv/tikv/issues/4052\n\n### Rook\n\nRook is an open source cloud-native storage orchestrator for Kubernetes, providing the platform, framework, and support for a diverse set of storage solutions to natively integrate with cloud-native environments.\n\nWebsite: https://rook.io/ \nGitHub: https://github.com/rook/rook\n\n#### Upgrade Rook to a more advanced operator/controller framework\n\n- Description: Rook currently builds its [operator](https://coreos.com/blog/introducing-operators.html) functionality from its own homegrown [operator kit](https://github.com/rook/operator-kit).\n This framework was a very early effort in the ecosystem and there are now more mature efforts that provide more rich functionality and experience.\n The various available operator/controller frameworks should be evaluated and the best fit for advancing the Rook project should be integrated into the numerous Rook operators and controllers.\n This will provide a more robust experience for both our developer and end user communities, as well as provide the student with a deep experience and familiarity to Kubernetes custom controllers written for production scenarios.\n- Recommended Skills: Kubernetes, Golang\n- Mentor(s): [Jared Watts](https://github.com/jbw976) and [Yannis Zarkadas](https://github.com/yanniszark)\n- Issue: [#1981](https://github.com/rook/rook/issues/1981)\n\n#### Storage provider features and enhancements\n\n- Description: Rook supports many storage providers to integrate them into Kubernetes and provide their storage services to pods and workloads.\n This project will enable you to become familiar with many of Rook's supported storage systems and bring multiple enhancements through the full software development life-cycle.\n Along with the mentor for this project, you will learn about the storage systems supported by Rook, choose the highest impact features to benefit the community, then design and implement the features to be included in a future official release.\n Some examples include:\n - Support a \"secure\" mode in the CockroachDB operator to include certificates and SSL in all network communication\n - Add a dynamic provisioner to the Network File System (NFS) operator to provision NFS storage for client pods on demand\n- Recommended Skills: Kubernetes, Golang, storage concepts and systems\n- Mentor(s): [Jared Watts](https://github.com/jbw976) and [Rohan Gupta](https://github.com/rohan47)\n- Issue: Multiple issues to be chosen by student, such as [#1809](https://github.com/rook/rook/issues/1809), [#2062](https://github.com/rook/rook/issues/2062), [#2283](https://github.com/rook/rook/issues/2283), [#2531](https://github.com/rook/rook/issues/2531), [#1804](https://github.com/rook/rook/issues/1804)\n\n#### Enable multiple network interfaces for Rook storage providers\n\n- Description: Many of the storage providers supported by Rook can benefit from enabling them to consume multiple network interfaces.\n A common pattern for utilizing these multiple networks is to separate the internal \"backend\" traffic amongst the storage system components from the client \"frontend\" traffic to service client requests, increasing performance and throughput.\n This project will include designing a common experience for exposing this concept to storage administrators and also implementing a reusable code implementation for multiple storage providers to easily integrate this functionality.\n Familiarity with networking concepts and architecture will be very beneficial while building this feature.\n- Recommended Skills: Kubernetes, Golang. networking\n- Mentor(s): [Dmitry Yusupov](https://github.com/dyusupov)\n- Issue: [#2621](https://github.com/rook/rook/issues/2621)\n\n#### Enhance and extend the Rook framework for storage solutions\n\n- Description: Rook is more than just a collection of operators and custom resources, it is a framework for storage providers to integrate their solutions into cloud-native environments.\n This framework provides general implementations that each storage solution can consume to integrate with Kubernetes more easily and provide more functionality.\n We'd like to continue growing and developing this framework to broaden its scope of impact.\n For example, it would greatly improve the user experience for many of Rooks supported storage solutions if we could support early validation, status reporting, and progress for long running operations.\n Likewise, many storage solutions would benefit if the Rook framework supported specifying the underlying storage fabric in a more flexible and dynamic way.\n For this project, you will learn about the design and features of the Rook framework then choose the highest impact enhancements to design, implement, and bring through the entire software development life-cycle to be included in a future official release.\n- Recommended Skills: Kubernetes, Golang\n- Mentor(s): [Jared Watts](https://github.com/jbw976)\n- Issue: Multiple issues to be chosen by student, such as [#1539](https://github.com/rook/rook/issues/1539), [#2363](https://github.com/rook/rook/issues/2363), [#2107](https://github.com/rook/rook/issues/2107), [#1744](https://github.com/rook/rook/issues/1744), and [#1228](https://github.com/rook/rook/issues/1228)\n\n#### Expand coverage and scope of Rook's continuous integration (CI) system\n\n- Description: For every pull request, commit to master, and official release, Rook runs a [build and testing continuous integration system](https://jenkins.rook.io/).\n This system builds and packages all of the Rook artifacts, dynamically deploys and configures multiple versions of Kubernetes clusters across multiple environments, and then executes all of the Rook integration tests to ensure that the current version of Rook meets all the quality expectations of the community.\n It would greatly benefit the broader community to expand the coverage of this CI system to cover more hardware architectures, cloud provider environments, and Kubernetes offerings.\n In addition to expanding test coverage to all these new platforms, it would also be beneficial to parallelize the testing pipelines to improve efficiency and lower test run time.\n- Recommended Skills: Kubernetes, Golang, testing and quality assurance\n- Mentor(s): [Jared Watts](https://github.com/jbw976)\n- Issue: Multiple issues, including [#1901](https://github.com/rook/rook/issues/1901), [#1315](https://github.com/rook/rook/issues/1315), [#1841](https://github.com/rook/rook/issues/1841), and [#1218](https://github.com/rook/rook/issues/1218)\n\n#### Dynamic provisioning for portable workloads\n\n- Description: Rook has architected a great solution for integrating many storage systems into cloud-native environments and also supporting the provisioning of storage for clients in these systems.\n This solution can be taken further to support scenarios of workload portability, where an application merely needs to express its need for a general type of storage, and a matching Rook storage provider will dynamically provision this storage on demand, enabling applications to be written once but run anywhere.\n For example, an application could express its general need for an object storage bucket, and at deployment time that bucket could be provided from Ceph, EdgeFS, Minio, or even one of the public cloud providers.\n This project is an early vision and there will be significant design work to bring this to practical fruition, including integration with the [Crossplane project](https://crossplane.io/).\n It is recommended to read the [high level architecture/vision document](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit?usp=sharing) for further background understanding.\n- Recommended Skills: Kubernetes, Golang\n- Mentor(s): [Jared Watts](https://github.com/jbw976)\n- Issue: [#1705](https://github.com/rook/rook/issues/1705), [#1704](https://github.com/rook/rook/issues/1704)\n\n### Linkerd and Envoy\n\nLinkerd is an ultralight service mesh for Kubernetes and beyond: https://linkerd.io.\nEnvoy is an open source edge and service proxy, designed for cloud-native applications: https://www.envoyproxy.io.\n\n#### Benchmarks for Linkerd and Envoy\n\n- Description: Linkerd, like other service meshes are plagued by the question of adopters asking the question: \"what's the performance overhead of the service mesh?\". Envoy does not publish performance test results [see How fast is Envoy](https://www.envoyproxy.io/docs/envoy/latest/faq/how_fast_is_envoy)). Linkerd, Istio, Envoy and the list of other service meshes don't have a consistent set of performance benchmarks between them. So, even if Envoy were to publish performance results, users still wouldn't be able to compare overhead between Linkerd and Envoy. The [project idea](https://layer5.io/meshery) here is to build a multi-mesh performance benchmark tool.\n\n- Recommended Skills: Golang, JavaScript, Kubernetes\n- Mentor(s): Lee Calcote ((@lcalcote)[https://twitter.com/lcalcote), Girish Ranganathan (@ingenious_G)\n- Project: [https://layer5.io/meshery](https://layer5.io/meshery)\n- Issue: https://github.com/envoyproxy/envoy/issues/5536 and https://discourse.linkerd.io/t/linkerd-performance/146\n\n### Virtual Kubelet \n\nVirtual kubelet is a Kubernetes kubelet implementation.\n\n#### Conformance testing for Virtual Kubelet\n\n* Description: As the project gets closer to stabilizing the interface that providers implement, users of vk are looking for a run through the Kubertenes conformance test suite. This project will direct parts of the virtual kubelet interface.\n* Issue: https://github.com/virtual-kubelet/virtual-kubelet/issues/81\n* Recommended Skills: Go\n* Mentors: Ria Bhatia (rbitia), Brian Goff (cpuguy83)\n\n#### Controller for Virtual Kubelet\n\n* Descrption: The user experience around installation and management of Virtual Kubelet leaves a lot to be desired. This project looks to explore how to improve this UX through the use of a new Kubernetes controller for managing Virtual Kubelet instances.\n* Issue: https://github.com/virtual-kubelet/virtual-kubelet/issues/565\n* Recommended Skills: Go\n* Mentors: Ria Bhatia (rbitia), Brian Goff (cpuguy83)\n\n### Linkerd\n\nLinkerd is an ultralight service mesh for Kubernetes that provides\nobservability, reliability, and security for your microservices.\n[https://linkerd.io](https://linkerd.io)\n\n#### Cross-cloud integration testing\n\n- Description: With the proliferation of managed Kubernetes services on many\n cloud platforms (GKE, AKS, EKS, Kubernetes on DigitalOcean), the subtle\n differences between these providers can create hard to debug and understand\n issues. This project involves building out the tooling to create clusters on\n multiple providers, interact with those and run the integration test suite\n on them. It will surface bugs earlier, make it easier to replicate user\n issues and provide a common framework to build sample workloads on top of.\n- Recommended Skills: Bash, TravisCI, Go, Cloud Providers\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue: [https://github.com/linkerd/linkerd2/issues/2213](https://github.com/linkerd/linkerd2/issues/2213)\n\n#### Auto-Update\n\n- Description: Linkerd has frequent updates and keeping up with the weekly edge\n releases can be difficult. This project involves building an Kubernetes\n operator that can observe the version-check API, auto-update the control plane\n and replace the Linkerd data plane proxies with the correct version.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue: [https://github.com/linkerd/linkerd2/issues/1903](https://github.com/linkerd/linkerd2/issues/1903)\n\n#### Conformance Validation\n\n- Description: Linkerd has an extensive `check` suite that validates a cluster\n is ready to install Linkerd and that the install was successful. These checks\n are, unfortunately, static checks. Because of the wide number of ways a\n Kubernetes cluster can be configured, Users want a way to validate their\n specific install for conformance over time. This project involves building a\n sample application that exercises all the features of Linkerd and allows an\n end user to run this on their own cluster to validate that everything is\n working and configured correctly over a long time.\n- Recommended Skills: Go, Bash, Kubernetes, gRPC\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue: [https://github.com/linkerd/linkerd2/issues/1096](https://github.com/linkerd/linkerd2/issues/1096)\n\n#### Alertmanager Integration\n\n- Description: Linkerd provides rich metrics that are stored in Prometheus out\n of the box. These are for both the control plane and data plane. The goal is\n to provide Alertmanager integration that comes out of the box, is configurable\n with preferred channels (email, slack) and works with ServiceProfiles to\n easily create alerts that are per-service and per-route.\n- Recommended Skills: Go, Prometheus, Grafana, Kubernetes\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue: [https://github.com/linkerd/linkerd2/issues/1726](https://github.com/linkerd/linkerd2/issues/1726)\n\n#### Kafka Introspection\n\n- Description: HTTP based traffic is only one type of modern applications. Many use message\n queues such as Kafka. Getting the metrics for consumers/producers/messages are\n just as critical to application health as requests and responses in HTTP. The\n goal of this project is to implement a Kafka codec for the Linkerd proxy that\n allows it to introspect the Kafka protocol and provide metrics on that protocol.\n- Recommended Skills: Go, Rust, Kubernetes, Kafka\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue: [https://github.com/linkerd/linkerd2/issues/2214](https://github.com/linkerd/linkerd2/issues/2214)\n\n### rkt\n\nrkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.\n\n#### Add support for the OCI runtime spec by implementing a runc stage2\n\n- Description: rkt implements the App Container Executor specification of the [appc Container Specification](https://github.com/appc/spec) and uses systemd unit properties to implement its features. To implement the OCI runtime spec, systemd unit properties are not suitable since they differ from what the spec defines. The idea is to replace systemd unit properties by runc to implement the OCI runtime spec. Work for this [has already started](https://github.com/rkt/rkt/issues/3408).\n- Recommended Skills: Golang.\n- Mentor(s): Iago López Galeiras (@iaguis), Alban Crequy (@albanc)\n\n#### Add native OCI image support\n\n- Description: rkt supports the OCI image spec by converting an OCI image to its internal format (appc). The idea is to implement native support for the OCI image spec using the [containers/image library](https://github.com/containers/image). This will also involve coming up with a reasonable scheme to support both appc and OCI images, and refactoring rkt's image store and fetching logic.\n- Recommended Skills: Golang.\n- Mentor(s): Iago López Galeiras (@iaguis), Alban Crequy (@albanc)\n- Issue: https://github.com/rkt/rkt/issues/2541\n\n### containerd\n\ncontainerd is a OCI-compliant container runtime for Linux. It is a stable, secure, and performant runtime used in both Docker and Kubernetes, as well as many other projects.\n\n#### Snapshotter implementation for block devices\n\n- Description: containerd uses snapshotter drivers to interface with specific filesystem technologies, like overlayfs, aufs, btrfs, among others. Several projects would benefit from a snapshotter implementation for block or remote devices.\n- Recommended Skills: Golang.\n- Mentor(s): Derek McGowan (@dmcgowan), Phil Estes (@estesp)\n\n#### p2p or remote blob store implementation\n\n- Description: containerd stores image content (layer blobs) in a local content store today. Implementation of a p2p or remote blob store would be a great addition to containerd capabilities.\n- Recommended Skills: Golang.\n- Mentor(s): Derek McGowan (@dmcgowan), Phil Estes (@estesp)\n\n### Falco\n\n[Falco](https://falco.org) is an open source project for intrusion and abnormality detection for Cloud Native platforms such as Kubernetes, Mesosphere, and Cloud Foundry. \n\n**Communication**:\n\nFor any questions or comments, please reach out to us on the #gsoc channel on the [Falco/Sysdig OSS slack](http://slack.sysdig.com/).\nPlease don't use DMs or personal emails unless strictly necessary.\n\n#### Improved Falco Outputs\n\n-\tDescription: The goal behind this idea is to improve the available options for sending alerts from Falco when a security violation occurs inside a container. Currently outputs are limited to stdout, files, syslog, and executing a program. We’d like to offer more output options such as: NATS.io, Kafka, gRPC, Google Pub/Sub, AWS SNS, HTTPs Webhooks, etc.\n-\tRecommended Skills: C/C++ experience, working with external libraries, working knowledge of message queues and modern Pub/Sub systems\n-\tMentor(s): Mark Stemm (@mstemm), Loris Degioanni (@ldegio), Michael Ducy (@mfdii)\n\n#### Additional Event Sources\n\n-\tDescription: Allow Falco to ingest events from other sources. Currently Falco ingests system call events and events from Kubernetes audit logging. End users can then use Falco’s out of the box (or create their own) rules to detect abnormal behavior in these event streams. This idea would implement the ability for Falco to ingest other event sources such as: cloud provider events, application events, events from Service Mesh tools such as Istio, etc.\n-\tRecommended Skills: C/C++ experience, working with external libraries, parsing JSON, best practices around running applications that send events to define new rules for the event source.\n-\tMentor(s): Mark Stemm (@mstemm), Loris Degioanni (@ldegio), Michael Ducy (@mfdii) \n\n#### Layer 7 Inspection and Detection\n\n-\tDescription: Extend Falco to inspect layer 7 payloads and create rules to detect bad best practices such as storing secrets in plain text, attempts at exploiting an api, etc. This would optionally include work to intercept layer 7 payloads before encryption occurs. \n-\tRecommended Skills: C/C++ experience, understanding of shared memory on Linux, cryptography knowledge.\n-\tMentor(s): Mark Stemm (@mstemm), Loris Degioanni (@ldegio)\n\n#### Falco integration with AI/ML platforms\n\n-\tDescription: Falco can generate a large number of events. This is useful for creating a complete audit trail of activity in a cloud native platform such as Kubernetes. As this audit trail may container normal conditions and abnormal conditions, applying ML models to this audit trail can be useful to baseline “normal” and then to detect activity that is suspect. This idea would take Falco alerts and ship them into a ML system for analysis. As this is an experiment, we are indifferent to the ML tool of choice but Cloud based tools such as Google Cloud AI or Google Cloud ML. \n-\tRecommended Skills: C/C++, Lua, Tensorflow\n-\tMentor(s): Mark Stemm (@mstemm), Loris Degioanni (@ldegio), Michael Ducy (@mfdii)\n\n#### Prometheus Metrics Exporter\n\n-\tDescription: Export Prometheus metrics for Falco events and alerts such as: Total rules triggered; Events dropped; Count of rules triggered by: rule name, rule event source, rule tag; Alerts sent; Alerts failed to send: Total, by output.\n-\tRecommended Skills: C/C++, Lua, Understanding of Prometheus Metrics format and best practices \n-\tMentor(s): Mark Stemm (@mstemm), Loris Degioanni (@ldegio), Michael Ducy (@mfdii)\n\n#### Performance Analysis and Optimization\n\n-\tDescription: Analyze the performance of Falco in regards to the number of events that can be processed by the Falco engine. Document the existing performance constraints of Falco. Optimize the Falco engine to increase the throughput of the Falco engine and provide an analysis of the performance improvements implemented with before and after metrics.\n-\tRecommended Skills: C/C++, Lua, Understanding of performance analysis\n-\tMentor(s): Mark Stemm (@mstemm), Loris Degioanni (@ldegio), Michael Ducy (@mfdii)\n\n#### Falco rules profiles for applications and security benchmarks\n\n-\tDescription: Create Falco rules for common applications and security benchmarks such as CIS benchmarks. Rules should allow access to common files, folders, processes, and network ports based on profiling of applications.\n-\tRecommended Skills: Understanding of common Applications and Security Benchmarks\n-\tMentor(s): Mark Stemm (@mstemm), Michael Ducy (@mfdii)\n\n### Cortex\n\nCortex is an open-source project providing horizontally scalable, multi-tenant, long term storage for [Prometheus](https://prometheus.io/). You can find the project at [https://github.com/cortexproject/cortex](https://github.com/cortexproject/cortex).\n\n#### Improve Ingester Handover\n\n- Description: The ingester is a stateful component in the Cortex ecosystem that builds Prometheus chunks from incoming samples. In order to distribute load, a [Distributed Hash Table](https://en.wikipedia.org/wiki/Distributed_hash_table) is used to route requests to different Ingesters. The current implementation only allows users to scale up their ingester pools by 1 Ingester per 12 hour period, which is not great when load changes dramatically. This project will be to improve how Ingesters hand over their data when they are being created or deleted in order to easily scale.\n- Recommended Skills: Golang\n- Mentor(s): Bryan Boreham (@bboreham)\n\n#### Centralized Rate Limiting\n\n- Description: The current rate limiting implementation in Cortex is per instance of a component. This project is to make rate limiting central so that an operator does not have to change their limits whenever they scale their cluster. See [this issue](https://github.com/cortexproject/cortex/issues/1090).\n- Recommended Skills: Golang\n- Mentor(s): Bryan Boreham (@bboreham)\n\n#### Use etcd in Cortex\n\n- Description: Cortex currently uses Consul as a key value store to hold cluster state. We would like Cortex to support [etcd](https://github.com/etcd-io/etcd), another CNCF project that many people are familiar with running. See [this issue](https://github.com/cortexproject/cortex/issues/1144).\n- Recommended Skills: Golang\n- Mentor(s): Bryan Boreham (@bboreham)\n\n" }, { "path": "programs/summerofcode/2020.md", "content": "Project Ideas\n-------------\n\nIf you are a project maintainer and consider mentoring during the GSoC 2020 cycle, please, submit your ideas below using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\nFor example:\n\n### Prometheus (sample):\n\n#### Refactor the APIs for better readability and less maintenance overhead\n\n-\tDescription: Currently the HTTP API is not very well organized and needs some tidying up. The actual course of action is not decided yet, but [go-kit](https://github.com/go-kit/kit) looks like a good fit.\n-\tRecommended Skills: golang\n-\tMentor(s): Krasi Georgiev (@krasi-georgiev)\n-\tIssue: https://github.com/prometheus/prometheus/issues/3416\n\n_Add your project ideas below:_\n\n### Kubernetes\n\n#### Cluster Addons: Package all the things!\n\n- Description: The cluster-addons project aims to make kubernetes\n simpler and more reliable, by dividing clusters into simple,\n reusable, modularized parts. Collaboration between the various\n approaches in the ecosystem has now gotten us to a point where we\n have a reasonable framework and a few example operators, but it's\n time to start building out the full set of real-world operators that\n will run on the world's Kubernetes clusters. That's where you come\n in! Though this should start gently (there are plenty of simple\n addons), it won't be quite that simple: you should expect to find\n lots of fun challenges that need fixing, likely a few design flaws,\n and plan to get involved with the kubernetes community in fixing\n them.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Justin Santa Barbara (@justinsb), Leigh Capili (@stealthybox)\n- Issue: https://github.com/kubernetes-sigs/cluster-addons/issues/39\n\n#### CoreDNS operator: Prototype to Reality\n- Description: CoreDNS Operator aims to manage the lifecycle of the CoreDNS installation in the cluster.\n It is concerned with the installation, updating, and configuration of CoreDNS. The current operator\n is a proof of concept of the add-on library. The goal of the alpha operator is to provide a minimal feature\n set that is manageable, predictable, and reliable in a production environment. You will work with\n various CNCF groups to understand the problem and set milestones and criteria for the productionization\n of the operator. You will establish the fundamental testing for the operator to ensure long term\n success of the project. The project is ran out of the cluster addons working group which provides a\n friendly venue to learn more about the internals of Kubernetes.\n- Recommended Skills: Go, Kubernetes, Bash, CoreDNS\n- Mentor(s): Jeff Johnson (@johnsonj), Sandeep Rajan (@rajansandeep)\n- Issue: https://github.com/kubernetes-sigs/cluster-addons/issues/47\n\n#### Kubernetes Multitenancy Working Group: Benchmarks\n\n- Description: The Kubernetes Multi-Tenancy Working Group is chartered with exploring and defining multi-tenancy models for Kubernetes. An overview of working group activities can be found in this [Kubernetes Multi-Tenancy Working Group](https://drive.google.com/file/d/1VFVE0lktXq9zaV6H04GyZBV3oQzoYKV6/edit) . The [Multitenancy Benchmarks](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/benchmarks) effort focuses on measuring and validating the desired behaviors for multitenancy. Part of this effort is to automate behavioral and configuration checks on existing clusters, which will be the focus of this project. This automated test suit will help all Kubernetes users validate whether their clusters are setup correctly for multi-tenancy.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s):Tasha Drew (@tashimi), Ryan Bezdicek (@rjbez17), Jim Bugwadia (@JimBugwadia)\n- Issue: https://github.com/kubernetes-sigs/multi-tenancy/issues/551\n\n#### A better experience for Kubernetes to provision and consume cloud resources\n\n- Description: This task focus on creating a better experience for Kubernetes to provision cloud resources by simply using CRDs to model them and leveraging various existing mechanisms including Service Catalog, OAM Trait system and Service Binding Operator to achieve smarter connection information injection and consuming. It also helps a lot to achieve better interoperability between Kubernetes community and public cloud providers.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Jianbo Sun (@wonderflow), Ryan Zhang (@ryanzhang-oss)\n- Issue: Multiple issues - https://github.com/kubernetes/kubernetes/issues/14475, https://github.com/kubernetes/community/pull/254, https://github.com/oam-dev/cloud-provider/issues/13\n\n### Thanos\n\n#### Per Series Metric Retention\n\n-\tDescription: Thanos is allowing storing metrics for long, if not unlimited time. Currently however there is no fine-granular process of retaining only some portion of metrics for longer time e.g useful\naggregations), while deleting other part early on. This task is aiming to implment this missing feature in Thanos and potentially Prometheus.\n-\tRecommended Skills: golang, distributed systems, object storage (AWS, S3)\n-\tMentor(s): Bartlomiej Plotka (@bwplotka), Matthias Loibl (@metalmatze)\n-\tIssue: https://github.com/thanos-io/thanos/issues/903\n\n#### Enriching and Extending Thanos UIs with React for Awesome User Experience!\n\n- Description: Thanos allows scaling Prometheus metrics in an easy and gradual process. So far we used successfully pieces of old Prometheus UI with some improvements. However, since Prometheus now moved all UI pages to React, it opens new possibilities for Thanos as well. Thanks to reacting we can enrich our UI even more while resuing many components from Prometheus with ease. As part of this task, we plan to move all UI to React and enrich them with Thanos features. We also plan to add UI to every component of Thanos ensuring consistency and improve the experience of using Thanos even more! Help us and work with friendly community and team towards our goals! 💪\n- Mentor(s): Bartlomiej Plotka (@bwplotka), Lucas Servén Marín (@squat)\n- Issue: https://github.com/thanos-io/thanos/issues/2198\n\n### TiKV\n\n#### Support Cold/Hot Tier storage in TiKV\n- Description:\nTiKV uses RocksDB as its storage layer, currently RocksDB support assigns a list of path, newer data is placed into paths specified earlier in the list while older data gradually moves to paths specified later in the list. For example we may use a 300GB fast local SSD as the first path, and a 2TB HDD disk as the second path, and an 16TB remote network disk as the last path. This will reduce the total cost, but the older data doesn’t mean it is cold data. If there is some older but frequently accessed data, it will host in block-cache normally, but the total memory is limited. If this frequently accessed data can be pulled up to the first path(the local fast ssd), it can achieve a better read performance for TiKV.\n-\tRecommended Skills: Rust, RocksDB\n-\tMentor(s): Yi Wu (@yiwu-arbug), Wei Liu (@Little-Wallace)\n-\tIssue: https://github.com/tikv/tikv/issues/6507\n\n#### Versioned RawKV.\n- Description: TiKV with raw-mode does not support multiple version with one key. When user migrate data from HBase to TiKV, they want to read history record and hope TiKV could delete expired key. In addition, atomic operations like incrementAndGet and checkAndPut can be introduced to ease HBase to TiKV migration. See more in Versioned KV\n- Recommended Skills: HBase or BigTable, Rust\n- Mentor(s): Wei Liu (@Little-Wallace)\n- Issue: https://github.com/tikv/tikv/issues/6508\n\n#### Cloud-native KV-service\n- Description: Explore cloud-native design for distributed KV-service that is cost effective. Investigate using different storage backend (local/persistent SSDs, EBS, S3, etc) to store TiKV data, and their pros and cons.\n- Recommended Skills: Golang, Rust\n- Mentor(s): Yi Wu (@yiwu-arbug), Wei Liu (@Little-Wallace)\n- Issue: https://github.com/tikv/tikv/issues/6506\n\n### Cortex\n\n#### Allow Cortex to selectively disable indexing of labels.\n\n- Description: The idea is that Cortex should have config saying \"do not index any label `kubernetes_io_arch`\", then ingester skips indexing it and querier knows if it does appear in a query to fall back to scanning each chunk.\nRationale: some labels are not very selective, or very rarely come up in queries. Not indexing them reduces IO and storage cost.\n- Recommended Skills: Go\n- Mentor(s): Bryan Boreham (@bboreham)\n- Issue: https://github.com/cortexproject/cortex/issues/2068\n\n### Dragonfly\n\n#### Optimize the p2p scheduling algorithm for stremaing-p2p in Dragonfly\n\n- Description: Dragonfly is plannig to implement a new P2P based on streaming, which sends the data between p2p network to user end directly, in order to achieve the purpose of reading and writing to disk as few as possible. And the **P2P Streaming Sliding Window** is designed to control the number of pieces of a file that can be scheduled and downloaded to avoid unlimited memory usage. So It's better to optimize the p2p scheduling algorithm for this new feature, which can reduce the memory usage of client and promote the p2p transmisstion.\n- Recommended Skills: Go\n- Mentor(s): Jin Zhang (@lowzj), Yuxing Liu (@Starnop)\n- Issue: https://github.com/dragonflyoss/Dragonfly/issues/1164\n\n\n### Flux\n\n#### Improve observability and error reporting in Flux.\n\n- Description: Users have been requesting better observability and error reporting in Flux for a while. We should improve that situation, letting users monitor the state of Flux and diagnose any problems easily. Among other ways, this can be done by improving/replacing Flux's events API, improving logs and error reporting, adding Prometheus metrics and adding a Grafana dashboard.\n- Recommended Skills: Go, Prometheus, Grafana, Kubernetes\n- Mentor(s): Hidde Beydals (@hiddeco), Michael Bridgen (@squaremo), Stefan Prodan (@stefanprodan)\n- Issue: https://github.com/fluxcd/flux/issues/2812\n\n### KubeEdge\n\n#### KubeEdge installer to support conversion between different config versions\n\n- Description: the latest KubeEdge release introduced component config API to config components. The structure is different with the old configuration file used in prior (v1.2 and older) releases. Providing convert functionality to generate new configuration according old ones would help speed up the upgrade process from an old KubeEdge release. And to provide backward compatibility during follow-up component config API enhancements, conversion framework is needed to support multiple component config API versions in a same release.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): kadis (@kadisi), Kevin Wang (@kevin-wangzefeng)\n- Issue： https://github.com/kubeedge/kubeedge/issues/1437\n\n#### KubeEdge AI application\n\n- Description: KubeEdge has a repository (https://github.com/kubeedge/example) shows sample applications and demos to illustrate possible use cases of KubeEdge platform. The idea is to build a new sample application to run OpenCV on KubeEdge platform to demo image processing (or computer vision) at edge.\n- Recommended Skills: Go, Python, Kubernetes\n- Mentor(s): Yin Ding (@dingyin)\n- Issue：https://github.com/kubeedge/examples/issues/39\n\n### OpenTelemetry\n\n#### OpenTelemetry integration with Azure, Amazon, and Google Cloud metadata services\n\n- Description: OpenTelemetry C# SDK can be used on any cloud. All major clouds provide a similar mechanisms to obtain deployment instance information. The task is to obtain those properties from the service like [this](https://docs.microsoft.com/azure/virtual-machines/windows/instance-metadata-service) and associate resulting properties with the telemetry reported by SDK.\n- Recommended Skills: C# (or any other major language)\n- Mentor(s): Sergey Kanzhelev (@SergeyKanzhelev)\n\n#### OpenTelemetry libraries compatibility tests\n\n- Description: OpenTelemetry project has a unique challenge - it implements similar patterns for data collection on many languages. Building a framework and a set of libraries compatibility tests is a great way to ensure the best experience for end users. Need to know one or more programming languages. Specified C# which I maintain, but happy to mentor on other languages.\n- Recommended Skills: C# (or any other major language)\n- Mentor(s): Sergey Kanzhelev (@SergeyKanzhelev)\n\n### Prometheus\n\n#### Persist Retroactive Rule Reevaluations\n\n-\tDescription: Right now one of the biggest issues with recording rules is that data is only available since the rule was created. Which means any dashboards that use the recording rule will not have data prior to the recording rules create time. We can already reevaluate queries on old data, but we should be able to persist that for a certain window from [Oldest, Now).\n-\tRecommended Skills: Golang\n-\tMentor(s): Ganesh Vernekar (@codesome)\n-\tIssue: https://github.com/prometheus/prometheus/issues/11.\n\n#### Rule formatting tool\n\n-\tDescription: Like \"gofmt\" for Go, we ought to have a \"promfmt\" functionality for Prometheus since we have a syntax tree. The idea being that the system produces uniform style PromQL expressions and rule files that minimizes deviation and learning curve. Care should be taken to preserve comments.\n-\tRecommended Skills: Golang\n-\tMentor(s): Ganesh Vernekar (@codesome), Tobias Guggenmos (@slrtbtfs)\n-\tIssue: https://github.com/prometheus/prometheus/issues/21.\n\n#### Allow running prombench locally\n-\tDescription: Currently prombench development requires the user to setup GKE environment. Having prombench to run in a local k8s cluster would make adding changes much easier and faster. Support for kubeconfig and a proper way to switch local and GKE environment is not available yet. Adding these features will be essential to the completion of the project.\n-\tRecommended Skills: CI, Golang, Kubernetes\n-\tMentor(s): Hrishikesh Barman (@geekodour)\n-\tIssue: https://github.com/prometheus/test-infra/issues/333.\n\n#### Allow running prombench on EKS\n-\tDescription: Currently prombench benchmarking infrastructure runs on GKE. It'll be good to have it run on EKS as well if we need to migrate away from GKE, that'll be very useful. This is similar to [#333](https://github.com/prometheus/test-infra/issues/333) and could possibly be worked on together.\n-\tRecommended Skills: CI, Golang, Kubernetes\n-\tMentor(s): Hrishikesh Barman (@geekodour)\n-\tIssue: https://github.com/prometheus/test-infra/issues/341.\n\n#### Update Grafana dashboards for test-infra\n-\tDescription: The test-infra dashboards available at [prombench.prometheus.io/grafana](http://prombench.prometheus.io/grafana/) could be improved on different aspects, some of it will require understanding prometheus metrics and make the dashboards more useful to catch bugs during the bench tests. There are various high and low priority issues to work on.\n-\tRecommended Skills: CI, Golang, Grafana, Kubernetes, Prometheus\n-\tMentor(s): Hrishikesh Barman (@geekodour)\n-\tIssue: https://github.com/prometheus/test-infra/issues/328.\n\n### in-toto\n\n#### Port runlib into in-toto golang\n\n-\tDescription: The in-toto golang implementation is missing parts of the\n runlib library (the runtime library to capture evidence of a running\n process). Port the missing implementation parts from either the Python or\n the Java implementations.\n-\tRecommended Skills: Golang\n-\tMentor(s): Santiago Torres-Arias (@santiagotorres), Lukas Puehringer (@lukpueh), Justin Cappos (@JustinCappos)\n-\tIssue: https://github.com/in-toto/in-toto-golang/issues/30\n\n#### Port verify into in-toto Java\n\n-\tDescription: The in-toto java implementation (as used by the Jenkins\n plugin), is missing methods to provide a full `verify()` function. Implement\n those, based off of either the golang or python implementations\n-\tRecommended Skills: Java\n-\tMentor(s): Santiago Torres-Arias (@santiagotorres), Lukas Puehringer (@lukpueh), Justin Cappos (@JustinCappos)\n-\tIssue: https://github.com/in-toto/in-toto-java/issues/17\n\n#### Add metadata pretty print function\n\n-\tDescription: in-toto could use a method/tool to provide custom-formatting\n and display of metadata to ease integration with third-party tools or to\n ease human-readability\n-\tRecommended Skills: Python\n-\tMentor(s): Santiago Torres-Arias (@santiagotorres), Lukas Puehringer (@lukpueh), Justin Cappos (@JustinCappos)\n-\tIssue: https://github.com/in-toto/in-toto/issues/18\n\n### TUF\n\n#### Reinstate full protection against slow retrieval attacks\n\n-\tDescription: The current python implementation removed protection for\n slow-retrieval attacks, due to python-lock management, requests and urllib.\n Provie a possibly async-io based replacement to handle timeout on slow\n retrieval attacks\n-\tRecommended Skills: python, async-io (preferred, but not necessary)\n-\tMentor(s): Santiago Torres-Arias (@santiagotorres), Lukas Puehringer (@lukpueh), Trishank Karthik Kuppusamy (@trishankatdatadog), Justin Cappos (@JustinCappos)\n-\tIssue: https://github.com/theupdateframework/tuf/issues/932\n\n#### Improve delegation graph management code\n\n-\tDescription: The reference implementation continues to try to provide a\n 1-to-1 mapping of roles to\n keyids-the-role-should-be-signed-by-in-order-to-be-valid. This is not\n correct: the same role may need to be validated expecting different sets of\n keys, based on how the role was reached in the depth-first search while\n looking for target information.\n-\tRecommended Skills: python\n-\tMentor(s): Santiago Torres-Arias (@santiagotorres), Lukas Puehringer (@lukpueh), Trishank Karthik Kuppusamy (@trishankatdatadog), Justin Cappos (@JustinCappos)\n-\tIssue: https://github.com/theupdateframework/tuf/issues/660\n\n### CoreDNS\n\n#### Anomaly detection of CoreDNS server through machine learning\n\n- Description: As a DNS server, CoreDNS is critical to overall devops infrastructure. Any anomaly related to CoreDNS server should be taken seriously. While altering rules (combined with monitoring tools such as Prometheus) helps in discovering issues, those rules are often crafted manually and requires human expertise. It would help a lot if machine learning could be utilized to further automate the monitoring/alerting in case of anomaly.\n This project intends to build and train a model that could be used for anomaly detection of CoreDNS server through metrics collected from Prometheus. Since the metrics pipeline to Prometheus is already available in CoreDNS, the project’s focus is mostly on model building. It is suggested to use tf.keras to build the model. A successful model should at least be able to detect a scenario that is alerting and requires further devops or security intervention.\n- Recommended Skills: DNS/CoreDNS, Prometheus, Keras/TensorFlow, Python\n- Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)\n- Issue: https://github.com/coredns/coredns/issues/3658\n\n\n\n#### External health check and orchestration of CoreDNS in Kubernetes clusters\n\n- Description: CoreDNS is the cluster DNS server for Kubernetes and is very much critical for the overall health of the Kubernetes cluster. It is very important to monitoring the health of CoreDNS itself and restarting or repairing any CoreDNS pods that are not behaving correctly. While CoreDNS exposes a health check itself, the health check is not UDP (DNS) based. The existing health check is also launched locally which could be very much different when accessed by other pods remotely.\n This project intends to build an application that checks CoreDNS health through UDP (DNS) externally, and, restart CoreDNS pods by interacting with Kubernetes API through golang. This is an important project that will greatly improve the overall health of Kubernetes clusters through automation.\n- Recommended Skills: Go, DNS, Kubernetes\n- Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)\n- Issue: https://github.com/coredns/coredns/issues/3658\n\n\n### Open Policy Agent (OPA)\n\nOPA is a domain-agnostic policy engine that embodies \"policy as code\": https://www.openpolicyagent.org/\n\n#### IntelliJ plugin to experiment with and visualize policy evaluation\n\n- Description: OPA features a high-level declarative language that lets you express policies like \"user X can perform operation Y on resource Z\" or \"all images deployed in Kubernetes must come from an internal registry and be scanned for vulnerabilities\". The language supports many features: unit testing, dry running, tracing, etc. While users can access these features via the command-line, IDE integrations greatly improve the policy authoring experience. The idea is to port functionality that we have inside of [VS Code](https://github.com/tsandall/vscode-opa) to IntelliJ. This would significantly improve the authoring experience for people that use IntelliJ on a day-to-day basis.\n- Recommended Skills: Java, IntelliJ (not required, but nice to have)\n- Mentor(s): Asad Ali (@asadali)\n- Issue: https://github.com/open-policy-agent/opa/issues/1085\n\n#### OPA - MongoDB query translator\n\n- Description: MongoDB is a general-purpose, document-based, distributed database with a rich query language. OPA features a high-level declarative language called `Rego` purpose-built for expressing policies over complex hierarchical data structures. OPA is often used to enforce policies over incoming API requests, but using OPA's \"partial evaluation\" feature it is also possible to enforce policies when data is accessed inside of document-oriented databases like MongoDB. In this model, callers query OPA to obtain a set of conditions to apply to the database query and then rewrite the database query accordingly. There are existing projects that translate \"partial evaluation\" results to SQL and Elasticsearch. This project would involve designing and implementing a Rego to MongoDB query translator that supports basic relational operations like ==, !=, >, <, etc. This project would hugely benefit the community to perform authorization and data-filtering in MongoDB using OPA.\n- Recommended Skills: Go/Python, MongoDB (not required, but nice to have)\n- Mentor(s): Ash Narkar (@ashutosh-narkar)\n- Issue: https://github.com/open-policy-agent/opa/issues/2059\n\n### Virtual Kubelet\n\n#### Enhance Volcano scheduler to support Virtual Kubelet\n\n- Description: When there're not enough resources in one cluster, virtual kubelet is one of solutions to scale out cluster.\n It's better to enhance scheduler to balance resource in cluster and virtual kubelet. It's also a good example to the other\n scheduler on how to integrate with Virtual Kubelet.\n- Recommended Skills: Go, Kubernetes, Virtual Kubelet, Volcano\n- Mentor(s): Klaus Ma (@k82cn)\n- Issue: https://github.com/volcano-sh/volcano/issues/624 , https://github.com/virtual-kubelet/virtual-kubelet/issues/812\n\n### Vitess\n\n#### Native Failover without Orchestrator\n\n- Description: Currently Vitess relies on [Orchestrator](https://github.com/openark/orchestrator) to provide automated failover. While the functionality provided meets user expectations, it increases the complexity of [getting started](https://vitess.io/docs/user-guides/integration-with-orchestrator/) and operating Vitess. We see benefit in having a native implementation.\n- Recommended Skills: golang, mysql\n- Mentor(s): Anthony Yeh (@enisoc)\n- Issue: https://github.com/vitessio/vitess/issues/2366\n\n#### Support for collations in VTGate\n\n- Description: Currently the Vitess router (vtgate) does not support MySQL collations. This makes it difficult to push down queries that have constraints, ordering or grouping requirements on types that support character sets (i.e. varchar, char, text).\n- Recommended Skills: golang, mysql\n- Mentor(s): Morgan Tocker (@morgo)\n- Issue: https://github.com/vitessio/vitess/issues/3591\n\n### Cloud Native Buildpacks\n\n#### Build Process Instrumentation\n\n- Description: Provide better insight into the events that occur during the build process. This would include event output, outcomes of various commands, performance tracking. This is geared less towards user facing output and more towards generating consumable data.\n- Recommended Skills: Go\n- Mentor(s): Javier Romero (@jromero)\n- Issue: https://github.com/buildpacks/lifecycle/issues/265\n\n#### CI/CD Proof of Concepts\n\n- Description: Cloud Native Buildpacks' primary function is to turn source code into a runnable image and because of that it's natural for it to be used within various CI/CD platform pipelines. Let's create some proof-of-concept integrations with various CI/CD platforms. Some of the integrations would be adopted by the CNB project. Others could yield samples or documentation depending on the outcome.\n- Recommended Skills: Go, Docker\n- Mentor(s): Javier Romero (@jromero)\n- Issue: https://github.com/buildpacks/pack/issues/515\n\n#### Client Side Buildpack Registry\n\n- Description: The Buildpack Registry is a place to publish, store, and discover buildpacks. The initial implementation is a client side with minimal server-side support. The first pass will include setting up the GitHub repo and adding the relevant commands in the CLI.\n- Recommended Skills: Go, Docker\n- Mentor(s): Javier Romero (@jromero), Joe Kutner (@codefinger), Terence Lee (@hone)\n- Issue: https://github.com/buildpacks/rfcs/blob/master/text/0022-client-side-buildpack-registry.md\n\n#### Isolate Registry Credentials from Builder Images\n\n- Description: pack is a CLI for doing builds with Cloud Native Buildpacks. It uses builder images to create all lifecycle phase containers. When pack build is run with the --publish flag, the user's registry credentials are injected into the analyze and export containers as environment variables. This means that users must place a high level of trust in their selected builder image. Users may not realize that credentials are given to builder images and experiment with builders from untrusted vendors. This change isolates analyze, restore, and export phases in containers built from trusted images rather than the builder image.\n- Recommended Skills: Go, Docker\n- Mentor(s): Javier Romero (@jromero), Emily Casey (@ekcasey)\n- Issue: https://github.com/buildpacks/rfcs/blob/master/text/0025-dont-trust-builders.md\n\n#### Lifecycle Transparency\n\n- Description: Cloud Native Buildpacks are magic! Magic is great, but sometimes users want to better understand what is going on under the hood. Redesign the lifecycle output to demystify the build process for users. This will require some creativity.\n- Recommended Skills: Go\n- Mentor(s): Javier Romero (@jromero), Emily Casey (@ekcasey), Stephen Levine (@sclevine)\n- Issue: https://github.com/buildpacks/lifecycle/issues/264\n\n### OpenEBS\n\n#### kubectl plugin for OpenEBS\n\n- Description: OpenEBS is completely Kubernetes native and is implemented using microservices. The microservices are deployed as Kubernetes deployments, statefulset or daemon sets and so forth. In order to know the status of the components - like OpenEBS control plane or a given OpenEBS volume, a user may have to multiple kubectl commands to get the required information. To improve the usability, the proposal is to have a kubectl plugin for OpenEBS can provide a simple CLI to perform common operations.\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Kiran Mova (@kmova), Amit Kumar Das (@AmitKumarDas)\n- Issue: https://github.com/openebs/openebs/issues/2946, https://github.com/openebs/openebs/issues/290\n\n#### Grafana dashboards for OpenEBS\n- Description: All the openebs components are deployed as Kubernetes native objects and support scraping of metrics via Prometheus. This is a feature request to implement Grafana dashboards for: overall status, volume and pool usage.\n- Recommended Skills: Prometheus, Grafana\n- Mentor(s): Kiran Mova (@kmova)\n- Issue: https://github.com/openebs/openebs/issues/2947\n\n#### Improve the release management process for OpenEBS\n- Description: OpenEBS uses microservices architecture pattern and its components are developed in different GitHub repositories. Tagging the repository with a new release, will trigger a build process on Travis CI and new version of the component is built and pushed to container registeries. There is certain order/dependency in which the components are released, and requires release tagging the components to happen in a specified order. It would be nice to automate this process by making use of web hooks on docker, travis and github or there could be a better alternative that needs to be explored.\n- Recommended Skills: Build and Release Management, Makefiles, GitHub, Travis\n- Mentor(s): Kiran Mova (@kmova)\n- Issue: https://github.com/openebs/openebs/issues/288\n\n### Rook\n#### Rewrite NFS Operator to use controller runtime and fix other open issues along with it.\n\n- Description: Convert the [NFS controller](https://github.com/rook/rook/blob/master/pkg/operator/nfs/controller.go) to be managed with the controller-runtime.\n Currently Rook only has a simple watch in an informer as seen [here](https://github.com/rook/rook/blob/master/pkg/operator/k8sutil/customresource.go#L54).\n What is use case behind this feature ?\n - The controller runtime will improve reliability of the operator in several areas:\n - Events can be re-queued if failed or the operator is not able to complete the operation\n - Exponential backoff is provided automatically for re-queued events\n - Waiting for the next event does not need to block on the current event if it is taking a long time and the event can be re-queued.\n Several controllers in Rook are using the controller runtime. For examples, see the [pool controller](https://github.com/rook/rook/blob/master/pkg/operator/ceph/pool/controller.go) or [disruption budget controller](https://github.com/rook/rook/blob/master/pkg/operator/ceph/disruption/clusterdisruption/reconcile.go).\n Also other open NFS Operator issues can be easily addressed while rewriting the operator.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Ashish Ranjan(@ashishranjan738), Jared Watts(@jbw976), Rohan Gupta(@rohan47)\n- Issues:\n - https://github.com/rook/rook/issues/4950\n - https://github.com/rook/rook/issues/4259\n - https://github.com/rook/rook/issues/2721\n - https://github.com/rook/rook/issues/3073\n - https://github.com/rook/rook/issues/3074\n\n### Service Mesh Interface (SMI)\n#### Conformance Tool\n\n - Description: Ensure that a service mesh is properly configured and that its behavior\n conforms to official SMI specifications. Conformance consists of both capabilities\n and compliance status as outlined in the design specification. Use Meshery as the\n underlying technology to support SMI validation.\n - Recommended Skills: Golang, Kubernetes\n - Mentor(s): Lee Calcote (@lcalcote), Sagar Utekar (@named_uttu)\n-- Issues: [https://github.com/servicemeshinterface/smi-spec/issues/70](https://github.com/servicemeshinterface/smi-spec/issues/70)\n - Design Spec: [https://docs.google.com/document/d/1HL8Sk7NSLLj-9PRqoHYVIGyU6fZxUQFotrxbmfFtjwc/edit#](https://docs.google.com/document/d/1HL8Sk7NSLLj-9PRqoHYVIGyU6fZxUQFotrxbmfFtjwc/edit#)\n\n\n### Envoy\n#### Distributed Load Testing of Envoy Data Planes\n- Description: Many performance benchmarks are limited to single instance load generation\n (single pod load generator). This limits the amount of traffic that can be generated to output of the single machine that the benchmark tool runs on in or out of a cluster. Overcoming this limitation would allow for more flexible and robust testing. Distributed load testing in parallel poses a challenge when merging results without losing the precision we need to gain insight into the high tail percentiles.\n- Recommended Skill(s): Golang, Kubernetes\n- Issue(s): https://github.com/envoyproxy/envoy-perf/issues/72\n- Mentor(s): Lee Calcote (@lcalcote), Prateek Sahu (@PrateekSahu22), Shivay Lamba (@howdevelop)\n\n### Linkerd\n\n#### Egress Metrics\n\n-\tDescription: Linkerd provides rich metrics for traffic inside the mesh. As most external services utilize HTTPS, it is unable to provide metrics today. This project intends to provide visibility into the traffic that is leaving clusters and surface metrics for that traffic.\n-\tRecommended Skills: golang, Kubernetes\n-\tMentor(s): Thomas Rampelberg (@grampelberg)\n-\tIssue:\n\t- https://github.com/linkerd/linkerd2/issues/3190\n\n#### Service Topologies\n\n- Description: It is valuable to have metadata related to the topology of a cluster when making load balancing decisions. This metadata can be used to control egress costs between regions or even make advanced routing decisions in multicluster situations. As part of Kubernetes 1.17, [service topology](https://kubernetes.io/docs/concepts/services-networking/service-topology/) landed. This provides extra metadata as part of endpoints for a service to control weighting. Imagine transparently failing over to nodes running in a different zone if the pods locally are no longer running. Linkerd should implement support for this functionality.\n- Recommended Skills: golang, Kubernetes, rust, Tokio\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/4325\n\n#### PCAP-NG Export\n\n- Description: It is difficult to debug what is happening to the network traffic for workloads on Kubernetes. Linkerd provides tap and stat to provide some glimpses into what's happening. Many times, this is enough. Unfortunately, when low level problems and protocol issues crop up, the existing tools are not enough. This causes users to inject the debug container and tcpdump traffic on a pod by pod basis. This project will add PCAP-NG as an export format for tap. This can then be dumped locally or forwarded to Wireshark for analysis and debugging.\n- Recommended Skills: golang, Kubernetes, rust, Tokio\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/4326\n\n#### Granular RBAC for Metrics\n\n- Description: Kubernetes is a multitenant system, many users can interact without seeing what others are working with. Today, Linkerd runs a single control plane per cluster. This results in the metrics collected being stored in a single backend (Prometheus). In some high security environments, this means that the users of the cluster are unable to get the benefit of Linkerd's rich metrics. This project will introduce Kubernetes based, granular RBAC so that cluster operators can control what end users are able to view.\n- Recommended Skills: golang, Kubernetes, Prometheus\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/3312\n\n#### Kafka Proxy Codec\n\n- Description: HTTP based traffic is only one type of modern applications. Many use message queues such as Kafka. Getting the metrics for consumers/producers/messages are just as critical to application health as requests and responses in HTTP. This project will implement a Kafka codec that allows the Linkerd proxy to introspect Kafka's protocol and provide metrics for the communications between consumers and producers. This should show up as a CLI command, dashboard and visualization of the topology between message consumers and HTTP actors.\n- Recommended Skills: golang, Kubernetes, rust, Tokio, Kafka\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/2214\n\n#### JWT Authentication\n\n- Description: Linkerd implements service-service authentication today via. mTLS. This does not yet extend to user based authentication. This project will implement JWT authentication to provide applications using the service mesh a method for implementing authorization on a per-user basis.\n- Recommended Skills: golang, Kubernetes, rust, Tokio\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/3704\n\n#### Network Diagnostics\n\n- Description: It can be challenging to diagnose why things aren't working in a remote cluster. Is there a connectivity issue? What happens when a specific request is sent to a service? How do I work with the data that comes back? Linkerd should make this kind of interaction with a cluster's traffic easy and seamless. This project introduces a new command to the CLI: `exec`. This will wire up the networking locally for a user where local binaries (such as curl or ping) can interact with a Kubernetes cluster natively. It will use local binaries and produce local output to allow users to use their local tools and files to diagnose what's going on with their cluster.\n- Recommended Skills: golang, Kubernetes\n- Mentor(s): Thomas Rampelberg (@grampelberg)\n- Issue:\n - https://github.com/linkerd/linkerd2/issues/4327\n" }, { "path": "programs/summerofcode/2021.md", "content": "- [Project Ideas](#project-ideas)\n - [Kubernetes](#kubernetes)\n - [Cluster Addons: CRI-based CSI Volume Image Driver](#cluster-addons-cri-based-csi-volume-image-driver)\n - [Web-based Simulator for the Kubernetes Scheduler](#web-based-simulator-for-the-kubernetes-scheduler)\n - [Strimzi](#strimzi)\n - [Add support for changing a KafkaTopic's `replicationFactor`](#add-support-for-changing-a-kafkatopics-replicationfactor)\n - [TiKV](#tikv)\n - [TLA+ Specification for async commit](#tla-specification-for-async-commit)\n - [High-performance data import tool](#high-performance-data-import-tool)\n - [CoreDNS](#coredns)\n - [Add ACME protocol support for certificate management with DNS](#add-acme-protocol-support-for-certificate-management-with-dns)\n - [Keptn](#keptn)\n - [Provide a hub for Keptn integrations, extensions & services](#provide-a-hub-for-keptn-integrations-extensions--services)\n - [Tremor](#tremor)\n - [Add plugin support for tremor (PDK)](#add-plugin-support-for-tremor-pdk)\n - [Add gRPC client and server support to tremor](#add-grpc-client-and-server-support-to-tremor)\n - [cert-manager](#cert-manager)\n - [Improve the usability of cert-manager on multiple cloud providers](#improve-the-usability-of-cert-manager-on-multiple-cloud-providers)\n - [`kubectl cert-manager install`: A CLI plugin to make it easy to install and verify the installation of cert-manager](#kubectl-cert-manager-install-a-cli-plugin-to-make-it-easy-to-install-and-verify-the-installation-of-cert-manager)\n - [LitmusChaos](#litmuschaos)\n - [Rewrite litmus portal authentication server and add third-party integration of Gmail and Github.](#rewrite-litmus-portal-authentication-server-and-add-third-party-integration-of-gmail-and-github)\n - [Envoy](#envoy)\n - [Adaptive Load Control and Distributed Load Testing of Envoy Data Planes](#adaptive-load-control-and-distributed-load-testing-of-envoy-data-planes)\n - [Open Service Mesh](#open-service-mesh)\n - [Support for WebAssembly filters](#support-for-webassembly-filters)\n - [Service Mesh Interface](#service-mesh-interface)\n - [Support for Multi-Cluster Operations](#support-for-multi-cluster-operations)\n - [OpenEBS](#openebs)\n - [Add support for updating mountpoints and capacity of devices using dmesg parser](#add-support-for-updating-mountpoints-and-capacity-of-devices-using-dmesg-parser)\n - [Prometheus](#prometheus)\n - [Implement configurable retention time for Prometheus series](#implement-configurable-retention-time-for-prometheus-series)\n - [Port the Prometheus API to OpenAPI](#port-the-prometheus-api-to-openapi)\n - [Thanos](#thanos)\n - [Smart automation for project documentation and website](#smart-automation-for-project-documentation-and-website)\n - [Automated, Granular TLS client support in Thanos](#automated-granular-tls-client-support-in-thanos)\n - [Crossplane](#crossplane)\n - [Upgrade OAM Implementation in Crossplane to Latest Release of Spec](#upgrade-oam-implementation-in-crossplane-to-latest-release-of-spec)\n - [Cloud Native Buildpacks](#cloud-native-buildpacks)\n - [Buildpack Registry Github Action Updates](#buildpack-registry-github-action-updates)\n - [Jenkins Plugin](#jenkins-plugin)\n - [Lifecycle Prepare Phase](#lifecycle-prepare-phase)\n - [in-toto](#in-toto)\n - [Develop in-toto-rs (Rust) for integration with rebuilderd](#develop-in-toto-rs-rust-for-integration-with-rebuilderd)\n - [Add support for new signature specification, complying with ITE-5](#add-support-for-new-signature-specification-complying-with-ite-5)\n - [TUF](#tuf)\n - [Hashed bin delegations](#hashed-bin-delegations)\n - [Pravega](#pravega)\n - [Dynamic Auto-scaling](#dynamic-auto-scaling)\n - [Write logs to Pravega, log4j appender or syslog listener](#write-logs-to-pravega)\n - [SLTS ChunkStorage for GPC or Azure](#slts-chunkstorage-implementations)\n\n## Project Ideas\n\nIf you are a project maintainer and consider mentoring during the GSoC 2021 cycle, please, submit your ideas below using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n### Kubernetes\n\n#### Cluster Addons: CRI-based CSI Volume Image Driver\n\n- Description: The [csi-driver-image-populator](https://github.com/kubernetes-csi/csi-driver-image-populator) is a CSI plugin that allows you to mount the contents of a container image as a volume in a container, but it does not use the node's CRI endpoint to pull images. This means that images pulled as volumes will have different configuration (proxy, auth, mirror, etc) from other images run a cluster. A version of of the csi-driver-image-populator that uses a node's CRI provider to pull images would avoid that problem and make it simpler to build on-cluster tooling that makes use of [manifest bundles](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/addons/2494-Manifest-Bundle). It may also be worth looking at the CSI / CRI interfaces to see if improvements can be made to simplify the driver, or to enable the use of [OCI artifacts](https://github.com/opencontainers/artifacts).\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Evan Cordell (@ecordell)\n- Issue: https://github.com/kubernetes-sigs/cluster-addons/issues/100\n\n#### Web-based Simulator for the Kubernetes Scheduler\n\n- Description: [Kubernetes](https://k8s.io) (k8s) is a production-grade container-orchestration system. The [k8s scheduler](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/) decides which pods (containers) should go to which machines to be run. Not everyone has a running cluster lying around, so a web-based simulator that simulates the scheduler's behavior serves as an excellent interactive learning tool.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Adhityaa Chandrasekar (@adtac)\n- Issue(s): https://github.com/kubernetes/kubernetes/issues/99605\n\n### Strimzi\n\n#### Add support for changing a KafkaTopic's `replicationFactor`\n\n- The [Strimzi](https://strimzi.io) project provides an easy way of running Apache Kafka on Kubernetes. It uses KafkaTopic custom resources to provide a cloud-native way of managing topics in a Kafka cluster. Strimzi also uses [Cruise Control](https://github.com/linkedin/cruise-control) to provide Kafka cluster balancing functions. This project would add support for changing a KafkaTopic’s replicationFactor property by using Cruise Control.\n- Recommended Skills: Java\n- Mentor(s): Tom Bentley (@tombentley), Tom Cooper (@tomncooper)\n- Issue: https://github.com/strimzi/strimzi-kafka-operator/issues/191\n\n### TiKV\n\n#### TLA+ Specification for async commit\n\n- [TiKV](https://github.com/tikv/tikv) has recently been launching a new feature in the transaction model named [Async commit](https://github.com/tikv/sig-transaction/tree/master/design/async-commit). It's an optimization that reduces the commit latency from 2PC to 1PC. However, this feature has not been reflected in the [TLA+ Specs](https://github.com/pingcap/tla-plus/tree/master/DistributedTransaction). This project aims to update the spec and to run TLC model checker on the new model to gain more confidence in the async commit design.\n- Recommended Skills: Go, Rust, TLA+\n- Mentor(s): Ziqian Qin (@ekexium), Andy Lok (@andylokandy)\n- Issue: https://github.com/tikv/sig-transaction/issues/97\n\n#### High-performance data import tool\n\n- [TiKV](https://github.com/tikv/tikv) currently lacks a robust tool to import great amount of data. But, in fact, TiKV has implemented [`sst_importer`](https://github.com/pingcap/kvproto/blob/3cd2fc5fad226caeffed72297e3e13a571f5592e/proto/import_sstpb.proto#L34) to fast import SQL data to TiDB by [`Lightning`](https://github.com/pingcap/br) tool. `Lightning` imports SQL data in two steps: translating SQL data in KV pairs and importing KV pairs into TiKV. By exposing the second steps, we can support importing KV-like data into TiKV, e.g. migrating from HBase to TiKV.\n- Recommended Skills: Go\n- Mentor(s): Kenny (@kennytm), Andy Lok (@andylokandy)\n- Issue: https://github.com/tikv/tikv/issues/9778\n\n### CoreDNS\n\n#### Add ACME protocol support for certificate management with DNS\n\n- [CoreDNS](https://github.com/coredns/coredns) is a cloud-native DNS server with a focus on service discovery. While best known as the default DNS server for Kubernetes, CoreDNS is capable of handle many other scenarios within or outside of Kubernetes clusters for make easy infrastructure management. One such case is the certificate management. This project is to provide ACME protocol support so that it is possible to have automatic certificate management through CoreDNS. More details and discussions are available in https://github.com/coredns/coredns/issues/3460.\n- Recommended Skills: Golang, DNS, TLS, Certificate Management\n- Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)\n- Issue: https://github.com/coredns/coredns/issues/3460\n\n### Keptn\n\n#### Provide a hub for Keptn integrations, extensions & services\n\n- The [Keptn project](https://keptn.sh) is a cloud-native application life-cycle orchestrator, acting as a control-plane for different tools for deploying, testing, etc of your applications. Currently, Keptn services and integrations can be found on an overview page. While this served fine as a central overview of all currently supported integrations, a more sophisticated \"integrations hub\" is desired.\n- Recommended Skills: Angular/TypeScript\n- Mentor(s): Juergen Etzlstorfer (@jetzlstorfer)\n- Issue: https://github.com/keptn/keptn/issues/3406\n\n### Tremor\n\n#### Add plugin support for tremor (PDK)\n\n- Description: The PDK or (plugin development kit) aims to allow loading artifacts into tremor at runtime instead of requiring a full recompilation. This streamlines the development process of extending tremor with custom functionality. The goal is to allow live loading of a number of artifacts so start with: Pipeline Operators, Codecs, Pre- and Postprocessors, Custom Functions.\n- Recommended Skills: rust, Linux\n- Mentor(s): Darach Ennis (@darach), Matthias Wahl (@mfelsche)\n- Issue: https://github.com/tremor-rs/tremor-runtime/issues/791\n\n#### Add gRPC client and server support to tremor\n\n- Description: gRPC is an industry-standard API abstraction and runtime. Currently, tremor supports interfacing with the outside world over WebSockets, HTTP/1.1, or target-specific connectors. Adding support for gRPC will allow generalizing a whole lot of client and server connections and making interfacing with other cloud-native applications easier. The goal of this project is to add support for such generic gRPC based services.\n- Recommended Skills: rust, Linux, http/2, protocol buffers\n- Mentor(s): Heinz Gies (@Licenser), Anup Dhamala (@anupdhml)\n- Issue: https://github.com/tremor-rs/tremor-runtime/issues/790\n\n### cert-manager\n\n#### Improve the usability of cert-manager on multiple cloud providers\n\n- [cert-manager](https://cert-manager.io) is one of the most popular Kubernetes addons. It introduces Certificate Authorities and Certificates as custom resource types in the Kubernetes API, and enables automatically managed certificate rotation. While the most common use is publicly trusted ACME certificates for Ingress controllers, it can also be used to manage identites in service meshes such as Istio. The project is to improve the user experience of deploying cert-manager on different cloud providers, helping to diagnose, fix and recommend workarounds for any discovered issues.\n- Recommended Skills: Golang, Infrastructure as Code\n- Mentors: Jake Sanders (@jakexks), team-cert-manager@Jetstack\n- Issue: https://github.com/jetstack/cert-manager/issues/3720\n\n#### `kubectl cert-manager install`: A CLI plugin to make it easy to install and verify the installation of cert-manager\n\n- Description: cert-manager can be [installed using Helm or with regular Kubernetes manifests](https://cert-manager.io/docs/installation/),\n but when using regular manifests it is difficult to customize the deployment.\n This CLI will make it easier for non-Helm users to customize the configuration of cert-manager,\n it will provide a way to see all the configuration options for a cert-manager deployment from the command line\n (i.e. by running kubectl cert-manager install --help).\n It will provide an option to wait for and verify the deployment, perhaps by integrating the code of [cert-manager-verifier](https://github.com/alenkacz/cert-manager-verifier).\n And it may become the foundation of a future `kubectl cert-manager upgrade` command, which will help users safely upgrade and downgrade between cert-manager versions.\n- Recommended Skills: Golang, Kubernetes\n- Mentors: team-cert-manager@Jetstack\n- Issue: https://github.com/jetstack/cert-manager/issues/3783\n\n### LitmusChaos\n\n#### Rewrite litmus portal authentication server and add third-party integration of Gmail and Github.\n\n- [LitmusChaos](https://litmuschaos.io) is a Kubernetes native chaos engineering framework that helps SREs & developers find weaknesses in their deployments, with the chaos intent being defined via custom resources. The goal of this project is to rewrite the authentication server to make it modular and lightweight. Also, add third-party integration of Gmail and Github.\n- Recommended Skills: Golang, Kubernetes, MongoDB.\n- Mentors: Karthik Satchitanand (@ksatchit), Raj Babu Das (@rajdas98)\n- Issue: https://github.com/litmuschaos/litmus/issues/2483\n\n### Envoy\n\n#### Adaptive Load Control and Distributed Load Testing of Envoy Data Planes\n\n- Description: Users configuring their Envoy-based data planes don't know how to find the optimal Envoy configuration given their workload's resiliency and performance requirements. Nighthawk, Envoy's load generator, supports adaptive load control and horizontally distributed scaling of itself. Using distributed load testing and the creation of a set of adaptive load controllers, Envoy users can be empowered with repeatable tooling to automate identification of an optimal Envoy data plane configuration.\n- Recommended Skill(s): Golang, C++, Rust\n- Issue(s): https://github.com/envoyproxy/envoy-perf/issues/72\n- Mentor(s): Lee Calcote (@lcalcote), Otto van der Schaaf (@oschaaf)\n\n### Open Service Mesh\n\n##### Support for WebAssembly filters\n\n- Description: Bring OSM on par with other service meshes that support WASM filters in their data plane. OSM's Envoy proxies can be extended at runtime with filters that are running in a WebAssembly sandbox (https://github.com/envoyproxy/envoy-wasm). Provide ability to dynamically load and unload Envoy WASM filters. Provide general purpose filtering of application infrastrcuture logic, tying business logic closer to the mesh.\n- Recommended Skills: golang, rust\n- Mentor(s): Lee Calcote (@leecalcote), Abishek Kumar (@kumarabd)\n- Upstream Issue (URL): https://github.com/openservicemesh/osm/issues/1671\n\n### Service Mesh Interface\n\n##### Support for Multi-Cluster Operations\n\n- Description: Facilitate federation service mesh deployments across Kubernetes clusters, considering for service catalog federation and\n identity federation. Account for 1) multiple Kubernetes clusters using the same service mesh, 2) hetrogenius workloads (Kubernetes, VMs, Bare metal) using the same service mesh, 3) multiple Kubernetes clusters using different service meshes (e.g. Istio and Linkerd), 4) heterogeneous workloads using different service meshes (e.g. Istio, Consul).\n- Recommended Skills: golang, kubernetes, meshery, smi\n- Mentor(s): Lee Calcote (@leecalcote), Abishek Kumar (@kumarabd)\n- Upstream Issue (URL): https://github.com/servicemeshinterface/smi-spec/issues/212\n\n### OpenEBS\n\n#### Add support for updating mountpoints and capacity of devices using dmesg parser\n\n- [OpenEBS](https://openebs.io/) is the leading Container Attached Storage solution. OpenEBS NDM exposes storage devices on the hosts as BlockDevice custom resources. The capacity and mountpoints of these devices can change dynamically on the host and openebs needs to update it in the custom resources, without doing a full reinitialization. The goal is to update this information by parsing dmesg and thus provide the latest information to the users.\n- Recommended Skills: Golang, Linux\n- Mentor(s): Akhil Mohan (@akhilerm)\n- Issue: https://github.com/openebs/openebs/issues/3135\n\n### Prometheus\n\n#### Implement configurable retention time for Prometheus series\n\n- Description: Currently, Prometheus data is deleted after a configurable amount of time, or once the disk size reaches a configured limit. However, many users would like to keep some data, such as the result of recording rules or SLO data, for a longer period of time than higher cardinality raw data. The goal of this project is to allow users to configure Prometheus to configure the retention time on a per series basis.\n- Recommended Skills: golang\n- Mentor(s): Chris Marchbanks (@csmarchbanks), Bartlomiej Plotka (@bwplotka)\n- Issue: https://github.com/prometheus/prometheus/issues/1381\n\n#### Port the Prometheus API to OpenAPI\n\n- Description: Prometheus offers rest API of all sorts but they are not well\n documented. The idea would be to use OpenAPI to have self-documentation and\n specification files to be used by third parties. This would enable the use of\n Prometheus API's with clients from any languages easily.\n- Recommended Skills: golang\n- Mentor(s): Julien Pivotto (@roidelapluie)\n- Issue: https://github.com/prometheus/prometheus/issues/2392\n\n### Thanos\n\n#### Smart automation for project documentation and website\n\n- Description: In Thanos we don’t like manual work. That’s why we try to automate as much as we can, ensuring our documentation is up to date, links are working and documentation works from both GitHub and Website. We want to consolidate our automation and scripts to separate projects called mdox, so it’s working more reliably and helping other projects too! This project is to finish that work and allows students to have a great impact in the project tooling community. NOTE: This is a documentation tooling project, not related strictly to Thanos/Prometheus distributed systems - it’s a great starting point for passionate person interested in working with Go and wanting a soft intro to Cloud Native project maintenance topics!\n- Recommended Skills: golang\n- Mentor(s): Bartlomiej Plotka (@bwplotka)\n- Issue: https://github.com/thanos-io/thanos/issues/3081\n\n#### Automated, Granular TLS client support in Thanos\n\n- Description: Thanos Querier component supports basic TLS configuration for internal gRPC communication. This works great for basic use cases but it still requires extra forward proxies to make it work for bigger deployments. It’s also hard to rotate certificates automatically and configure safe mTLS. This project aims to remove those simplifications allowing better TLS story for all Thanos metrics APIs!\n- Recommended Skills: go, distributed systems, TLS, gRPC\n- Mentor(s): Bartek Plotka (@bwplotka), Kemal Akkoyun (@kakkoyun)\n- Issue: https://github.com/thanos-io/thanos/issues/977\n\n### Crossplane\n\n#### Upgrade OAM Implementation in Crossplane to Latest Release of Spec\n\n- Description: [Crossplane](https://crossplane.io) is an open source Kubernetes add-on that supercharges your Kubernetes clusters enabling you to provision and manage infrastructure, services, and applications. Under the hood, it leverage Open Application Model to define and ship applications across clusters in an developer centric approach. Currently, the [implementation in Crossplane is OAM spec v0.2.1](https://github.com/crossplane/oam-kubernetes-runtime) and didn't fully reflect the latest release of upstream specification. This proposal will help Crossplane catch up with the latest change.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Ryan Zhang (@ryanzhang-oss), Sun Jianbo (@wonderflow)\n- Issue(s): https://github.com/crossplane/oam-kubernetes-runtime/issues/321\n\n### Cloud Native Buildpacks\n\n##### Buildpack Registry Github Action Updates\n\n- Description: This project would ensure that the [Buildpack Registry Index](https://github.com/buildpacks/registry-index/) and [Buildpack Registry Namespace](https://github.com/buildpacks/registry-namespaces/) repositories are updated with the latest [Github Actions](https://github.com/buildpacks/github-actions) version automatically after it is released.\n- Recommended Skills: Go, Github Actions\n- Mentor(s): Joe Kutner (@jkutner)\n- Upstream Issue (URL): https://github.com/buildpacks/github-actions/issues/40\n\n##### Jenkins Plugin\n\n- Description: Cloud Native Buildpacks' primary function is to turn source code into a runnable image and because of that it's natural for it to be used within common CI/CD platform pipelines. This project would focus on creating a pipeline plugin that makes it easy for users to use Cloud Native Buildpacks within [Jenkins](https://www.jenkins.io/).\n- Recommended Skills: Java, Docker\n- Mentor(s): Javier Romero (@jromero)\n- Upstream Issue (URL): https://github.com/buildpacks/pack/issues/531\n\n##### Lifecycle Prepare Phase\n\n- Description: A Lifecycle Prepare phase should make it easier for platforms to achieve parity with features of Pack. Today, features like [`project.toml`](https://buildpacks.io/docs/app-developer-guide/using-project-descriptor/) are only supported by Pack, and a new platform would need to write it’s own parser. This project would include design (writing an RFC), specification (updating the CNB spec), and implementation (writing the code for the phase in [Lifecycle](https://github.com/buildpacks/lifecycle)).\n- Recommended Skills: Go\n- Mentor(s): Joe Kutner (@jkutner), Natalie Arellano (@natalieparellano)\n- Upstream Issue (URL): https://github.com/buildpacks/lifecycle/issues/555\n\n### in-toto\n\n#### Develop in-toto-rs (Rust) for integration with rebuilderd\n\n- Description: [rebuilderd](https://github.com/kpcyrd/rebuilderd) is a verification system for binary packages. It repeats the build process of a package in an identical environment and verifies that the package is identical. It is part of the [Reproducible Builds](https://reproducible-builds.org/) effort and can currently be used to [rebuild Arch Linux packages](https://tests.reproducible-builds.org/archlinux/archlinux.html). The rebuild must optionally generate in-toto link attestations which can be used to verify the entire process. To that end, the nascent [in-toto-rs](https://github.com/in-toto/in-toto-rs) library must be developed to enable this integration with rebuilderd.\n- Recommended Skills: Rust\n- Mentor(s): Santiago Torres-Arias (@SantiagoTorres)\n- Upstream Issue (URL): https://github.com/in-toto/in-toto-rs/issues/4\n\n#### Add support for new signature specification, complying with ITE-5\n\n- Description: The in-toto team is working with the TUF project to replace the current signature wrapper used by both projects. This effort has resulted in the [signing-spec](https://github.com/secure-systems-lab/signing-spec). The new specification removes the current dependence on canonicalization and is open to encodings other than JSON. Further, moving the signature specification out helps the in-toto specification focus on its key goals, making it more readable. The switch to the new signature specification is proposed in an in-toto Enhancement, [ITE-5](https://github.com/in-toto/ITE/pull/13). The task at hand is adding support to the in-toto reference implementation for the new specification.\n- Recommended Skills: Python\n- Mentor(s): Santiago Torres-Arias (@SantiagoTorres), Aditya Sirish A Yelgundhalli (@adityasaky)\n- Upstream Issue (URL): https://github.com/in-toto/in-toto/issues/445 \n\n### TUF\n\n#### Hashed bin delegations\n\n- Description: The Update Framework (TUF) supports delegating responsibility for signing images. In order to support a large number of delegations, the [specification](https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#file-formats-targetsjson-and-delegated-target-roles--file-formats-targets) supports binning delegations based on their hash. This project would involve adding this feature to the [go implementation](https://github.com/theupdateframework/go-tuf) of TUF.\n- Recommended Skills: Go\n- Mentor(s): Marina Moore (@mnm678)\n- Upstream Issue (URL): https://github.com/theupdateframework/go-tuf/issues/45\n\n### Pravega\n\n#### Dynamic Auto-scaling\n\n- Description: Dynamic scaling of the Pravega Cluster by the [pravega-operator](https://github.com/pravega/pravega-operator) using [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). This should be simple to implement, and we've already done [a successful POC](https://github.com/pravega/pravega-operator/issues/131).\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Prajakta Belgundi (@pbelgundi)\n- Upstream Issue (URL): https://github.com/pravega/pravega-operator/issues/483\n\n### Write logs to Pravega\n\n- Description: Create a Log4j appender or syslog listener that will write application events to a Stream (record timestamps, event types, etc).\n- Recommended Skills: Java, Rust, Python, C#, a language with gRPC bindings\n- Mentor(s): Andrei Paduroiu (@andreipaduroiu)\n\n### SLTS ChunkStorage implementations\n\n- Description: [Simplified Long Term Storage](https://www.youtube.com/watch?v=Qyd1_t3c6LE) allows Pravega to use almost any storage API for Stream storage. Pravega has ChunkStorage implementations for [Extended S3 (ECS)](https://github.com/pravega/pravega/blob/master/bindings/src/main/java/io/pravega/storage/extendeds3/ExtendedS3ChunkStorage.java), [HDFS](https://github.com/pravega/pravega/blob/master/bindings/src/main/java/io/pravega/storage/hdfs/HDFSChunkStorage.java), [NFS](https://github.com/pravega/pravega/blob/master/bindings/src/main/java/io/pravega/storage/filesystem/FileSystemChunkStorage.java) and [BookKeeper/BlobIt](https://github.com/diegosalvi/pravega-blobit-chunkmanager). Write a [ChunkStorage](https://github.com/pravega/pravega/blob/master/segmentstore/storage/src/main/java/io/pravega/segmentstore/storage/chunklayer/ChunkStorage.java) implementation for GCP or Azure.\n- Recommended Skills: Java\n- Mentor(s): Sachin Joshi (@sachin-j-joshi)\n" }, { "path": "programs/summerofcode/2022.md", "content": "- [Project Ideas](#project-ideas)\n - [Argo](#argo)\n - [Memoization storage](#memoization-storage)\n - [UI plugins](#ui-plugins)\n - [Count-based enhanced depends logic](#count-based-enhanced-depends-logic)\n - [Buildpacks](#buildpacks)\n - [Standardize Cache Flag options](#standardize-cache-flag-options)\n - [Proof of concept for lifecycle registry only approach](#proof-of-concept-for-lifecycle-registry-only-approach)\n - [Kubernetes](#kubernetes)\n - [Kubebuilder (https://github.com/kubernetes-sigs/kubebuilder)](#kubebuilder-httpsgithubcomkubernetes-sigskubebuilder)\n - [New Golang plugin to help Operator authors skill up (Size: Medium)](#new-golang-plugin-to-help-operator-authors-skill-up-size-medium)\n - [New Grafana dashboard plugin for visualizing controller-runtime metrics (size: medium)](#new-grafana-dashboard-plugin-for-visualizing-controller-runtime-metrics-size-medium)\n - [Cluster API Provider GCP](#cluster-api-provider-gcp)\n - [Improve CAPG by adding more features and support GKE](#improve-capg-by-adding-more-features-and-support-gke)\n - [Cluster API Provider AWS](#cluster-api-provider-aws)\n - [Improve observability of CAPA](#improve-observability-of-capa)\n - [KubeVela](#kubevela)\n - [Extend more Cloud providers and Cloud resources](#extend-more-cloud-providers-and-cloud-resources)\n - [Add GitOps addon for KubeVela](#add-gitops-addon-for-kubevela)\n - [Enhance multi-cluster observability](#enhance-multi-cluster-observability)\n - [Chaos Mesh](#chaos-mesh)\n - [Single binary deployment outside kubernetes environment](#single-binary-deployment-outside-kubernetes-environment)\n - [RPC cross different namespaces through unix socket](#rpc-cross-different-namespaces-through-unix-socket)\n - [Vitess](#vitess)\n - [Improve evaluation engine](#improve-evaluation-engine)\n - [KubeArmor](#kubearmor)\n - [Observability and policy discovery helper tool](#observability-and-policy-discovery-helper-tool)\n - [Supporting KubeArmor for ARM platforms](#supporting-kubearmor-for-arm-platforms)\n - [TiKV](#tikv)\n - [Normalize TiKV Java client for TiSpark](#normalize-tikv-java-client-for-tispark)\n - [Latency Tracing](#latency-tracing)\n - [Karmada](#karmada)\n - [Refactor community official website](#refactor-community-official-website)\n - [Pixie](#pixie)\n - [Augment Pixie Metadata Context](#augment-pixie-metadata-context)\n - [TrafficNet & Protocol Inference Models](#trafficnet--protocol-inference-models)\n - [Expand PxL Function Library](#expand-pxl-function-library)\n - [CoreDNS](#coredns)\n - [Automatic Certificate Management in TLS plugin](#automatic-certificate-management-in-tls-plugin)\n - [in-toto](#in-toto)\n - [Add support for Dead Simple Signing Envelope (DSSE)](#add-support-for-dead-simple-signing-envelope-dsse)\n - [Add provenance extension to Jenkins plugin](#add-provenance-extension-to-jenkins-plugin)\n - [Add SLSA provenance support to in-toto-rs and rebuilderd](#add-slsa-provenance-support-to-in-toto-rs-and-rebuilderd)\n - [KubeEdge](#kubeedge)\n - [Init UI dashboard for kubeedge](#init-ui-dashboard-for-kubeedge)\n - [KubeEdge SIG AI: Benchmarks for Edge-cloud Joint Inference](#kubeedge-sig-ai-benchmarks-for-edge-cloud-joint-inference)\n - [KubeEdge SIG AI: Benchmarks for Edge-cloud Collaborative Lifelong Learning](#kubeedge-sig-ai-benchmarks-for-edge-cloud-collaborative-lifelong-learning)\n - [Sedna features supports visualized operation and management](#sedna-features-supports-visualized-operation-and-management)\n - [WasmEdge](#wasmedge)\n - [feat: Implement WASI and wasmedge process host functions on the Windows platform](#feat-implement-wasi-and-wasmedge-process-host-functions-on-the-windows-platform)\n - [Kyverno](#kyverno)\n - [Grammar, Parser, and Validator for Kyverno JMESPath](#grammar-parser-and-validator-for-kyverno-jmespath)\n - [Time-bound policies for Kubernetes](#time-bound-policies-for-kubernetes)\n - [Dynamic approvals for Kubernetes resources](#dynamic-approvals-for-kubernetes-resources)\n - [Brigade](#brigade)\n - [Storage Tests](#storage-tests)\n - [New Event Gateways](#new-event-gateways)\n - [New Web Dashboard](#new-web-dashboard)\n - [cert-manager](#cert-manager)\n - [Tooling for deployment and cross-configuration of cert-manager and external dependencies](#tooling-for-deployment-and-cross-configuration-of-cert-manager-and-external-dependencies)\n - [The Update Framework (TUF)](#the-update-framework-tuf)\n - [User-controlled key management](#user-controlled-key-management)\n - [Managing TUF Versions](#managing-tuf-versions)\n - [Succinct hashed bin delegations](#succinct-hashed-bin-delegations)\n - [Repository Tool](#repository-tool)\n - [Keylime](#keylime)\n - [Support push model for agent attestation](#support-push-model-for-agent-attestation)\n - [Remove requirement for atomic quotes and improve validation architecture](#remove-requirement-for-atomic-quotes-and-improve-validation-architecture)\n - [Improved Web UI for Keylime](#improved-web-ui-for-keylime)\n - [Enhanced Event Logging](#enhanced-event-logging)\n - [Thanos](#thanos)\n - [Consistent Hashing in Thanos Receive Hashrings](#consistent-hashing-in-thanos-receive-hashrings)\n - [Compaction/Downsampling: build chunks from object storage without touching disks](#compactiondownsampling-build-chunks-from-object-storage-without-touching-disks)\n - [LitmusChaos](#litmuschaos)\n - [Develop a terraform provider or scripts to provision litmuschaos functionalities](#develop-a-terraform-provider-or-scripts-to-provision-litmuschaos-functionalities)\n - [Meshery](#meshery)\n - [Service Mesh Catalog](#service-mesh-catalog)\n - [Service Mesh Performance](#service-mesh-performance)\n - [CNCF Cluster: Performance Benchmarking](#cncf-cluster-performance-benchmarking)\n - [Knative](#knative)\n - [Improve Knative Eventing End-to-End Observability by addressing top issues identified by community](#improve-knative-eventing-end-to-end-observability-by-addressing-top-issues-identified-by-community)\n - [Make Knative running on Edge](#make-knative-running-on-edge)\n\n---\n\n## Project Ideas\n\nIf you are a project maintainer and consider mentoring during the GSoC 2022 cycle, please, submit your ideas below using the [template](/PROJECT_IDEA_TEMPLATE.md).\n\n---\n\n### Argo\n\n#### Memoization storage\n\n- Description: Memoization is a feature that allows users to run workflows faster by avoiding repeating work that has already been done. Currently, memoization uses a Kubernetes ConfigMap for storage. This will not scale to large number of entries and it requires elevated RBAC. We'd like to make this extensible that could support additional storage systems to store step memoization cache for Argo Workflows.\n- Expected Outcome: The memoization feature is extended to allow additional storage systems.\n- Recommended Skills: Golang, Kubernetes, Databases\n- Mentor(s): Yuan Tang (@terrytangyuan) and Alex Collins (@alexec)\n- Expected Project Size: 175 hours\n- Difficulty Rating: Medium\n- Upstream Issue (URL): https://github.com/argoproj/argo-workflows/issues/3587\n\n\n#### UI plugins\n\n- Description: Currently, any user who wants to add additional resources to the UI needs to implement both backend and frontend changes. Instead, we'd like to implement an UI extension mechanism to load and embed UI elements in Argo Workflows UI. Argo CD already has a UI extension mechanism to load the Argo Rollouts into the UI that is proven to be successful. We can lift inspiration from this and implement something similar in Argo Workflows.\n- Expected Outcome: An extension mechanism in Argo Workflows UI to embed custom UI elements.\n- Recommended Skills: Typescript, React, Golang\n- Mentor(s): Alex Collins (@alexec)\n- Expected Project Size: 175 hours\n- Difficulty Rating: Medium\n- Upstream Issue (URL): https://github.com/argoproj/argo-workflows/issues/6945\n\n#### Count-based enhanced depends logic\n\n- Description: Currently, Argo Workflows has a feature called enhanced depends logic that allows users to specify dependent tasks based on their statuses via complex boolean logic. However, this requires users to specify task names explicitly which may be difficult or unnecessary to obtain. For example, there are situations where the tasks are dynamically generated and task names cannot be easily obtained or users might not care the statuses for specific tasks and instead focus on the number of tasks of a particular status. We'd like to implement a count-based enhanced depends logic in Argo Workflows in addition to the existing depends logic based on dependent tasks and their statuses.\n- Expected Outcome: Support count-based enhanced depends logic in Argo Workflows in addition to the existing depends logic based on dependent tasks and their statuses.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Yuan Tang (@terrytangyuan)\n- Expected Project Size: 175 hours\n- Difficulty Rating: Medium\n- Upstream Issue (URL): https://github.com/argoproj/argo-workflows/issues/3171\n\n### Buildpacks\n\n#### Standardize Cache Flag options\n\n- Description: The `pack` CLI has many layers of cache with various methods to configure them. In this project, the goal would be to implement a [proposed solution](https://github.com/buildpacks/rfcs/blob/main/text/0091-pack-cache-options.md) for how the end-user provides caching options. The caching mechanisms are already implemented but they are not currently exposed to the end-user.\n- Expected outcome: A new argument to the Pack CLI that allows users to configure various types of cache options.\n- Recommended Skills: Golang, Docker\n- Mentor(s): Javier Romero (@jromero)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/buildpacks/pack/issues/1077\n\n#### Proof of concept for lifecycle registry only approach\n\n- Description: A proof of concept implementing an OCI registry facade to stand in the middle between the lifecycle and the Daemon is required to evaluate the deprecation of the Daemon support.\nThe idea is to create a component that is capable of translating OCI format to V1 format and viceversa and simplify the Lifecycle base code to only interact with OCI registry without loosing the current capability of dealing with the Daemon. There are some concerns about how this will affect the performance but the PoC will help us to understand all the side effects of the approach. There are some more information discussed about removing the Daemon support in the following [draft RFC](https://github.com/buildpacks/rfcs/pull/201)\n- Expected outcome: Implementation of a basic OCI registry wrapper capable of translating inbound/outbound OCI requests to Daemon requests\n- Recommended Skills: Golang, Docker\n- Mentor(s): Javier Romero (@jromero), Juan Bustamante (@jjbustamante)\n- Expected project size: 350 Hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/buildpacks/pack/issues/1372\n\n### Kubernetes\n\n#### Kubebuilder (https://github.com/kubernetes-sigs/kubebuilder)\n\n##### New Golang plugin to help Operator authors skill up (Size: Medium)\n\n- Description: Your goal is to develop a [Kubebuilder Plugin](https://book.kubebuilder.io/plugins/plugins.html) which generates the files with all possible common desired source code implementation for an Operator Author to achieve the goal of deploying an Operand(image/Pod) following the [Operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) and common best practices and recommendations such as using [StatusConditionals](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties), tests, etc. Note that we can begin implementing this plugin with basic implementation and then start to provide many follow-ups as much we wish to grow it incrementally. This plugin can help a lot of Operator Authors save time and give good direction and start to point to them. You can begin by following, for example, the quick tutorial [Golang Operator](https://sdk.operatorframework.io/docs/building-operators/golang/tutorial/) and the document [Common recommendations and suggestions](https://sdk.operatorframework.io/docs/best-practices/common-recommendation/) to have an idea of how Operators works and what code this plugin would generate by default. It is ideal for those who are looking to know more about [Operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) and its good practices, how to develop tests and ensure the quality and maintainability of solutions.\n- Expected outcome: Implementation of a new Golang Plugin in Kubebuilder to generate scaffolds required to deploy and manage an image on the cluster. Other possibe outcomes are to provide examples of the code implementation and recommend best practices in documentation.\n- Recommended Skills: Golang, Kubernetes, Operators\n- Mentor(s): Camila Macedo (@camilamacedo86) and Rashmi Gottipati(@rashmigottipati)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/code-generate-image-plugin.md\n\n##### New Grafana dashboard plugin for visualizing controller-runtime metrics (size: medium)\n\n- Description: Your goal is to develop a [Kubebuilder Plugin](https://book.kubebuilder.io/plugins/plugins.html) which will generate the manifests required to provide Grafana dashboards for visualizing the default [metrics exported](https://book.kubebuilder.io/reference/metrics.html). You can begin by first looking into the requirements for exporting the controller-runtime metrics and steps to create a custom dashboard. After figuring out the configuration files which are needed, we can start by creating a plugin when invoked scaffolds them. The plugins [here](https://github.com/operator-framework/operator-sdk/tree/master/internal/plugins) can give a good idea on how they work. An extended goal would be to figure out on how we can make it available on https://grafana.com/grafana/dashboards for users to be able to easily export it.\n- Expected outcome: Create a plugin, when invoked scaffolds out the required manifests for integrating Grafana dashboard. Make the Grafana dashboard available in https://grafana.com/grafana/dashboards based on the inputs from the community.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Varsha Prasad (@varshaprasad96)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/kubebuilder/issues/2183\n\n#### Cluster API Provider GCP\n\n##### Improve CAPG by adding more features and support GKE\n\n- Description: [CAPG](https://github.com/kubernetes-sigs/cluster-api-provider-gcp) is a subporject under the SIG-Cluster-LifeCycle and it is an implementation for GCP of Cluster-API which is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.\n- Expected outcome: This work will bring CAPG inline with CAPA and CAPZ, both of which support creating unmanaged and managed clusters.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Carlos Panato (@cpanato), Davanum Srinivas (@dims), Richard Case (@richardcase), Winnie Kwon (@pydctw)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/cluster-api-provider-gcp/issues/512 / https://github.com/kubernetes-sigs/cluster-api-provider-gcp/issues/478 / https://github.com/kubernetes-sigs/cluster-api-provider-gcp/issues/289\n\n#### Cluster API Provider AWS\n\n##### Improve observability of CAPA\n\n- Description: Cluster API Provider AWS (CAPA) is a subproject of SIG Cluster Lifecycle that extends Cluster API to simplify lifecycle management of Kubernetes clusters on AWS.\n The focus of this project is to improve the observability of CAPA by integrating it with observability tools such as OpenTelemetry/Jaeger/Prometheus.\n With the help of metrics/traces emitted by these observability integrations, users will easily analyze CAPA's behaviour and performance.\n This project will also focus on improving developer experience with OpenTelemetry collectors and by documenting the integration steps.\n- Expected outcome: The main outcome is to instrument CAPA to export OpenTelemetry trace and improve the metrics exposed.\n Another outcome is to improve development environment by deploying OpenTelemetry for collecting traces, Jaeger and Prometheus for viewing traces and visualizing metrics.\n- Recommended Skills: Golang, Kubernetes, observability tools (such as OpenTelemetry/Jaeger/Prometheus)\n- Mentor(s): Sedef Savas (@sedefsavas) Richard Case (@richcase)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubernetes-sigs/cluster-api-provider-aws/issues/2178\n\n### KubeVela\n\n#### Extend more Cloud providers and Cloud resources\n\n- Description: To enable KubeVela end-users to better manage cloud resources, more cloud providers and cloud resources are needed to support in KubeVela.\n These are some cloud providers which have been supported as [Terraform Addons](https://kubevela.io/docs/tutorials/consume-cloud-services#enabling-cloud-vendor-addons).\n But there are also some which have been supported by [Terraform Controller](https://github.com/oam-dev/terraform-controller#supported-cloud-providers), but not by KubeVela. They are expected to be extended as Terraform Cloud providers in KubeVela.\n KubeVela has supported 110 cloud resources across cloud providers. But we need more cloud resources to be extended as KubeVela Terraform ComponentDefinition.\n- Expected outcome: 15+ cloud providers are supported by KubeVela as Terraform addons; 300+ cloud resources are supported; \n Tools and docs to support extending Terraform provider addons and cloud resources in an easy and productive way\n- Recommended Skills: Golang, Terraform\n- Mentor(s): ZhengXi Zhou (@zzxwill)\n- Expected project size: 350 Hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/oam-dev/kubevela/issues/2442\n\n#### Add GitOps addon for KubeVela\n\n- Description: Improve the capabilities of KubeVela GitOps to make it a standalone Addon.\n- Expected outcome: Create a KubeVela GitOps addon to simplify use and debugging.\n- Recommended Skills: Golang, Kubernetes, Cue\n- Mentor(s): FogDong (@FogDong)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/oam-dev/kubevela/issues/3205\n\n#### Enhance multi-cluster observability\n\n- Description: Extend the observability of multi-cluster information on KubeVela control plane\n- Expected outcome: Provide extensible cluster information, starting with providing more information such as: the health status, available cpu cores, whether it is a GPU cluster, the stability of connections with KubeVela control plane, etc.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Da Yin (@Somefive)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/oam-dev/kubevela/issues/3177\n\n### Chaos Mesh\n\n#### Single binary deployment outside kubernetes environment\n\n- Description: Chaos Mesh supports injecting errors into a bare metal server through [chaosd](https://github.com/chaos-mesh/chaosd) and `PhysicalMachineChaos`. It's convenient to manage the physical machine injection through Chaos Mesh, considering its dashboard, `Workflow` and `Schedule` function. However, for a bare metal user without any kubernetes environment, he has to deploy a kubernetes cluster to manage and install Chaos Mesh. This project is to simplify this routine by packaging the neccesary part of Kubernetes and the controller of Chaos Mesh together (just like a much more simplified k3s). You will need to investigate the source codes of Chaos Mesh and Kubernetes, combine their controllers and api-servers, and extract the useful part of them. You also need to provide a out-of-box configuration for the certificates and leader election. What's more? This project has the potential to empower Kubernetes to become a framework to develop a high-available declarative API for any cloud-native projects.\n- Expected outcome: Provide an executable file to start Chaos Mesh and related kubernetes environment with high-availability support under one process. \n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Yang Keao (@YangKeao)\n- Expected project size: 350 Hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/chaos-mesh/chaos-mesh/issues/2848\n\n#### RPC cross different namespaces through unix socket\n\n- Description: Communicate with subprocess in another namespace through unix\nsocket.\n- Detailed description: The `chaos-daemon` component of Chaos Mesh manages many subprocesses to inject faults into other containers(Linux namespaces), and we need to communicate with the subprocesses (to modify configurations or monitor statuses). However, some of the subprocesses run in another network namespace (hard to access by network), others of them may run in another mount namespace (hard to access by named unix socket). Currently, `chaos-daemon` communicate with subprocesses by stdin and stdout, it works across different namespaces but lacks session layers, and we have to be cautious of printing logs into stdout. So, we need a better way to communicate with subprocesses, and the abstract unix socket is a reasonable choice.\n- Expected outcome:\n - The `chaos-daemon` can pass file description of unix socket listeners to subprocesses and dial them.\n - The subprocesses can receive file descriptions and re-construct unix socket listeners.\n- Recommended Skills: Golang, Rust, Docker, Linux\n- Mentor(s): Hexilee (@Hexilee), Yang Keao (@YangKeao)\n- Expected project size: 350 Hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/chaos-mesh/rfcs/pull/34\n\n### Vitess\n\n#### Improve evaluation engine\n\n- Description: Improve the compatbility of Vitess' evaluation engine against MySQL by adding support for more built-in SQL functions.\n- Detailed description: The evaluation engine in Vitess is one of the most critical parts of our query serving infrastructure. This engine is capable of evaluating arbitrary SQL expressions directly inside Vitess' process, without reaching out to a live MySQL instance, and this allows us to plan and execute complex user queries (e.g. queries that contain WHERE and similar filter clauses) between Vitess shards much more efficiently. If you're interested in this GSoC project, your task for the summer will involve continuing the work on this evaluation engine by implementing support for as many built-in SQL functions as possible, using the behavior of MySQL as a reference.\n- Expected outcomes: We expect the Evaluation Engine in Vitess to be close to 100% compatible with MySQL after all the leftover SQL built-ins have been implemented.\n- Recommended Skills: Golang, MySQL\n- Mentor(s): Vicent Marti (@vmg)\n- Expected size of the project: 350h\n- Difficulty rating: Medium\n- Upstream Issue (URL): https://github.com/vitessio/vitess/issues/9647\n\n### KubeArmor\n\n#### Observability and policy discovery helper tool\n\n- Description: KubeArmor provides a visibility telemetry events to show pod/container observability data such as process executions, file system accesses, network accesses. This information is to be used to bind together more comprehensive analysis data showing the security posture for the pod/container. This security posture/visibility information would help user in turn to discover optimal policy settings. One of the aim for this work is to ensure that the system shows only useful/aggregated data and does simply throw bunch of events/logs to the user. The overall design involves developing and deploying a k8s service that will wait on the kubearmor events and aggregate those events at the container/pod level. The cli-tool (already present but has to be extended) will be pulling the information from the service to show it to the user. An extended goal could be to show a simply TUI to the user by querying the kubearmor service. Detailed use-cases and requirements are mentioned in [this slide deck](https://docs.google.com/presentation/d/1THIcxrZrIOqihsFG9rxmR73XkmXa10CVkU1ewzP6ToQ/edit?usp=sharing).\n- Expected outcome: Develop a k8s service/deployment that could aggregate events from kubearmor and show observability data to the user. An extended goal is to show a TUI based on this observability data.\n- Recommended Skills: golang, tui, mysql, grpc, k8s\n- Mentor(s): Barun Acharya (@daemon1024), Rahul Jadhav (@nyrahul)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubearmor/KubeArmor/issues/613\n\n#### Supporting KubeArmor for ARM platforms\n\n- Description: KubeArmor has garnered interests from edge computing platforms (such as LF Edge OpenHorizon) that leverages k8s control plane for workload orchestration. The primary requirement is to support ARM platforms that are prevalent on the edge devices (especially Raspberry PI). KubeArmor leverages eBPF for observability and Linux Security Modules (such as AppArmor) for policy enforcement. One of the challenge is to check if the eBPF primitives such as observing kprobe, kretprobe, tracepoints that are typically available on the x86 platform are also available on the ARM platform and check if the parameter list fulfills the requirement. Post this analysis, the kubearmor code might have to be changed to accomodate any differences in the eBPF behaviour.\n- Expected outcome: Kubearmor observability features should work on ARM platform. Extended goal would be to ensure that Kubearmor's policy enforcement features (based on AppArmor) are also supported on ARM platforms.\n- Recommended Skills: golang, raspberry-pi, ebpf, k8s\n- Mentor(s): Rahul Jadhav (@nyrahul), Barun Acharya (@daemon1024)\n- Expected project size: 350 Hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/kubearmor/KubeArmor/issues/614\n\n### TiKV\n\n#### Normalize TiKV Java client for TiSpark\n\n- Description: TiSpark maintains a fork of TiKV Java client of little use and could use the upstream TiKV Java client.\n- Expected outcome: TiSpark abandons self-maintained TiKV Java client and uses upstream TiKV Java client. Everything should work as before.\n- Recommended Skills: Java, Spark, TiKV\n- Mentor(s): Xiang Zhang (@zhangyangyu), Yuhang Shi (@shiyuhang0)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/tikv/client-java/issues/514\n\n#### Latency Tracing\n\n- Description: [TiKV](https://github.com/tikv/tikv) is an open-source, distributed, and transactional key-value database. TiKV is widely used in many mission-critical scenarios that require request latency to be below a single millisecond level, so knowing where the latency has consumed is important. This project is going to let TiKV has the ability to observe the latency composition and diagnose slow requests. CPU-bound requests in TiKV, such as coprocessor requests, are executed at the requested granularity, which is relatively convenient to trace. However, for IO-bound requests in TiKV, such as prewrite requests, batch processing has been introduced to improve IO throughput, which will bring some challenges to trace since it's a scenario not covered by most tracing frameworks. Also, we need to fetch statistics from RocksDB, the storage engine powering TiKV, to provide further tracing details for IO-bound requests.\n- Expected outcome: Improve observability for IO-bound requests in TiKV. Concretely, we expect to learn about latency details of RaftStore and RocksDB from the improved tracing results.\n- Recommended Skills: Rust, C++, OpenTracing, RocksDB\n- Mentor(s): Zhenchi (@zhongzc), breeswish (@breeswish)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/tikv/tikv/issues/11872\n\n### Karmada\n\n#### Refactor community official website\n\n- Description: [Karmada (Kubernetes Armada)](https://github.com/karmada-io/karmada/) is a Kubernetes management system that enables you to run your cloud-native applications across multiple Kubernetes clusters and clouds. This project is to develop the community official website to hold the necessary documents. \n- Expected outcome: A brand-new website with enhancements to hold documents. \n- Recommended Skills: Frontend HTML/CSS/JavaScript, Backend Node/Python/Go/etc\n- Mentor(s): Hongcai Ren (@RainbowMango)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/karmada-io/website/issues/14\n\n### Pixie\n\n#### Augment Pixie Metadata Context\n\n- Description: Pixie helps contextualize the data it collects by joining it with the relevant K8s metadata. This helps us answer questions like “Pod A has a HTTP request latency of 30ms” and allows us to build resource-level visualizations. Currently, Pixie pulls in metadata about namespaces, pods, and services, but is currently missing other useful K8s resources. You can help add resources to Pixie’s metadata context and experiment with what views and dashboards can leverage this new metadata.\n- Expected outcome: More queryable metadata context for Pixie data (for example, the equivalent of `px.pod_*` functions), and a dashboard (PxL + visspec) for the newly added resource (similar to `px/pod`).\n- Recommended Skills: Go, C++, understanding of Kubernetes resources\n- Mentor(s): Michelle Nguyen (@aimichelle)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/pixie-io/pixie/issues/34\n\n#### TrafficNet & Protocol Inference Models\n\n- Description: Pixie’s protocol tracer captures traffic for various protocols, including HTTP, gRPC, postgres and many more. The protocol tracer relies on protocol inference rules to classify traffic based on the contents of the messages being sent. To validate the accuracy of our protocol inference rules, we need a large database of different traffic patterns. We call this dataset TrafficNet. For this project, you will try to (1) expand the TrafficNet data set to include more samples of existing and new protocols, and (2) experiment with different inference models to improve the accuracy of the protocol inference.\n- Expected outcome:\n - An augmented data set of traffic patterns with a variety of protocols, based on new workloads.\n - An report of protocol inferences rules on the TrafficNet data sets to identify the best performing models, and evaluating the trade-offs of the models.\n- Recommended Skills: C++, Python\n- Mentor(s): Omid Azizi (@oazizi000)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/pixie-io/pixie/issues/404\n\n#### Expand PxL Function Library\n\n- Description: PxL is a Pandas-based query language which is used to query Pixie’s data. Help add to PxL’s function library to make it easier for users to transform their data and build interesting views. This may include adding math and string operations, or functions of your own choice. \n- Expected outcome: New functions in PxL, with the number of functions/complexity of the function up to your choice\n- Recommended Skills: C++\n- Mentor(s): Natalie Serrino (@nserrino)\n- Expected project size: 175 Hours\n- Difficulty: Easy\n- Upstream Issue (URL): https://github.com/pixie-io/pixie/issues/405 https://github.com/pixie-io/pixie/issues/356\n\n### CoreDNS\n\n#### Automatic Certificate Management in TLS plugin\n\n- Description: [CoreDNS](https://github.com/coredns/coredns) is a cloud-native DNS server with a focus on service discovery. While best known as the default DNS server for Kubernetes, CoreDNS is capable of handle many other scenarios such as severing DNS through HTTPS/TLS. As HTTPS/TLS requires valid certificate any renewal of corticate periodically, an automation (e.g., through ACME protocol) will minimize the manual maintenance need. This project is to provide certificate management automation in TLS plugin of CoreDNS.\n- Expected outcome: An option will be added to TLS plugin for automatically renewing certificate through ACME protocol, and exposing the updated certificate.\n- Recommended Skills: Golang, DNS, TLS, Certificate Management\n- Mentor(s): Yong Tang (@yongtang) Paul Greenberg (@greenpau)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/coredns/coredns/issues/3460\n\n### in-toto\n\n#### Add support for Dead Simple Signing Envelope (DSSE)\n\n- Description: [Dead Simple Signing Envelope (DSSE)](https://github.com/secure-systems-lab/dsse) is a new signature wrapper, and [a proposal](https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc) to make it the default for in-toto metadata has been accepted. However, there is currently no Python implementation that can be used by in-toto and other projects. The aim of this project is to fix that by writing a fully featured and well tested DSSE implementation, and using it to allow users to generate in-toto metadata using DSSE rather than the legacy signature wrapper.\n- Expected Outcome: The Python reference implementation can generate in-toto metadata using DSSE.\n- Expected Project Size: 175\n- Difficulty: Medium\n- Recommended Skills: Python\n- Mentor(s): Aditya Sirish (@adityasaky), Lukas Pühringer (@lukpueh)\n- Upstream Issue (URL): https://github.com/in-toto/in-toto/issues/445\n\n#### Add provenance extension to Jenkins plugin\n\n- Description: The [in-toto Jenkins plugin](https://github.com/jenkinsci/in-toto-plugin/) allows users to generate in-toto link metadata in their build pipelines. However, with ITE-6 and the in-toto Attestations project, the plugin must also be capable of generating other in-toto attestations such as the [provenance specification](https://slsa.dev/provenance/v0.2). The aim of this project is to refactor the Jenkins plugin to allow for new attestation types, as well as to implement the provenance attestation. The [in-toto-java implementation](https://github.com/in-toto/in-toto-java) can be leveraged to create the new attestations in the Jenkins plugin.\n- Expected Outcome: The Jenkins in-toto plugin can generate SLSA provenance metadata for tasks performed in pipelines.\n- Expected Project Size: 175\n- Difficulty: Easy\n- Recommended Skills: Java, Jenkins\n- Mentor(s): Aditya Sirish (@adityasaky), Santiago Torres-Arias (@SantiagoTorres)\n- Upstream Issue (URL): https://github.com/in-toto/in-toto-jenkins-plugin/issues/1\n\n#### Add SLSA provenance support to in-toto-rs and rebuilderd\n\n- Description: [rebuilderd](https://rebuilderd.com) is a verification system for binary packages. It repeates the build process of a package in an identical environment and verifies that the package is identical. It currently generates in-toto link attestations when a package is successfully rebuilt. As part of this task, rebuilderd must be updated to generate [in-toto SLSA provenance](https://slsa.dev/provenance/v0.2). To enable this feature, [in-toto-rs](https://github.com/in-toto/in-toto-rs) must be extended to support the provenance specification as well.\n- Expected Outcome: in-toto-rs gains ITE-6 semantics and the ability to generate SLSA provenance metadata, which is then used by rebuilderd to generate provenance for successful package rebuilds.\n- Expected Project Size: 350\n- Difficulty: Medium\n- Recommended Skills: Rust\n- Mentor(s): Aditya Sirish (@adityasaky), Santiago Torres-Arias (@SantiagoTorres)\n- Upstream Issue (URL): https://github.com/in-toto/in-toto-rs/issues/17, https://github.com/in-toto/rebuilderd/issues/5\n\n### KubeEdge\n\n#### Init UI dashboard for kubeedge\n- Description: Init the UI dashboard for kubeedge, users can operate the kubeedge objs in dashboad.\n- Expected outcome: Create a KubeEdge objs dashboard\n- Recommended Skills: Kubernetes, KubeEdge, HTML/CSS/JavaScript\n- Mentor(s): Yue Bao(@Shelley-BaoYue), Fisher Xu (@fisherxu)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubeedge/kubeedge/issues/3608\n\n#### KubeEdge SIG AI: Benchmarks for Edge-cloud Joint Inference\n- Description: The KubeEdge SIG AI is chartered to facilitate Edge AI applications with KubeEdge. An overview of SIG AI activities can be found in this [charter](https://github.com/kubeedge/community/blob/master/sig-ai/charter.md). This project focuses on measuring and validating the desired behaviors for an epoch-making Edge AI scheme, i.e., [Edge-cloud Joint Inference](https://sedna.readthedocs.io/en/latest/proposals/joint-inference.html). The scheme of Edge-cloud Joint Inference has been released in [KubeEdge-Sedna](https://github.com/kubeedge/sedna/releases/tag/v0.1.0) together with [a hands-on example](https://sedna.readthedocs.io/en/latest/examples/joint_inference/helmet_detection_inference/README.html) and [a free playground](https://www.katacoda.com/kubeedge-sedna/scenarios/joint-inference-example). Part of the effort is to develop test cases on the existing scheme of Edge-cloud Joint Inference on KubeEdge-Sedna, including interfaces for benchmark datasets, metrics, and even baselines. These test cases will help all Edge AI application developers to validate and select the best-matched algorithm of joint inference. Several breath-taking Edge-AI scenarios have been prepared for benchmarking: looking forward to seeing your codes involved in real-world robots, outer-space satellites, and industrial production lines! \n- Expected outcome: Develop tests around the existing scheme of Edge-cloud Joint Inference on KubeEdge-Sedna, including interfaces for benchmark datasets, metrics, and baselines.\n- Recommended Skills: TensorFlow/Pytorch, Python\n- Mentor(s): Jie Pu(@jaypume)\n- Expected project size: 175\n- Difficulty: Medium\n- Upstream Issue(URL): https://github.com/kubeedge/sedna/issues/274\n\n#### KubeEdge SIG AI: Benchmarks for Edge-cloud Collaborative Lifelong Learning\n- Description: The KubeEdge SIG AI is chartered to facilitate Edge AI applications with KubeEdge. An overview of SIG AI activities can be found in this [charter](https://github.com/kubeedge/community/blob/master/sig-ai/charter.md). This project focuses on measuring and validating the desired behaviors for an epoch-making Edge AI scheme, i.e., [Edge-cloud Collaborative Lifelong Learning](https://sedna.readthedocs.io/en/latest/proposals/lifelong-learning.html). The scheme of Edge-cloud Collaborative Lifelong Learning has been released in [KubeEdge-Sedna](https://github.com/kubeedge/sedna/releases/tag/v0.3.0) together with [a hands-on example](https://sedna.readthedocs.io/en/latest/examples/lifelong_learning/atcii/README.html) and [a free playground](https://www.katacoda.com/kubeedge-sedna/scenarios/lifelong-learning-example). Part of the effort is to develop test cases for this existing scheme on KubeEdge-Sedna, including interfaces for benchmark datasets, metrics, and even baselines. These test cases will help all Edge AI application developers to validate and select the best-matched algorithm of lifelong learning. Several breath-taking Edge-AI scenarios have been prepared for benchmarking: looking forward to seeing your codes involved in real-world robots, outer-space satellites, and industrial production lines! \n- Expected outcome: Develop test cases around the existing scheme of Edge-cloud Collaborative Lifelong Learning on KubeEdge-Sedna, including interfaces for benchmark datasets, metrics, and even baselines.\n- Recommended Skills: TensorFlow/Pytorch, Python\n- Mentor(s): Zimu Zheng (@MooreZheng)\n- Expected project size: 175\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubeedge/sedna/issues/275\n\n#### Sedna features supports visualized operation and management \n- Description: Sedna features support job status and pod status centralized visualization as visualized O&M of intelligent collaboration is a basic requirement.\n- Expected outcome: Sedna features support job status（such as job status, jobstage status), pod status and worker status（such as worker status, worker service output) centralized visualization.\n- Recommended Skills: golang, Prometheus, Grafana\n- Mentor(s): Jin Yang(@JimmyYang20)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue(URL): https://github.com/kubeedge/sedna/issues/273\n\n### WasmEdge\n\n#### feat: Implement WASI and wasmedge process host functions on the Windows platform\n\n- Description: [WasmEdge](https://github.com/WasmEdge/WasmEdge) is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is designed to support multiple operating systems. However, the WASI and wasmedge process components are only implemented on macOS and Linux platforms. Most of the host functions are not supported on the Windows platform. Since we have lots of windows users, it is necessary to finish the implementations.\n- Expected outcome: [The WASI and process host functions](https://github.com/WasmEdge/WasmEdge/tree/master/lib/host) are implemented on Windows platform.\n- Recommended Skills: C++, Windows API\n- Mentor(s): Hung-Ying Tai (@hydai), Shen-Ta Hsieh (@ibmibmibm)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/1227\n\n### Kyverno\n\n#### Grammar, Parser, and Validator for Kyverno JMESPath\n\n- Description: Kyverno, the Kubernetes native policy engine, is designed to easily secure and automate Kubernetes configurations. Kyverno uses an extended [JMESPath query language](https://jmespath.org/specification.html) for complex JSON data processing. Kyverno extends JMESPath by allowing nested expressions and an extended set of custom functions. As Kyverno's declarative policy language has evolved its become important to provide proper tooling around embedding, syntax checking and validation of JMESPath expressions including the extensions.\n- Expected outcome: This project will define a formal specification of Kyverno's JMESPath extensions using ABNF notation and create a parser-validator for this grammar for use in Kyverno. \n- Recommended Skills: Golang, Kubernetes, Language Design, DSLs\n- Mentor(s): Jim Bugwadia (@JimBugwadia)\n- Expected project size: 350 hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/3217\n\n#### Time-bound policies for Kubernetes\n\n- Description: Kyverno policies can validate, mutate, and generate any Kubernetes resource. A common use case is for organizations to allow access to Kubernetes cluster resources based on schedules, such as a pager rotation schedule for SREs. This feature enables time-based policies for Kyverno, to allow select operations for authorized users based on time ranges and schedule constraints. \n- Expected outcome: The feature will extend Kyverno's policy rule definition to support time ranges and block requests which do not match the configured values.\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Chip Zoller (@chipzoller), Jim Bugwadia (@JimBugwadia)\n- Expected project size: 175 hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/2233\n\n#### Dynamic approvals for Kubernetes resources\n\n- Description: Kyverno is a Kubernetes native policy engine that makes it easy to validate, mutate, and generate resources. While Kyverno policies allow configuratrion of exceptions, excluding policy enforcement on select resources requires manual configuration by cluster administrators. This feature extends Kyverno to allow users to request policy exceptions, and for administrative approvals to be granted asynchronously. The goal of this feature is to allow easier collaboration across developers and operations teams, and to make it easier to manage policies at scale.\n- Expected outcome:\n- Recommended Skills: Golang, Kubernetes\n- Mentor(s): Shuting Zhao (@realshuting), Jim Bugwadia (@JimBugwadia)\n- Expected project size: 350 hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kyverno/kyverno/issues/2627\n\n### Brigade\n\n#### Storage Tests\n\n- Description: Brigade's data access packages are currently unit-tested against mock implementations of MongoDB client interfaces. These tests have been adequate for asserting that queries and statements are constructed properly (look like we think they should) and that mock query and statement results can be unmarshaled without error into domain types, but this approach cannot assert that DB queries and statements are logically correct and actually achieve the desired results, since a live database would be required to accomplish that. Given the importance of the data access code, we would like to develop a new suite of integration tests directly targeted at that code. These new tests should run against a live (and disposable) MongoDB database and assert that all queries and statements achieve the desired results. If the new suite of tests exposes bugs in the existing data access code, correcting those bugs is within the scope of this project as well.\n- Expected outcome: New test suite merged into main branch and fully integrated into CI/CD pipelines\n- Recommended Skills: Golang, MongoDB, Docker\n- Mentor(s): Kent Rancourt (@krancour)\n- Expected project size: 175 hours\n- Difficulty: Easy\n- Upstream Issue (URL): https://github.com/brigadecore/brigade/issues/1811\n\n#### New Event Gateways\n\n- Description: Brigade event gateways are peripheral components that are installed alongside Brigade to receive events from external systems, transform those events into Brigade events, and enqueue them on Brigade's event bus. Most gateways are small, simple programs. On the more sophisticated end of the spectrum, gateways may go as far as utilizing the Brigade API to monitor the status of events they have created so they can report those statuses \"upstream\" to the original source of the event. This project invites candidates to propose and implement one or more new gateways.\n- Expected outcome: The GA release of one or more new gateways that will be donated to the Brigade project\n- Recommended Skills: Golang or TypeScript, Kubernetes, Helm\n- Mentor(s): Kent Rancourt (@krancour)\n- Expected project size: 175 hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/brigadecore/brigade/issues/1817\n\n#### New Web Dashboard\n\n- Description: An early prototype exists for a web-based, Brigade v2-compatible dashboard application. It does not yet meet the high bar for quality that the Brigade project, as a whole, aspires to. With our core team's front-end bench strength somewhat lacking at the moment, this project invites a suitable candidate to take ownership of this application's principal development. Specific areas of focus will include improving error-handling, developing test suites, ensuring compatibility across popular browsers, improving the overall look, feel, and responsiveness of UI elements, improving the overall UX, and improving accessibility.\n- Expected outcome: The GA release of the new dashboard\n- Recommended Skills: HTLM, CSS, TypeScript, React\n- Mentor(s): Kent Rancourt (@krancour)\n- Expected project size: 350 hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/brigadecore/brigade-dashboard/issues/4\n\n### cert-manager\n\n#### Tooling for deployment and cross-configuration of cert-manager and external dependencies\n\n- Description: Create a means to easily install and configure various combinations of cert-manager, external dependencies (i.e ingress controllers) and cert-manager custom resources for local development and testing purposes.\n- Detailed description: [cert-manager](https://github.com/cert-manager/cert-manager) is a Kubernetes addon that helps with management and issuance of TLS certificates in a Kubernetes cluster. In practice, such a TLS setup can involve a deployment of cert-manager, [cert-manager custom resources](https://cert-manager.io/docs/concepts/) and some external tools, such as Vault or some [ingress controller implementation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) and all of these tools also need to be configured to work together.\nAs cert-manager developers working on new cert-manager integrations, trying to reproduce bugs etc, we often spend significant amount of time setting up and cross-configuring cert-manager and these external tools.\nIt would be great if we had a way to easily deploy cert-manager, cert-manager resources and any required external tools, all configured to work for a particular TLS setup scenario.\n\nThe expected outcomes:\n- create a new installation mechanism that can install and configure resources for a few common Kuberenetes TLS setup scenarios (an example scenario would be cert-manager + [cert-manager ACME `Issuer`](https://cert-manager.io/docs/configuration/) + [ingress-nginx](https://kubernetes.github.io/ingress-nginx/)) like in our [nginx-ingress tutorial](https://cert-manager.io/docs/tutorials/acme/nginx-ingress/))\n- The new mechanism:\n - should be easy to update, so that it is straigtforward for a developer, who knows how to set up a particular scenario, to share their knowledge with the team by adding new functionality to the installation mechanism\n - should allow for easy parameterization/modification of any of the deployed resources\n - if possible, should not involve developers having to learn a complex new language/framework\n\nThe implementation could be a CLI tool, a collection of scripts, a bunch of [Terraform modules](https://www.terraform.io/language/modules/develop) or other - we would like to involve the GSoC student in the design process and welcome students' ideas.\n\n- Expected size of the project: 350h\n- Difficulty rating: medium\n- Recommended Skills: Kubernetes, Bash, Terraform, Go\n- Mentor(s): @irbekrm\n- Upstream Issue (URL): https://github.com/cert-manager/cert-manager/issues/4855\n\n### The Update Framework (TUF)\n\n#### User-controlled key management\n\n- Description: Write an implementation of [TAP 13](https://github.com/theupdateframework/taps/blob/master/tap13.md) in the [go implementation](https://github.com/theupdateframework/go-tuf) of TUF. TUF metadata provides key management for developers who want to sign packages that they upload to a repository. However, this means that users are trusting the repository administrators to accurately portray the correct signing key for each package. TAP 13 reduces trust in repository administrators by adding support for user-managed keys to TUF, allowing users to override the key management done by the repository to trust only a subset of images on that repository. The implementation will be built on the new python-tuf client.\n- Expected outcome: An extension is added to the python-tuf client that allows users to specify TAP 13 metadata.\n- Recommended Skills: go\n- Mentors: Marina Moore (@mnm678)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue: https://github.com/theupdateframework/taps/issues/137\n\n#### Managing TUF Versions\n- Description: Implement [version management](https://github.com/theupdateframework/taps/blob/master/tap14.md) for TUF’s python reference implementation. The implementation does not currently have a way to migrate TUF repositories or clients to a new TUF version that has breaking changes. This project will be the implementation of a proposal for coordinating specification versions between a repository and a client to prevent interruptions in access to updates after a major version change to the specification.\n- Expected outcome: Version management for python-tuf is implemented.\n- Recommended Skills: python\n- Mentors: Marina Moore (@mnm678), Zack Newman (@znewman01)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue: https://github.com/theupdateframework/taps/issues/136\n\n#### Succinct hashed bin delegations\n- Description: Improve hashed bin delegations in TUF by adding [succinct hashed bin delegations](https://github.com/theupdateframework/taps/blob/master/tap15.md) to the python-tuf reference implementation. TUF delegations allow the repository to specify which developer (or signing key) is associated with which packages are downloaded using TUF. Hashed bin delegations allow TUF to delegate many projects to the same signing keys more efficiently. However, the current implementation has a lot of duplicated metadata that can be simplified without affecting the functionality of this feature. This project would be implementing these simplifications to hashed bin delegations.\n- Expected outcome: Succinct hashed bin delegation are implemented in python-tuf\n- Recommended Skills: Python\n- Mentors: Marina Moore (@mnm678), Lukas Pühringer (@lukpueh), Zack Newman (@znewman01)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue: https://github.com/theupdateframework/taps/issues/132\n\n#### Repository Tool\n- Description: The Metadata API of the python-tuf reference implementation provides a modern API for accessing individual pieces of TUF metadata. It does not, however, provide any wider context help to someone looking to implement a TUF repository. The goal of this project is to implement a minimal repository abstraction that includes carefully selected core functionality, without implementing all repository actions itself. Instead it should become easy for application code on top of such an abstraction to perform those actions autonomously, while maintaining compliance with the TUF specification.\n- Expected outcome: A minimal repository abstraction is implemented.\n- Recommended Skills: Python\n- Mentors: Lukas Pühringer (@lukpueh)\n- Expected project size: 350 Hours\n- Difficulty: Hard\n- Upstream Issue: https://github.com/theupdateframework/python-tuf/issues/1136\n\n### Keylime\n\n#### Support push model for agent attestation\n\n- Description: [Keylime](http://keylime.dev) enables users to monitor remote nodes (file integrity and measured boot) using a hardware based cryptographic root of trust. Keylime currently operates on a pull basis which means that the tenant or verifier connect to the agent to collect attestation data. This works fine in most virtualized environments where all the devices are in the same network, but not for edge devices or in BYOD contexts. This work would allow remote nodes to work in a \"push\" model instead of the normal \"pull\" model.\n- Expected outcome: An implementation, corresponding tests and documentation for an agent-push model.\n- Recommended Skills: Python, Security\n- Mentor(s): Thore Sommer (@THS-on), Michael Peters (@mpeters), Marcio Silva (@maugustosilva)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/keylime/enhancements/issues/60\n\n#### Remove requirement for atomic quotes and improve validation architecture\n\n- Description: [Keylime](http://keylime.dev) enables users to monitor remote nodes (file integrity and measured boot) using a hardware based cryptographic root of trust. Keylime currently uses \"Atomic Quotes\" of PCRs from TPM security modules which can cause some extra churn in attestation and extra work for the TPM itself. These atomic quotes are not strictly necessary and removing them would help performance and scalability of the verification and also less work on the target agents.\n- Expected outcome: A new configuration option for the keylime verifier that would tell agents that generating an atomic quote is not necessary with the verifier completing the attestation without, along with corresponding tests.\n- Recommended Skills: Python, Security, Trusted Platform Modules (TPM)\n- Mentor(s): Thore Sommer (@THS-on), Michael Peters (@mpeters)\n- Expected project size: 175\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/keylime/enhancements/issues/59\n\n#### Improved Web UI for Keylime\n\n- Description: [Keylime](http://keylime.dev) enables users to monitor remote nodes (file integrity and measured boot) using a hardware based cryptographic root of trust. Most of the interactions with Keylime are via the CLI or REST APIs. There exists a bare bones web UI but it is limited in usability and usefulness. This task would be to overhaul and improve the UI to make it more usable and attractive.\n- Expected outcome: A design and implementation for a new web UI to make it easier to interact with the various keylime services in a single place.\n- Recommended Skills: Python, Javascript, Web UIs\n- Mentor(s): Michael Peters (@mpeters)\n- Expected project size: 175\n- Difficulty: Easy\n- Upstream Issue (URL): https://github.com/keylime/enhancements/issues/61\n\n#### Enhanced Event Logging\n\n- Description: [Keylime](http://keylime.dev) enables users to monitor remote nodes (file integrity and measured boot) using a hardware based cryptographic root of trust. Various keylime components currently log events and information in a text log on the machine where the process is running. Not only does this make it challenging in a distributed environment, but it is also difficult to parse through the unstructured data looking for specific historical events. We would like to create structured events for every state change in keylime (new agent registered, agent passes attestation, agent fails attestation, etc) and send those to a 3rd party system like ElasticSearch. This will allow creating more detailed dashboards as well as historical event logs for forensic analysis.\n- Expected outcome: New integrations and corresponding tests for integration with an ElasticSearch like backend to record all attestation actions and phases for each target managed by Keylime.\n- Recommended Skills: Python, ElasticSearch\n- Mentor(s): Michael Peters (@mpeters)\n- Expected project size: 175\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/keylime/enhancements/issues/62\n\n### Thanos\n\n#### Consistent Hashing in Thanos Receive Hashrings\n- Description: The current implementation of the Thanos Receive uses non-consistent hashing to distribute metrics across distributed ingesting replicas. The scalability that this enables can be improved. Because the hash is not consistent, every change in number or replicas considered for metric distribution can cause larger memory utilization for short periods. In the past, we tried to mitigate this problem by flushing the replica content to object storage which caused delays in scale-out and down. Switching to consistent hash implementation like a hash ring would allow us to mitigate this issue without delaying the scaling process. This should improve the life of Thanos receive users by enabling easier auto-scaling capabilities for production systems that have to react to different metric consumption characteristics. Join us in the effort of moving the hashing method to a consistent one!\n- Expected outcome: Thanos Receive uses a consistent hashing method instead of a non-consistent one.\n- Recommended Skills: Golang, Distributed Systems\n- Mentor(s): Lucas Servén Marín (@squat), Prem Saraswat (@onprem), Matej Gera (@matej-g)\n- Expected project size: 175\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/4972\n\n#### Compaction/Downsampling: build chunks from object storage without touching disks\n- Description: Right now during the compaction/downsampling stage, the Thanos Compactor always\ndownloads TSDB blocks to local disk first and compacts/downsamples them later. This download process\ntakes a long time if the data is large. Actually it is doable to read the data we need from the\nobject storage directly and perform the action on the fly. This improvement will help save a lot\nof disk space in larger deployment.\n- Expected outcome: On-the-fly compaction/downsampling feature is implemented and production ready.\n- Recommended Skills: Golang, Distributed Systems\n- Mentor(s): Ben Ye (@yeya24), Matej Gera (@matej-g)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/thanos-io/thanos/issues/3406\n\n### LitmusChaos\n\n#### Develop a terraform provider or scripts to provision litmuschaos functionalities\n\n- Description: [LitmusChaos](https://litmuschaos.io) is an open-source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way. This project aims to develop a terraform provider or scripts to provision litmuschaos functionalities.\n- Expected outcomes: Develop a terraform provider ( Along with the documentation ) on top of helm provider to provision litmus with the following operations\n - Install chaoscenter on k8s\n - Install chaos agent via helm\n - Add chaoshub to ChaosCenter via API provider\n - Run chaos workflows via API provider\n- Recommended Skills: Terraform, Kubernetes, Golang\n- Mentor(s): Vedant Shrotria (@Jonsy13), Raj Babu Das (@rajdas98), Adarsh Kumar (@Adarshkumar14)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/3456\n\n\n### Meshery\n\n#### Service Mesh Catalog\n\n- Description: [Meshery](https://meshery.io) Meshery is the open source, service mesh management plane that enables the adoption, operation, and management of any service mesh and their workloads. The Service Mesh Catalog project provides a place for users to consume and publishers share WebAssembly filters, [Service Mesh Patterns](https://github.com/service-mesh-patterns), eBPF programs\n- Expected outcome: Create a centralized catalog of Patterns, WebAssembly filters and eBPF programs which let's the user import, edit and deploy patterns. \n- Recommended Skills: Reactjs, TypeScript, Golang\n- Mentor(s): [Lee Calcote](https://github.com/leecalcote), [Aditya Chatterjee](https://github.com/warunicorn19)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/meshery/meshery.io/issues/677\n\n\n### Service Mesh Performance\n\n#### CNCF Cluster: Performance Benchmarking\n\n- Description: [Service Mesh Performance](https://smp-spec.io) Service Mesh Performance is a standard for capturing and characterizing the details of infrastructure capacity, service mesh configuration, and workload metadata. Service Mesh Performance test results capture rich performance profiles and realtime statistical analysis of microservices. There is a need of a dashboard of these results in which all service mesh projects are representeed, analyzed and charted visually in order to give better insight as to the performance characaterstics and value povided by cloud native infrastructure.\n- Expected outcome: \n A dashboard facilitating Service Mesh Performance profiles and results which are analysed and charted visually to give better insights to performance results.\n - Design backend for facilitating the dashboard data\n - Design frontend for visually appealing dashboard\n- Recommended Skills: Reactjs, Chartjs, DevOps, GitHub Actions, \n- Mentor(s): [Lee Calcote](https://github.com/leecalcote), [Xin Huang](https://github.com/gyohuangxin)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/service-mesh-performance/service-mesh-performance/issues/272\n\n\n### Knative\n\n#### Improve Knative Eventing End-to-End Observability by addressing top issues identified by community \n\n- Description: Today, Knative Eventing has some support for observability [1](https://knative.dev/docs/eventing/observability/logging/collecting-logs/) [2](https://knative.dev/docs/eventing/accessing-traces/) [3](https://knative.dev/docs/eventing/troubleshooting/) but it is piecewise and user needs for end-to-end observability are not fully addressed [4](https://github.com/knative/eventing/issues/3387) [5](https://github.com/knative-sandbox/eventing-kafka/issues/29) [6](https://github.com/lionelvillard/kn-trace). The idea is to find out what are the biggest gaps in Knative Eventing by asking the community. Then to find a few issues that are “low hanging” fruits that can be solved during summer with the overall goal to to simplify end-to-end observability by improving support for OpenTelemetry in Knative Eventing and/or create a new plugin(s) for kn CLI. We see that work to be accomplished in few stages. Initial Stage (few weeks) of getting used to knative-eventing with few sample applications, reach out to Knative Eventing community via mailing list and Knative Slack to ask for interviews or feedback on what are biggest problems with observability in Knative Eventing. Then first stage (few weeks) to identify the highest priority problem that can be solved in 1-2 weeks (small size), share the solution, gather feedback. Possible second stage (if time allows) to improve the features from previous stage and/or address larger problem in 3-4 weeks. And final Stage (last weeks of summer) to write Knative docs, blog post, advertise\n- Expected outcome: Improved e2e Knative Eventing observability documented and described in one or more blog posts\n- Expected size of the project: 350h\n- Difficulty rating: Medium\n- Recommended Skills: Golang skill level: Intermediate to Advanced, Kubernetes: Intermediate to Advanced, familiarity with projects: Knative Eventing, Knative Client, Prometheus, Jaeger, OpenTelemetry\n- Mentor(s): Aleksander Slominski @aslom, Ansu Varghese @aavarghese, and Lionel Villard @lionelvillard\n- Upstream Issue (URL): https://github.com/knative/eventing/issues/6247\n\n#### Make Knative running on Edge\n\n- Description: More and more workload is moving towards running on the edge. We saw experiments running Kubernetes on vehicles, fighter jets, 5G antenna and various far edge, near edge and fat edge environments. We would like to see what the challenges are when Knative is run on a resource limited environment. While there are multiple edge-friendly Kubernetes distributions, we would like to see [k0s](https://k0sproject.io/) is used as the base platform. Fixes should also go into the [mink](https://github.com/mattmoor/mink) project which is a minimal Knative+Tekton distribution. Knative consists of Serving and Eventing modules but focusing on Serving as a first step is a better idea. Stages:\n * Run Knative on k0s with minimal resources: Find out problems here, solve them.\n * Run mink on k0s: Get the fixes from previous stage into mink to make it running on k0s too.\n * Merge k0s and mink into a single binary\n * Stretch goal: Find out what happens with architectures other than x86_64.\n- Expected outcome: Finding issues blocking a minimal Knative distribution, and possibly fixing them. If there's none, actually preparing that distribution and running experiments with that. As a stretch goal, set improve the Knative CI to produce images that can run on architectures other than x86_64.\n- Expected size of the project: 350h\n- Difficulty rating: Hard\n- Recommended Skills: Golang, Kubernetes, Knative, Kubernetes Controllers\n- Mentor(s): Ali Ok @aliok, Carlos Santana @csantanapr\n- Upstream Issue (URL): https://github.com/knative/serving/issues/12718\n\n" }, { "path": "programs/summerofcode/2023.md", "content": "## Project Ideas\n\nIf you are a project maintainer and consider mentoring during the GSoC 2023 cycle, please, submit your ideas below using the template.\n\n[Google summer of code timeline](https://developers.google.com/open-source/gsoc/timeline).\n\n---\n\n### Template\n\n```\n### CNCF Project Name\n\n#### Title\n\n- Description: (2-5+ sentences)\n- Expected outcome:\n- Recommended Skills:\n- Mentor(s): (Name, github, email)\n- Expected project size: (175 or 350 Hours)\n- Difficulty: (Easy, Medium, or Hard)\n- Upstream Issue (URL):\n```\n\n---\n\n- [Ideas](#ideas)\n * [Armada](#armada)\n + [Add Kubectl Plugin for Armada](#add-kubectl-plugin-for-armada)\n + [Build interfaces around Postgres for Armada](#build-interfaces-around-postgres-for-armada)\n * [Cilium](#cilium)\n + [Remove dependencies from Tetragon](#remove-dependencies-from-tetragon)\n * [Cloud Native Buildpacks](#cloud-native-buildpacks)\n + [The Need for Speed](#the-need-for-speed)\n + [Enhancements for Dockerfiles](#enhancements-for-dockerfiles)\n * [CoreDNS](#coredns)\n + [Add DNS-over-QUIC (DoQ) and/or DNS-over-HTTP/3 (DoH3) support](#add-dns-over-quic-doq-andor-dns-over-http3-doh3-support)\n * [CRI-O](#cri-o)\n + [Add additional log drivers to conmon-rs](#add-additional-log-drivers-to-conmon-rs)\n + [Add podman support in conmon-rs](#add-podman-support-in-conmon-rs)\n * [Curve](#curve)\n + [Support metadata of Curve Block Storage stored in the database](#support-metadata-of-curve-block-storage-stored-in-the-database)\n + [Add compression feature for Curve snapshot](#add-compression-feature-for-curve-snapshot)\n + [Add Tracing feature for Curve](#add-tracing-feature-for-curve)\n * [Falco](#falco)\n + [Falco Playground: Web IDE for Security Rules with WebAssembly](#falco-playground-web-ide-for-security-rules-with-webassembly)\n * [in-toto](#in-toto)\n + [Add support for in-toto Attestations to the Python implementation](#add-support-for-in-toto-attestations-to-the-python-implementation)\n + [Improve in-toto's test setup](#improve-in-totos-test-setup)\n * [Jaeger](#jaeger)\n + [Implement ClickHouse support](#implement-clickhouse-support)\n + [Implement Critical Path analysis](#implement-critical-path-analysis)\n * [Keptn](#keptn)\n + [Keptn Plugin for Backstage](#keptn-plugin-for-backstage)\n + [Build Standard KeptnTaskDefinition Library](#build-standard-keptntaskdefinition-library)\n + [Additional Metric Providers for the Lifecycle Toolkit](#additional-metric-providers-for-the-lifecycle-toolkit)\n + [Timeframe for Metrics](#timeframe-for-metrics)\n * [Knative](#knative)\n + [Multiple Knative Eventing control planes](#multiple-knative-eventing-control-planes)\n + [Eventing Sender Identity](#eventing-sender-identity)\n + [NetworkPolicy support for Knative Serving](#networkpolicy-support-for-knative-serving)\n + [Improving Observability in Knative Eventing](#improving-observability-in-knative-eventing)\n + [Dataplane migration for Apache Kafka communications: From Vert.x to Project Loom](#dataplane-migration-for-apache-kafka-communications-from-vertx-to-project-loom)\n + [Porting Knative Serving to Microshift](#porting-knative-serving-to-microshift)\n + [Self-Balancing Knative Kafka Broker partitions](#self-balancing-knative-kafka-broker-partitions)\n * [KubeArmor](#kubearmor)\n + [GitHub Actions for KubeArmor](#github-actions-for-kubearmor)\n + [Store KubeArmor policies in OCI registry](#store-kubearmor-policies-in-oci-registry)\n * [Kubebuilder](#kubebuilder)\n + [Leverage Phase 2 Plugins API to allow creation and usage of external plugins](#leverage-phase-2-plugins-api-to-allow-creation-and-usage-of-external-plugins)\n + [Helper to upgrade the projects](#helper-to-upgrade-the-projects)\n * [Kubescape](#kubescape)\n + [Design, build and document a generic security API](#design-build-and-document-a-generic-security-api)\n + [Fully integrate Kubescape with Backstage](#fully-integrate-kubescape-with-backstage)\n * [KubeVela](#kubevela)\n + [Vela IDE Plugins](#vela-ide-plugins)\n + [Auto-generate the TypeScript and Java languages API SDK](#auto-generate-the-typescript-and-java-languages-api-sdk)\n + [Expand multiple database drivers for the API server](#expand-multiple-database-drivers-for-the-api-server)\n + [KubeVela HA Enhancement-Cluster Meta Backup&Restore](#kubevela-ha-enhancement-cluster-meta-backuprestore)\n * [Meshery](#meshery)\n + [In-browser OPA policy evaluation in WASM and Rego](#in-browser-opa-policy-evaluation-in-wasm-and-rego)\n + [[MeshModel] Kubernetes Ontology Browser](#meshmodel-kubernetes-ontology-browser)\n + [Adopt OCI as the packaging and distribution format for Meshery MeshModels](#adopt-oci-as-the-packaging-and-distribution-format-for-meshery-meshmodels)\n * [OpenFeature](#openfeature)\n + [Streamlined OpenFeature Enhancement Proposal Process](#streamlined-openfeature-enhancement-proposal-process)\n * [Prometheus](#prometheus)\n + [Support OpenMetrics `_created` timestamp in Prometheus](#support-openmetrics-_created-timestamp-in-prometheus)\n * [Strimzi](#strimzi)\n + [Proof of Concept of an MQTT to Apache Kafka bridge for producing messages](#proof-of-concept-of-an-mqtt-to-apache-kafka-bridge-for-producing-messages)\n * [The Update Framework (TUF)](#the-update-framework-tuf)\n + [Prototyping Support for Content Addressable Systems like IPFS in TUF](#prototyping-support-for-content-addressable-systems-like-ipfs-in-tuf)\n * [WasmEdge](#wasmedge)\n + [Serialization Completion](#serialization-completion)\n + [`zlib` Plugin Support](#zlib-plugin-support)\n\n---\n\n## Ideas\n\n### Armada\n\n#### Add Kubectl Plugin for Armada\n\n- Description: Armada is a multi-cluster batch scheduling platform for running high-throughput jobs. Armada provides a CLI for interacting with jobs, queues and watching events. A common way that Kubernetes users interact with Kubernetes is via kubectl. This project is to build a kubectl plugin that allows users to submit jobs to Armada using kubectl.\n- Expected outcomes:\n - Publish a [Krew Plugin](https://krew.sigs.k8s.io/) for Armada\n - Users can submit jobs, create queues, watch jobs etc using kubectl.\n- Recommend Skills: Go, Kubernetes, Kubectl\n- Mentor(s): Kevin Hannon, @kannon92, kannon1992@gmail.com\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/armadaproject/armada/issues/2120\n\n#### Build interfaces around Postgres for Armada\n\n- Description: Open source projects should not be hard coded to a particular Database. Armada currently only allows users to use Postgres. This project is to build interfaces around our connections to Postgres so we can allow other databases.\n- Expected outcomes:\n - A interface is created that allows Armada to interact with any SQL database without exposing implementation details of postgres\n - With an interface, mocking and testing becomes much easier as you can implement mocks for the DB access. Currently we require a postgres DB for unit testing.\n - Test coverage could increase\n- Recommend Skills: Go, SQL\n- Mentor(s):\n - Kevin Hannon, @kannon92, kannon1992@gmail.com\n - Geoffrey Wilson, @suprjinx, geoff@gr-oss.com\n- Expected project size: 350 Hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/armadaproject/armada/issues/2121\n\n### Cilium\n\n#### Remove Dependencies From Tetragon\n\n- Description: Tetragon can run both with and without Cilium on the same node. Some functionality, however, still depends on the Cilium agent being present. Specifically, Tetragon uses Cilium to retrieve the pod information for destination IPs for pods which are not local to the node. The goal of this project is to introduce this functionality on Tetragon. One approach would be for the Tetragon agent to keep information about all pods in the cluster, but this approach does not scale well due to the Kubernetes API server needing to propagate all pod information to all nodes. Instead, the plan is to introduce a new custom resource (CR) which is maintained by the Tetragon operator and provides a mapping from IPs to the small subset of pod information that Tetragon needs. The Tetragon operator will monitor pod information and update the resource as needed. Tetragon agents will watch this CR to provide pod information for destination IPs.\n\n- Expected outcome: Cilium dependency is removed from Tetragon\n- Recommended Skills: Go, Kubernetes\n- Mentor(s): Michi Mutsuzaki, michi-covalent, michi@isovalent.com. Kornilios Kourtis, kkourt,kornilios@isovalent.com\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/cilium/tetragon/issues/794\n\n### Cloud Native Buildpacks\n\n#### The Need for Speed\n\n- Description: Cloud Native Buildpacks are integral to the release and deployment of multiple platforms, which means speed of execution is a feature our users depend on. However there's currently no suite of benchmark tests to catch regressions in speed, nor have we done systematic profiling to look for easy wins or small changes that could decrease runtime of common operations. This is an excellent skill to build early in one's career as it tends to be portable between projects and is often appreciated.\n- Expected outcome: Existence of one or more benchmark tests in the [lifecycle](https://github.com/buildpacks/lifecycle/) repository that can run as part of the Pull Request suite. After creating benchmarks, we can apply profiling to look for speedups, so the best possible outcome will also include documented user-facing performance improvements.\n- Recommended Skills: Golang, software development literacy. We will provide mentorship re. benchmarking and profiling and integrating results with github actions.\n- Mentor(s): Natalie Arellano (@natalieparellano); Joe Kimmel (@joe-kimmel-vmw)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/buildpacks/lifecycle/issues/993\n\n\n#### Enhancements for Dockerfiles\n\n- Description: Build out samples and workflows showing how to use Dockerfiles in\n harmony with a cloud native buildpacks platform.\n- Expected outcome: updating the `pack` implementation to be more performant by taking advantage of the available daemon, and updating documentation and sample workflows to reflect the changes\n- Recommended Skills: Golang, software development literacy, familiarity with the Cloud Native Buildpacks spec, familiarity with Docker and Dockerfiles.\n- Mentor(s): Natalie Arellano (@natalieparellano)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/buildpacks/pack/issues/1623\n\n### CoreDNS\n\n#### Add DNS-over-QUIC (DoQ) and/or DNS-over-HTTP/3 (DoH3) support\n\n- Description: DNS-over-QUIC (DoQ) and DNS-over-HTTP/3 (DoH3) are relatively new protocols for transmitting DNS queries with security and privacy. Additionally, DoQ and DoH3 also offers other benefits such as improved latency and better error detection. The goal of this proposal is to add DoQ and/or DoH3 support to CoreDNS.\n- Expected outcome: An implementation of DoQ or DoH3 for CoreDNS. A stretch goal of adding both DoQ and DoH3 is also within scope.\n- Recommended Skills: Golang, DNS.\n- Mentor(s): Yong Tang @yongtang (yong.tang.github@outlook.com); Chris O'Haver @chrisohaver (cohaver@infoblox.com)\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/coredns/coredns/issues/5583, https://github.com/coredns/coredns/issues/5539\n\n### CRI-O\n\n#### Add additional log drivers to conmon-rs\n\n- Description: conmon-rs is a container monitor written in Rust, used by CRI-O to monitor a container's lifecycle. Part of its responsibilities is log forwarding--taking the output of the container and writing that output to various places. Currently, conmon-rs supports one format: the one required by the Kubernetes CRI. The goal of this proposal is to add new log formats from the list of standardized ones, like JSON, Splunk, Journald.\n- Expected outcome: A JSON log driver and Journald log driver are added to conmon-rs. A stretch goal of adding a Splunk log driver is also within scope.\n- Recommended Skills: Rust, familiarity with containers\n- Mentor(s): Peter Hunt, haircommander, pehunt@redhat.com; Sascha Grunert, saschagrunert, mail@saschagrunert.de\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/containers/conmon-rs/issues/1126\n\n#### Add podman support in conmon-rs\n\n- Description: conmon-rs is a container monitor written in Rust, used by CRI-O to monitor a container's lifecycle. In order to declare stability of conmon-rs for CRI-O, many features have to be added for its sibling project: [podman](podman.io). The goal of this proposal is to add additional features that are required by podman to conmon-rs, so conmon-rs can be stabalied\n- Expected outcome: Additional CreateContainer request options are added and supported in conmon-rs to finalize support for podman. Further, the RestoreContainer RPC should be added and supported.\n- Recommended Skills: Rust, familiarity with containers\n- Mentor(s): Peter Hunt, haircommander, pehunt@redhat.com; Matt Heon, mheon, mheon@redhat.com\n- Expected project size: 350 Hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/containers/conmon-rs/issues/1127\n\n### Curve\n\n#### Support metadata of Curve Block Storage stored in the database\n\n- Description: Currently the [metadata](https://github.com/opencurve/curve/blob/master/src/mds/nameserver2/namespace_storage.cpp) of current CurveBS is stored in [Etcd](https://github.com/opencurve/curve/tree/master/src/kvstorageclient). However, Etcd has limited scalability, and the amount of metadata that can be stored is limited. In order to support larger clusters, it is hoped that the metadata can add a sql database like mysql, MariaDB, PostgreSQL, etc. as one of the storage engines. Add a new sqlstorageclient for [metadata](https://github.com/opencurve/curve/blob/master/src/mds/nameserver2/namespace_storage.cpp).\n- Expected outcome: It is hoped that the user can choose whether the metadata is stored in the kv engine or the sql engine through the configuration file.\n- Recommended Skills: C++, SQL\n- Mentor(s): Xiaocui Li @ilixiaocui (ilixiaocui@163.com)\n- Expected project size: 175h\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/opencurve/curve/issues/2224\n\n#### Add compression feature for Curve snapshot\n\n- Description: Curve snapshots are currently uploaded to s3, and no compression is used. Using compression can greatly reduce the space occupied by snapshots, thereby saving storage costs.\n- Expected outcome: 1） Detailed Design Documentation 2） Realize curve snapshot compression upload and download decompression 3） Add unit tests and integration test cases 4） Merge your PR into the opencurve repo\n- Recommended Skills: C++\n- Mentor(s): Chaojie Xu @xu-chaojie (xuchaojie@outlook.com)\n- Expected project size: 175 hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/opencurve/curve/issues/2223\n\n#### Add Tracing feature for Curve\n\n- Description: At present, Curve has logging and metrics, both of which can be used to analyze performance as well as locate problems. While they improve the observability of the system, the granularity is coarse and does not allow for precise analysis of how long requests take at each stage. Tracing is a powerful tool that can concatenate invocation relationships between services and log invocation time in the request dimension, preserving essential information and concatenating dispersed log events to help us better understand system behavior, assist in debugging and troubleshooting performance issues.\n- Expected outcome: Design the solution and implement it, introduce it into CurveBS, and analyze the latency of IO requests. The implementation needs to be well scalable and can be applied to other modules.\n- Recommended Skills: C++, OpenTracing\n- Mentor(s): Hanqing Wu @wu-hanqing (wuhanqing@corp.netease.com)\n- Expected project size: 350 hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/opencurve/curve/issues/2229\n\n### Falco\n\n#### Falco Playground: Web IDE for Security Rules with WebAssembly\n\n- Description: [Falco](https://falco.org/) provides an intuitive and highly expressive rule language for configuring its powerful runtime security engine. However, the community still lacks an official and frictionless IDE solution for writing and testing Falco rules. Since the last few releases, [the Falco libraries](https://github.com/falcosecurity/libs) increased the support for multiple architectures and platforms, and the integrated rules validator added a new output in machine-readable JSON format. The idea for this project is to add WebAssembly as a new officially-supported compilation target for Falco by leveraging the [Emscripten toolchain](https://emscripten.org/), and creating a new development environment for security rules in the form of a web single-page application by running Falco right inside the browser. The end result is envisioned to be similar to [the Go Playground](https://go.dev/play/), but without the need of any backend. The beauty of this idea is the opportunity of experiencing very different technologies of the cloud-native landscape all in a single project: low-level system code close to the Linux kernel, the fast-growing WebAssembly world, and frontend development for a web application.\n- Expected outcome: The contributor will collaborate with the Falco maintainers to introduce WebAssembly as a new supported compilation target, and will work on the frontend development of the web application. The feasibility of the project has already been assessed. The rules editor playground will dramatically benefit the learning curve and the development experience of security practitioners writing Falco rules, and will be the basis on which new educational content could be created for the community. A stretch goal would be to provide reusable groundwork for future integrations with other IDEs supporting WebAssembly, such as Visual Studio Code.\n- Recommended Skills: Familiarity with C/C++, JavaScript or Typescript, a frontend framework of choice (React, Vue, Angular, Svelte, etc…)\n- Mentor(s): Jason Dellaluce, [@jasondellaluce](https://github.com/jasondellaluce/), jasondellaluce@gmail.com\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/falcosecurity/evolution/issues/262\n\n### in-toto\n\n#### Add support for in-toto Attestations to the Python implementation\n\n- Description: in-toto's Python implementation currently does not support the generation of the new-style [in-toto Attestations](https://github.com/in-toto/attestation). The implementation must be updated with the schemas for attestations and some commonly used predicate types such as SLSA Provenance.\n- Expected outcome: in-toto-python includes support for attestations and some predicate types.\n- Recommended Skills: Python\n- Mentor(s): Aditya Sirish A Yelgundhalli (@adityasaky, aditya DOT sirish AT nyu DOT edu), Santiago Torres-Arias (@SantiagoTorres, santiagotorres AT purdue DOT edu)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/in-toto/in-toto/issues/562\n\n#### Improve in-toto's test setup\n\n- Description: in-toto maintains four implementations written in Python, Go, Java, and Rust. While all of them were written using the same specification, they are not currently tested against each other to ensure compatibility. Part of this task, therefore, is to implement cross-implementation testing for common in-toto workflows such as generating metadata with one implementation and verifying it with another. Additionally, in-toto's implementation releases are not tested against releases of dependencies that have breaking changes. In some situations, users who interact with in-toto's tooling may update a dependency that breaks in-toto. The other part of this task is to implement this testing framework.\n- Expected outcome: in-toto implementations are better tested against each other and their dependencies.\n- Recommended Skills: Python, Go, optionally some Rust and Java\n- Mentor(s): Aditya Sirish A Yelgundhalli (@adityasaky, aditya DOT sirish AT nyu DOT edu), Santiago Torres-Arias (@SantiagoTorres, santiagotorres AT purdue DOT edu)\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/in-toto/in-toto/issues/563\n\n### Jaeger\n\n#### Implement ClickHouse support\n\n- Description: Jaeger (https://jaegertracing.io) is a popular platform for distributed tracing. ClickHouse is a powerful columnar database, utilized in many commercial and some open source monitoring products. Jaeger currently has a community-provided (unofficial) plugin that implements Jaeger storage backend on top of ClickHouse. This project is to build first-class support for ClickHouse in Jaeger as a core functionality.\n- Expected outcomes:\n - Design table schema, document trade-offs\n - Implement ClickHouse support as core storage backend\n - Address schema creation problem / tooling\n - Add relevant documentation to the Jaeger website\n- Stretch goals:\n - Use Kafka Connector for ClickHouse for bulk inserts\n - Support Monitoring tab in Jaeger directly from ClickHouse\n- Recommended Skills: Go, SQL\n- Mentor(s): Yuri Shkuro, @yurishkuro\n- Expected project size: 350 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/jaegertracing/jaeger/issues/4196\n\n#### Implement Critical Path analysis\n\n- Description: Jaeger (https://jaegertracing.io) is a popular platform for distributed tracing. Critical path analysis is an important tool in the latency investigations. This project aims to add support for critical path analysis to Jaeger UI.\n- Expected outcomes:\n - Implement critical path determination algorithm\n - Enhance Trace Timeline view to overlay critical path on top of the trace.\n - Add relevant documentation to the Jaeger website\n - Author a blog post on Jaeger blog explaining the new feature\n- Stretch goals:\n - Add critical path visualization to other trace views (graph, table, flamechart)\n- Recommended Skills: Javascript, Typescript\n- Mentor(s): Yuri Shkuro, @yurishkuro\n- Expected project size: 175 Hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/jaegertracing/jaeger-ui/issues/1288\n\n### Keptn\n\n#### Keptn Plugin for Backstage\n\n- Description: Backstage is an open platform for building developer portals. As the website states, \"powered by a centralized software catalog, Backstage restores order to your infrastructure and enables your product teams to ship high-quality code quickly — without compromising autonomy\". It would be nice to provide Keptn integration for this portal so that Keptn can connect as many as other tools. See all Backstage Plugins. A Possible solution could be a specialized plugin for Keptn using Keptn REST API and/or CLI. It might be also possible to create a unified plugin for Keptn and other CI/CD tools, e.g. implemented on the top of the Cloud Events / CDEvents standard.\n- Expected outcome: Finding issues blocking multiple control planes, and possibly fixing them.\n- Recommended Skills: Typescript, Javascript, React, Backstage\n- Mentor(s): [Brad McCoy](https://github.com/bradmccoydev) bradmccoydev@gmail.com\n- Expected project size: 175h\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/keptn/integrations/issues/19\n\n#### Build Standard KeptnTaskDefinition Library\n- Description: [Keptn Lifecycle Toolkit (KLT)](https://github.com/keptn/lifecycle-toolkit) can run pre and post deployment tasks. Currently KLT supports the [Deno](https://deno.land) runtime. KeptnTasks can be used for almost anything that an individual can dream up and script in JavaScript. However, users (especially new adopters) usually need a useful set of example tasks that they can use and / or modify to suit their requirements.\n\nThis project would build such a library of re-usable tasks for common tasks such as:\n\n- Notifying Chat tools\n- Triggering external tools (eg. a pipeline)\n- Integrations with Systems of Record (i.e. to update a CMDB)\n\nThis project lends itself to GSoC due to the modular nature of the tasks which almost guarantees that something will be delivered - the task delivery can be planned an organised easily into sprints across the project lifecycle. It is also relatively easy - given that the tasks are simply JavaScript - it should be easy for most first time contributors.\n\n- Expected outcome: A catalogue of useful, re-usable `KeptnTaskDefinitions` that will serve as useful reference material for adopters\n- Recommended Skills: Typescript and / or JavaScript, basic understanding of Keptn Lifecycle Toolkit, Kubernetes basic knowledge, knowledge of CRDs\n- Mentor[s]: [Adam Gardner (adam at agardner dot net)](https://github.com/agardnerit)\n- Expected project size: 175h\n- Difficulty: Easy\n- Upstream Issue (URL): https://github.com/keptn-contrib/klt-tasks/issues/3\n\n#### Additional Metric Providers for the Lifecycle Toolkit\n\n- Description: At the moment, Keptn Metrics only support Prometheus and Dynatrace providing metrics, but there are many other metric providers out there. The goal of this project is to add support for additional metric providers.\n- Expected outcome: Create at least 3-5 additional metrics providers for the lifecycle toolkit, Document their usage and provide examples\n- Recommended Skills: Go, Kubernetes, Prometheus, Observability in General\n- Mentor(s): Thomas Schuetz @thschue (thomas.schuetz at t-sc dot eu), Anna Reale @RealAnna (anna.reale at dynatrace dot com)\n- Expected project size: 175h\n- Difficulty: Easy\n- Upstream Issue (URL): https://github.com/keptn/lifecycle-toolkit/issues/745\n\n#### Timeframe for Metrics\n\n- Description: The main idea of this proposal is to make it possible to define timeframes for metrics and get standardized aggregated results for this timeframe. For instance, it should be possible to query the metrics for the last n minutes, hours, days, weeks, months, years, etc. and get the aggregated results for this timeframe.\n- Expected outcome: Propose a solution for this issue, Implement the solution and provide docs and examples, provide tests\n- Recommended Skills: Go, Kubernetes, Prometheus, Observability in General\n- Mentor(s): Thomas Schuetz @thschue (thomas.schuetz at t-sc dot eu), Florian Bacher @bacherfl (florian.bacher at dynatrace dot com)\n- Expected project size: 175h\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/keptn/lifecycle-toolkit/issues/859\n\n### Knative\n\n#### Multiple Knative Eventing control planes\n\n- Description: We see more users asking for complete isolation in Knative Eventing deployments. While there are Knative Eventing components that support isolated data planes, we are interested in to see isolated control planes as well. There were discussions about this in the community before and many of the asks were left unadressed. However, we have tools that support multitenancy today, such as [kcp](https://github.com/kcp-dev/kcp). We see this project as an experiment.\n- Expected outcome: Finding issues blocking multiple control planes, and possibly fixing them.\n- Recommended Skills: Golang, Kubernetes, Knative, Kubernetes Controllers\n- Mentor(s): Ali Ok @aliok (aliok AT redhat DOT com), Christoph Stäbler @creydr (cstaebler AT redhat DOT com)\n- Expected project size: 350h\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/knative/eventing/issues/6601\n\n#### Eventing Sender Identity\n\n- Description: Leveraging Kubernetes Service Account identity and OAuth audiences, users should be able to configure Knative Eventing components to authenticate CloudEvent deliveries using the identity of the Subscription, Trigger, or Source. Additionally, Brokers and Channels can leverage the OAuth identity associated with incoming CloudEvents to implement policy.\n- Expected outcome: At least the following components are able to use service accounts for authentication: in-memory-channel, multitenant broker, apiserver source, ping source. Ideally, the primitives from this project could be re-used by other channel and broker implementations.\n- Recommended Skills: Golang, Kubernetes, OAuth or OIDC\n- Mentor(s): Evan Anderson @evankanderson\n- Expected project size: 350h\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/knative/eventing/issues/5047\n\n#### NetworkPolicy support for Knative Serving\n\n- Description: Implement port-level network routing for Knative Serving internal addresses. This will be an extension of https://github.com/knative-sandbox/net-kourier/pull/852 to other Knative Ingress implementations, along with implementation of default NetworkPolicies for the activator and Knative Revisions to enforce that requests are routed through the Knative Ingress.\n- Expected outcome: Users will be able to use NetworkPolicy to restrict access to their Knative Services at a network (L4 / TCP) level.\n- Recommended Skills: Golang, Kubernetes networking, Envoy or protocol familiarity with HTTP\n- Mentor(s): Evan Anderson @evankanderson\n- Expected project size: 350h\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/knative/serving/issues/13780\n\n#### Improving Observability in Knative Eventing\n\n- Description: We see users struggling to observe what happens inside Knative Eventing and we want that to be improved by providing easy to use tools. The idea is divided into stages. First stage is to write code (python and/or golang) that implements a plugin for Knative command-line interface (kn CLI). The plugin takes output from observability data gathered by Knative and answers simple questions such as: where did my event go based on event id? Show clusters/groups of common traces and show exceptions? The plugin should be able to verify that necessary Knative configuration for observability is enabled, access server side components. Possible next stages may be to create active probes that add to CLI capability to send probe events to specific Knative components (such as Kafka source or broker) and report if they work as expected (health checks). Another area to explore is using conversational AI to improve the plugin by using AI to parse natural language input and/or process available observability data for common Knative questions. As part of the work there may be proposed fixes and improvements for identified gaps in Knative observability that may be discovered when testing the plugin.\n- Expected outcome: Improved Knative Eventing observability, improved documentation and published one or more blog posts\n- Recommended Skills: Python, data science skills, Golang, Kubernetes\n- Mentor(s): Aleksander Slominski @aslom (aslomins AT redhat DOT com), Ansu Varghese @aavarghese (anvarghe AT redhat DOT com), and Lionel Villard @lionelvillard (lvillard AT redhat DOT com)\n- Expected project size: 350h\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/knative/eventing/issues/6247\n\n#### Dataplane migration for Apache Kafka communications: From Vert.x to Project Loom\n\n- Description: The Knative Broker's data-plane communication with Apache Kafka for consuming and producing records is currently done via the Vertx Kafka client [library](https://github.com/vert-x3/vertx-kafka-client). The library is basically a wrapper for communications with Apache Kafka inside of the Vertx threading model. This project requires an evaluation the OpenJDK 19 [\"Project Loom\"](https://wiki.openjdk.org/display/loom) itself and how to leverage it for efficient communications with an Apache Kafka cluster. The goal of the project is to migrate the usage of Vertx for any communications with Apache Kafka to pure OpenJDK 19's Loom, and reduce the number of 3rd party frameworks, such as vertx for Apache Kafka communication.\n- Expected outcome: OpenJDK 19 gets evaluated for our use case, Knative Kafka Broker gets migrated to use Loom for Apache Kafka communication.\n- Recommended Skills: Java, Apache Kafka, understanding of Kubernetes\n- Mentor(s): Matthias Wessendorf @matzew (matzew AT redhat DOT com), Pierangelo Di Pilato @pierDipi (pierdipi AT redhat DOT com)\n- Expected project size: 350h\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/knative-sandbox/eventing-kafka-broker/issues/2928\n\n#### Porting Knative Serving to Microshift\n\n- Description: More and more workload is moving towards running on the edge. We saw experiments running Kubernetes on vehicles, fighter jets, 5G antenna and various far edge, near edge and fat edge environments. We would like to see what the challenges are when Knative is run in a resource limited environment. While there are multiple edge-friendly Kubernetes distributions, we would like to see [Microshift](https://github.com/openshift/microshift) used as the base platform. Knative consists of Serving and Eventing modules but focusing on Knative Serving as a first step should be more approachable. The project consists of 2 stages. First one is to run Knative on Microshift with minimal resources. This requires finding out problems here, solving them. A stretch goal is to find out what happens with architectures other than x86_64.\n- Expected outcome: Having Knative Serving with an ingress layer running on top of Microshift. Having a Hello-World Knative Service running on top. Finding issues blocking the edge setup, and possibly fixing them.\n- Recommended Skills: Golang, Kubernetes, Knative, good understanding of networking, good understanding of CI/CD\n- Mentor(s): Reto Lehmann @ReToCode (rlehmann AT redhat DOT com), Stavros Kontopoulos @skonto (skontopo AT redhat DOT com)\n- Expected project size: 350h\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/knative/serving/issues/12718\n\n#### Self-Balancing Knative Kafka Broker partitions\n\n- Description: Creating a Knative Kafka Broker requires developers to specify the number of partitions the backing Kafka topic should have, however, this is not an easy decision to make and it requires planning based on the expected load the Knative Broker could receive. This project aims to remove this configuration setting by having an autoscaler that is responsible to add or remove partitions based on the effective load the Knative Kafka Broker receives while preserving [ordered and unordered delivery features](https://knative.dev/docs/eventing/brokers/broker-types/kafka-broker/#configuring-the-order-of-delivered-events) for Triggers.\n- Expected outcome: A Knative Kafka Broker can be created without setting the number of partitions and the number of partitions for a topic backing the Knative Kafka Broker increases or decreases based on the observed load received.\n- Recommended Skills: Kubernetes, Apache Kafka, Go, Java\n- Mentor(s): Pierangelo Di Pilato @pierDipi (pierdipi AT redhat DOT com), Ali Ok @aliok (aliok AT redhat DOT com)\n- Expected project size: 350h\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/knative-sandbox/eventing-kafka-broker/issues/2917\n\n### KubeArmor\n\n#### GitHub Actions for KubeArmor\n\n- Description: Build a GitHub action to allow the usage of KubeArmor in the CI. KubeArmor should be able to identify change in the application posture early in the dev life cycle. If the app changes results in new app behavior such as new process invocation or new file system access or new network connections, then the same has to be highlighted early in the application life cycle so that the security posture changes can be handled accordingly.\n- Expected outcome: [`karmor summary`](https://github.com/kubearmor/kubearmor-client/) provides a way to verify the [application behavior](https://github.com/kubearmor/KubeArmor/blob/main/getting-started/workload_visibility.md). The aim here would be to baseline the application behavior and check for any deviation during subsequent application updates. It then should look for any potential security gaps and recommend policies leveraging based on that.\nThe action should be able to generate a summary using baseline benchmark and then show the application based changes in the graphical mode.\n- Mentor(s): Ankur Kothiwal(Ankurk99, ankur DOT kothiwal99 AT gmail DOT com), Anurag Kumar(kranurag7, contact DOT anurag7 AT gmail DOT com), Barun Acharya(daemon1024, barun1024 AT gmail DOT com)\n- Expected project size: 175 Hours\n- Recommended Skills: Kubernetes, GitHub Actions\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubearmor/KubeArmor/issues/1128\n\n#### Store KubeArmor policies in OCI registry\n\n- Description: Store KubeArmor policies & host policies as OCI Artifacts.\nOCI Artifacts are a set of conventions that allows us to store assets other than the container images, like Helm Charts, inside an OCI registry.\n[Artifact Hub](https://artifacthub.io/) is a website where users can find, install, and publish packages and configurations for CNCF projects. The idea is to use Artifact Hub for pushing, pulling and verifying the authenticity of KubeArmor policies using [cosign](https://github.com/sigstore/cosign).\n- Expected outcome: The contributor is expected to create subcommand for `karmor` to interact with OCI registries for pushing, pulling and verifying policies based on OCI Artifacts specification.\n- Mentor(s): Ankur Kothiwal(Ankurk99, ankur DOT kothiwal99 AT gmail DOT com), Anurag Kumar(kranurag7, contact DOT anurag7 AT gmail DOT com), Barun Acharya(daemon1024, barun1024 AT gmail DOT com)\n- Expected project size: 175 Hours\n- Recommended Skills: Go, Containers\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubearmor/KubeArmor/issues/1130\n\n### Kubebuilder\n\n#### Leverage Phase 2 Plugins API to allow creation and usage of external plugins\n\n- Description: Kubebuilder introduced [Phase 2 Plugins](https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/extensible-cli-and-scaffolding-plugins-phase-2.md) to make itself more extensible as a CLI and as a library. This enables the community to develop, use, maintain and release their own plugins independently. Phase 2 Plugins has been available for a few releases, and in order to further increase and help facilitate adoption of this functionality, we need to work on creating an extensive sample, documentation and tutorial on how to build and use external plugins. To be able to achieve this goal, we can use Go, Ansible, Python or Helm to create the sample external plugin that will be used as a central reference plugin that serves as an example of an external plugin that leverages Phase 2 Plugins.\n\n- Expected outcome:\n - Finish the remaining tasks in the meta task (the big task that tracks various subtasks for the feature): \n - Ensure the quality of the sample and Phase 2 Plugins API by:\n - Adding e2e tests which should validate that the sample can be built and used with the Kubebuilder CLI.\n - Implementing a maintainable solution to ensure that the sample will not get outdated.\n - We might need to so something like: \n - However, a dependabot for the sample might suffice in this case, just to ensure the dependencies.\n - Review and improve the Plugin documentation to ensure that we the community can easily leverage the Phase 2 Plugins API: \n - Verify that we are generating go docs for the Phase 2 Plugins API.\n - Create a tutorial with the sample to let the community and users know how to build and use their own external plugins.\n - Add an extra sample using any other language other than Golang.\n - Create a video demo to showcase the Phase 2 Plugin working with the sample. This will demonstrate the achievements and will be shared with the community. We also will add the link to the demo in the docs.\n- Recommended Skills: Go\n- Mentor(s): [Rashmi Gottipati](https://github.com/rashmigottipati) (rgottipa AT redhat DOT com), [Bryce Palmer](https://github.com/everettraven) (bpalmer AT redhat DOT com)\n- Expected project size: 350h\n- Difficulty: Medium\n- Upstream Issue (URL): \n\n#### Helper to upgrade the projects\n\n- Description: Things change, and we constantly grow the [KubeBuilder](https://github.com/kubernetes-sigs/kubebuilder), providing new features and bug fixes. Also, sometimes it is required to address incompatible changes via new plugin versions. However, all changes and growth bring some complexities to its users keeping their solutions upgraded and adopting all that is new. The primary motivation of this project is to provide a helper via a command CLI that will automate a common and manual part of this process and try to make it less painful. Also, this project will add a lot of value for Kubebuilder, and its maintainers since it can encourage their users to move forward more frequently. We might be able to use this feature to create lovely automation using git and provide GitHub actions in the future. Note that we have a design proposal to develop the initial version of this feature, which is expected in this project. However, your ideas and input to solve this challenge will be very welcome!\n- Expected outcome:\n - Develop a helper to achieve the goal, making it easier for users to upgrade their projects.\n - Interact with the community: make sure the roadmap is generally expected, and continuously receive feedback to move forward with the project.\n - Make the helpers covered adequately with tests and documentation\n - Demonstrate the feature in the community meeting\n- Recommended Skills: Go\n- Mentor(s): [Camila Macedo](https://github.com/camilamacedo86) (camilamacedo86 AT gmail DOT com), [Varsha](https://github.com/varshaprasad96) (vnarsing AT redhat DOT com), [Tony (TianYi)](https://github.com/Kavinjsir) (kavinjsir AT gmail DOT com)\n- Expected project size: 350h\n- Difficulty: Medium\n- Upstream Issue (URL): \n\n### Kubescape\n\n#### Design, build and document a generic security API\n\n- Description: Kubescape has the ability to submit scan results to a backend service, which can then store them and provide UIs to give insight over time as to a users' security posture. There is an implementation of this API by the commercial service that Kubescape's original creators, ARMO, runs. We would like to fully document this API, and improve it for future use cases, which may eventually have a wider scope than just Kubescape itself. If the student wants to extend the project, they could also build a sample backend to store data in-cluster using this API. (Please specify in your application if you are looking to work half or full time.)\n- Expected outcome: An improved and fully-documented API for how to send scan results from a Kubescape client to a security backend service. \n- Recommended Skills: Go, OpenAPI\n- Mentor(s): [Craig Box](https://github.com/craigbox), [Ben Hirschberg](https://github.com/slashben)\n- Expected project size: 175h for API only, 350h for API + sample backend\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubescape/kubescape/issues/1172\n\n#### Fully integrate Kubescape with Backstage\n\n- Description: Kubescape is a platform that can scan clusters for configuration and vulnerability issues. Some work has been done to integrate Kubescape with Backstage, to present the data from a cluster. This project will build on that work by making Backstage a fully-supported method for interacting with Kubescape's in-cluster components and API server. If the student is interested the project could be extended to add a Grafana dashboard to display information in a similar fashion. (Please specify in your application if you are looking to work half or full time.)\n- Expected outcome: A production-ready Backstage plugin for Kubescape in the [plugin marketplace](https://backstage.io/plugins/)\n- Recommended Skills: TypeScript, React, Go \n- Mentor(s): [Craig Box](https://github.com/craigbox), [Ben Hirschberg](https://github.com/slashben)\n- Expected project size: 175h for Backstage only, 350h for Backstage + Grafana\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/kubescape/kubescape/issues/1173\n\n### KubeVela\n\n#### Vela IDE Plugins\n\n- Description: With more and more developers start writing KubeVela (OAM) application YAML file and CUE-based X-Definitions, it is increasingly important to provide some tools to help user make correct configurations. IDE plugin is one way to reach that. We can make VSCode/Jetbrains plugins for formatting and previewing the written applications and KubeVela's X-Definitions. The plugin should be able to sync environment data (including installed X-Definitions) and make dryrun preview for the rendering result of applications intelligently. It can also provide preview capability for the selected clusters when topology policy is written. Live-diff for the current application and remote application configuration is useful as well. In addition to the application, when users write X-Defintinitions based on CUELang, auto validating and previewing for rendering results under mock inputs can also support them.\n- Expected outcome: IDE Plugins for KubeVela, or standalone desktop apps\n- Recommended Skills: Golang, Kubernetes, NodeJS, KubeVela, CUELang\n- Mentor(s): Da Yin @Somefive\n- Expected project size: 350h\n- Difficulty: Hard\n- Upstream Issues (URL): https://github.com/kubevela/kubevela/issues/5366\n\n#### Auto-generate the TypeScript and Java languages API SDK\n\n- Description: Some developers have started to integrate KubeVela into the enterprise system. It is getting increasingly important to provide an API SDK to help developers start faster. Java and TypeScript are currently the two most in-demand languages. KubeVela API server follows the Open API schema. It means the Open API generator tools could provide some help.\n- Expected outcomes:\n - Commit the high-quality SDK code, include the TypeScript and Java languages.\n - Commit the GitHub action config and tools to auto-generate SDK.\n- Recommended Skills: Java, TypeScript, NodeJS, KubeVela, GithubAction\n- Mentor(s): QingGuo Zeng @barnettZQG (barnett.zqg AT gmail.com)\n- Expected project size: 175h\n- Difficulty: Medium\n- Upstream Issues (URL): https://github.com/kubevela/kubevela/issues/5428\n\n#### Expand multiple database drivers for the API server\n\n- Description: The API server of the KubeVela needs to save the metadata data to the database to obtain more efficient query efficiency and larger storage space. Now we only support MongoDB. Some users don't have the MongoDB infrastructure. Mysql and PostgreSQL drivers are needed by many users. Most users install the KubeVela without the database. When they want to use it for production, the existing data need to migrate to one database. The migration tool is important.\n- Expected outcomes:\n - Commit the Mysql driver code.\n - Commit the PostgreSQL driver code.\n - Commit the migrate data tool code.\n- Recommended Skills: Go, KubeVela, Mysql, PostgreSQL\n- Mentor(s): QingGuo Zeng @barnettZQG (barnett.zqg AT gmail.com)\n- Expected project size: 175h\n- Difficulty: Medium\n- Upstream Issues (URL): https://github.com/kubevela/kubevela/issues/5426\n\n#### KubeVela HA Enhancement-Cluster Meta Backup&Restore\n\n- Description: KubeVela can be deployed in a single management cluster.The KubeVela management cluster has a single point of risk. When KubeVela management clusterdisaster occurs, business continuity cannot be guaranteed. In the production environment of enterprise use case(financial industry), KubeVela needs to have higher availability requirements. Consider these three enhancements to achieve this goal: cluster meta backup & recovery, master redundancy, failover support. Cluster meta backup & recovery is baseline feature for velaha.\n- Expected outcomes:\n - implement velero as KubeVela addon to install velero in kubevela cluster.\n - implement `cli> vela ha enable` to enable cluster meta backup with config scheduled(cron).\n - implement `cli> vela ha restore` to restore cluster meta.\n- Recommended Skills: Golang, Kubernetes, KubeVela, CUELang\n- Mentor(s): Jiahang Xu @jefree-cat(jiahang_xu@cmbchina.com), Xiangbo Ma @fourierr(maxiangboo@gmail.com)\n- Expected project size: 350h\n- Difficulty: Medium\n- Upstream Issues (URL): https://github.com/kubevela/kubevela/issues/5483\n\n### Meshery\n\n#### In-browser OPA policy evaluation in WASM and Rego\n\n- Description: Meshery's highly dynamic infrastructure configuration capabilities require real-time evaluation of complex policies. Policies of various types and with a high number of parameters need to be evaluted client-side. With policies expressed in Rego, the goal of this project is to incorporate use of the https://github.com/open-policy-agent/golang-opa-wasm project into Meshery UI, so that a powerful, real-time user experience is possible.\n- Expected outcome:\n- Recommended Skills: Golang, Open Policy Agent, WASM\n- Mentor(s): Lee Calcote @leecalcote (leecalcote@gmail.com), Abhishek Kumar @Abhishek-kumar09 (abhimait1909@gmail.com)\n- Expected project size: 350 hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/7019\n\n#### [MeshModel] Kubernetes Ontology Browser\n\n- Description: Network topologies and graph databases go hand-in-hand. The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph.\n- Expected outcome: \n - Web-based MeshModel capabilities browser\n - Modeling in graph database\n - Augmentation of cuelang-based component generator\n - Stretch: Import/export of MeshModel models and components as OCI images\n- Recommended Skills: Reactjs, Golang, Cuelang, GraphQL, OpenAPI Schema\n- Mentor(s): Lee Calcote @leecalcote (leecalcote@gmail.com), Abhishek Kumar @Abhishek-kumar09 (abhimait1909@gmail.com)\n- Expected project size: 350 hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/7465\n\n#### Adopt OCI as the packaging and distribution format for Meshery MeshModels\n\n- Description: Meshery MeshModels represent a schema-based description of cloud native infratructure. MeshModels need to be portable between Meshery deployments as well as easily versionable in external repositories. \n- Expected outcome:\n - Meshery clients (mesheryctl and Meshery UI) should be able to import/export MeshModels as OCI images.\n - Meshery clients (mesheryctl and Meshery UI) should be able to push/pull from OCI-compatible registries.\n - Stretch Goal: OCI image signing; Verify the authenticity of MeshModels using [cosign](https://github.com/sigstore/cosign).\n - Target registries: Meshery Catalog (https://meshery.io/catalog), Artifact Hub.\n- Recommended Skills: Reactjs, Golang, GraphQL\n- Mentor(s): Lee Calcote @leecalcote (leecalcote@gmail.com), Abhishek Kumar @Abhishek-kumar09 (abhimait1909@gmail.com)\n- Expected project size: 175 hours\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/meshery/meshery/issues/6447\n\n### OpenFeature\n\n#### Streamlined OpenFeature Enhancement Proposal Process\n\n- Description: It’s important that non-trivial changes in OpenFeature are agreed upon and documented. The OpenFeature Enhancement Proposal process should be used to gather community feedback and ensure overall alignment with the project. This process should be streamlined to encourage community participation by creating documentation, scripts, and automated workflows.\n- Expected outcome: Create an end-to-end workflow for creating, reviewing, approving, and publishing OpenFeature Enhancement Proposals.\n- Recommended Skills: TypeScript, Python, GitHub Actions\n- Mentor(s): Michael Beemer @beeme1mr (michael.beemer at dynatrace dot com), David Hirsch @DavidPHirsch (david.hirsch at dynatrace dot com)\n- Expected project size: 175\n- Difficulty: Easy\n- Upstream Issue (URL): https://github.com/open-feature/ofep/issues/48\n\n### Prometheus\n\n#### Support OpenMetrics `_created` timestamp in Prometheus\n\n- Description: OpenMetrics specifies the text and protobuf format for metrics the application exposes to systems like Prometheus. One aspect of the Open Metrics format is the exposition of the created time for some metrics like [counters](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#counter), [summaries](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#summary) and [histograms](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#histogram). It allows greater accuracy of rates (counter resets and initial value), compatibility with OpenTelemetry data model and more. Currently, Prometheus does not handle \"create timestamps\". Thus, this project aims to design and implement initial support for created timestamps in Prometheus (within its APIs and database storage). Note that we don't expect a detailed proposal as a part of the application process. We will work on the final design document together. However, initial thoughts and ideas are welcome and will help the selection process. Mentors are in the EMEA and NA time zones.\n- Expected outcome: Prometheus when scraping metrics in OpenMetrics format stores the created timestamp for export and querying purposes.\n- Recommended Skills: Go, protobuf, Prometheus\n- Mentor(s): Bartlomiej Plotka @bwplotka (bwplotka@gmail.com), Daniel Hrabovcak @TheSpiritXIII (thespiritxiii@gmail.com), Max Amin @macxamin (maxamin25@gmail.com)\n- Expected project size: 350h\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/prometheus/prometheus/issues/6541\n\n### Strimzi\n\n#### Proof of Concept of an MQTT to Apache Kafka bridge for producing messages\n\n- Description: A really common use case we have been seeing is about enabling an IoT scenario with MQTT based devices and using an Apache Kafka cluster as the events and storage platform running on Kubernetes via Strimzi. In order to do that, there is the need to map the MQTT protocol to the custom Apache Kafka one and bridge from one to the other. This project idea is about designing such a mapping and developing a pure [Netty](https://github.com/netty/netty/tree/4.1/codec-mqtt/src/main/java/io/netty/handler/codec/mqtt) based MQTT server component (not a full MQTT broker) able to accept MQTT client connections and handling the corresponding communication based on the [MQTT 3.1.1 specification](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html). Finally, developing the Kafka producer part to get messages from MQTT clients and sending them to an Apache Kafka cluster.\n- Expected outcome: POC source code for an MQTT to Apache Kafka bridge\n- Recommended Skills: Java, MQTT protocol (not mandatory but to be learned)\n- Mentor(s): Paolo Patierno @ppatierno (ppatiern AT redhat DOT com), Kyle Liberti @kyguy (kliberti AT redhat DOT com)\n- Expected project size: 350h\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/strimzi/strimzi-kafka-operator/issues/8030\n\n### The Update Framework (TUF)\n\n#### Prototyping Support for Content Addressable Systems like IPFS in TUF\n\n- Description: TUF’s specification was written with artifacts stored in traditional file systems in mind. As such, it specifies explicitly how artifacts must be hashed in order to guarantee their integrity. Since TUF was first created, however, content addressable systems for storage and data transmission have become more prominent. Some examples of these systems are Git, the InterPlanetary File System (IPFS), and OSTree. All of these can present a file-like interface for artifacts they store, and have built-in mechanisms for ensuring the integrity of artifacts. When TUF is used with these systems, it is redundant for it to also ensure artifact integrity. Instead, TUF can delegate these guarantees to the underlying content addressable system, and focus on higher level security properties the specification provides. As part of this GSoC project, the participant will add support to an existing TUF implementation to delegate artifact integrity verification to the underlying content addressable system, specifically IPFS.\n- Expected Outcome: Prototype of support in TUF for artifacts stored in IPFS\n- Recommended Skills: Python\n- Mentor(s): Aditya Sirish A Yelgundhalli (@adityasaky, aditya DOT sirish AT nyu DOT edu), John Ericson (@Ericson2314, gsoc AT johnericson DOT me), Marina Moore (@mnm678, mnm678 AT gmail DOT com)\n- Expected Project Size: 350 Hours\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/theupdateframework/python-tuf/issues/2325\n\n### WasmEdge\n\n#### Serialization Completion\n\n- Description: WasmEdge is a WebAssembly runtime in both interpreter and ahead-of-time mode. However, WasmEdge only supports the binary format for the input WebAssembly file. To help the text format WebAssembly loader feature in the future, the implementation of serializing a WebAssembly module is necessary. In this mentorship, we hope the mentee should complete the serialization functions already in [the `dev/serialize` branch](https://github.com/WasmEdge/WasmEdge/tree/dev/serialize) of the `WasmEdge` repo.\n- Expected outcome: Complete the serialization functions of WebAssembly modules, such as the element segment and data segment encoding. Complete the WebAssembly instructions encoding. Generate the unit test data and pass the unit tests. >80% of code coverage for serialization.\n- Recommended Skills: C/C++, WebAssembly\n- Mentors: Yi-Ying He @q82419 (yiying at secondstate dot io), Hung-Ying Tai @hydai (hydai at secondstate dot io)\n- Expected project size: 350h\n- Difficulty: Medium\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/2262\n\n#### `zlib` Plugin Support\n\n- Description: The zlib is required for compiling and running many existing C / C++ / Rust apps in Wasm. Most noticeably, it is [needed in the Python port to Wasm](https://github.com/python/cpython/issues/93819). The VMWare Wasm Labs team is using a zlib port from [Singlestore](https://github.com/singlestore-labs/python-wasi) in [their Python Wasm runtime](https://wasmlabs.dev/articles/python-wasm32-wasi/). In WasmEdge, we could support the zlib host functions through our [plugin system](https://wasmedge.org/book/en/plugin.html). This way, any existing zlib apps can be compiled to Wasm and runs inside WasmEdge.\n- Expected outcome: Create a new [WasmEdge plugin](https://wasmedge.org/book/en/plugin.html) that exports all public functions in `zlib`. Implement SDK (in C/Rust) that uses the C ABI to generate corresponding headers for the above plugin. Generate the unit tests and pass the unit tests. >80% of code coverage for verification.\n- Recommended Skills: C/C++, Rust, WebAssembly\n- Mentors: Yi-Ying He @q82419 (yiying at secondstate dot io), Hung-Ying Tai @hydai (hydai at secondstate dot io)\n- Expected project size: 350h\n- Difficulty: Hard\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/2244\n" }, { "path": "programs/summerofcode/2024.md", "content": "## Project Ideas\n\nIf you are a project maintainer and consider mentoring during the GSoC 2024 cycle, please, submit your ideas below using the template.\n\n[Google summer of code timeline](https://developers.google.com/open-source/gsoc/timeline).\n\nYou can find the project ideas from previous year [here](./2023.md).\n\n> **NOTE:** Please note that GSoC is a program known for its strict deadlines. In addition to responding to your mentee on time, you will be required to submit evaluations on time. Failures to meet the deadlines might affect CNCF's future participation in GSoC.\n\n---\n\n### Template\n\n```\n#### CNCF Project Name\n\n##### Project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Expected project size: # one of small (~90 hour projects), medium (~175 hour projects) and large (~350 hour projects)\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - Jane Doe (@jane-github, jane@email.address) - primary\n - John Doe (@john-github, john@email.address)\n- Upstream Issue (URL):\n```\n\n---\n\n### Proposals\n\n#### CNCF GOSST\n\n##### CNCF and Google Open Source Security Team GSoC Collaboration - Enhancing Security Across CNCF Ecosystem\n\n- Description: This project is a collaborative effort between the CNCF and Google's Open Source Security Team to improve security practices across various CNCF projects. The focus is identifying and addressing security vulnerabilities, integrating security tools like OSS-Fuzz, and enhancing build and release security processes. The goal is to get all CNCF projects to use scorecards (focusing on graduated/incubating projects first) and to remediate some of the findings.\n- Expected Outcome:\n * All graduated and incubating CNCF projects using OpenSSF Scorecards to assess and enhance their security postures. Stretch goal: all (including sandbox) CNCF projects using OpenSFF Scorecards.\n * Remediation of identified vulnerabilities based on scorecard findings\n * Where CNCF projects are already using [OpenSSF Scorecard](https://securityscorecards.dev/), improved scores (remediating [various risk assessments](https://securityscorecards.dev/#the-checks)\n * Integration or enhancement of fuzzing with [OSS-Fuzz](https://google.github.io/oss-fuzz/) for CNCF projects\n * Improved build/release security by automating builds and releases, added build provenance, signing, and improved reproducibility\n- Recommended Skills: Security analysis, CI/CD practices, programming (preferably Go), knowledge of CNCF projects.\n- Expected project size: large (~350 hour projects)\n- Mentor(s):\n - Nate Waddington (@nate-double-u, natew@cncf.io)\n - Dustin Ingram (dustiningram@google.com)\n- Upstream Issue (URL): https://github.com/cncf/mentoring/issues/1196\n\n#### Falco\n\n##### Upgrading event-generator and automating Falco performance testing\n\n- Description: Falco is a real-time security tool designed to detect abnormal behaviours and security-related runtime events in Linux systems and the cloud. The _event-generator_ is an utility within the Falco ecosystem that helps testing Falco’s detection capabilities. The tool also has benchmark capabilities that represent a building block of the Falco performance testing practices. However, the project received less attention than required in the past few years and would require some care and renovation. This Google Summer of Code project proposes upgrading the _event-generator_ to improve its testing and benchmarking capabilities, its reliability, and its consistency, and developing new Continuous Integration pipelines based on it. The end goal is to evolve the _event-generator_ and make it the standard tool for systematically assessing the correctness and performance of Falco’s threat detection capabilities at every release and development cycle\n- Expected Outcome: The project will result in an extended version of the _event-generator_ tool that reliably generates a consistent number of events per second and stresses the most common detection scenarios of Falco. This enhanced utility will be integrated into Falco’s Continuous Integration (CI) pipeline, allowing for efficient systematic monitoring of performance regressions while ensuring alignment with past benchmarking results. Eventually, this could originate new performance optimizations in Falco itself. A stretch goal for the mentee would be to become an official maintainer of the _event-generator_ project and/or of other repositories of the Falco ecosystem\n- Recommended Skills: Go programming language, familiarity with continuous integration, understanding of performance benchmarking concepts\n- Expected project size: Large (350 hour project)\n- Mentor(s):\n - Jason Dellaluce (@jasondellaluce, jasondellaluce@gmail.com) - primary\n - Aldo Lacuku (@alacuku, aldo@lacuku.eu)\n- Upstream Issue (URL): https://github.com/falcosecurity/evolution/issues/362\n\n#### in-toto\n\n##### Sigstore support for in-toto-jenkins\n\n- Description: The [in-toto Jenkins plugin](https://github.com/in-toto/in-toto-jenkins-plugin) allows users to generate metadata in their build pipelines. Currently keys or credentials must be provided to the plugin to sign the metadata, whereas Sigstore offers keyless signing and verification. The addition of Sigstore transport will allow seamless uploading of metadata to Rekor transparency log. This project aims to enhance the Jenkins plugin by adding [Sigstore](https://www.sigstore.dev) support, allowing keyless signing and adding Sigstore transport.\n- Expected Outcome: in-toto-jenkins plugins gets support for Sigstore\n- Recommended Skills: Java, Jenkins\n- Expected project size: Medium (175 hour project)\n- Mentor(s):\n - Santiago Torres-Arias (@SantiagoTorres, santiagotorres@purdue.edu) - primary\n - Pradyumna Krishna (@PradyumnaKrishna, git@onpy.in)\n- Upstream Issue (URL): https://github.com/in-toto/in-toto-jenkins-plugin/issues/6\n\n##### Add GUAC support\n\n- Description: The project aims to integrate Graph for Understanding Artifact Composition (GUAC) with in-toto, a framework safeguarding software supply chain integrity. [Graph for Understanding Artifact Composition (GUAC)](https://guac.sh/) aggregates software security metadata into a high fidelity graph database—normalizing entity identities and mapping standard relationships between them. This project seeks to extend in-toto's capabilities by incorporating GUAC, enabling users to query GUAC with Package URLs (purls) and retrieve pertinent attestations.\n- Expected Outcome: Adds functionality to query GUAC, retrieve and parse relevant attestations for the specified artifact.\n- Recommended Skills: Go, Python\n- Expected project size: Medium (175 hour project)\n- Mentor(s):\n - Santiago Torres-Arias (@SantiagoTorres, santiagotorres@purdue.edu) - primary\n - Pradyumna Krishna (@PradyumnaKrishna, git@onpy.in)\n- Upstream Issue (URL): https://github.com/in-toto/attestation-verifier/issues/29\n\n#### Jaeger\n\n##### Deployment options for Jaeger v2\n\n- Description: Jaeger is a distributed tracing platform. We are working towards [Jaeger v2](https://github.com/jaegertracing/jaeger/issues/4843) that is re-architected to be a custom distribution of the [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector). There are multiple tracks towards that milestone, one of them is to address the deployment process for the end users. The project involves analysis of the existing solutions, such as Kubernetes Operators for Jaeger-v1 and OpenTelemetry Collector, deciding on the strategy for how to support deployment options for Jaeger-v2, and implementing + documenting them.\n- Expected Outcome:\n - Support deploying Jaeger v2 via Kubernetes Operator, Helm chart, and brew.\n - Documentation on the website.\n- Recommended Skills: Go, Kubernetes, scripting, CI/CD\n- Expected project size: Large (350 hour project)\n- Mentor(s):\n - Yuri Shkuro (@yurishkuro, github@ysh.us) - primary\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n- Upstream Issue (URL): https://github.com/jaegertracing/jaeger/issues/5221\n\n#### Keptn\n\n##### GitHub issue self-assignment bot\n\n- Description: The goal is to create a self-service issue assignment bot for GitHub contributors who are not yet part of the organization but would like to work on issues marked for external handling. The bot should be able to check if the user is part of the organization, examine if the pre-conditions for self-assignment are met (configurable labels or rules about number of issues already assigned/PRs opened), and assign the issue. Additionally, the bot should be able to track the state of the issue by adding/removing specific labels. The bot should be part of the CI and executed as an action on an issue change.\n- Expected Outcome:\n - Implement GitHub bot in TypeScript/Golang\n - Bot does not require an external hosting\n - Bot is able to assign GitHub issues to contributors following the pre-defined set of rules\n - Bot is able to track the status of GitHub issues with labels\n - Introduce documentation about how to use and configure the bot\n- Recommended Skills: GitHub API, TypeScript/Golang, Webhooks\n- Expected project size: Large (350 hour project)\n- Mentor(s):\n - Ondrej Dubaj (@odubajDT, ondrej.dubaj@dynatrace.com) - primary\n - Florian Bacher (@bacherfl, florian.bacher@dynatrace.com)\n- Upstream Issue (URL): https://github.com/keptn/lifecycle-toolkit/issues/2823\n\n#### Knative\n\n##### Improving Wasm support in Knative Functions\n\n- Description: Wasm aka WebAssembly provides a portable binary-code format that is ideal to write small functions. However, current support for Wasm in Knative Functions is limited and slow. This project will improve this support.\n- Expected Outcome: Contribute Wasm support to Knative functions, documentation, sample code etc. Ideal outcome would be running Wasm code via Knative Functions in a convenient way. However, there are some unknowns. Other possible outcome could be identifying the roadblocks and possible improvements\n- Recommended Skills: basic programming skills, use IDE and debugger, some experience with Kubernetes\n- Expected project size: Medium (175 hour project)\n- Mentor(s):\n - Aleksander Slominski @aslom (aslomins AT redhat DOT com) - primary\n - Matthias Wessendorf @matzew (matzew AT redhat DOT com)\n - Luke Kingland @lkingland (lkingland AT redhat DOT com)\n- Upstream Issue (URL): https://github.com/knative/func/issues/2151\n\n#### KubeArmor\n\n##### Rancher Plugin Integration\n\n- Description: The goal is to create an extension for Rancher, a Kubernetes management platform, which will enable interaction with KubeArmor. The extension will have the capability to install KubeArmor, allow the users to easily see the state and manage KubeArmor policies, default posture, protected containers, and provide monitoring of workload behavior through alerts and telemetry.\n- Expected Outcome: Rancher plugin address the following points:\n - Install KubeArmor\n - Manage KubeArmor Security Policy Resources\n - Manage ClusterWide and Namespace Specific KubeArmor Configuration and Security Postures (Policy Decision and Visibility)\n - Handle Recommendation of Policies based on `karmor recommend`\n - Integrate KubeArmor Visibility Dashboards based on Grafana with Rancher Preset Grafana Dashboards\n- Recommended Skills: Rancher, Grafana stack, Javascript\n- Expected project size: Large (350 hour project)\n- Mentor(s):\n - Barun Acharya (@daemon1024, barun1024@gmail.com) - primary\n - Prashant Mishra (@primalpimmy, prashant20.pm@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com )\n - Anurag Kumar (@kranurag7, kranurag7@linux.com)\n- Upstream Issue: kubearmor/KubeArmor#992\n\n##### Automating Benchmarking Workflow\n\n- Description: This project aims to develop an automated benchmarking system for KubeArmor. The focus will be to enhance the efficiency and repeatability of performance evaluations, which are currently being done manually. The benchmarking system will streamline the process across various scenarios, ensuring that KubeArmor’s performance is consistently and rigorously evaluated after each release.\nThe task would include Automate the execution of benchmarks under various scenarios, Metrics Collection and reporting it through appropriate channel(slack, or updating readme) after every release.\n\n- Expected Outcome: \n - A fully automated benchmarking system that can reliably assess the performance of KubeArmor across various scenarios.\n\n- Recommended Skills: Go programming language, understanding of how CI concepts continuous integration\n\n- Expected project size: Large (350 hour project)\n\n- Mentor(s):\n - Barun Acharya (@daemon1024, barun1024@gmail.com) - primary\n - Shreyas Mishra (@Shreyas220, shreyas.ny@gmail.com)\n - Prashant Mishra (@primalpimmy, prashant20.pm@gmail.com)\n - Rudraksh Pareek (@DelusionalOptimist, rudrakshpareek3601@gmail.com)\n\n- Upstream Issue: kubearmor/KubeArmor#1669\n\n#### Kubernetes Gateway API\n\n##### Design and develop notification mechanism for ingress2gateway.\n\n- Description: [Gateway API](https://gateway-api.sigs.k8s.io/) is the new generation of Kubernetes Networking APIs. Ingress2gateway is a tool to help users migrate and convert Ingress, and implementation-specific configurations to Gateway API. As we add more conversion logic, and onboard more implementations (essentially Ingress and Gateway controllers like Istio, Kong, etc.), logs become insufficient to report conversion results, warnings and crucial messages regarding the conversion. To improve the tool usability, we need to enable users to know exactly the original resource/s -> new resource/s mapping, PLUS what the tool couldn't convert so they could make the final touches before applying the new resources to the cluster.\n A few of the notification types we'll need to support:\n - Overview of original resources and the equivalent resources to which they have been converted\n - Warnings about partial conversions (partial fields within a resource)\n - Warnings about fields/logics not supported in Gateway API\n- Expected Outcome: A new notification mechanism to notify users conversion results, warnings and crucial messages regarding their conversion has been added and is being used across implementations supported by the tool.\n- Recommended Skills: Go, Kubernetes\n- Expected project size: Medium (175 hour project)\n- Mentor(s):\n - (Lior Lieberman, @LiorLieberman)\n - (Mattia Lavacca, @mlavacca)\n- Upstream Issue: https://github.com/kubernetes-sigs/ingress2gateway/issues/131\n\n#### LitmusChaos\n\n##### Integration of Fuzzing Test Suites for LitmusChaos(ChaosCenter) with OSS-FUZZ\n\n- Description: This task aims to implement comprehensive fuzzing test suites for our GraphQL interface and Authentication server ([ChaosCenter](https://github.com/litmuschaos/litmus/tree/master/chaoscenter)) to identify vulnerabilities and ensure robustness. The process involves developing targeted fuzzing strategies to thoroughly test these components and integrating the tests with [OSS-FUZZ](https://github.com/google/oss-fuzz) for automated fuzzing. This integration should streamline the process of monitoring and addressing potential security issues. The task also includes making the results accessible through the [ClusterFuzz Dashboard](https://google.github.io/clusterfuzz) for efficient management and analysis\n- Expected Outcome:\n - Comprehensive fuzzing test suites for the GraphQL interface and Authentication server are developed and demonstrate good coverage of the codebase.\n - Successful integration with OSS-FUZZ, ensuring that fuzzing tests are automatically run and their outcomes are reported.\n - All test results, including coverage statistics, vulnerabilities, and crash reports, are visible and manageable through the ClusterFuzz Dashboard.\n - Documentation on how to maintain and extend the fuzzing tests as the project evolves.\n- Recommended Skills: Golang, Kubernetes\n- Expected project size: Large (350 hour project)\n- Mentors(s):\n - Saranya Jena (@Saranya-jena, saranya.jena@harness.io) - primary\n - Karthik S (@ksatchit, karthik.s@harness.io)\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/4425\n\n#### Meshery\n\n##### Understanding and Codifying the Relationships between Kubernetes Resources\n\n- Description: The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph.\n- Expected Outcome: YAML-formatted definition\n- Recommended Skills: DevOps, Kubernetes Administration, Light familiarity with all of the CNCF projects and a desire to study each project and their operators/resources.\n- Expected project size: Large (350 hour project)\n- Mentor(s):\n - Lee Calcote (@leecalcote, leecalcote@gmail.com) - primary\n - Uzair Shaikh (@muzairs15, muzair.shaikh810@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/10264\n\n#### Prometheus\n\n##### Add Created Timestamp to Prometheus/OpenMetrics Text Format\n\n- Description: Created Timestamp was added to Prometheus protobuf format and storage in 2023 GSoC in the summer. The important follow up was to add optional created timestamp feature to Prometheus or OpenMetrics Text formats, similar to https://github.com/prometheus/proposals/pull/32. This project will involve proposal and implementation of the design that would be accepted by Prometheus community. The change has to be carefully designed as the scrape text formats are the most commonly used \"APIs\" for pulling (scraping) metrics in the CNCF generally. NOTE: No need to carefully prepare design upfront, we will do the proper design together.\n- Expected Outcome: Prometheus or OpenMetrics Text format have support for created timestamp (for OpenMetrics it means replacing the current design that inolves extra series, which can be problematic) e.g. in metadata or similar to exemplar.\n- Recommended Skills: HTTP, Go, defining stable APIs\n- Expected project size: Medium (175 hour project)\n- Mentor(s):\n - Bartek Plotka (@bwplotka, bwplotka@gmail.com) - primary\n - Arthur Silva Sens (@arthurSens, arthursens2005@gmail.com)\n - Daniel Hrabovcak (@TheSpiritXIII, thespiritxiii@gmail.com)\n- Upstream Issue (URL): https://github.com/prometheus/prometheus/issues/13537\n\n##### Move out of gogo/protobuf to protobuf with vtproto implementation\n\n- Description: Prometheus, like many other Go projects, still use \"gogo\" (https://github.com/gogo/protobuf) implementation of the protobuf generator, which was deprecated a while ago. Since then protobuf projects moved forward with the new API version and various amazing protobuf plugins in the community like \"vtproto\" (https://github.com/planetscale/vtprotobuf) from Vitess. In Prometheus we use protobuf mainly for remote writing, as well as protobuf scraping protocols. In both cases the efficiency of the solution is critical. This is why gogo implementation was popular--it allowed a certain \"nullable\" option, that reduced amount of pointers in generated structures and instead preferred allocating bigger amount of memory at once (e.g. `[]*CustomType` was in gogo `[]CustomType`). Long story short, moving Prometheus out of gogo protobuf to native Go protobuf with vtproto has to happen due to lack of support for gogo for new protobuf API iterations. However, it not only requires code changes, but also carefully benchmarking and optimizing for different generated message structures (allocating smaller objects, but more of them). If you want to dive into amazing world of coding optimizations and benchmarks -- this project is for you! NOTE: No need to carefully prepare design upfront, we will do the proper design together.\n- Expected Outcome: Prometheus project does not depend on gogo protobuf and its performance (e.g. scraping and remote write) is not worse than what we have now with gogo.\n- Recommended Skills: Go, protobuf, benchmarking\n- Expected project size: Medium (175 hour project)\n- Mentor(s):\n - Callum Styan (@cstyan, callumstyan@gmail.com) - primary\n - Max Amin (@macxamin, maxamin25@gmail.com)\n - Bartek Plotka (@bwplotka, bwplotka@gmail.com)\n - Daniel Hrabovcak @TheSpiritXIII (thespiritxiii@gmail.com)\n- Upstream Issue (URL): https://github.com/prometheus/prometheus/issues/11908\n\n#### Service Mesh Performance\n\n##### Service Mesh Performance IDE Plugin\n\n- Description: The objective of this project is to develop IDE plugins that can enhance the developer experience while working with Service Mesh Performance Performance Profiles. The proposed plugins will leverage technologies such as golang and cuelang to provide features such as syntax highlighting, auto-completion, validation, and rendering previews for Service Mesh Performance profile and model definitions.\n- Expected outcome:\n- 1. Release VS Code Extension\n- 2. Syntax Highlighting and Auto-completion: The plugin can fetch SMP Model definitions such as cloud-native components and their relationships. This information can be used to provide syntax highlighting and auto-completion for these definitions in the JSON files, making it easier for developers to write error-free code.\n- 3. Validation and Reference: For Meshery MeshModel definitions such as cloud-native components and their relationships, the plugin can use the CUE language to provide validation for the CUE input and preview the rendering result. The plugin can also fetch the SMP Model schemas and display them in the IDE for reference.\n- Recommended Skills: Cuelang\n- Expected project size: Large (350 hour project)\n- Mentor(s):\n - Lee Calcote (@leecalcote, leecalcote@gmail.com) - primary\n - Xin Huang (@gyohuangxin, xin1.huang@intel.com)\n- Upstream Issue (URL): https://github.com/service-mesh-performance/service-mesh-performance/issues/379\n\n#### WasmEdge\n\n##### Implementing Coredump for Post-Mortem Debugging in WebAssembly\n\n- Description: This project, [wasm-coredump](https://github.com/WebAssembly/tool-conventions/blob/main/Coredump.md), aims to enhance the debugging capabilities of WebAssembly by implementing a coredump feature for post-mortem analysis. When WebAssembly encounters a runtime error, it will initiate a process to collect debugging information, including stack frames, local variable values, and a snapshot of the linear memory. This data is saved in a coredump file, which, along with DWARF information, can be analyzed post-mortem to debug the error. The project involves creating or enhancing tools to generate and analyze Wasm coredumps, addressing the unique challenges of WebAssembly's memory model and execution semantics.\n- Expected Outcome:\n - A set of new API and tool options to specify the saved coredump files.\n - Implement the coredump inside the WasmEdge components, when a trap is triggered, there should be a whole process to log and save any information defined in the [wasm-coredump](https://github.com/WebAssembly/tool-conventions/blob/main/Coredump.md) spec.\n - The coredump file must be compatible with the current toolchain, including [wasmgdb](https://github.com/xtuc/wasm-coredump/tree/main/bin/wasmgdb) and [wasm-edit](https://github.com/xtuc/wasm-coredump/tree/main/bin/rewriter).\n - Documentation on the coredump format, including how to encode process, module, and instance information.\n - Tutorials, examples, and demonstration of post-mortem debugging using the implemented coredump feature.\n- Recommended Skills: WebAssembly, C++, Debugger\n- Expected project size: Large (350 hour project)\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io) - primary\n - Shen-Ta Hsieh (@ibmibmibm, beststeve@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/3205\n\n##### Enabling LLM fine tuning in the WASI-NN PyTorch plugin\n\n- Description: WasmEdge now offers a PyTorch inference feature through the [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) proposal. As LLM (Language Model) is a highly sought-after topic, it has become essential to provide LLM fine-tuning as well. To achieve this, we plan to fine-tune the LLM model and extend the current WASI-NN spec by adding a set of extra APIs. With this plugin, application developers can develop the logic to enhance the model as per their requirements.\n- Expected Outcome:\n - Take llama2-7b as the fine-tuning target; the final implementation should handle it correctly.\n - Extend the WASI-NN spec if needed to support the fine-tuning feature.\n - Implement the fine-tuning functions inside WASI-NN PyTorch plugin.\n - Documentation, examples, tutorials, and demonstration are required.\n- Recommended Skills: C++, WebAssembly, PyTorch\n- Expected project size: Large (350 hour project)\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io) - primary\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/3208\n\n##### Enabling LLM fine tuning in the WASI-NN ggml plugin\n\n- Description: WasmEdge now offers an embedded llama.cpp backend via [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) spec. However, we only support inference at the current stage. As LLM (Language Model) is a highly sought-after topic, it has become essential to provide LLM fine-tuning as well. To achieve this, we plan to fine-tune the LLM model and extend the current WASI-NN spec by adding a set of extra APIs. With this plugin, application developers can develop the logic to enhance the model as per their requirements.\n- Expected Outcome:\n - Take llama2-7b as the fine-tuning target; the final implementation should handle it correctly.\n - Extend the [WASI-NN](https://github.com/second-state/wasmedge-wasi-nn) spec if needed to support the fine-tuning feature.\n - Implement the fine-tuning functions inside [WASI-NN ggml plugin](https://github.com/WasmEdge/WasmEdge/blob/master/plugins/wasi_nn/ggml.h).\n - Documentation, examples, tutorials, and demonstration are required.\n- Recommended Skills: C++, WebAssembly, LLM fine-tuning\n- Expected project size: Large (350 hour project)\n- Mentor(s):\n - Michael Yuan (@juntao, michael@secondstate.io) - primary\n - Hung-Ying Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/3209\n\n#### Open Cluster Management\n\n##### Scheduling AI workload among multiple clusters\n\n- Description: \n Open Cluster Management (OCM) focuses on multicluster and multicloud management scenarios for Kubernetes applications. Open APIs are evolving within this project for cluster registration, workload distribution, dynamic placement of policies and workloads, and much more. The placement concept is used to dynamically select a set of clusters so that higher level users can either replicate Kubernetes resources to the member clusters or run their advanced workload. For example: as an application developer, I can deploy my workload to clusters with the most allocatable memory and CPU.\n \n Now, with the rise of AI technology, there’s a growing need to schedule AI workload based on GPU/TPU resources. In this project we want you to use the placement [extensible scheduling mechanism](https://open-cluster-management.io/scenarios/extend-multicluster-scheduling-capabilities/) to implement a GPU/TPU resource collector addon by [addon template](https://open-cluster-management.io/developer-guides/addon/#build-an-addon-with-addon-template) and provide an `AddonPlacementScore` to make placement decision based on GPU/TPU resources. We also want you to propose a customized external Kueue Admission Check controller to consume the placement decision to schedule AI workload among multiple clusters based on GPU/TPU resources. \n\n- Expected Outcome:\n - Develop the GPU/TPU resource collector addon, which includes documentation of the addon architecture and describing the `AddonPlacementScore` usage. Also, implement the addon using the addon template and contribute the code to the [addon-contrib](https://github.com/open-cluster-management-io/addon-contrib/tree/main/) repository.\n - Deliver a proposal for the external Kueue Admission Check controller. The proposal should outline the API design and explain how the controller uses the OCM scheduling result and interacts with Kueue. The proposal needs to be finally reviewed in OCM community meeting. Also, you need to deliver a prototype based on the proposal. \n\n- Recommended Skills: Golang, Kubernetes, Scheduling\n- Expected project size: Large (350 hour project)\n- Mentor(s): \n - Qing Hao (@haoqing0110, qhao@redhat.com) - primary\n - Jian Qiu (@qiujian16, jqiu@redhat.com)\n- Upstream Issue (URL): https://github.com/open-cluster-management-io/ocm/issues/369\n" }, { "path": "programs/summerofcode/2025.md", "content": "## Project Ideas\n\nIf you are a project maintainer and consider mentoring during the GSoC 2025 cycle, please, submit your ideas below using the template.\n\n[Google summer of code timeline](https://developers.google.com/open-source/gsoc/timeline).\n\nYou can find the project ideas from previous year [here](./2024.md).\n\n> **NOTE:** Please note that GSoC is a program known for its strict deadlines. In addition to responding to your mentee on time, you will be required to submit evaluations on time. Failures to meet the deadlines might affect CNCF's future participation in GSoC.\n\n---\n\n### Template\n\n```\n#### CNCF Project Name\n\n##### Project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Expected project size: # one of small (~90 hour projects), medium (~175 hour projects) and large (~350 hour projects)\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - Jane Doe (@jane-github, jane@email.address) - primary\n - John Doe (@john-github, john@email.address)\n- Upstream Issue (URL):\n```\n\n---\n\n## Ideas\n\n\n* [etcd](#etcd)\n * [etcd cache](#etcd-cache)\n* [Harbor](#harbor)\n * [Enhance Harbor Satellite for Artifact Replication from Remote Registry to Edge](#enhance-harbor-satellite-for-artifact-replication-from-remote-registry-to-edge)\n* [Jaeger](#jaeger)\n * [Service performance analysis on top of Elasticsearch / OpenSearch data](#service-performance-analysis-on-top-of-elasticsearch--opensearch-data)\n* [KCL](#kcl)\n * [KCL OCI third-party dependency management enhancement](#kcl-oci-third-party-dependency-management-enhancement)\n* [Konveyor](#konveyor)\n * [Extend usage of Konveyor AI to detect and update deprecated Kubernetes API usage in golang applications](#extend-usage-of-konveyor-ai-to-detect-and-update-deprecated-kubernetes-api-usage-in-golang-applications)\n* [KubeArmor](#kubearmor)\n * [Improve KubeArmor Observability Spectrum](#improve-kubearmor-observability-spectrum)\n* [KubeBuilder](#kubebuilder)\n * [Automating Operator Maintenance: Driving Better Results with Less Overhead](#automating-operator-maintenance-driving-better-results-with-less-overhead)\n* [KubeStellar](#kubestellar)\n * [Automating Benchmarking of KubeStellar Data-Plane](#automating-benchmarking-of-kubeStellar-data-plane)\n* [Kubewarden](#kubewarden)\n * [Allow policies to be written using JavaScript](#allow-policies-to-be-written-using-javascript)\n * [Elevate our .NET SDK into a first class citizen](#elevate-our-net-sdk-into-a-first-class-citizen)\n* [Lima](#lima)\n * [VM plugin subsystem](#vm-plugin-subsystem)\n* [LitmusChaos](#litmuschaos)\n * [Terraform Support for LitmusChaos](#terraform-support-for-litmuschaos)\n* [Meshery](#meshery)\n * [Multi-player Collaboration: Resilient Websockets and GraphQL Subscriptions](#multi-player-collaboration-resilient-websockets-and-graphql-subscriptions)\n * [Support for Azure in Meshery](#support-for-azure-in-meshery)\n * [Distributed client-side inference (policy evaluation) with WebAssembly (WASM) and OPA in Meshery](#distributed-client-side-inference-policy-evaluation-with-webassembly-wasm-and-opa-in-meshery)\n* [Open Cluster Management](#open-cluster-management)\n * [Privacy-preserving and efficient AI model training across multi-cluster](#privacy-preserving-and-efficient-ai-model-training-across-multi-cluster)\n* [ORAS](#oras)\n * [Enhance Java ORAS SDK](#enhance-java-oras-sdk)\n* [The Update Framework (TUF)](#the-update-framework-tuf)\n * [Snapshot Merkle trees](#snapshot-merkle-trees)\n* [Vitess](#vitess)\n * [Enhancements for FAQ Chatbot for Vitess](#enhancements-for-faq-chatbot-for-vitess)\n* [WasmEdge](#wasmedge)\n * [Virtual filesystem security for WasmEdge plug-ins with exporting WASI APIs](#virtual-filesystem-security-for-wasmedge-plug-ins-with-exporting-wasi-apis)\n * [Port WasmEdge and the WASI-NN ggml backend to the s390x platform](#port-wasmedge-and-the-wasi-nn-ggml-backend-to-the-s390x-platform)\n * [Use Runwasi with WasmEdge runtime to test multiple WASM apps as cloud services](#use-runwasi-with-wasmedge-runtime-to-test-multiple-wasm-apps-as-cloud-services)\n\n\n#### etcd\n\n##### etcd cache\n\n- Description: Develop a generic, high-performance caching library for etcd, inspired by the Kubernetes watch cache, to facilitate building scalable and efficient etcd-based applications.\n- Expected Outcome:\n - A well-tested and performant library providing core caching primitives similar to Kubernetes' watch cache, significantly reducing etcd load and latency for generic etcd use cases.\n - The library will offer feature parity with Kubernetes watch cache, including support for:\n - Caching watch events and demultiplexing requests.\n - Caching non-consistent list requests using a B-tree structure, updated via watch events.\n - Handling requests during cache initialization and re-initialization.\n - Custom encoders/decoders for data serialization.\n - Custom indexing for optimized lookups.\n - Consistent reads.\n - Exact stale reads via B-tree snapshots.\n - Comprehensive documentation, examples, benchmarks, and metrics to enable easy adoption and monitoring. This includes e2e and robustness tests.\n- Recommended Skills: Go, Distributes Systems\n- Expected project size: small\n- Mentor(s):\n - Marek Siarkowicz (@serathius, siarkowicz@google.com) - primary\n - Madhav Jivrajani (@MadhavJivrajani, madhav.jiv@gmail.com)\n- Upstream Issue (URL): https://github.com/etcd-io/etcd/issues/19371\n\n#### Harbor\n\n##### Enhance Harbor Satellite for Artifact Replication from Remote Registry to Edge\n\n- Description: The Harbor Satellite project aims to enable decentralized artifact replication in edge computing environments. This project currently focuses on [Use Case #1](https://github.com/container-registry/harbor-satellite/blob/main/docs/images/satellite_use_case_1.svg), where Harbor Satellite will pull images from a central Harbor registry and store them in a local OCI-compliant registry for use by edge devices. The solution is designed for environments with limited or intermittent internet connectivity, ensuring continuous access to required artifacts by local edge devices even when connectivity is unavailable.\n- Expected Outcome:\n - Enhance Harbor Satellite to enable reliable artifact replication from a central Harbor registry to a local OCI-compliant registry at the edge.\n - Implement secure synchronization between central and local registries, especially in air-gapped environments.\n - Optimize configuration management for edge container runtimes to pull images from the local registry.\n - Provide clear documentation and setup guides for deploying Harbor Satellite in edge environments.\n- Recommended Skills: Go, OCI-Registries, Distribution-spec\n- Expected project size: medium (~175 hour projects)\n- Mentor(s):\n - Vadim Bauer (@vad1mo, vb@container-registry.com) - primary\n - Orlin Vasilev (@OrlinVasilev, orlin@orlix.org)\n - Prasanth Baskar (@bupd, bupdprasanth@gmail.com)\n- Upstream Issue (URL): https://github.com/goharbor/harbor/issues/21605\n\n#### Jaeger\n\n##### Service performance analysis on top of Elasticsearch / OpenSearch data\n\n- Description: [Jaeger](https://www.jaegertracing.io/) is an open-source, distributed tracing platform designed to monitor and troubleshoot transactions in distributed systems. In its basic deployment it allows collecting tracing data, storing it in a database, and querying & analyzing individual traces in the UI. This workflow is great for deep-diving into individual requests, but it does not answer some higher level questions like \"which endpoints in my service are the slowest?\" To address those questions Jaeger has a special feature called [SPM (Service Performance Management)](https://www.jaegertracing.io/docs/2.2/spm/), which allows the user to see the trends of services' and endpoints' performance and to drill down into the outliers. However, this feature requires a more complicated deployment where a special real-time processor is running and extracting metrics from the traces and storing those metrics in a Prometheus-compatible remote storage. Some of the storage backends supported by Jaeger, such as Elasticsearch & OpenSearch, can provide the same aggregate answers directly from the trace data, which can significantly simplify the deployment. This project aims to enable this integration.\n- Expected Outcome:\n - Support SPM functionality directly in Elasticsearch / OpenSearch backends by implementing the metrics query API\n - Enhance existing e2e integration tests to continuously test this new capability\n- Recommended Skills: Go, basic familiarity with Elasticsearch\n- Expected project size: large (~350 hour projects)\n- Mentors:\n - Yuri Shkuro (@yurishkuro, github@ysh.us) - primary\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n- Upstream Issue (URL): https://github.com/jaegertracing/jaeger/issues/6641\n\n#### KCL\n\n##### KCL OCI third-party dependency management enhancement\n\n- Description: KCL is an open-source constraint-based record & functional language mainly used in configuration and policy scenarios. KPM is a package management tool for the KCL language that supports the management of KCL packages in the OCI registry and Git Repo. This topic only applies to third-party dependencies from the OCI registry. Use the layering mechanism in OCI to help KPM implement dependency management of KCL third-party dependencies.\n\n- Expected Outcome:\n - Refactor the current KPM dependency management module with the OCI's layered mechanism.\n- Recommended Skills: Go, OCI\n- Expected project size: medium (~175 hour projects)\n- Mentor(s):\n - Zhe Zong (@zong-zhe, zongzhe1024@163.com)\n - Heipa (@He1pa, he1pa404@gmail.com)\n- Upstream Issue (URL): https://github.com/kcl-lang/kpm/issues/598\n\n#### Knative Functions\n\n##### Dynamic AI Agent Callbacks\n\n- Description: Knative Functions is well-suited for AI agent integration. The serverless nature and isolated runtime environment of Functions make them ideal for creating lightweight, purpose-built services that can be dynamically invoked and even created by agents.\n- Expected Outcome: This project would be a combination of research and practicum.\n First, an analysis of current AI agent interaction patterns, including emergent protocols and available frameworks.\n Second, the development of a Proof-of-concept integration between Functions and AI agents. This would involve at a minimum invocation, with a stretch goal of implementation and deployment by the agent based on a human prompt.\n- Recommended Skills:\n - Strong language and communication skills, with the ability to both research deeply and communicate clearly.\n - Experience with AI/ML agents and desire to learn about programmatic LLM integrations.\n - Familiarity with the Go programming language (ideal) or Python (secondarily), and web services.\n - Familiarity with kubernetes, serveless, and microservices a plus.\n- Expected project size: Large\n- Mentor(s):\n - Luke Kingland @lkingland (kingland AT redhat DOT com) - primary\n - Aleksander Slominski @aslom (aslomins AT redhat DOT com)\n- Upstream Issue (URL): https://github.com/knative/func/issues/2690\n\n#### Konveyor\n\n##### Extend usage of Konveyor AI to detect and update deprecated Kubernetes API usage in golang applications\n\n- Description: [Konveyor](https://www.konveyor.io/) is an application modernization platform that helps organizations migrate legacy applications to Kubernetes at scale. As part of this effort, you will contribute to [Konveyor AI (Kai)](https://github.com/konveyor/kai), an intelligent code assistant that automates source code updates using data from static code analysis and changelog histories. Your work will focus on applying Generative AI techniques to detect and update deprecated Kubernetes APIs in Golang applications. You’ll build a tool that uses a LLM to generate [Konveyor static code analysis rules](https://github.com/konveyor/analyzer-lsp/blob/main/docs/rules.md) from published documentation such as the [Kubernetes deprecated API guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/). Additionally, you’ll create workflows to identify deprecated API usage in legacy applications and automate code suggestions for updates — all powered by Konveyor AI.\n\n- Expected Outcome:\n - Develop a prototype tool to convert Kubernetes API deprecation documentation into static code analysis rules.\n - Collaborate with the Konveyor AI team to extend support for Golang applications, identify issues, and contribute improvements.\n - Demonstrate Konveyor AI’s ability to detect and suggest fixes for deprecated API usage in Golang projects.\n\n- Recommended Skills: Golang, Python, Kubernetes, Generative AI\n- Expected project size: # Large (~350 hours)\n- Mentor(s):\n - John Matthews (@jwmatthews, jwmatthews@gmail.com) - primary\n - Savitha Raghunathan (@savitharaghunathan, saveetha13@gmail.com)\n- Upstream Issue (URL): https://github.com/konveyor/kai/issues/644\n\n#### KubeArmor\n\n##### Improve KubeArmor Observability Spectrum\n\n- Description: KubeArmor is a security enforcement system that provides runtime protection for Kubernetes workloads. To enhance observability, this task involves exposing key Prometheus metrics related to KubeArmor’s policy enforcement. These metrics will provide insights into security policy activity and alerting within a Kubernetes cluster.\n\n For starters, the following metrics can be started with:\n\n - Number of Policies Applied\n - Number of Alerts Triggered\n - List of Active Policies\n - Policy Status (Active/Inactive)\n\n- Expected Outcome: Prometheus metrics are successfully integrated into KubeArmor, allowing users to monitor policy enforcement and security events effectively. The metrics should be accessible via a Prometheus endpoint and conform to best practices for Prometheus metric exposition.\n\n- Recommended Skills: Go, Prometheus, Kubernetes.\n- Expected project size: 175 hrs\n- Mentor(s):\n - Rishabh Soni (@rootxrishabh, risrock02@gmail.com)\n - Prateek Nandle (@Prateeknandle, prateeknandle@gmail.com)\n - Barun Acharya (@daemon1024, barun1024@gmail.com)\n - Nishant Singh (@tesla59, talktonishantsingh.ns@gmail.com)\n- Upstream Issue (URL): https://github.com/kubearmor/KubeArmor/issues/1902\n\n#### KubeBuilder\n\n##### Automating Operator Maintenance: Driving Better Results with Less Overhead\n\n- Description: \nCode-generation tools like Kubebuilder and Operator-SDK have transformed cloud-native application development by providing scalable, community-driven frameworks. These tools simplify complexity, accelerate results, and enable developers to create tailored solutions while avoiding common pitfalls, laying a strong foundation for innovation. \nHowever, as these tools evolve with ecosystem changes and new features, projects risk becoming outdated. Manual updates are time-consuming, error-prone, and make it challenging to maintain security, adopt advancements, and stay aligned with modern standards. \nThis project introduces an automated solution for Kubebuilder, with potential applications for similar tools or those built on its foundation. By streamlining maintenance, projects remain aligned with modern standards, improve security, and adopt the latest advancements. It fosters growth and innovation across the ecosystem, letting developers focus on what matters most: building great solutions. \nNote that the initial idea is to solve this with **3-way Git merges**. However, users will face conflicts, and in the first phase, we want to study whether AI could help resolve these conflicts in a future phase to achieve this goal.\n\n- Expected Outcome\n - Conduct research on [3-Way Merge & Advanced Merge Options in Git](https://youtu.be/3Kb9glVJBJM?si=a0g3QMSrW_CMl1L9).\n - **Conduct research on how AI could help resolve conflicts**. If open-source solutions are available and align with the proposal, include them for consideration in a second phase.\n - Develop a **Proof of Concept (POC)** implementing a **GitHub Action** that automatically creates a **Pull Request (PR)** in a mock repository, demonstrating the feasibility of the proposed solution.\n - Successfully complete the proposal for [PEP](https://github.com/kubernetes-sigs/kubebuilder/pull/4302).\n - Introduce a new [Kubebuilder Plugin](https://book.kubebuilder.io/plugins/plugins) that scaffolds the **GitHub Action** based on the POC. This plugin will be released as an **alpha feature**, allowing users to opt-in for automated updates. The initial solution does **not need to have AI**, but AI integration could be a future enhancement if feasible.\n\n- Recommended Skills\n - Golang\n - GitHub Actions\n - Software Automation\n - CI/CD\n - Git\n - IA\n\n- Expected project size: **Large** (~350 hour projects)\n\n- Mentor(s)\n - Camila Macedo (@camilamacedo86, camilamacedo86@gmail.com) - Primary\n - Varsha Prasad (@varshaprasad96, varshaprasad1507@gmail.com)\n - TianYi(Tony) (@Kavinjsir)\n\n- Upstream Issue: [WIP - Proposal: Automating Operator Maintenance: Driving Better Results with Less Overhead](https://github.com/kubernetes-sigs/kubebuilder/pull/4302)\n\n#### KubeStellar\n\n##### Automating Benchmarking of KubeStellar Data-Plane\n\n- Description: KubeStellar (KS) is an open-source Kubernetes multi-cluster workload configuration management system that can be used to manage AI workloads in multi-cluster environments. Hence, understanding KS performance is crucial especially for AI use-case scenarios. \n\n This project aims to extend the performance monitoring & analysis tools for KS and develop an automated system to measure and provide real-time performance values and statistics of the KubeStellar data plane with focus on enhance the efficiency and repeatability of our measurements (e.g., down-syncing and up-syncing latencies, etc.). This framework will provide a dashboard of these results in which all KS data-plane metrics are represented, analyzed and charted visually to give better insight to the performance characteristics of KubeStellar data-plane. We will explore different AI use-cases to evaluate this framework and the performance of KS when managing resource intensive AI workloads.\n\n- Expected Outcome:\n - A fully automated framework that can reliably assess the performance of KubeStellar data plane across various scenarios including AI use-cases.\n - Dashboards facilitating KubeStellar Performance profiles and results which are analyzed and charted visually to give better insights to performance results.\n - Dashboards added as a plugin to the KubeStellar UI. \n - Design the solution and implement it, introduce it the KubeStellar community. The implementation needs to be well scalable and applicable across various scenarios.\n \n- Recommended Skills:\n - Understanding of performance analysi\n - Kubernetes and container orchestration\n - Cloud native AI/ML apps deployment\n - Python, Go (for Kubernetes integrations)\n - Experience with logging/monitoring tools (Prometheus, OpenTelemetry)\n - Familiarity with KubeStellar (preferred but not required)\n - Expected Project Size: Large (~350 hours)\n \n- Mentor(s):\n - Braulio Dumba (@dumb0002, brauliodumba@gmail.com) - Primary Mentor\n - Jim Cadden (@jimcadden, jcadden@ibm.com) - Secondary Mentor\n - Andy Anderson (@clubanderson, andy@clubanderson.com) - Secondary Mentor\n- Upstream Issue (URL): https://github.com/kubestellar/kubestellar/issues/2853\n\n#### Kubewarden\n\n##### Allow policies to be written using JavaScript\n\n- Description: Kubewarden is a Policy Engine powered by WebAssembly policies\n that enforces security and compliance in Kubernetes clusters. Its policies can\n be written in CEL, Rego (OPA & Gatekeeper flavours), Rust, Go, YAML, and\n others.\n\n Kubewarden does not have a JavaScript SDK yet. Recent work done inside of the Bytecode Alliance made possible to compile Javascript code into WebAssembly . This means\n It's now possible to create such a SDK. This task consists\n on writing a JavaScript SDK that provides an idiomatic way to write Kubewarden policies.\n\n- Expected Outcome: A new JavaScript SDK is created. The SDK API is documented, and the policy tutorial as well.\n- Recommended Skills: JavaScript, Kubernetes.\n- Expected project size: Large\n- Mentor(s):\n - Victor Cuadrado (@viccuad, vcuadradojuan@suse.com) - primary\n - Flavio Castelli (@flavio, fcastelli@suse.com)\n - José Guilherme Vanz (@jvanz, jguilhermevanz@suse.com)\n - Fabrizio Sestito (@fabriziosestito, fabrizio.sestito@suse.com)\n- Upstream Issue (URL): https://github.com/kubewarden/community/issues/37\n\n##### Elevate our .NET SDK into a first class citizen\n\n- Description: Kubewarden is a Policy Engine powered by WebAssembly policies\n that enforces security and compliance in Kubernetes clusters. Its policies can\n be written in CEL, Rego (OPA & Gatekeeper flavours), Rust, Go, YAML, and\n others.\n\n Kubewarden has a .NET SDK that allows policy authors to write policies in C#.\n Starting with .NET 8, a big chunk of the work from\n https://github.com/dotnet/dotnet-wasi-sdk made its way upstream. This means\n it's a good time to revisit Kubewarden's .NET SDK for policies. This task consists\n on bringing our .NET SDK up to standard with the rest of our SDKs such as the\n [Go](https://github.com/kubewarden/policy-sdk-go) or\n [Rust](https://github.com/kubewarden/policy-sdk-rust) ones.\n\n- Expected Outcome: Our .NET SDK has been ported to .NET 9, and supports the\n same capabilities as our other SDKs. The SDK API is documented, and the policy tutorial\n as well.\n- Recommended Skills: C#, .NET, Kubernetes.\n- Expected project size: medium\n- Mentor(s):\n - Victor Cuadrado (@viccuad, vcuadradojuan@suse.com) - primary\n - Flavio Castelli (@flavio, fcastelli@suse.com)\n - José Guilherme Vanz (@jvanz, jguilhermevanz@suse.com)\n - Fabrizio Sestito (@fabriziosestito, fabrizio.sestito@suse.com)\n- Upstream Issue (URL): https://github.com/kubewarden/policy-sdk-dotnet/issues/47\n\n#### Lima\n\n##### VM plugin subsystem\n\n- Description: Lima () is a project that provides Linux virtual machines with a focus on running containers.\n Lima supports several VM backends via built-in drivers: `qemu`, `vz` (Apple Virtualization.framework), and `wsl2` (see [`lima/pkg/driverutil/instance.go`](https://github.com/lima-vm/lima/blob/v1.0.5/pkg/driverutil/instance.go#L11-L20)).\n The idea for GSoC is to make a plugin subsystem that decouples the built-in VM drivers into separate binaries that communicate with the main Lima binary via some RPC (probably gRPC).\n This idea will improve the maintainability of the code base, and also help supporting additional VM backends (e.g., `vfkit` and cloud-based drivers).\n- Expected Outcome:\n - Design the plugin subsystem and its RPC (probably gRPC)\n - Migrate the existing built-in VM drivers to the new plugin subsystem\n - Implement additional VM plugins if the time allows\n- Recommended Skills: Go, gRPC, QEMU, macOS\n- Expected project size: medium (~175 hour projects)\n- Mentor(s):\n - Akihiro Suda (@AkihiroSuda, suda.kyoto@gmail.com) - primary\n - Anders Björklund (@afbjorklund, anders.f.bjorklund@gmail.com)\n- Upstream Issue (URL): https://github.com/lima-vm/lima/discussions/2007\n\n#### LitmusChaos\n\n##### Terraform Support for LitmusChaos\n\n- Description: [LitmusChaos](https://litmuschaos.io/) is an open-source Chaos Engineering platform that helps teams uncover weaknesses and potential outages in their applications by running controlled chaos experiments. However, before injecting chaos, several prerequisite steps must be completed, including user and project creation, connecting target infrastructure, and setting up experiments. To streamline this process, developers and SREs often seek automation, especially when integrating chaos testing into CI/CD pipelines. This Google Summer of Code (GSoC) project proposes developing a Terraform provider for LitmusChaos, enabling users to automate these essential setup steps and seamlessly manage chaos experiments through Terraform.\n\n- Expected Outcome: \n - LitmusChaos will have a terraform provider supporting user, project, infrastructure, and experiment resource operations along with proper documentation and usage scripts. \n - A stretch goal for the mentee would be to become an official maintainer of the Litmus Terraform provider project.\n- Recommended Skills: Golang, Terraform\n- Expected project size: large (~175 hour projects)\n- Mentor(s):\n - Saranya Jena (@Saranya-jena, saranya.jena@harness.io)\n - Sarthak Jain (@SarthakJain26, sarthak.jain@harness.io)\n- Upstream Issue (URL): https://github.com/litmuschaos/litmus/issues/5042 \n\n#### Meshery\n\n##### Extensibility of Meshery Dashboard: Enhance meshery dashboard with extensible widgets\n\nCurrent Behavior\n\n-Description: All dashboard widgets in Meshery UI are currently defined and bundled directly within the UI, limiting extensibility and modularity.\nExpected Behavior\n\n-Expected Behavior: Widgets should be independent extension points, similar to other UI extensions.\n\n New widgets should be developed, including:\n - Metrics widget\n - Resource Aggregation Charts widget\n -\n Beyond widgets, general improvements are needed for the dashboard and resource tables, including:\n Deep linking between resources\n Support for ad-hoc actions\n\n- Recommended Skills: Golang, Kubernetes,React, Azure, well-written and well-spoken English\n- Expected project size: large (~350 hour project)\n- Mentor(s):\n - Lee Calcote (@leecalcote, leecalcote@gmail.com)\n - Edward Corley (@codeSafari10, codeSafari10@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/14084\n\n##### Support for Azure in Meshery\n\n- Description: Enhance Meshery's existing orchestration capabilities to include support for Azure. The [Azure Service Operator](https://azure.github.io/azure-service-operator/)Azure Service Operator (ASO) provides a wide variety of Azure Resources via Kubernetes custom resources.\nas first-class [Meshery Models](https://docs.meshery.io/concepts/logical/models). This involves enabling Meshery to manage and orchestrate Azure services and their resources, similar to how it handles other Kubernetes resources. The project will also include generating support for Azure services and their resources in Meshery's Model generator.\n\n- Expected Outcome: Meshery will be able to orchestrate and manage all Azure services supported by ASO. This includes the ability to discover, configure, deploy, and operate the lifecycle of Azure services through Meshery. The Meshery Model generator will be updated to automatically generate models for Azure services, simplifying their integration and management within Meshery. This will be an officially supported feature of Meshery.\n- Recommended Skills: Golang, Kubernetes, Azure, well-written and well-spoken English\n- Expected project size: large (~175 hour project)\n- Mentor(s):\n - Lee Calcote (@leecalcote, leecalcote@gmail.com)\n - Mia Grenell (@miacycle, mia.grenell2337@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/11244\n\n##### Distributed client-side inference (policy evaluation) with WebAssembly (WASM) and OPA in Meshery\n\n- Description: Meshery's highly dynamic infrastructure configuration capabilities require real-time evaluation of complex policies. Policies of various types and with a high number of parameters need to be evaluted client-side. With policies expressed in Rego, the goal of this project is to incorporate use of the https://github.com/open-policy-agent/golang-opa-wasm project into Meshery UI, so that a powerful, real-time user experience is possible.\n\n- Expected Outcome: The goal of this project is to enhance Meshery's infrastructure configuration capabilities by incorporating real-time policy evaluation using the golang-opa-wasm project. This project will integrate the capabilities of golang-opa-wasm into the Meshery UI, enabling users to experience the existing, powerful, server-side policy evaluation client-side.\n- Recommended Skills: WebAssembly, Golang, Open Policy Agent, well-written and well-spoken English\n- Expected project size: large (~350 hour project)\n- Mentor(s): Lee Calcote (@leecalcote, leecalcote@gmail.com), James Horton (@hortison, james.horton2337@gmail.com)\n- Upstream Issue: https://github.com/meshery/meshery/issues/13555\n\n#### Open Cluster Management\n\n##### Privacy-preserving and efficient AI model training across multi-cluster\n\n- Description: Open Cluster Management (OCM) streamlines multi-cluster workload management through APIs that align with SIG-Multicluster standards. Beyond traditional workload orchestration, OCM enables scalable AI training and inference across distributed environments.\n\n As machine learning (ML) expands across clusters, data privacy becomes a critical concern. ML models rely on vast datasets, making it essential to safeguard sensitive information across clusters without compromising model performance.\n\n This project integrates Federated Learning (FL) into OCM, enabling privacy-preserving, collaborative model training without transferring raw data between clusters. Instead, training occurs locally where the data resides, ensuring compliance, enhancing efficiency, and reducing bandwidth and storage costs.\n\n By leveraging OCM's Placement, ManifestWork, and other APIs. we standardize FL workflows and seamlessly integrate frameworks like Flower and OpenFL through a unified interface. This approach harnesses OCM's capabilities to deliver scalable, cost-efficient, and privacy-preserving AI solutions in multi-cluster environments.\n\n- Expected Outcome:\n - Comprehensive Documentation:\n - Define the scenarios addressed by the prototype, highlighting its purpose and value. \n - Provide an intuitive and architectural comparison between **Federated Learning (FL)** and **OCM**, mapping FL terminology to OCM APIs to showcase OCM's native support for FL. \n - Illustrate the complete **Federated Learning workflow** within **Open Cluster Management**. \n - Extended Prototype (or CRD) Support:\n - Enable model aggregation persistence in **AWS S3** (currently supports only **native PVC**). \n - Extend compatibility to support additional **Federated Learning frameworks** like [OpenFL](https://github.com/securefederatedai/openfl) and [NVIDIA FLARE](https://developer.nvidia.com/flare) (currently supports **Flower**). This involves understanding how OpenFL, NVIDIA FLARE, and other frameworks function, containerizing them, and integrating them into the prototype.\n - Enhanced Observability and Metrics for Federated Learning API:\n - Define key metrics, expose them via API and ensure extensibility for future enhancements. \n - Track resource usage (optional), monitoring GPU, CPU, and memory usage for client training is beneficial but not essential. \n\n- Recommended Skills: Golang, Kubernetes, Federated Learning, Open Cluster Management, Scheduling\n\n- Expected project size: large (~350 hour projects)\n\n- Mentor(s):\n - Meng Yan (@yanmxa, myan@redhat.com) - primary\n - Qing Hao (@haoqing0110, qhao@redhat.com)\n\n- Upstream Issue (URL): [open-cluster-management-io/ocm#825](https://github.com/open-cluster-management-io/ocm/issues/825)\n\n#### ORAS\n\n##### Enhance Java ORAS SDK\n\n- Description: The ORAS project aims to enhance its Java SDK to support a broader range of features from the OCI Distribution spec. This involves implementing missing functionality, improving existing features, and expanding the SDK’s overall capabilities.\n- Expected Outcome:\n - Implement missing features from the OCI Distribution and Image Specifications, such as [chunked uploads](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#pushing-blobs) and the [Referrers API](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#endpoints)\n - Improve existing features, robustness and tests to ensure full compatibility with the OCI Distribution and Image Specifications.\n - Enhance documentation and provide more comprehensive examples.\n - Add support for additional authentication methods, including using credentials from docker config.json\n- Recommended Skills: java, oci\n- Expected project size: medium (~175 hour projects)\n- Mentor(s):\n - Valentin Delaye (@jonesbusy, jonesbusy@gmail.com) - primary\n - Feynman Zhou (@FeynmanZhou, zpf0610@gmail.com)\n- Upstream Issues: https://github.com/oras-project/oras-java/issues\n\n#### The Update Framework (TUF)\n\n##### Snapshot Merkle trees\n\n- Description: The TUF [*snapshot* role](https://theupdateframework.com/docs/metadata/) is responsible for consistency proofs in a TUF repository. In certain high-volume repositories, the related snapshot metadata file can become prohibitively large, and thus impose a significant overhead for TUF clients. [TAP 16](https://github.com/theupdateframework/taps/blob/master/tap16.md) proposes a method for reducing the size of snapshot metadata a client must download without significantly weakening the security properties of TUF. In this project you will add TAP 16 support to [python-tuf](https://github.com/theupdateframework/python-tuf).\n- Expected Outcome: Snapshot Merkle trees are implemented in python-tuf Metadata API and `ngclient`\n- Recommended Skills: Python, data structures (merkle trees)\n- Expected project size: medium (~175 hour projects)\n- Mentor(s):\n - Lukas Pühringer (@lukpueh) - primary\n - Justin Cappos (@JustinCappos)\n- Upstream Issue (URL): https://github.com/theupdateframework/taps/issues/134\n\n#### Vitess\n\n##### Enhancements for FAQ Chatbot for Vitess\n\n- Description: Vitess is a distributed database system built on MySQL. Developers often need to search through documentation, Slack\ndiscussions, and GitHub issues to find answers. We are starting a project to implement an AI-powered FAQ chatbot using\n**Retrieval-Augmented Generation**, integrating **vector search** with an **LLM** (such as OpenAI, DeepSeek,\nGPT-4, Mistral, Llama 3). The chatbot will be available via a **CLI and Slack bot** for developer support.\n\n In the next phase, which will be implemented in this Summer Of Code (SOC) project, we will be adding more features like:\n - Content filtering for chatbot safety and response validation\n - Fine-tuning the model for improved accuracy\n - Pipelines for refreshing data from new/updated docs\n - Caching previous replies to reduce LLM costs\n - Rate-limiting\n - Better benchmarking for iterative improvements\n - User feedback integration to improve relevancy\n\n- Expected Outcome: Improved chatbot that provides accurate Vitess-related answers via CLI and Slack, using indexed documentation and discussions for retrieval.\n- Recommended Skills: golang, python, LLM APIs, vector databases\n- Expected project size: large (~350 hour projects)\n- Mentor(s):\n - Rohit Nayak (@rohit-nayak-ps, rohit@planetscale.com)\n - Manan Gupta (@GuptaManan100, manan@planetscale.com)\n- Upstream Issue: https://github.com/vitessio/vitess/issues/17690\n\n#### WasmEdge\n\n##### Virtual filesystem security for WasmEdge plug-ins with exporting WASI APIs\n\n- Description: The WASI proposal defines the variety of rules to guarantee the virtual filesystem security and isolation when executing WASM binaries. However, besides using WASI directly in WASM, developers can also implement the host functions to access the filesystem in their guest programming language. This will break the sandbox of WebAssembly. In this program, our goal is to export the WASI APIs in WasmEdge, and use the APIs in WasmEdge plug-ins to ensure the filesystem security and WebAssembly isolation.\n- Expected Outcome:\n - Export needed WASI APIs in WasmEdge internal to provide the functions of checking and accessing host filesystem.\n - Apply the APIs in some WasmEdge plug-ins which accessing the filesystem, such as WASI-NN.\n - Implement test suites to verify the above behaviors.\n- Recommended Skills:\n - C++\n - WebAssembly\n- Expected project size: Large (~350 hour projects)\n- Mentor(s):\n - YiYing He (@q82419 , yiying@secondstate.io) - Primary\n - Shen-Ta Hsieh (@ibmibmibm , beststeve@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4012\n\n##### Port WasmEdge and the WASI-NN ggml backend to the s390x platform\n\n- Description: WasmEdge provides cross-platform support for amd64 and arm64 for executing AI/LLM applications. We would like to support as many new hardware platforms as possible, so developers and users will no longer need to worry about the actual hardware. All they need to do is develop their AI agent or LLM applications once and deploy their services anywhere. For more information, please check the upstream issue.\n- Expected Outcome:\n - Make the WasmEdge toolchain support the s390x platform, including the interpreter and the AOT mode.\n - Ensure the WASI-NN ggml plugin can execute without any issues on the s390x platform.\n - Implement test suites to verify the above behaviors.\n - Write a document discussing the compilation, installation, execution, and verification of the work.\n- Recommended Skills:\n - C++\n - s390x\n - LLVM\n- Expected project size: Large (~350 hour projects)\n- Mentor(s):\n - Hung-Ying Tai (@hydai, hydai@secondstate.io) - Primary\n - dm4 (@dm4, dm4@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4010\n\n##### Use Runwasi with WasmEdge runtime to test multiple WASM apps as cloud services\n\n- Description: With WasmEdge serving as one of Runwasi’s standard runtimes, and as our C++-implemented library continues to evolve, we also need a verification process integrated into Runwasi to streamline and validate the stability of both container and cloud environments.\n- Expected Outcome:\n - A concise GitHub workflow demonstrates Runwasi end-to-end testing on Kubernetes.\n - Need to design an interactive application scenario that supports multiple nodes\n - Try to incorporate the use of the WasmEdge plugin into this scenario\n - Document\n- Recommended Skills:\n - Rust\n - C++\n - GDB\n - git / github workflow\n - shell script\n- Expected project size: Large (~350 hour projects)\n- Mentor(s):\n - Vincent (@CaptainVincent, vincent@secondstate.io) - Primary\n - yi (@0yi0 yi@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4011\n" }, { "path": "programs/summerofcode/2026.md", "content": "## Project Ideas\n\nIf you are a project maintainer and are considering mentoring during the GSoC 2026 cycle, please, submit your ideas below using the template.\n\n[Google Summer of Code 2026 Announcement](https://groups.google.com/g/google-summer-of-code-discuss/c/D-aU3nHnGBQ/m/VU7lwF_MBQAJ) \n[Google Summer of Code Timeline](https://developers.google.com/open-source/gsoc/timeline)\n\nKey GSoC 2026 dates:\n* Organizations application period: Monday, Jan 19, to Tuesday, Feb 3, 2026\n* CNCF Project proposals submissions recommendation: Wednesday Jan 14, 2026\n **Note**, proposals can still be submitted after this recommended date, but the Mentorship team needs time to evaluate the proposals and package our application. The more proposals we have, the stronger our org application will be.\n\nYou can find the project ideas from previous year [here](./2025.md).\n\n> **NOTE:** Please note that GSoC is a program known for its strict deadlines. In addition to responding to your mentee on time, you will be required to submit evaluations on time. Failures to meet the deadlines might affect CNCF's future participation in GSoC.\n\nLinux Foundation [Guidance Regarding Use of Generative AI Tools for Open Source Software Development](https://www.linuxfoundation.org/legal/generative-ai)\n\n---\n\n### Template\n\n```\n#### CNCF Project Name\n\n##### Project Title\n\n- Description:\n- Expected Outcome:\n- Recommended Skills:\n- Expected project size: # one of small (~90 hour projects), medium (~175 hour projects) and large (~350 hour projects)\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - Jane Doe (@jane-github, jane@email.address) - primary\n - John Doe (@john-github, john@email.address)\n- Upstream Issue (URL):\n```\n\n---\n\n## Ideas\n\n\n\n* [Drasi](#drasi)\n * [Reactive Agents with Drasi & Dapr](#reactive-agents-with-drasi-dapr)\n* [Inspektor Gadget](#inspektor-gadget)\n * [Security-focused UX Improvements for the Inspektor Gadget kubernetes-sigs/headlamp Plugin](#security-focused-ux-improvements-for-the-inspektor-gadget-kubernetes-sigsheadlamp-plugin)\n* [Jaeger](#jaeger)\n * [AI-Powered Trace Analysis: Phase 2 - Self-Service \"Skills\" Framework](#ai-powered-trace-analysis-phase-2---self-service-skills-framework)\n* [kgateway](#kgateway)\n * [Benchmarking and Performance Evaluation of Inference Routing Extensions in kgateway](#benchmarking-and-performance-evaluation-of-inference-routing-extensions-in-kgateway)\n* [KitOps](#kitops)\n * [Enrich KitOps Integration Guides with Kubeflow Model Registry, Argo Workflows, Kyverno](#enrich-kitops-integration-guides-with-kubeflow-model-registry-argo-workflows-kyverno)\n* [Kmesh](#kmesh)\n * [Kmesh Dashboard for Simplified Service Mesh Management](#kmesh-dashboard-for-simplified-service-mesh-management)\n* [kpt](#kpt)\n * [Build e-commerce example kpt package](#build-e-commerce-example-kpt-package)\n* [ModelPack](#modelpack)\n * [Unified transformer specification and its auto-generation method for the existing models](#unified-transformer-specification-and-its-auto-generation-method-for-the-existing-models)\n* [OpenKruise](#openkruise)\n * [Alternative progressive delivery of deployment without changing strategy to Recreate](#alternative-progressive-delivery-of-deployment-without-changing-strategy-to-recreate)\n* [OSCAL Compass](#oscal-compass)\n * [OSCAL documents signing](#oscal-documents-signing)\n* [PipeCD](#pipecd)\n * [GCP Cloud Run plugin for pipedv1](#gcp-cloud-run-plugin-for-pipedv1)\n* [WasmEdge](#wasmedge)\n * [Implement Custom Section Parsing and Branch Hinting proposal](#implement-custom-section-parsing-and-branch-hinting-proposal)\n * [Refine the WASM instruction structure in WasmEdge](#refine-the-wasm-instruction-structure-in-wasmedge)\n * [WASM Exception-Handling proposal for AOT/JIT in WasmEdge](#wasm-exception-handling-proposal-for-aotjit-in-wasmedge)\n\n\n#### Drasi\n\n##### Reactive Agents with Drasi & Dapr\n\n- Description: Current AI Agents are mostly \"passive\"—they wait for a user to chat with them. To build \"Ambient Agents\" that can autonomously monitor and react to the world (e.g., \"Wake up when a high-value order is stuck\"), developers need to bridge Real-Time Change Detection with Resilient Agent Runtimes.\n\n- This project connects two CNCF ecosystem projects: **Drasi** (Change Detection) and **Dapr Agents** (Agent Framework). The goal is to build a unified Python-based integration layer that allows Dapr Agents to dynamically \"sense\" their environment. The student will build a \"Smart Router\" reaction that will allow Drasi to send events to Dapr Pub/Sub as standard CloudEvents, and update the Dapr Agents SDK to make subscribing to these events a one-line code experience. This enables \"Scale-to-Zero\" architectures where agents only wake up when specific data conditions are met, eliminating inefficient polling or fragile persistent socket connections.\n\n- Expected Outcome:\n - **Drasi Router Reaction (Python):** A configurable microservice that routes Drasi events to Dapr Pub/Sub topics based on dynamic rules and hosts an embedded MCP (Model Context Protocol) Server for agents to discover queries at runtime.\n - **Dapr Agents SDK Extensions:** A Python module (`dapr_agents.extensions.drasi`) containing Pydantic models for Drasi events and a `@drasi_trigger` decorator that handles CloudEvent validation and subscription automatically.\n - **Ambient Agent Demo:** A complete end-to-end reference architecture (e.g., a \"Proactive Support Agent\") that detects critical database changes and trigger a Dapr Agent workflow to resolve them.\n\n- Recommended Skills:\n - Python (Intermediate/Advanced)\n - Kubernetes & Docker (Intermediate)\n - Understanding of Microservices and Pub/Sub\n\n- Expected project size: Large\n\n- Mentor(s):\n - Aman Singh (@amansinghoriginal, singh.amandeep@microsoft.com) from Drasi - primary\n - Casper Nielsen (@CasperGN, casper@diagrid.io) from Dapr Agents\n\n- Upstream Issue (URL): https://github.com/drasi-project/drasi-platform/issues/383\n\n\n#### Inspektor Gadget\n\n##### Security-focused UX Improvements for the Inspektor Gadget kubernetes-sigs/headlamp Plugin\n\n- Description:\n This project improves the user experience of the Inspektor Gadget plugin for Headlamp with a security-first perspective. The work focuses on four areas: (1) improving interactive traffic visualization so operators can understand and investigate cluster communication patterns, (2) adding an ebpftop-style view to monitor resource usage and runtime status of eBPF gadgets (to make observability overhead transparent), (3) improving DNS debugging workflows with security-relevant signals (failed lookups, retry storms, unexpected domains/resolutions), and (4) streamlining installation/onboarding with guided setup, prerequisite checks, and clearer error handling to reduce misconfiguration and unsafe permissioning. \n\n- Expected Outcome:\n - Improvements to an interactive traffic capture and visualization experience in Headlamp that helps operators understand and investigate cluster communication patterns.\n - Improvements to a resource monitoring dashboard for eBPF programs/gadgets showing real-time and (where feasible) historical CPU/memory metrics to understand observability overhead.\n - Improvements to DNS debugging UX that helps diagnose DNS failures and highlights security-relevant DNS behaviors (failed lookups, retry storms, unexpected domains/resolutions) scoped to relevant workloads/namespaces.\n - Improvements to the Inspektor Gadget installation/onboarding experience with step-by-step guidance, prerequisite checks, actionable error messages, and troubleshooting assistance.\n \n- Recommended Skills: \n TypeScript, React, UX design principles \n Optional Kubernetes fundamentals, networking concepts, eBPF fundamentals \n\n- Expected project size: \n large (~350 hour projects) \n- Mentor(s): \n - Ashu Ghildiyal (@ashu8912, ashughildiyal5@gmail.com) - primary\n - Dor Serero (@dorser, dor.serero@gmail.com)\n - Rene Dudfield (@illume, renesd@gmail.com) \n\n- Upstream Issue (URL): \n - https://github.com/inspektor-gadget/headlamp-plugin/issues/17 \n\n\n#### Jaeger\n\n##### AI-Powered Trace Analysis: Phase 2 - Self-Service \"Skills\" Framework\n\n- **Description:** Jaeger is the industry-standard platform for distributed tracing. As microservice architectures grow complex, finding root causes in massive trace data becomes increasingly difficult. While Phase 1 of this initiative established a baseline AI assistant for natural language search, the system currently relies on hard-coded capabilities. This project (Phase 2\\) aims to transform the Jaeger AI agent from a static chatbot into an extensible, user-programmable platform. The primary objective is to implement a \"Self-Service Skills\" framework, architecturally similar to \"Claude Code Skills.\" This will allow end-users to teach the Jaeger AI new debugging workflows (e.g., \"Analyze Critical Path\" or \"Detect N+1 Queries\") by simply adding configuration files containing system prompts and logic rules, without needing to recompile the Jaeger binary. The applicant will build this extension within the Jaeger v2 (OpenTelemetry-based) architecture, utilizing **LangChainGo** to orchestrate interactions with Language Models (SLMs/LLMs). This project bridges the gap between generic AI reasoning and domain-specific observability expertise.\n- **Expected Outcome:**\n - **Skills Engine Implementation:** A robust backend framework in Go that dynamically discovers, validates, and loads user-defined \"Skills\" (prompts and tool definitions) from configuration.\n - **Smart Analysis Features:** A polished implementation of Natural Language Search and Contextual Trace Explanation that intelligently leverages these loaded skills.\n - **Local-First Support:** Verified compatibility with local model runners (e.g., Ollama, Llama.cpp) to ensure deterministic performance without sending data to public clouds.\n - **UI Integration:** Enhancements to the Jaeger React UI to expose these AI capabilities and visualize the \"reasoning steps\" taken by the agent.\n - **Documentation:** A complete guide for users on \"How to Author Custom AI Skills for Jaeger.\"\n- **Learning Opportunities:**\n - **Agentic AI Architecture:** Learn to design stateful AI agents in Go that utilize \"Tool Calling\" and \"Reasoning Loops\" rather than simple text generation.\n - **OpenTelemetry Internals:** Gain deep familiarity with the OpenTelemetry Collector architecture, as Jaeger v2 is built directly on top of it.\n - **Cloud-Native Engineering:** Experience contributing to a graduated CNCF project, including navigating code reviews, writing design docs (RFDs), and adhering to open-source best practices.\n - **Full-Stack Development:** Practical experience bridging a complex Go backend with a modern React frontend.\n- **Recommended Skills:**\n - **Languages:** Strong proficiency in **Go (Golang)** is required. Experience with **TypeScript/React** is highly recommended.\n - **AI/LLM:** Familiarity with LLM concepts (Prompt Engineering, RAG, Function Calling) and frameworks like LangChain.\n - **Domain Knowledge:** Basic understanding of distributed systems, observability, or debugging workflows is beneficial.\n- **Expected project size:** Large (~350 hour projects)\n- **Mentors:**\n - Jonah Kowall (@jkowall, jkowall@kowall.net)\n - Yuri Shkuro (@yurishkuro, github@ysh.us)\n- Upstream Issue: https://github.com/jaegertracing/jaeger/issues/7827\n\n\n#### kgateway\n\n##### Benchmarking and Performance Evaluation of Inference Routing Extensions in kgateway\n\n- Description: kgateway provides inference routing capabilities based on the Kubernetes Gateway API Inference Extension project. This integration enables advanced behaviors such as model-aware routing, serving priority, and customizable load-balancing of self-hosted Generative AI models.\n\n However, there is currently no standardized or reproducible way to evaluate the performance impact of these inference routing extensions.\n\n This project aims to design and implement a comprehensive benchmarking framework to measure the latency, throughput, and resource overhead introduced by inference routing extensions in kgateway. The benchmarks will help maintainers and users understand performance tradeoffs, validate optimizations, and guide future architectural decisions.\n\n- Expected Outcome:\n - A reproducible benchmarking framework for inference routing extensions in kgateway\n - Benchmark scenarios covering:\n - Baseline gateway routing vs inference-enabled routing\n - Different inference extensions and EPP configurations\n - Request/response and streaming inference workloads\n - Collected metrics including:\n - End-to-end latency (p50 / p95 / p99)\n - Throughput\n - CPU and memory overhead\n - Automated benchmark execution (e.g., via CI or documented scripts)\n - Documentation describing benchmark methodology, results interpretation, and best practices\n\n- Recommended Skills:\n - Go\n - Kubernetes\n - Familiarity with gateways or networking concepts\n - Basic understanding of AI inference workloads is a plus\n\n- Expected project size:\n Medium (~175 hour projects)\n\n- Mentor(s):\n - Primary Mentor: Nina Polshakova (@npolshakova, nina.polshakova@solo.io)\n - Secondary Mentor: Daneyon Hansen (@danehans, daneyon.hansen@solo.io)\n\n- Upstream Issue (URL):\n https://github.com/kgateway-dev/kgateway/issues/12289\n\n\n#### KitOps\n\n##### Enrich KitOps Integration Guides with Kubeflow Model Registry, Argo Workflows, Kyverno\n\n- Description: KitOps enables OCI-based packaging and distribution of ML artifacts such as models, datasets, and configurations. Kubeflow’s Model Registry supports OCI-based storage, which aligns well with KitOps’ design. However, there is currently no standardized guidance on how to use KitOps with the Kubeflow Model Registry. This project will define documentation explaining how to set up and use KitOps for model registration, retrieval, and lifecycle management within a Kubeflow environment. The work will cover setup, usage patterns, and best practices, with optional references to extending these workflows to related tools such as Argo Workflows. There is also potential for a guide on how to extend policy engines for ML workflows with Kyverno. \n\n- Expected Outcome:\n - Documentation describing how to use KitOps with Kubeflow Model Registry\n - Step-by-step guides for model registration, retrieval, and management\n - tutorial\n- Recommended Skills:\n - Python\n - Golang\n - Technical Writing\n- Expected project size: small\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - Gorkem Ercan (@gorkem, gorkem.ercan@gmail.com) - primary\n - Angel Misevski (@amisevsk, amisevsk@gmail.com)\n- Upstream Issue (URL): https://github.com/kitops-ml/kitops/issues/858\n\n\n#### Kmesh\n\n##### Kmesh Dashboard for Simplified Service Mesh Management\n\n- Description: In discussions with developers and end-users, we have received numerous comments indicating that Kmesh presents an excessively high barrier to use. For example, the use of waypoints encompasses three levels of granularity: Namespace, Service, and Workload. Furthermore, certain traffic management policies necessitate editing the Envoy filter. Following discussions on this matter during the community meeting, it was decided to incorporate a Kmesh dashboard into the Kmesh project. This will lower the barrier to using Kmesh through an interactive interface.\n- Expected Outcome:\n - A user-friendly dashboard that simplifies Kmesh operations through intuitive UI workflows\n - One-click or guided waypoint installation across Namespace, Service, and Workload levels with clear visual feedback\n - Interactive service topology map (similar to Kiali) showing service dependencies, traffic flow, and health status\n - Simplified circuit breaker configuration interface with preset templates and real-time validation\n - Rate limiting configuration with visual policy builder and immediate feedback on applied rules\n - Integrated metrics dashboard showing key service mesh performance indicators (latency, error rates, throughput)\n - Built-in authentication support with role-based access control (RBAC) for secure dashboard access\n - Comprehensive documentation and user guides for all dashboard features\n- Recommended Skills: TypeScript, React, Kubernetes, Service Mesh concepts, UX/UI design principles\n- Expected project size: medium\n- Mentor(s):\n - ZhenCheng Li (@LiZhenCheng9527, leezhencheng6@gmail.com) - primary\n - Zhonghu Xu (@hzxuzhonghu, zhhxu2011@gmail.com)\n - Zengzeng Yao (@yaozengzeng, yaozengzeng@huawei.com)\n- Upstream Issue (URL): https://github.com/kmesh-net/kmesh/issues/1552\n\n\n#### [kpt](https://kpt.dev/)\n\n[kpt](https://kpt.dev/) is a toolchain that allows users to customize kubernetes packages declaratively. kpt uses a\n[configuration as data](https://cloud.google.com/blog/products/containers-kubernetes/understanding-configuration-as-data-in-kubernetes)\napproach for customization. The user specifies their customization changes as data in yaml files and kpt updates\nthe source package by applying the customization to the kubernetes package. Unlike templating tools such as helm,\nthere are no customization directives in the source package itself.\n\nCurrently, complete examples for using kpt are in specialized domains such as telecommunication management, which \nare difficult to understand without familiarity with that domain. Other examples such as those in the documentation \nare rather piecemeal and don't give a complete picture of the power of kpt. The purpose of this project is to \nprovide a complete example that demonstrates the power of kpt in a domain that is more widely understood.\n\n##### Build e-commerce example kpt package\n\nIn this project, the contributor will take a complete e-commerce application such as [Online Boutique](https://github.com/GoogleCloudPlatform/microservices-demo)\nand package it as a kpt package. The contributor will then show how the example can be customized using the kpt \ntoolchain in a number of ways such as:\n\n1. Change from online boutique to online florist or online car accessory site\n1. Language and currency localization\n1. Sales Tax/VAT localization\n1. Deployment configuration (Small/medium/large)\n\n\n- Description: Use an example e-commerce application and create the related kpt package with the description how to deploy the application.\n- Expected Outcome: The kpt file and related documentation of an e-commerce example application are contributed to kpt\n- Recommended Skills: Capability to learn, basic cloud native skills\n- Expected project size: small (~90 hours)\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - Liam Fallon (@liamfallon) - primary\n - Ciaran Johnston (@ciaranjohnston)\n - Gergely Csatari (@CcsatariGergely)\n- Upstream Issue (URL): https://github.com/kptdev/kpt/issues/4326\n\n\n#### ModelPack\n\n##### Unified transformer specification and its auto-generation method for the existing models\n\n- Description: Transformer is the dominant architecture for modern LLMs, and its design has largely converged. For example, most state-of-the-art open-source models adopt GQA/MLA for the Attention layer and MoE for the MLP layer. As a result, a Transformer can be viewed as a composition of standardized building blocks. This enables further abstraction of a unified architectural specification across different open-source models, which can serve as the Transformer specification in ModelPack. Based on this specification, many valuable capabilities become possible. For inference engines, it enables automatic support for multiple Transformer models, so newly trained Transformer models can be supported without per-model adaptation.\n- Expected Outcome:\n - Jointly complete a unified Transformer specification (an in-progress PR already exists)\n - Using vLLM and SGLang, conduct POCs on three or more mainstream open-source Transformer models based on this specification\n - Design a workflow or Claude skills that can automatically generate Transformer specification definitions from models in the Hugging Face transformers repository\n- Recommended Skills:\n - Python\n - Familiar with LLM Prompts and LLM Inference Engine\n- Expected project size: medium\n- Mentor(s):\n - Zhao Chen (@aftersnow, zhaochen.zju@gmail.com) - primary\n - Peng Tao (@bergwolf, bergwolf@hyper.sh)\n- Upstream Issue (URL): https://github.com/modelpack/model-spec/issues/164\n\n\n\n#### OpenKruise\n\n##### Alternative progressive delivery of deployment without changing strategy to Recreate\n\n- Description: Currently **OpenKruise Rollout** change the updateStrategy of kubernetes Deployment to Recreate during the progressive delivery. However such hack cause concerns about the risk of recreate all pods if deployment is not paused properly. This program will explore an alternative strategy that utilize the minReadySeconds and maxUnvailable knobs to control the progressive delivery of Deployment. It is hopefully a more robust way of enabling progressive delivery for native Deployment workload.\n- Expected Outcome:\n - add an alternative implementation for progressive delivery of Deployment in OpenKruise Rollout\n - end-to-end test cases that cover related normal rollout, rollback cases\n- Recommended Skills:\n - Kubernetes (Intermediate)\n - Operator Development\n - Golang\n- Expected project size: medium\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - Zhang Zhen (@furykerry, furykerry@gmail.com) - primary\n - Zhong Tianyun (@AiRanthem, airanthem666@gmail.com)\n- Upstream Issue (URL): https://github.com/openkruise/rollouts/issues/323\n\n\n#### OSCAL Compass\n\n##### OSCAL documents signing\n\n- Description: CNCF OSCAL Compass trestle provides means to author and validate OSCAL documents including catalogs, profiles, component definitions and such. There is currently no standardized way to sign same. Needed is to define the signing goals and trust model, choosing the signing and envelope standards, and the implementation of signing during artifact generation. Also needed are key management and identity, verification support, and provenance metadata support. See upstream issue for more details.\n\n- Expected Outcome:\n - trestle code to sign and verify signing of OSCAL documents\n - clear error messages for failures\n - sufficient test case coverage\n - documentation\n - tutorial\n- Recommended Skills:\n - Python\n- Expected project size: large\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - Lou DeGenaro (@degenaro, lou.degenaro@gmail.com) - primary\n - Chris Butler (@butler54, chris.butler@redhat.com)\n - Vikas Agarwal (@vikas-agarwal76, avikas@in.ibm.com)\n- Upstream Issue (URL): https://github.com/oscal-compass/compliance-trestle/issues/2037\n\n\n#### PipeCD\n\n##### GCP Cloud Run plugin for pipedv1\n\n- Description: PipeCD v1 - the new version based on a plugin architecture (ref: [PipeCD plugin-arch overview blog](https://pipecd.dev/blog/2024/11/28/overview-of-the-plan-for-pluginnable-pipecd/)), has released an alpha version, and we are rapidly adding features supported in v0. We need to develop a plugin for PipeCD v1 to support [GCP Cloud Run](https://cloud.google.com/run) deployment. In PipeCD v0, the support for GCP Cloud Run deployment is built in piped source directly (ref [PipeCD Cloud Run deployment](https://pipecd.dev/docs-v0.55.x/user-guide/managing-application/defining-app-configuration/cloudrun/)), the idea is to move the Cloud Run deployment support to the plugin to make it easier to maintain and extend.\n- Expected Outcome:\n - CloudRun plugin for PipeCD\n - Possible update plugin SDK while develop the plugin\n - Possible update docs how to develop PipeCD plugin\n - Blog about how to develop a PipeCD plugin on [https://pipecd.dev/blog/](https://pipecd.dev/blog/)\n- Recommended Skills:\n - Golang\n - GCP Cloud Run\n - GitOps\n - Continuous Delivery (CD)\n- Expected project size: Medium\n- Mentor(s):\n - Khanh Tran (@khanhtc1202, khanhtc1202@gmail.com)\n - Shinnosuke Sawada-Dazai (@Warashi, shin@warashi.dev)\n- Upstream Issue:\n - https://github.com/pipe-cd/pipecd/issues/6114\n\n#### WasmEdge\n\n##### Implement Custom Section Parsing and Branch Hinting proposal\n\n- Description: As discussed in the [WasmEdge January 2026 community meeting](https://youtu.be/MKOHVU1VBzg), some toolchains may want to apply the branch hinting proposal. However, WasmEdge is currently unable to implement it due to the lack of custom section parsing. In this program, we aim to incorporate custom section parsing and branch hinting into the WasmEdge toolchain.\n- Expected Outcome:\n - A series of test cases that verify the behavior of the custom section parsing and branch hinting proposal\n - An implementation of these defined features\n - A document discussing the design decisions and how to use them\n- Recommended Skills:\n - C++\n - WebAssembly\n- Expected project size: large\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - YiYing He (@q82419, yiying@secondstate.io) - primary\n - Hung-Ying, Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4517\n\n\n##### Refine the WASM instruction structure in WasmEdge\n\n- Description: According to the definition of WASM instructions, there are variety of immediates in every instructions. And in WasmEdge data structures currently, the immediates data of each instructions is packaged in the instruction class. This causes the situation that the instruction class should have the enough size to fit both the instructions with large and small size of immediates, and the runtime memory usage is wasted. In this program, we expect the mentee to refactor the data structures to split the instruction OpCode vector and the immediates data buffer vector to refine the memory usage of WasmEdge.\n- Expected Outcome:\n - Refactor the instruction class to split the OpCode vector and immediates data\n - Update all tests which contain the instruction class and pass all tests\n - Perf the memory usage to prove the implementation\n- Recommended Skills:\n - C/C++\n - WebAssembly\n- Expected project size: large\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - YiYing He (@q82419, yiying@secondstate.io) - primary\n - Hung-Ying, Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4558\n\n\n##### WASM Exception-Handling proposal for AOT/JIT in WasmEdge\n\n- Description: The exception-handling proposal is merged into the WASM spec version 3.0. In WasmEdge, we supported the interpreter mode. Since the WASM 3.0 become the default WASM standard currently, we should implement the AOT/JIT mode of this proposal for the completion of the WASM 3.0. In this program, we expect the mentee to implement the exception-handling proposal in AOT/JIT and pass the spec tests.\n- Expected Outcome:\n - Implement the AOT/JIT of exception-handling proposal according to the WASM spec\n - Pass the spec tests\n- Recommended Skills:\n - C/C++\n - WebAssembly\n - LLVM\n- Expected project size: large\n- Mentor(s): #For GSoC, it is **required** to have at least 2 mentors with 1 being a primary mentor.\n - YiYing He (@q82419, yiying@secondstate.io) - primary\n - Hung-Ying, Tai (@hydai, hydai@secondstate.io)\n- Upstream Issue (URL): https://github.com/WasmEdge/WasmEdge/issues/4557\n\n" }, { "path": "programs/summerofcode/README.md", "content": "# CNCF + Summer of Code\n\nThe Cloud Native Computing Foundation participates in the [Google Summer of Code](https://summerofcode.withgoogle.com/) (GSoC). CNCF is a great place to spend a summer learning, coding, participating, and contributing. We are an exciting open source foundation with a vibrant community of projects, and we look forward to your application and your project ideas!\n\n## Organization Admins\n\n- Nate W. ([@nate-double-u](https://github.com/nate-double-u))\n\n## Communication\n\nPlease reach out to us in the [Discussions tab](https://github.com/cncf/mentoring/discussions).\nPlease don't use DMs unless strictly necessary as doing so both has the potential of overwhelming project maintainers and others with similar questions lose the benefit of public discussion.\n\nIt's best if you use a public communication channel whenever possible; however, if you need to communicate in private, please feel free to send the admins a note via soc@cncf.io (please use the public channels for any project-related discussion).\n\n## Current Year\n\nDetails about the 2026 program are available [here](https://github.com/cncf/mentoring/blob/main/programs/summerofcode/2026.md).\n\n[Google summer of code timeline](https://developers.google.com/open-source/gsoc/timeline).\n\n" } ]