Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CRI-O: Development Process & How to Contribute - Urvashi Mohnani & Peter Hunt, Red Hat

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

CRI-O: Development Process & How to Contribute - Urvashi Mohnani & Peter Hunt, Red Hat

Are you interested in contributing to Cloud Native projects, or open source, but are unsure on where to start? The CRI-O community strives to be welcoming and accessible for new contributors, and would love your help! Urvashi Mohnani and Peter Hunt will dive into the basic workflow behind open source development, using CRI-O as an example. They will walk attendees through the entire process of contribution, including: finding a bug or feature to work on, submitting a PR, cooperating with the needs of CI/CD systems, the approval process, and having their work integrated downstream. After seeing this talk, budding community members should be ready to submit their first contribution to CRI-O.

https://sched.co/Zewa

A

Hello, everyone and welcome to our talk. My name is peter hunt. I'm a software engineer for red hat working on openshift. I primarily focus my time on the project's cryo and pod man and con mon and other container related technologies.

B

Hello: everyone, my name, is urishi monani and I'm a senior software engineer on the openshift note team at red hat, I mainly work on cryo and other container tools such as podman builder and scorpio.

B

Today, we're going to talk about how one can contribute to open source projects getting started with contributing to open source projects can be very difficult due to how many different projects there are and narrowing your scope down to the cncf doesn't really help that much either. There's just so many so to make it easier for you today, we'll show you how to contribute to cryo.

B

So what is cryo crime is a lightweight container engine focused on making kubernetes container deployments as secure and seamless as possible. Cryo implements the kubernetes container runtime interface, hence the cri and cryo.

B

The o stands for open container initiative, which means that cryo supports all osi compatible images, as well as all oci compliant runtimes, such as scada run c gvisor and xeron.

B

The cryo development process embodies the unix philosophy, which states that you should design programs that do one thing to do it well and to work well with other programs.

B

To that end, cry uses a number of components under the hood that focus on different areas of the container space, such as storage, image management and networking.

B

This way, each building block of cryo can evolve at its own rate, while cryo picks features that best supports kubernetes requirements.

B

We have other tools such as podman, builda and scorpio, that are built on top of the same components, to address adjacent problems in the container space, so even more open source container-based projects that you can all contribute to now. Let's look at the open source process.

B

So now that you have picked a project to work on, the next step is to learn more about it. You should start by always going through the readme, as well as any contributing guidelines available.

B

Then you should clone the repository and try playing around with the project in your own environment change some code around add some new test cases don't be afraid to break some things.

B

Another good source of information on any project is blog posts or talks by the maintainers. We really love talking about our babies. In fact, the cryo repository has a dock called awesome.md with the links to articles talks, tutorials and just about anything cry related.

B

So now that you understand the project at a high level, you have cloned the repository you've played around it with a bit. The next step is to find something to work on all repositories. Have an issues page which has a list of tasks that need to be done.

B

These issues can broadly be broken up into two main categories: bugs and features bugs are when the program doesn't behave as expected, they are generally found when users test the project in the wild or in their production environments.

B

On the other hand, features can be thought of as nice to have things that help make the project even better features are usually decided upon by community discussions through either issues or sick meeting meetings.

B

Speaking of features here are some cool things. We're working on for the near future that were precipitated by the community. Dropping the infra container, which is not needed, will improve the speed of containerized workloads, we're also adding c groups v2 and user namespace support, as well as increasing our unit test coverage.

B

Other exciting work includes integration of lipboard, with cryo and potentially moving some of our components over to rust to improve performance, and everyone is welcome to contribute to these features.

B

Now, circling back to the issues page most repositories will have some variation of a good first issue label on their issues. These labels highlight bugs or features that the maintainers have determined are of low difficulty, so new contributors will easily be able to pick them up, have built up your confidence and competence. The next step is to look for issues that have help wanted on them.

B

These are issues that maintainers need help with and are actively looking for community contributors to assist on. Finally, another useful task to build your familiarity with projects is fixing the documentation, contrary to popular belief. Maintainers are not perfect and there will be typos and errors in most docs.

B

Next, we'll have peter walk us through a full workflow for contributing.

A

Thanks dervishy hello again, I'm now going to walk us through a demo of choosing an issue to work on submitting a pull request and then having that pull request merged, I'm going to start off by trying to figure out find an issue that we want to work on. So let's look at the cryo repository.

A

