GSoC Journey: Weeks 1 & 3 — Community Bonding

Mon, May 14, 2018

On Monday, April 23rd, I got accepted as a Google Summer of Code student, to work with Cloud Native Computing Foundation. Over the next four months, I’ll be working on the Kubernetes project, implementing a new API server for handling etcd storage for aggregated API servers.

I’ll not go too deep into the project details, but if you’re interested to learn more about what I’m working on, you can check:

In this blog post, I’m going to focus on the first and third week of GSoC: starting contributing to upstream Kubernetes, learning more about the project I’ll work on, introducing myself to the community, and interaction with my mentors. The week 2 was KubeCon week and it’s going to be covered in its own blog post.

Update: KubeCon blog post is available here: GSoC Journey: Week 2 — Getting started with Kubernetes & KubeCon.

I’ll try to post my experience here every few weeks as I believe sharing is very valuable, especially for future students. Also, it can be a great motivation to see what I’ve been working on in the past :)

Week 1 — Onboarding

The first week started by waiting the projects announcement. At first, I was not sure when is it going to get announced, but I learned that the most important events are happening at 6pm European time. I was quite excited, and nervous, especially for the last two hours.

I was working for few months with Kubernetes, mostly on Cluster Lifecycle related stuff with Kubicorn project, and I wanted to start contributing to upstream. GSoC looked like the best chance to get started and to learn more about the project. You get a mentor, or two in my case, so it’s much easier to get around the project. Even that I had some experience with Cluster Lifecycle, for my GSoC project I decided to chose to work with SIG-API-Machinery. I wanted to learn more about Kubernetes APIs, how they work, and how do extend the API. Before I started, that looked like some magic to me. And.. it indeed is magical!

Not so long ago after getting accepted, I received message on Slack from my mentors, David Eads and Stefan Schimanski, congratulating me on getting accepted. We started introducing each other, talking little bit about the project and milestones. They explained to me everything I wanted to know about Kubernetes, contributing , and a lot of other stuff.

While working on the project proposal I was preparing it with Stefan, but I was also talking to David about some points, so we knew each other from before. From the beginning, I was pretty sure I have the two most awesome mentors! :)

The first three weeks are called Community Bonding period, and the three most important tasks include:

Setting up developing environment, getting know to your project and project you’ll contribute to, contributing rules, code of conduct, etc,
Getting known with your mentors,
Getting known with the community.

Getting know with mentors and the community

When you’re working on a large projects, such as Kubernetes, interacting with the community from the first day is the key to the successful project. Kubernetes has a lot of users and is very popular. It has almost 40k stars on GitHub. The KubeCon EU 2018, conference about Kuberentes and Cloud Native technologies had around 4200 attendees!

When you publicly publish your proposal, somebody will agree, somebody will disagree with your project, but for a project such as Kubernetes, that is totally normal, and you shouldn’t be demotivated. Check out do the project you contribute to has meetings and office hours. The SIG-API-Machinery has biweekly Zoom meetings where we discuss everything related to API-Machinery, related projects and issues. It was very helpful to talk more about opinions and what community expects from my GSoC project.

To help the community to track your GSoC project progress, I recommend providing weekly and/or daily updates. This will help mentors to know how are you progressing, but as well will help community, so they know how the project is going on, what and when they can expect.

For my project, I’m using:

GitHub repository containing links to the relevant documents and project proposals. It is very useful to have all links and assets in the single place so you can easily refer them when needed.
Public Google Document containing daily updates about what has been done and where I’m stuck.
Public Trello Boards for tracking the overall progress.

This way, my mentors and the community can much easier learn more about the project and check its progress, but also, I can get feedback much easier.

Beside being active in meetings and mailing lists, if you have local meetups or you can afford going to the relevant conferences, try to purse the opportunity. I had a chance to go to KubeCon, and it really helped me. I’m so happy I had a chance to meet Stefan, one of my mentors, in-person. We talked a lot about the future of my project and it helped me to understand in what way the project should head. I also met with other SIG-API-Machinery members, and it was great to hear what do they think about my project. I was able to attend several awesome talks related to my project, that helped me to better understand several important points.

