🎉 [Google Summer of Code 2025] - Automating Operator Maintenance: Driving Better Results with Less Overhead

[camilamacedo86]

Kubebuilder is participating in Google Summer of Code 2025 under the CNCF organization.

📅 Proposal Submission: March 24 - April 8 (1800 UTC)

🚀 Project Overview

Code-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.
However, 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.

This 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.

Note 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.

Expected Outcome

• Conduct research on 3-Way Merge & Advanced Merge Options in Git.
• 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.
• 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.
• Successfully complete the proposal for WIP PEP.
• Introduce a new Kubebuilder Plugin 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.

---

Recommendation Before Submitting Your Proposal

Before submitting your proposal, it is highly recommended to go through the following steps to ensure you understand what will be required:
1️⃣ QuickStart Guide (10 min) – Follow this tutorial to build a basic project.
2️⃣ Hands-on Experimentation (20 min) – Try re-scaffolding a project using an older Kubebuilder release, simulate custom changes, and observe how updates impact user-defined code.

a) Clone the Project and Checkout an Older Release

Clone the Kubebuilder repository and switch to an older release (e.g., release-4.1):

git clone https://github.com/kubernetes-sigs/kubebuilder.git  
cd kubebuilder  
git checkout release-4.1  

This will allow you to work with an older version of Kubebuilder's scaffolded project.
📌 See: https://github.com/kubernetes-sigs/kubebuilder/tree/release-4.1/testdata/project-v4

b) Modify the Controller Code

Navigate to the test data project directory in your local environment:

cd testdata/project-v4  

Then, open the following file in a text editor:

📌 admiral_controller.go

Replace: // TODO(user): your logic here
With:

// CUSTOM USER CODE  
// This is a user-defined modification added to the project.  
// After upgrading the project, users expect their custom logic  
// to be retained instead of being overwritten by the update.  

c) Run Kubebuilder to Re-generate the Project

Using the latest release of Kubebuilder (ensure that you have it installed), inside the project directory, run:

kubebuilder alpha generate  

After execution, the project will be re-generated and will look the same as before—except your custom code will be missing. To restore the user-defined code, developers usually compare their local branch with the main branch in GitHub and manually re-add their modifications.

3️⃣ Check out the WIP Design Doc for this feature (15 min) – Read the WIP PEP.

💡 Pro Tip: If you're new to Operators, and I want to know more about check the Getting Started - 30 min.

Also, feel free to check some extra references:

• Kubebuilder Basic Project Tutorial
• Kubebuilder Project Config Reference
• Kubebuilder Rescaffold Reference

---

🚀 Guidance for the Application

The application is yours to shape as you see fit! To provide some guidance, we’ve created a template with a few questions, but feel free to approach it however you like. Be creative if you wish* Just ensure you include the key information while keeping it concise and to the point—no need for technical details or excessive verbosity. Our main goal is to understand your motivations and learn more about you.

You must submit your application through the Google Summer of Code platform.
The format doesn’t matter to us—just make sure all the necessary details are there.

Looking forward to your applications! 🚀

# About Me  

- **Where/What do you study?**  
  [Your university/institution, field of study]  
- **Are you graduated?**  
  [Yes/No - current year if applicable]  
- **Why IT/Development?**  
  [What got you interested in this field?]  

---  

# Why This Project?  

- **What excites you about Automate Project & Kubebuilder?**  
  [What interests you about this project?]  
- **What motivates you?**  
  [Why do you want to contribute?]  
- **Why this project specifically?**  
  [How does it align with your goals/interests?]  

---  

# How Would You Approach the Problem?  

- **Steps to solve it?**  
  [How would you break it down?]  
- **Challenges & how to handle them?**  
  [Any foreseeable challenges? How will you tackle them?]
  
---   
  
# How Would You Plan the Work?
   
- **Milestones/Roadmap?**  
  - [Milestone 1]  
  - [Milestone 2]  
  - [Milestone 3]  

---  

# What Do You Expect?  

- **What do you hope to learn/gain?**  
  [Skills, experience, connections, etc.]  
- **How can we help you?**  
  [What kind of support do you need?]  

---  

# Open Source Contributions  

*(Not mandatory, but share if you have!)*  

- **Projects/PRs:**  
  - [Project Name] – [Link]  
  - [Project Name] – [Link]  
- **Why did you contribute?**  
  [Brief reason]  

---  

# Other Projects (University/Personal)  