So we've got a bunch of issues here, um but I think this one that I was originally on seems like a pretty good candidate. Readme is not confident enough. I think it can make the readme more confident. So I will decide this. It's labeled the good first issue and I'm pretending to be a first time, so I could say I can take this and maybe a uh maintainer would assign me so now that I've chosen an issue we have to now uh decide on. We have.

A

We should probably read the contributing guidelines for how the project works, so many projects have contributing guidelines in a contributing.md or some other file. Cryo is no different. Basically, they talk about some guidelines to keep the style of your contribution in order with the rest of the contributions. So a couple of specific things that crowd has you do uh it's kind of similar to the kubernetes guidelines for contributing?

A

We require you to sign off your commits, which gives us an auditable log of all the contributions that allows us to thank people who make a good contribution and also follow up with people who have made contribution that there's an issue with.

A

We also require some other things like release, notes or documentation, uh which is for showing users some uh user-facing changes, and we like, when there are updates to the tests that, if there's a code change to test to uh reveal uh regressions and also test your new behavior.

A

So now that we've, uh you know kind of looked at the contribution guidelines. Let's go through the process of opening a pr, so we're going to do um this. Is my git account I'm going to push it to origin.

A

Read me confident so now that we've created the branch, let's go and open a pull request, compare and pull request.

A

So we're going to go from my fork to master and we're going to fill in some information here this. The kind of this is documentation. This is kind of crowd specific, but it follows the form of kubernetes and many other projects.

A

You should be more confident we gotta talk about how we fix it. So let's keep a ref to our uh issue.

A

Fixes that and a release note made me more confident so now that we're creating this pull request, we're going to notice a couple of things. One is we get some reviewers automatically assigned to us and those are people that are maintainers and they'll come and review our code.

A

We'll talk about that a little bit more later, and then we've got a bunch of tests that automatically start running and these tests uh theoretically should pass before we merge the code.

A

So let's now talk about the process for merging, so I've put up my pr what has to happen before my pr gets merged, so the cryo itself has some gaining criteria, as every other project does before prs can get merged. We have uh many different tiers of tests, so we have the validation test, which check doc updates.

A

Make sure that the git commits are saying check for release notes uh and most of these uh tests are automated, so or so we uh you know, we a bot can just tell us when a contributor has not done something, and then we have some unit tests which test some internals in cryo.

A

It's good for unit test coverage and then integration tests which test cryo with cry cuddle. These are good for testing, crowd, specific features that aren't necessarily covered in the uh kubernetes and the end tests, and then we have our end tests, which are really the meat and potatoes of our testing suite and those cover, uh kubernetes and openshift, and then test to make sure that any change we make in cryo doesn't break the you know, upstream compatibility and finally, for a pr to get merged.

A

We need at least two look at me on a pr as well as we need a maintainer to approve it, so I'm to show a an example of a pr that has all of these criteria so notice.

A

We have the approved label here and it has the hold, but I gave it the hold so I'm gonna hold, cancel and look good to me because we have one two uh people and I myself an improver and the person who sent it is also an approver, so we're going to set this and it also has passed all the tests. So we know it's a it's a good change.

A

So that's an example of moving from they a choosing an issue to tracking all the way through. If we had actually merged this change, which I don't think we will, uh then it would automatically close. This issue see it's linked here uh and but we won't do that today.

A

So finally, the question would be: how do we get our fixes into our distributions or you know downstream, so in open source? We have a flow that goes from upstream to downstream. Where upstream is like this github, you know upstream master, where we push all of the changes and uh then those changes are uh validated and verified and tested until they go downstream, which, when they're packaged for your distributions or your different, uh you know kubernetes environments.

A

um Cryo has an easy distinction between upstream and downstream upstream is uh git main or git master, and that is the the the main branch where we do our development and then the downstream is all the release branches. We have the release branches corresponding to kubernetes releases, so our 118 would be our latest downstream release. As of the time of recording. This typically downstream only gets bug fixes uh because we want to keep downstream stable and not disturb current users of the downstream and then so.

A

If you uh give us a feature, we're probably going to try to wait until next release to get it in. um So that is the end of our talk. Thank you very much for coming. uh We have a couple more resources here. We have our website and a couple places we're always happy to please reach out. If you have any questions, we'd love your contributions.

A

I especially would like you to get rid of all of my bugs and fix all my typos in the readme. Thank you very much for coming. Are there any questions.

B

And, most importantly, we look forward to your contributions. Thank you.