This way, you can reach out to more members and you can learn a lot what do they expect from your project.

Setting Up Development Environment and Contributing

One of the first things you need to do in order to get started is to set up the development environment. Clone the repository, install dependencies and see how you can compile/start your project. Also, check out do you need to sign CLA and/or register on the appropriate platform that hosts code or that’s used for the code reviews.

In case of Kubernetes, they have a very well written guide for new contributors that you should check out if you’re interested in contributing.

What helped me here is that I decided to try contributing earlier, before GSoC projects announcement. Onboarding is a hard task, especially for large projects such as Kubernetes. They have a lot of “rules” about getting started, you need to learn how to submit pull requests, what details you need to provide, how to use bots, how to run tests..

Even if you don’t get accepted, it’s a nice experience to learn more about the project, how to contribute, and it can help you to get started in any case. Talk to your suggested mentors is there some issue that you could work on. That issue doesn’t have to be a complicated one or related to your project. You want something that can bring you opportunity to learn more about the project and to start contributing.

Start Experimenting

As I already had development environment set up, I decided to spend some more time experimenting with technologies I’ll be working on, mostly with etcd.

What can help, is to create a simple Proof of Concept, showing how your project, or small subset of the project works. It’s a good way to practice your skills, and it can bring interesting questions that you can discuss with your mentors and community in the Community Bonding period.

In my case, I was working on a subset of the project, etcd-gRPC proxy that will be used by the API server I’m creating. It helped me to see what are potential problems, and I was able to discuss them with my mentors. KubeCon also had some talks that helped me better understand what’s actually going on behind the scenes.

Week 3 — Experimenting

So, the reason why we’re skipping Week 2 for now is that it was the KubeCon week. It started on Monday afternoon with flight to Copenhagen and ended on Friday with flight back to Belgrade. Probably the most exciting week of the year, so I want to write more about it. Stay tuned for the link to the blog post.

The week 3 is the last week of Community bonding period. The Coding period officially starts as of today, Monday, May 14th.

The goal of the week was to experiment more with the technologies I’ll be working on. I decided to experiment with the API servers, as the goal of the project is to create the API server for handling etcd for aggregated API servers.

I started from the sample-apiserver, by cloning the code and renaming types to match my needs. There’s still no recommended path for starting with aggregated API servers. Maybe apiserver-builder is a better way to start your own API server, as it brings a complete framework and tooling for creating API servers, however it says it’s still not production ready.

The biggest reason why I started with the sample-apiserver is because I wanted to start from scratch, so I can better understand some concepts.

It worked out pretty well. I came up with a etcdstorage-apiserver and it works with my etcdproxy PoC! There’s still no logic behind reference types, but it’s runnable and you can use API to create an EtcdStorage object.

I finished the work on the Installing CRDs PR. The PR is not directly related to my project, but it helped me a lot to learn about CRDs, SIG-API-Machinery and contributing workflow.

The week ended with a meeting with David, Stefan and me. We summarized what has been done in the past three weeks, talked about the next milestones, what I should work on next, what should I learn..

After the meeting I started working on the document explaining how we’re planning for users to use the API, as decided on the meeting between mentors and me.

Conclusion

Getting started on a new project is a hard task, but in the same time, it can be very exciting and fun. I hope this blog post will help you to learn more about processes involved, as well as will serve as a good motivation.

In this post I covered some of the problems that you could have as a new contribution onboarding on the large project such as Kubernetes, but if you want to learn more about this topic, check out the Onboarding issues in large open source projects three part series by Ellen Körbes.

If you want to learn more about GSoC, contributing to Kubernetes, about my GSoC project, or you have any suggestions, reach out to me on Twitter or Kubernetes Slack.

Thanks to my mentor, Dr. Stefan Schimanski, for reviewing this post!

xmudrii.com