- **Any past work you'd like to share?**  
  - [Project Name] – [Link (if any)]  
  - [Brief description]  

---  

# Availability & Commitments  

- **Other commitments?**  
  [Job, university, etc.]  
- **Time available per week?**  
  [Estimated hours]  

---  

# After GSoC?  

- **Plans after the project?**  
  [Continue contributing? Apply skills elsewhere?] 

---

❓ FAQ

📌 Getting Started with Contributions

💡 New to Open Source? Start with:

📌 CONTRIBUTING Guide
📌 VERSIONING
📌 Good First Issues

🆘 Need Help?

💬 Join us in #kubebuilder on Kubernetes Slack.
🐛 Open an issue in the Kubebuilder GitHub Repo.

---

👥 Mentors

📌 @Kavinjsir | @varshaprasad96 | @camilamacedo86

[vitorfloriano]

Hi @camilamacedo86, will there be a design document for these changes (like these docs) or is writing the document one of the outcomes for this project?

[camilamacedo86]

HI @vitorfloriano

One of the expected outcomes is:

• Successfully complete the proposal for 📖 WIP - Proposal: Automating Operator Maintenance: Driving Better Results with Less Overhead #4302.
  ^ See the PR with the design doc and the steps described here Before Submitting Your Proposal

Look the details of the answer bellow: #4592 (reply in thread)

[vitorfloriano]

@camilamacedo86 I understand that non-goals are part of the design document that comes out of this, but I believe it would be helpful for applicants to have an idea of what’s out of scope beforehand—just so we don’t get ahead of ourselves. Could you share what’s not expected?

[chethanm99]

Hi @vitorfloriano , even i had the same doubt , may be the major changes to be done according to the expected outcomes such as developing a POC implementing GitHub Actions which creates a pull request and introducing the plugin that scaffolds the GitHub Action based POC require documentation as they are major changes. Documentation for AI driven conflict resolution can be done it later phases and other expected outcomes such researching on git merging strategies and AI tools themselves act as documentation. Also https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/template.md mention that only major changes require docs.

[camilamacedo86]

Hi @chethanm99

Following the comments and answers inline:

One of the expected outcomes is:

• Successfully complete the proposal for 📖 WIP - Proposal: Automating Operator Maintenance: Driving Better Results with Less Overhead #4302.
  ^ See the PR with the design doc

Documentation for AI driven conflict resolution

Yes, it is a re-search to be added in the document above

So, if you follow the steps recommended at Before Submitting Your Proposal you will:

• 1️⃣ QuickStart Guide (10 min) – Follow this tutorial to build a basic project.
• 2️⃣ Hands-on Experimentation (20 min) – Try re-scaffolding a project using an older Kubebuilder release, simulate custom changes, and observe how updates impact user-defined code. That will show what the project is about
• 3️⃣ Check out the WIP Design Doc for this feature (15 min) – Read the 📖 WIP - Proposal: Automating Operator Maintenance: Driving Better Results with Less Overhead #4302. <= Read what we have in the design proposal already

What are the suggested project steps: (For the student that will do the project, after the application be accepted)

1. Conduct research on 3-Way Merge & Advanced Merge Options in Git.
2. 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.
3. Successfully complete the proposal for 📖 WIP - Proposal: Automating Operator Maintenance: Driving Better Results with Less Overhead #4302.
4. Introduce a new Kubebuilder Plugin that scaffolds the GitHub Action based on the POC.
5. 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.

[chethanm99]

Hi @camilamacedo86 I had doubt that as completing the proposal successfully for #4302 is one of the expected outcome of the project should we write the proposal for #4302 following the template of https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/template.md and include it within the project proposal or create a separate proposal for #4302 and submit it along with project proposal separately.

[camilamacedo86]

Hi @chethanm99,

I appreciate your interest! 🎉 Let me know if I can explain.
How will it work?

The student will conduct research and create a Proof of Concept (POC) as part of the project. These steps will help gather the necessary information to finalize the proposal, which is already a work in progress (WIP). You can find it here: #4302

Based on the POC, the student will work to code a solution which will make Kubebuilder scaffold the feature with a new **initial version /alpha ** of the functionality (it is the minimal required for we can provide those values to users).

✋ We will guide the student through these steps.

Followed by additional research to supplement the proposal document to explore whether AI could help resolve conflicts and solutions.

