Contributing to Open Source is fun and great learning, isn't it? What if you have an opportunity where you get mentorship from experienced developers (who are maintainers or contributors in an open-source project) to contribute to an open-source project?

One such opportunity is the LFX Mentorship program. It takes place thrice a year - Spring Term (March 1st - May 31st), Summer Term (June 1st - August 31st), and Fall Term (September 1st - Nov 30th). The exact dates may slightly vary each year.

Application process

You can apply for a maximum of any three projects per term. You'll need to submit a resume and cover letter separately for all the projects you apply. The cover letter consists of the following topics:

• How did you find out about our mentorship program?
• Why are you interested in this program?
• What experience and knowledge/skills do you have that are applicable to this program?
• What do you hope to get out of this mentorship experience?

In some of the projects, you might need to complete additional tasks as well. I had to submit only my resume and cover letter only. Having prior contributions in that project or other projects at least helps a lot to get selected. To learn more refer to these docs https://docs.linuxfoundation.org/lfx/mentorship.

How I came to know about it

Kunal Kushwaha is the person, from whom I got to know about open-source, numerous student programs, cloud-native, and many things. I came to know about the LFX Mentorship program from the same source. At that time, however, I was new to programming, so I didn't apply for it immediately.

Eventually, I came to know about DevOps, Kubernetes, and CI/CD towards the end of 2021 and developed a significant interest in them. At the beginning of 2022, I started contributing to Open-Source as well, and because of my interest in Kubernetes, most of my contributions were in 2-3 CNCF projects. From March 2022, I was looking for opportunities to apply the knowledge and skill I had acquired in nearly 1.5 years and work on some real-world problem-solving projects. Then I tried to learn more about the LFX Mentorship program and found it serves my need and interest.

About the project

My project was "CNCF - OpenELB: Provide the OpenELB Web UI for managing EIP and IP pool". I had to develop a web console for creating and managing the OpenELB resources. Now you might be wondering what is OpenELB. Well, OpenELB is an open-source load balancer implementation designed for exposing the LoadBalancer type of Kubernetes services in bare metal, edge, and virtualization environments. You can learn more about it here https://openelb.io/. Here's the project URL https://github.com/openelb/openelb. It is a sandbox project in CNCF.

My journey throughout the mentorship

Introduction

Usually, I start learning a new project by going through the getting started section in the documentation. I adopted the same strategy in OpenELB. After getting selected as a mentee, I contacted my mentor Feynman Zhou using Twitter. He provided me with a light on post-selection tasks and also informed me that the BGP mode of OpenELB will not work in Cloud VMs. Then, I tried to learn about the BGP and Layer2 configuration modes. I referred to a few external resources like Cloudflare learning center to learn more about BGP (Border Gateway Protocol), Autonomous systems, and routing.

After that, I finally started going through a basic configuration of OpenELB in BGP mode and testing if things function properly. Because of a lack of experience with router ID and Autonomous System Numbers and all, I encountered a lot of challenges, but with the help of one of my mentors Yunkang Ren, I was able to come through them. After that, I also improved the documentation of OpenELB in a way that new learners wouldn't encounter the problems I did. Here are the pull requests that I've created https://github.com/openelb/website/pulls?q=is%3Apr+author%3Aanuragthepathak+is%3Aclosed.

Then I started walking through the codebase of the OpenELB project. The other mentee of the OpenELB project Amal Thundiyil helped me in that process. I learned that there is a component named manager, that manages most of the tasks in OpenELB. It used Cobra CLI, so I had to learn enough to use it. During that time, I learned about the custom resource definitions of OpenELB as well and also a little about Kubebuilder and Kustomize. The book Programming Kubernetes by Michael Hausenblas, and Stefan Schimanski also helped quite a lot. I also had to go through Kubernetes docs to improve my understanding of the Kubernetes API. The Kubebuilder book was also very useful for me. After that, I also learned to use Makefiles and was ready to contribute to the OpenELB project.

Then on June 18th, 2022, I got a chance to meet our mentors and the other mentee of OpenELB (the mentee and the mentors of OpenFunction were also there). There I was informed about how to start working on the project, so I started learning about using the Kubernetes API client. After experimenting with the official Kubernetes Client, I learned that it's not very feasible to use that for dealing with CRDs (custom resource definitions), so I explored the controller-runtime client as per what I found in many sources, and found that it was a great fit for the backend of our project. During that time, I also built a simple project to see if everything would work as expected or not (as this was the first time I dealt with a Kubernetes client, I considered that debugging would be easier in a smaller project).

Core contribution

I started the implementation of our project by writing code for the HTTP server (which is used by the frontend) within the manager component. After a few days, it was almost ready to start working on the frontend, so I created a pull request.

After that, we started planning for the frontend. I was informed that it would be similar to the Kubesphere-Console. So I tried out Kubesphere from the user perspective and started going through the codebase. In the beginning, the Kubesphere-Console was very overwhelming for me as I never worked with any large-scale React project before. I also didn't work with any React project with class-based components. In the meantime, I was also provided with designs in Figma. Sadly, I never used Figma earlier, but with the help of my kind mentors, I quickly learned to use it. After consulting with my mentor Changjiang Li, we decided to use React function-based components and Typescript for this project (in contrast to Kubesphere-console, where React class-based components and Javascript were used). I chose to use Typescript because debugging larger Javascript codebases is usually very challenging.

I have completed the basic setup of a React project along with a few UI components like Navbar and created a pull request in the OpenELB-Console repository. It's worth noting that the use of Kube-design components boosted our productivity in the frontend. Then I was trying to develop a complicated component that was the table shown below.

It involved a large part of the codebase because it required setting wrappers around API fetching, state management, and many more. Even though the code pattern and overall project structure were supposed to be similar to that of Kubesphere-console, things were getting very challenging for me and consuming a significant amount of time because I had to convert class-based components to function-based components. When I made my mentor Changliang Li aware of the challenges I was encountering, he decided to provide a working table as that was where I was what I found most challenging. Unfortunately, while working on it, he realized that using React function-based components was not feasible for our project. Hence the repository was reset, and a new React app was added using class-based components. The table and routing (React-router v5) were also added. As I mentioned earlier, the addition of a working table involved not only the UI layer but also the data layer and a significant amount of abstractions related to it. As a result, the remaining tasks got significantly easier. My mentor was constantly guiding me with individual components, and I also sought help in getting unsolvable doubts/challenges. During that time, we also decided to implement update support (patch) in the backend, and eventually got it ready. My mentor Changliang Li also provided the code for the base React modal component, and a few other modal components for me to learn and understand how to use modals as I was unfamiliar with them. In this way, our project got nearly ready at the end of the mentorship. It though needs a few improvements to be perfect for release.

My contributions

• https://github.com/openelb/website/pulls?q=is%3Apr+is%3Aclosed+author%3AAnuragThePathak
• https://github.com/openelb/openelb/pulls/AnuragThePathak
• https://github.com/openelb/console/pulls?q=is%3Apr+author%3AAnuragThePathak+is%3Aclosed

Conclusion

On August 31st, the program came to an end. It was great learning and enhancement of my skills. I am very much grateful to all my three mentors Yunkang Ren, Changjiang Li, and Feynman Zhou, for putting their time and effort into mentoring me and making this project happen. They all are very helpful and supportive. Really enjoyed the mentorship and am glad to keep contributing to the OpenELB project in the future. Special thanks to the CNCF and LFX community as well, without whom this mentorship opportunity could have been possible.

Thank you for reading this blog, if you have got any questions or feedback, feel free to reach out to me on Twitter or LinkedIn. Always keep learning, apply, participate, be part of the community and most importantly never give up.

A few screenshots of the console