If you follow the steps in "Before Submitting Your Proposal," the hands-on will help understand the problem that needs to be solved.

Please feel free to ask any questions—I'm happy to help!

[camilamacedo86]

Hi @vitorfloriano, @chethanm99,

We are very excited about your interest! 🎉
If you have any questions, please don’t hesitate to ask. We're happy to help!

[chethanm99]

Thank you for your warm welcome! . I'm really excited about this project and looking forward to learning and contributing. I appreciate your support, and I'll be sure to reach out if I have any questions.

Looking forward to working with you all! 🚀

[vitorfloriano]

@camilamacedo86 If the solution from this proposal is built on top of v3 or newer versions, can we safely assume that the PROJECT file will always be available? If so, would relying on that file be a good design decision for the solution?

[camilamacedo86]

Yes, the PROJECT file will always be available.

To know more about, you might want to check the following references:

• Kubebuilder Basic Project Tutorial
• Kubebuilder Project Config Reference
• Kubebuilder Rescaffold Reference

PS.: I will add those references in the description

We only support Kubebuilder 4.x.
The PROJECT file has existed since version 3.0.0.

To implement this feature, we need to:

• Start tracking the tag of the tool used to initialize the scaffold. See: Add kubebuilderVersion Field in PROJECT File for Tracking Kubebuilder CLI Version #4398
• We might want to allow users to configure the GitHub action with a tag version that should be used for the initial version, if we want to support previous releases.
• Allow users to define the path to create the scaffold (to support monorepo repositories). - Not mandatory for the first initial release of this feature but nice to have in the medium-term

[Kuzuri247]

Hey @camilamacedo86 what do you prefer google doc or markdown file for proposal reviewing

[camilamacedo86]

For us, any format is acceptable, but you will need to submit your proposal through the Google Summer of Code (GSoC) system. You can check the estimated timeline here: GSoC Timeline. Please note that the system is not open yet.

It is important to review the formats allowed within the GSoC system to ensure your proposal meets their requirements. Once you submit your proposal there, we will review all submissions.
Let us know if you have any questions!

[chethanm99]

Hi @Kuzuri247 according to https://google.github.io/gsocguides/student/writing-a-proposal the proposal must be submitted in form of pdf

[Kuzuri247]

@chethanm99 I know but for reviewing it has to in markdown or doc form so that changes can be made according to the maintainers

[chethanm99]

@chethanm99 I know but for reviewing it has to in markdown or doc form so that changes can be made according to the maintainers

If you have created your proposal in google docs then i think you can export the draft as pdf and keep the original docs within google docs and make changes according to maintainers

[camilamacedo86]

Hey folks,

Just a quick guide to help with your application.

The application should be short and clear (not too verbose).
It should be a couple of pages with your thoughts (not result of re-search).

To keep it simple, mainly answering questions like:

1. Who are you? – Briefly introduce yourself.
2. Why are you interested in this project? – What excites you about it?
3. What motivates you? – Why do you want to work on this specifically?
4. How would you approach the problem? – What is your thought process for solving it? No need for technical details.
5. What do you expect from this project and from us? – What do you hope to learn or gain from this experience? <- We would like to know it from you.

Keep it simple and focus on your own ideas.
Let us know if you need help! 😊

[Kuzuri247]

https://github.com/Kuzuri247/Introduction My intro

[camilamacedo86]

Hi @Kuzuri247

thank you for being so interested in the project.
See that you will need to apply it via the Gs0C system.

Also, please look at the description, we updated it with a guidance to help out with what is expected in the application.

[camilamacedo86]

Hi @vitorfloriano @Kuzuri247 @chethanm99 @drnic,

@Kavinjsir, @varshaprasad96, and I discussed this and have added guidance in the description for the application.
We hope this helps provide better direction on what information to include.

Thank you so much for your interest in the project! 🙌

[LJTian]

Idea for Document Internationalization

Overview

I would like to implement internationalization changes for our documentation.

Current Tools

1. Kubebuilder: I have learned that Kubebuilder uses mdBook for its documentation.
2. Internationalization Support: The mdbook-i18n-helpers can facilitate internationalization for mdBook projects.

Proposed Workflow

1. Automatic Translation: If everything goes smoothly, we can leverage AI or translation APIs to automatically translate language files.
2. Manual Review: After automatic translation, we will conduct a manual review and approval process to ensure quality and accuracy.

[LJTian]

https://kubebuilder.cn 我已经完成了初步的实现。