├── .github └── workflows │ └── ci.yml ├── .gitignore ├── CONTRIBUTING.md ├── EMERITUS.md ├── GOVERNANCE.md ├── LICENSE ├── MAINTAINERS ├── README.md ├── SECURITY.md ├── SECURITY_ADVISORS ├── SIG-NODE.md ├── go.mod └── img ├── Advisories.png ├── Report-A-Vulnerability.png └── Security-Tab.png /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: Go 2 | 3 | on: 4 | push: 5 | branches: [ main ] 6 | pull_request: 7 | branches: [ main ] 8 | 9 | jobs: 10 | build: 11 | name: CI 12 | runs-on: ubuntu-22.04 13 | timeout-minutes: 5 14 | steps: 15 | 16 | - name: Check out code 17 | uses: actions/checkout@v4 18 | with: 19 | path: src/github.com/containerd/project 20 | fetch-depth: 25 21 | 22 | - uses: containerd/project-checks@v1.2.2 23 | with: 24 | working-directory: src/github.com/containerd/project 25 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Binaries for programs and plugins 2 | *.exe 3 | *.dll 4 | *.so 5 | *.dylib 6 | release-tool 7 | 8 | # Test binary, build with `go test -c` 9 | *.test 10 | 11 | # Output of the go coverage tool, specifically when used with LiteIDE 12 | *.out 13 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | Contributions should be made via pull requests. Pull requests will be reviewed 4 | by one or more maintainers and merged when acceptable. 5 | 6 | The goal of the containerd project is to enable developers to build container 7 | platforms on top of the APIs that the containerd projects expose. 8 | The main entry point for a containerd consumer is the Go API. `ctr` is a 9 | development tool to quickly test features of containerd and is unsupported in 10 | a production setting. The project has zero plans of supporting `ctr` in the future. 11 | 12 | When developing features inside the containerd codebase, changes should be focused 13 | towards building APIs to develop higher level functionality and not about adding a 14 | specific feature into the core codebase. 15 | Some features may benefit the container ecosystem, however, they may not be 16 | appropriate for a first class feature in containerd. 17 | 18 | ## Successful Changes 19 | 20 | We ask that before contributing, please make the effort to coordinate with the 21 | maintainers of the project before submitting large or high impact PRs. This 22 | will prevent you from doing extra work that may or may not be merged. 23 | 24 | PRs that are just submitted without any prior communication will likely be 25 | summarily closed. 26 | 27 | While pull requests are the methodology for submitting changes to code, changes 28 | are much more likely to be accepted if they are accompanied by additional 29 | engineering work. While we don't define this explicitly, most of these goals 30 | are accomplished through communication of the design goals and subsequent 31 | solutions. Often times, it helps to first state the problem before presenting 32 | solutions. 33 | 34 | Typically, the best methods of accomplishing this are to submit an issue, 35 | stating the problem. This issue can include a problem statement and a 36 | checklist with requirements. If solutions are proposed, alternatives should be 37 | listed and eliminated. Even if the criteria for elimination of a solution is 38 | frivolous, say so. 39 | 40 | Larger changes typically work best with design documents, similar to those found 41 | in `design/`. These are focused on providing context to the design at the time 42 | the feature was conceived and can inform future documentation contributions. 43 | 44 | Make sure that new tests are added for bugs in order to catch regressions and tests 45 | with new features to exercise the new functionality that is added. 46 | 47 | ## Commit Messages 48 | 49 | There are times for one line commit messages and this is not one of them. 50 | Commit messages should follow best practices, including explaining the context 51 | of the problem and how it was solved, including in caveats or follow up changes 52 | required. They should tell the story of the change and provide readers 53 | understanding of what led to it. 54 | 55 | If you're lost about what this even means, please see [How to Write a Git 56 | Commit Message](http://chris.beams.io/posts/git-commit/) for a start. 57 | 58 | In practice, the best approach to maintaining a nice commit message is to 59 | leverage a `git add -p` and `git commit --amend` to formulate a solid 60 | changeset. This allows one to piece together a change, as information becomes 61 | available. 62 | 63 | If you squash a series of commits, don't just submit that. Re-write the commit 64 | message, as if the series of commits was a single stroke of brilliance. 65 | 66 | That said, there is no requirement to have a single commit for a PR, as long as 67 | each commit tells the story. For example, if there is a feature that requires a 68 | package, it might make sense to have the package in a separate commit then have 69 | a subsequent commit that uses it. 70 | 71 | If there are multiple authors who worked together on a PR that needs to be squashed, 72 | please use `Co-authored-by` to indicate each person who contributed to the PR. This 73 | enables automated tools 74 | and [Github](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors) 75 | to highlight everyone's role in the PR. 76 | 77 | Remember, you're telling part of the story with the commit message. Don't make 78 | your chapter weird. 79 | 80 | ## Applying License Header to New Files 81 | 82 | If you submit a contribution that adds a new file, please add the license 83 | header. You can do so manually or use the `ltag` tool. The `ltag` templates 84 | for filetypes are in the `containerd/project` repository but the files you want 85 | to tag are most likely in the main containerd project or any of the possible 86 | subprojects. You can pass the path to the project repo root to `ltag` but you 87 | should run `ltag` in the directory where you have new files. 88 | 89 | 90 | ```console 91 | $ go get github.com/kunalkushwaha/ltag 92 | $ ltag -t {containerd/project rootdir}/script/validate/template 93 | ``` 94 | 95 | The above will add the appropriate license header to Go language source files, 96 | Makefiles, Dockerfiles, and shell scripts. New templates will need to be added 97 | if other kinds of files are added. Please consult the 98 | documentation at https://github.com/kunalkushwaha/ltag 99 | 100 | ## Sign your work 101 | 102 | The sign-off is a simple line at the end of the explanation for the patch. Your 103 | signature certifies that you wrote the patch or otherwise have the right to pass 104 | it on as an open-source patch. The rules are pretty simple: if you can certify 105 | the below (from [developercertificate.org](http://developercertificate.org/)): 106 | 107 | ``` 108 | Developer Certificate of Origin 109 | Version 1.1 110 | 111 | Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 112 | 660 York Street, Suite 102, 113 | San Francisco, CA 94110 USA 114 | 115 | Everyone is permitted to copy and distribute verbatim copies of this 116 | license document, but changing it is not allowed. 117 | 118 | Developer's Certificate of Origin 1.1 119 | 120 | By making a contribution to this project, I certify that: 121 | 122 | (a) The contribution was created in whole or in part by me and I 123 | have the right to submit it under the open source license 124 | indicated in the file; or 125 | 126 | (b) The contribution is based upon previous work that, to the best 127 | of my knowledge, is covered under an appropriate open source 128 | license and I have the right under that license to submit that 129 | work with modifications, whether created in whole or in part 130 | by me, under the same open source license (unless I am 131 | permitted to submit under a different license), as indicated 132 | in the file; or 133 | 134 | (c) The contribution was provided directly to me by some other 135 | person who certified (a), (b) or (c) and I have not modified 136 | it. 137 | 138 | (d) I understand and agree that this project and the contribution 139 | are public and that a record of the contribution (including all 140 | personal information I submit with it, including my sign-off) is 141 | maintained indefinitely and may be redistributed consistent with 142 | this project or the open source license(s) involved. 143 | ``` 144 | 145 | Then you just add a line to every git commit message: 146 | 147 | Signed-off-by: Joe Smith 148 | 149 | Use your real name (sorry, no pseudonyms or anonymous contributions.) 150 | 151 | If you set your `user.name` and `user.email` git configs, you can sign your 152 | commit automatically with `git commit -s`. 153 | -------------------------------------------------------------------------------- /EMERITUS.md: -------------------------------------------------------------------------------- 1 | # containerd Emeritus Maintainers 2 | 3 | ## John Howard [@lowenna](https://github.com/lowenna) 4 | 5 | John's tremendous efforts to get containers working on Windows lead to cross-platform images 6 | as they are known today. Due to his work, containerd has first class support for Windows and 7 | contributed to it being the most cross-platform capable container runtime. 8 | 9 | ## Kenfe-Mickaël Laventure [@mlaventure](https://github.com/mlaventure) 10 | 11 | One of the first contributors to containerd, Mickaël led the effort to get the first 12 | versions of containerd used as the runtime for dockerd. He has made a significant impact on the 13 | runtime codebase from the API to the OCI runtime. 14 | 15 | ## Abhinandan Prativadi [@abhi](https://github.com/abhi) 16 | 17 | A significant contributor to the CRI plugin and container networking, Abhi helped make 18 | containerd a reliable and complete container runtime for Kubernetes. 19 | 20 | ## Lantao Liu [@Random-Liu](https://github.com/Random-Liu) 21 | 22 | Lantao Liu was one of the initial authors of the containerd CRI plugin. Lantao 23 | worked across the Kubelet, Kubernetes project infrastructure, CRI, and 24 | containerd to enable containerd to be one of the first CRI-enabled runtimes for 25 | Kubernetes. containerd is now the default container runtime for several 26 | Kubernetes providers, which would not have been possible without Lantao's 27 | dedicated work. While Lantao is no longer involved in the day-to-day 28 | maintenance of the CRI plugin or containerd in general, he remains involved in 29 | the larger Kubernetes community. 30 | 31 | ## Dawn Chen [@dchen1107](https://github.com/dchen1107) 32 | 33 | Dawn Chen was the initiator of CRI for Kubernetes, and an important partner in 34 | enabling the containerd CRI plugin to happen. Dawn coordinated the needs of 35 | Kubernetes SIG-Node with containerd. containerd is now well-supported and a 36 | critical part of Kubernetes validation, which would not have been possible 37 | without Dawn’s advocacy. While Dawn is no longer involved in the day-to-day 38 | maintenance of the CRI plugin or containerd in general, she continues to serve 39 | as a Technical Lead for SIG-Node and an advocate for containerd in the 40 | Kubernetes community. 41 | 42 | ## Yu-Ju Hong [@yujuhong](https://github.com/yujuhong) 43 | 44 | Yu-Ju Hong proposed the first version of CRI and was a key part of early 45 | implementation of the containerd CRI plugin. Her work enabled Kubernetes to 46 | invoke runtimes via CRI, allowed the Kubernetes CI environment to test CRI 47 | integrations like containerd, and provided a standard set of tools and test 48 | suite for container runtimes. While Yu-Ju is not currently involved in 49 | containerd, she remains involved in the larger Kubernetes community. 50 | 51 | ## Stephen Day [@stevvooe](https://github.com/stevvooe) 52 | 53 | Both the author of the initial distribution specification and architect behind 54 | many of the containerd 1.0 designs, Stephen Day has had a tremendous impact on 55 | the container ecosystem. The containerd project has greatly benefited from 56 | Stephen’s bold and innovative ideas along with his large impact on the 57 | containerd codebase. We can both thank and `git blame` Stephen for many parts of 58 | containerd. 59 | 60 | ## Kevin Parsons [@kevpar](https://github.com/kevpar) 61 | 62 | Leading the development of Windows support in containerd has never been an easy 63 | task. Kevin has done a great job at both getting the Windows support in a good 64 | shape and bringing in new Windows contributors to continue to effort. 65 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | # containerd Project Governance 2 | 3 | As a CNCF member project, we abide by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). 4 | 5 | For specific guidance on practical contribution steps for any containerd sub-project please 6 | see our [CONTRIBUTING.md](./CONTRIBUTING.md) guide. 7 | 8 | ## Maintainership 9 | 10 | There are different types of maintainers, with different responsibilities, but 11 | all maintainers have 3 things in common: 12 | 13 | 1) They share responsibility in the project's success. 14 | 2) They have made a long-term, recurring time investment to improve the project. 15 | 3) They spend that time doing whatever needs to be done, not necessarily what 16 | is the most interesting or fun. 17 | 18 | Maintainers are often under-appreciated, because their work is harder to appreciate. 19 | It's easy to appreciate a really cool and technically advanced feature. It's harder 20 | to appreciate the absence of bugs, the slow but steady improvement in stability, 21 | or the reliability of a release process. But those things distinguish a good 22 | project from a great one. 23 | 24 | ## Reviewers 25 | 26 | A reviewer is a core maintainer within the project. 27 | They share in reviewing issues and pull requests and their LGTM counts towards the 28 | required LGTM count to merge a code change into the project. 29 | 30 | Reviewers are part of the organization but do not have write access. 31 | Becoming a reviewer is a core aspect in the journey to becoming a committer. 32 | 33 | ## Committers 34 | 35 | A committer is a core maintainer who is responsible for the overall quality and 36 | stewardship of the project. They share the same reviewing responsibilities as 37 | reviewers, but are also responsible for upholding the project bylaws as well as 38 | participating in project level votes. 39 | 40 | Committers are part of the organization with write access to all repositories. 41 | Committers are expected to remain actively involved in the project and 42 | participate in voting and discussing of proposed project level changes. 43 | 44 | ## Adding maintainers 45 | 46 | Maintainers are first and foremost contributors that have shown they are 47 | committed to the long term success of a project. Contributors wanting to become 48 | maintainers are expected to be deeply involved in contributing code, pull 49 | request review, and triage of issues in the project for more than three months. 50 | 51 | Just contributing does not make you a maintainer, it is about building trust 52 | with the current maintainers of the project and being a person that they can 53 | depend on and trust to make decisions in the best interest of the project. 54 | 55 | Periodically, the existing maintainers curate a list of contributors that have 56 | shown regular activity on the project over the prior months. From this list, 57 | maintainer candidates are selected and proposed in the maintainers forum. 58 | 59 | After a candidate has been informally proposed in the maintainers forum, the 60 | existing maintainers are given seven days to discuss the candidate, raise 61 | objections and show their support. Formal voting takes place on a pull request 62 | that adds the contributor to the MAINTAINERS file. Candidates must be approved 63 | by 2/3 of the current committers by adding their approval or LGTM to the pull 64 | request. The reviewer role has the same process but only requires 1/3 of current 65 | committers. 66 | 67 | If a candidate is approved, they will be invited to add their own LGTM or 68 | approval to the pull request to acknowledge their agreement. A committer will 69 | verify the numbers of votes that have been received and the allotted seven days 70 | have passed, then merge the pull request and invite the contributor to the 71 | organization. 72 | 73 | For non-core sub-projects, only committers of the repository that the candidate 74 | is proposed for are given votes. 75 | 76 | ## Security Advisors 77 | 78 | A security advisor is an advisory role in the project responsible for helping 79 | classify and advise on embargoed security disclosures. Security advisors are 80 | individuals trusted by maintainers and representing significant users of the 81 | project. 82 | 83 | Security advisors are part of the organization without write access, but with 84 | read access to security disclosures and advisories before becoming public. There 85 | is no expectation of advisors to become reviewers or participate in issue 86 | triage and code review. Security advisors help maintain the integrity of the 87 | security review process and encourage responsible disclosure. 88 | 89 | A reviewer may also be a security advisor, however, committers do not need this 90 | role as it is part of their regular duties. The security advisor duties are 91 | not part of the duties of being a reviewer. 92 | 93 | Candidates should contact a maintainer and request sponsorship for becoming a 94 | security advisor. Once a maintainer is willing to sponsor a candidate, the 95 | maintainer will open up a pull request to the SECURITY_ADVISORS files adding 96 | the candidate. Since it is not expected that candidates are active in the 97 | project, there is no expectation that they are well known by a majority of 98 | maintainers. Approving the pull request requires a two LGTM threshold of 99 | committers. A reviewer may sponsor themselves, but still require the same two 100 | LGTM threshold of committers. 101 | 102 | Security advisors may be removed by the same sponsoring maintainer with a two 103 | LGTM threshold or by any other maintainer with approval of 1/3 of current 104 | committers. 105 | 106 | ## Subprojects 107 | 108 | containerd subprojects are divided into two flavors currently: **core** and 109 | **non-core**. Most of the repositories within the containerd GitHub organization are 110 | "core" to the delivery of the containerd runtime project's releases. For example, 111 | the Golang implementations of the cgroups, runc, and console APIs, the ttrpc 112 | implementation, and various built-in plugins like the CRI implementation. These, among a 113 | handful of other repositories, are all **core** and required pieces which culminate 114 | in officially supported and maintained releases of containerd. 115 | 116 | Non-core projects have a strong affiliation with the containerd runtime, but 117 | operate similarly to the traditional `contrib/` directory in many open source 118 | projects. In most cases the maintainer list will be unique and the project can 119 | have unique release, support, and maintainer processes. Non-core projects may be 120 | written in other languages and therefore require different skills, developer 121 | tools, and CI systems than the core projects. For these reasons, non-core 122 | subprojects have a few unique properties that are described in the section 123 | "_Adding non-core subprojects_" below. 124 | 125 | Both core and non-core subprojects must adhere to the CNCF 126 | [charter](https://www.cncf.io/about/charter/) and mission. 127 | 128 | ### Adding core subprojects 129 | 130 | New core subprojects can request to be added to the containerd GitHub 131 | organization by submitting a project proposal via public forum (a 132 | `containerd/project` GitHub issue is the easiest way to provide this proposal). 133 | The existing maintainers are given seven days to discuss the new project, raise 134 | objections and cast their vote. Projects must be approved by 2/3 of the current 135 | core committers. 136 | 137 | If a project is approved, a maintainer will add the project to the containerd 138 | GitHub organization, and make an announcement on a public forum. 139 | 140 | Please add the suggested text from our [Project core documents](./README.md#project-core-documents) section 141 | to your `README.md`. 142 | 143 | ### Adding non-core subprojects 144 | 145 | Non-core subprojects will also submit a project proposal via public forum, and 146 | should state that the project is expected to be **non-core**. 147 | 148 | The proposal should include a proposed list of maintainers who will manage 149 | the non-core project and provide general information on support, releases, 150 | stability, and any additional detail useful for the containerd maintainers to 151 | understand the scope and nature of the project. 152 | 153 | The existing maintainers are given seven days to discuss the new project, raise 154 | objections and cast their vote. Projects must be approved by 2/3 of the current 155 | core committers. 156 | 157 | If a project is approved, a core maintainer will add the project to the containerd 158 | GitHub organization and provide write access for that repository to the proposed 159 | maintainer list, as well as make an announcement on a public forum. 160 | 161 | Unlike core maintainers, non-core project maintainers are responsible for maintenance 162 | tasks in their subproject only. Core maintainers have maintainer privileges across 163 | all core and non-core projects to help contribute to project health, maintenance, 164 | and release processes within the GitHub organization. For ease of list management, 165 | the `MAINTAINERS` file of a non-core project will only list the non-core project 166 | maintainers—the core maintainers of containerd will not be appended to each subproject. 167 | 168 | Please add the suggested text from our [Non-core project documents](./README.md#non-core-project-documents) 169 | section to your `README.md`. 170 | 171 | ### Changing the status of non-core subprojects 172 | 173 | A change of status of a non-core subproject can be made by submitting a change of 174 | status proposal via public forum. The types of changes may include: 175 | - promoting a non-core subproject to core 176 | - removing/archiving the non-core subproject 177 | - merging into another project 178 | 179 | The proposal should include some general information on support, releases, 180 | stability, downstream impacts, steps necessary to effect the change, and any 181 | additional detail useful for the containerd maintainers to understand the scope and 182 | nature of the project status change. GitHub issue is the easiest way to provide 183 | this proposal. 184 | 185 | The existing maintainers are given fourteen days to discuss the project change, 186 | raise objections and cast their vote. Project changes of this type must be approved 187 | by 2/3 of the current core committers and core committers are encouraged to consider the opinions and objections of the existing non-core project maintainers. 188 | 189 | Project status changes do not automatically change the status of any non-core project maintainers. Project status change proposals may be accompanied by additional proposals to change individual maintainer status, subject to the existing rules set forth in this document. 190 | 191 | If a change of status of the non-core subproject is approved, the maintainers will 192 | set forth a schedule for notifying downstream project users, implementing the change 193 | and finally making an announcement on a public forum when the change is complete. 194 | 195 | ## Stepping down policy 196 | 197 | Life priorities, interests, and passions can change. If you're a maintainer but 198 | feel you must remove yourself from the list, inform other maintainers that you 199 | intend to step down, and if possible, help find someone to pick up your work. 200 | At the very least, ensure your work can be continued where you left off. 201 | 202 | After you've informed other maintainers, create a pull request to remove 203 | yourself from the MAINTAINERS file. 204 | 205 | ## Handling inactive maintainers 206 | 207 | Similar to the procedure for adding new maintainers, existing maintainers can 208 | be removed from the list if they do not show consistent activity on the 209 | project. Depending on the existing role, committer or reviewer, there are 210 | variations to the inactivity process detailed as follows. 211 | 212 | ### Committer inactivity process 213 | 214 | For committers, the maintainers periodically review committer project 215 | activity. The maintainers use the CNCF "devstats" community metrics tool for 216 | data on user activity statistics. 217 | 218 | If a committer has shown no activity over a six-month period, the committer 219 | will be contacted to notify them of their activity status and offer a move to 220 | an Emeritus role. There is no automatic change of status in the project. First, 221 | the activity status is discussed directly with the committer, and second, 222 | maintainers discuss whether other non-tracked contributions to the project 223 | reflect an ongoing, active participation in the project. 224 | 225 | Based on the outcome of these discussions, the committer may choose to remove 226 | themselves from the MAINTAINERS file, as noted above in the "Stepping down 227 | policy" section. If another maintainer opens a pull request to the MAINTAINERS 228 | file on their behalf for removal, the PR must be approved by 2/3 of the current 229 | committers, or by the committer who is being removed. The voting and discussion 230 | period is seven days, after which a committer will verify the votes, merge the 231 | pull request, and apply the changes to the organization. 232 | 233 | ### Reviewer inactivity process 234 | 235 | While reviewers are not voting members of the containerd project, the maintainers 236 | may assess reviewer activity periodically and recommend removals for any 237 | completely inactive reviewers. 238 | 239 | Reviewers may remove themselves from the MAINTAINERS file if they wish to or 240 | any existing maintainer may open a pull request to the MAINTAINERS file on their 241 | behalf. If the pull request is not initiated by the reviewer, it must be approved 242 | by 2/3 of the current committers or by the reviewer who is being removed. The 243 | voting and discussion period is seven days, after which a committer will verify 244 | the votes, merge the pull request, and apply the changes to the organization. 245 | 246 | ## Emeritus maintainers 247 | 248 | For committers who are stepping down or being removed due to inactivity, 249 | the project would like to memorialize their contributions to the project by 250 | recognizing them as Emeritus maintainers in the EMERITUS.md file. The EMERITUS.md 251 | file will include a brief paragraph summarizing their contribution to the 252 | containerd project and recognize them as permanent Emeritus members of the 253 | community. While Emeritus maintainers are not active in the project, their 254 | expertise is always valued and their LGTM may count towards the required LGTM 255 | count to merge a code change into the project. 256 | 257 | If in the future an Emeritus maintainer has the desire or ability to return to 258 | contributing to the project, Emeritus maintainers can submit a pull request 259 | reversing their removal from the MAINTAINERS file and approval only requires 260 | 2 LGTMs from current committers to return to full committer status in the 261 | project. 262 | 263 | ## How are decisions made? 264 | 265 | containerd is an open-source project with an open design philosophy. This means 266 | that the repository is the source of truth for EVERY aspect of the project, 267 | including its philosophy, design, road map, and APIs. *If it's part of the 268 | project, it's in the repo. If it's in the repo, it's part of the project.* 269 | 270 | As a result, all decisions can be expressed as changes to the repository. An 271 | implementation change is a change to the source code. An API change is a change 272 | to the API specification. A philosophy change is a change to the philosophy 273 | manifesto, and so on. 274 | 275 | All decisions affecting containerd, big and small, follow the same 3 steps: 276 | 277 | * Step 1: Open a pull request. Anyone can do this. 278 | 279 | * Step 2: Discuss the pull request. Anyone can do this. 280 | 281 | * Step 3: Merge or refuse the pull request. Who does this depends on the nature 282 | of the pull request and which areas of the project it affects. 283 | 284 | ## Helping contributors with the DCO 285 | 286 | The [DCO or `Sign your work`](./CONTRIBUTING.md#sign-your-work) 287 | requirement is not intended as a roadblock or speed bump. 288 | 289 | Some containerd contributors are not as familiar with `git`, or have used a web 290 | based editor, and thus asking them to `git commit --amend -s` is not the best 291 | way forward. 292 | 293 | In this case, maintainers can update the commits based on clause (c) of the DCO. 294 | The most trivial way for a contributor to allow the maintainer to do this, is to 295 | add a DCO signature in a pull requests's comment, or a maintainer can simply 296 | note that the change is sufficiently trivial that it does not substantially 297 | change the existing contribution - i.e., a spelling change. 298 | 299 | When you add someone's DCO, please also add your own to keep a log. 300 | 301 | ## I'm a maintainer. Should I make pull requests too? 302 | 303 | Yes. Nobody should ever push to main directly. All changes should be 304 | made through a pull request. 305 | 306 | ## Conflict Resolution 307 | 308 | If you have a technical dispute that you feel has reached an impasse with a 309 | subset of the community, any contributor may open an issue, specifically 310 | calling for a resolution vote of the current core committers to resolve the 311 | dispute. A resolution vote must be approved by 2/3 of the current core 312 | committers. 313 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /MAINTAINERS: -------------------------------------------------------------------------------- 1 | # containerd project maintainers 2 | # 3 | # See GOVERNANCE.md for committer versus reviewer roles 4 | # 5 | # COMMITTERS 6 | # GitHub ID, Name, Email address,GPG fingerprint 7 | "AkihiroSuda","Akihiro Suda","akihiro.suda.cz@hco.ntt.co.jp","C020 EA87 6CE4 E06C 7AB9 5AEF 4952 4C6F 9F63 8F1A" 8 | "crosbymichael","Michael Crosby","crosbymichael@gmail.com","" 9 | "dmcgowan","Derek McGowan","derek@mcgstyle.net","8C7A 111C 2110 5794 B0E8 A27B F58C 5D0A 4405 ACDB" 10 | "estesp","Phil Estes","estesp@gmail.com","71AE 6DCD DFF8 C2D1 DDCA EEC9 FE25 9812 6B19 6A38" 11 | "mikebrow","Mike Brown","brownwm@us.ibm.com","" 12 | "fuweid","Fu Wei","fuweid89@gmail.com","" 13 | "mxpv","Maksym Pavlenko","pavlenko.maksym@gmail.com","" 14 | "dims","Davanum Srinivas","davanum@gmail.com","A67E 5FD8 80EB 089F 2317 7967 80D8 3A79 6103 BF59" 15 | "kzys","Kazuyoshi Kato","kaz@fly.io","" 16 | "samuelkarp","Samuel Karp","me@samuelkarp.com","0A4B DF41 8E8D ECB8 7F3E 9E14 AAA3 FE8A 831F C087,910C 2860 8D33 DDE6 89C0 3290 997C 5A3C D316 7CB5" 17 | "kiashok","Kirtana Ashok","kirtana.ashok@gmail.com","" 18 | # 19 | # REVIEWERS 20 | # GitHub ID, Name, Email address, GPG fingerprint 21 | "jterry75","Justin Terry","jlterry@amazon.com","" 22 | "cpuguy83","Brian Goff","cpuguy83@gmail.com","" 23 | "thajeztah","Sebastiaan van Stijn","github@gone.nl","DE9A E9A2 F211 75DC B4F0 E564 7669 8F39 D527 CE8C" 24 | "ktock","Kohei Tokunaga","ktokunaga.mail@gmail.com","" 25 | "dcantah","Daniel Canter","danny@dcantah.dev","" 26 | "MikeZappa87","Michael Zappa","Michael.Zappa@gmail.com","" 27 | "klihub","Krisztian Litkey","krisztian.litkey@intel.com","" 28 | "Iceber","Cai Wei","wei.cai-nat@daocloud.io","" 29 | "laurazard","Laura Brehm","laurabrehm@hey.com","" 30 | "henry118","Henry Wang","henwang@amazon.com","" 31 | "ruiwen-zhao","Ruiwen Zhao","zhaorw93@gmail.com","" 32 | "akhilerm","Akhil Mohan","akhilerm@gmail.com","" 33 | "corhere","Cory Snider","csnider@mirantis.com","" 34 | "austinvazquez","Austin Vazquez","macedonv@amazon.com","" 35 | "djdongjin","Jin Dong","djdongjin95@gmail.com","" 36 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # containerd common project repository 2 | This `project` repository contains the governance definitions and specified project 3 | roles like maintainers and security advisors. 4 | 5 | ## Scripts and utilities 6 | 7 | Originally, this repository held common CI scripts/checks as well as the 8 | `release-tool`. Neither of those items are maintained in this repository. 9 | See the below paragraphs for their new locations: 10 | 11 | ### The release-tool utility 12 | 13 | The `release-tool` now has its own repository. It is located in 14 | the [`release-tool`](https://github.com/containerd/release-tool) subproject. 15 | 16 | ### Common CI checks/scripts 17 | 18 | After migrating the entire project and all sub-projects to GitHub 19 | Actions for CI, we made a subproject repo that contains a common `project-checks` 20 | action with our file header, DCO, and vendor checks. That repository is 21 | located in [`project-checks`](https://github.com/containerd/project-checks) 22 | 23 | ## Project core documents 24 | 25 | Project governance, maintainer list, and contributing guidelines are all 26 | maintained as single copies within this repository and linked to from 27 | all containerd projects to reduce duplication and maintenance across all 28 | repos. 29 | 30 | You can see each of these core documents here: 31 | * [Governance for containerd projects](./GOVERNANCE.md) 32 | * [Maintainers and reviewers list](./MAINTAINERS) 33 | * [Contributing guidelines](./CONTRIBUTING.md) 34 | 35 | For an example of how to include these in a project's `README.md` file see 36 | the following markdown: 37 | ``` 38 | ## Project details 39 | 40 | {Some-project} is a containerd sub-project, licensed under the [Apache 2.0 license](./LICENSE). 41 | As a containerd sub-project, you will find the: 42 | * [Project governance](https://github.com/containerd/project/blob/main/GOVERNANCE.md), 43 | * [Maintainers](https://github.com/containerd/project/blob/main/MAINTAINERS), 44 | * and [Contributing guidelines](https://github.com/containerd/project/blob/main/CONTRIBUTING.md) 45 | 46 | information in our [`containerd/project`](https://github.com/containerd/project) repository. 47 | ``` 48 | 49 | ### Non-core project documents 50 | 51 | If your project is a non-core addition to the containerd GitHub organization, please 52 | make the following changes to your project once approved and added: 53 | 54 | * Clearly state in an opening sentence within your project `README.md` that "_Project X is 55 | a **non-core** subproject of containerd_" 56 | * Add the project details boilerplate provided above with the following two changes: 57 | 1. The first line should be modified to state: _{Some-project} is a **non-core** containerd subproject_ 58 | 2. Do not link to the core `MAINTAINERS` file in `containerd/project`. That link should be modified to point to your existing non-core project `MAINTAINERS` file. 59 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | # Security Policy 2 | 3 | ## Reporting a Vulnerability 4 | 5 | To report a containerd vulnerability: 6 | 7 | * Navigate to the security tab on the repository 8 | ![Github Security Tab](./img/Security-Tab.png) 9 | 10 | * Click on `Advisories` 11 | ![Github Advisories tab](./img/Advisories.png) 12 | 13 | * Click on `Report a vulnerability` 14 | ![Report a vulnerability](./img/Report-A-Vulnerability.png) 15 | 16 | The reporter(s) can expect a response within 24 hours acknowledging 17 | the issue was received. If a response is not received within 24 hours, please 18 | reach out to any committer directly to confirm receipt of the issue. 19 | 20 | ## Review Process 21 | 22 | Once a committer has confirmed the relevance of the report, a draft security 23 | advisory will be created on Github. The draft advisory will be used to discuss 24 | the issue with committers, the reporter(s), and containerd's security advisors. 25 | If the reporter(s) wishes to participate in this discussion, then provide 26 | reporter Github username(s) to be invited to the discussion. If the reporter(s) 27 | does not wish to participate directly in the discussion, then the reporter(s) 28 | can request to be updated regularly via email. 29 | 30 | If the vulnerability is accepted, a timeline for developing a patch, public 31 | disclosure, and patch release will be determined. If there is an embargo period 32 | on public disclosure before the patch release, an announcment will be sent to 33 | the security announce mailing list(`containerd-security-announce@lists.cncf.io`) 34 | announcing the scope of the vulnerability, the date of availability of the 35 | patch release, and the date of public disclosure. The reporter(s) are expected 36 | to participate in the discussion of the timeline and abide by agreed upon dates 37 | for public disclosure. 38 | 39 | ## Supported Versions 40 | 41 | See the [containerd releases page](https://github.com/containerd/containerd/blob/master/RELEASES.md#support-horizon) 42 | for information on supported versions of containerd. Any `Extended` or `Active` 43 | release branch may receive security updates. For any security issues discovered 44 | on older versions, non-core packages, or dependencies, please inform committers 45 | using the same security mailing list as for reporting vulnerabilities. 46 | 47 | ## Joining the security announce mailing list 48 | 49 | Any organization or individual who directly uses containerd and non-core 50 | packages in production or in a security critical application is eligible to join 51 | the security announce mailing list. Indirect users who use containerd through a 52 | vendor are not expected to join, but should request their vendor join. To join 53 | the mailing list, the individual or organization must be sponsored by either a 54 | containerd committer or security advisor as well as have a record of properly 55 | handling non-public security information. 56 | Sponsorship should not be requested via public channels since membership of the 57 | security announce list is not public. 58 | -------------------------------------------------------------------------------- /SECURITY_ADVISORS: -------------------------------------------------------------------------------- 1 | # containerd project security advisors 2 | # 3 | # See GOVERNANCE.md for description of role 4 | # 5 | # SECURITY ADVISORS 6 | # GitHub ID, Name, Email address, Company 7 | "justincormack","Justin Cormack","justin.cormack@docker.com","Docker" 8 | "rtheis","Richard Theis","rtheis@us.ibm.com","IBM" 9 | "ralphbuk","Ralph Bateman","ralph@uk.ibm.com","IBM" 10 | "SergeyKanzhelev","Sergey Kanzhelev","skanzhelev@google.com","Google" 11 | "tianon","Tianon Gravi","admwiggin@gmail.com","Docker" 12 | "tonistiigi","Tõnis Tiigi","tonistiigi@gmail.com","Docker" 13 | "cji","Craig Ingram","cjingram@google.com","Google" 14 | "henry118","Henry Wang","henwang@amazon.com","AWS" 15 | "adisky","Aditi Sharma","adi.sky17@gmail.com","VMware" 16 | "akhilerm","Akhil Mohan","akhilerm@gmail.com","VMware" 17 | "vinayakankugoyal","Vinayak Goyal","vinaygo@google.com","Google" 18 | -------------------------------------------------------------------------------- /SIG-NODE.md: -------------------------------------------------------------------------------- 1 | # Collaboration with Kubernetes SIG-Node 2 | 3 | containerd is a popular container runtime used with 4 | [Kubernetes](https://kubernetes.io). containerd implements the Kubernetes 5 | Container Runtime Interface (CRI) and is expected to participate in the 6 | development and implementation of CRI. 7 | 8 | Changes to Kubernetes (including CRI) are primarily driven through the 9 | [Kubernetes Enhancement Proposal (KEP) process](https://github.com/kubernetes/enhancements). 10 | KEPs are proposed to individual Special Interest Groups (SIGs) within the 11 | Kubernetes project, which help to refine, clarify, and decide the content of an 12 | individual KEP as well as drive its implementation. CRI-related KEPs are 13 | primarily handled through SIG-Node. SIG-Node has 14 | [adopted a policy](https://www.kubernetes.dev/docs/code/cri-api-dev-policies/) 15 | which requires KEPs to reach maturity in both containerd and CRI-O before 16 | advancing through graduation stages. 17 | 18 | This document describes the process that the containerd project uses to 19 | collaborate with SIG-Node on any KEP or other CRI-related change. 20 | 21 | ## Goals 22 | 23 | * Provide visibility of SIG-Node integration work for containerd (including 24 | KEPs) for: 25 | * containerd maintainers and community members who are not directly involved 26 | in SIG-Node 27 | * SIG-Node participants who are not involved in the containerd community 28 | * Ensure containerd maintainers and communtiy members have adequate 29 | opportunities to participate in design without requiring full context on 30 | every SIG-Node KEP or who are not familiar with the KEP process 31 | * Ensure contributors understand the status of their proposed contributions 32 | * Spread the KEP tracking and review load among interested maintainers, and 33 | enable at least two interested containerd maintainers per KEP or 34 | Kubernetes-related work item in order to facilitate knowledge sharing 35 | 36 | ## Non-goals 37 | 38 | * Change the development or release process of containerd. See the 39 | [contribution guidelines](CONTRIBUTING.md) and 40 | [versioning and release](https://containerd.io/releases) page. 41 | * Guarantee KEP delivery, outside of providing feedback during KEP design, 42 | guiding contributors through processes, and reviews. 43 | 44 | ## Roles 45 | 46 | * SIG-Node member liaison - a containerd maintainer responsible for 47 | facilitating communication between SIG-Node and the containerd project 48 | regarding KEP status, targeted containerd releases, and any other integration 49 | work or pain points. 50 | * KEP shepherd - for each KEP, at least one (preferably two) containerd 51 | maintainer(s) responsible for helping a KEP move through the implementation 52 | and release process in containerd. 53 | 54 | ## Metadata 55 | 56 | * Per-KEP issue in the 57 | [containerd/containerd](https://github.com/containerd/containerd) repository 58 | for tracking KEPs that require CRI changes in the container 59 | runtime or one of our other containerd subprojects. (This includes 60 | relatively minor changes, such as a runc update or checking containerd config 61 | to align defaults with feature gate GAs.) 62 | * Labels within the containerd/containerd repository corresponding to 63 | Kubernetes minor releases, applied to KEP tracking issues and PRs 64 | * Recording the assigned shepherd(s) on the KEP tracking issue 65 | 66 | ## Process 67 | 68 | For a KEP to be reviewed and implemented in containerd: 69 | 70 | ### Issue management 71 | 72 | * An issue should be created in the 73 | [containerd/containerd repository](https://github.com/containerd/containerd) 74 | tracking the individual KEP as soon as possible 75 | * containerd KEP tracking issues may be opened by one of the KEP owners, 76 | an interested maintainer, or by a group within SIG-Node that is managing 77 | the KEP process 78 | * This includes all KEPs for SIG-Node, whether they are in Draft or Approved 79 | status. The same issue should continue to track the KEP through each 80 | stage, alpha(s), beta(s), and GA 81 | * The new issue title should include both the KEP number and a short title or 82 | description of the goal of the KEP 83 | * containerd maintainers will triage new KEP tracking issues as needed 84 | * KEP tracking issues should be added to a label for the Kubernetes release 85 | cycle within the containerd/containerd repository during triage 86 | 87 | ### SIG-Node Liaison 88 | 89 | At least one containerd maintainer will be responsible to liaise with SIG-Node 90 | for each Kubernetes release cycle. The liaison role involves: 91 | 92 | * Tracking the status of each KEP both in containerd and the larger context in 93 | Kubernetes (including the status of the KEP in kubelet and/or other 94 | involved/dependent SIGs / projects). 95 | * Tracking the status of the other types of Node Integration pain points 96 | critical to the upcoming kubernetes releases (likely via issue) 97 | * Communicating which containerd release(s) will include a given KEP (usually 98 | the next minor release in our 99 | [6-month release cadence](https://containerd.io/releases/#release-cadence)) 100 | and whether there are implications to prior containerd releases as KEPs are 101 | promoted 102 | * Ensuring other types of SIG-Node integration pain points have at least one 103 | containerd maintainer assigned. These include urgent Kubernetes PRs that 104 | require containerd support and standard issues that don’t require a KEP, long 105 | running infra tasks, major critest/crictl interop up on 106 | kubernetes-sigs/critools, etc. 107 | * Being a 108 | [Kubernetes org member](https://github.com/kubernetes/community/blob/master/community-membership.md#member) 109 | and 110 | [SIG-Node member](https://github.com/kubernetes/community/blob/master/sig-node/sig-node-contributor-ladder.md) 111 | (prerequisite for volunteering) 112 | * Being available in the `#sig-node` channel of the [Kubernetes slack](https://slack.kubernetes.io) 113 | 114 | ### KEP shepherd 115 | 116 | At least one containerd maintainer will be assigned (as part of KEP triage) to 117 | shepherd each active KEP planned for integration with containerd. An active 118 | KEP is one which has already been implemented in an existing Kubernetes release 119 | or is being considered for an upcoming Kubernetes release. The shepherd role 120 | involves: 121 | 122 | * Engaging as early as possible in the KEP discussion (via the primary KEP 123 | issue, `#sig-node` Slack channel, and SIG-Node weekly calls) and design to 124 | represent the containerd maintainer perspective in terms of 125 | architecture/layering (i.e., should the new functionality reside in the 126 | runtime, Kubelet, or some other component) and priority so that 127 | implementation can be scheduled into an upcoming release. 128 | * Ensuring maintainers have consensus on how the KEP should be implemented in 129 | containerd and communicating to the KEP owner and our liaison if consensus on 130 | implementation details and/or timing cannot be reached in time for the next 131 | minor release. 132 | * Ensuring the implementation design discussion happens in the open and 133 | transparently; allowing proposals from the KEP owner, contributors, and 134 | maintainers. 135 | * Coordinating contributors to implement the KEP 136 | * Coordinating the review and merge of containerd side KEP-related PRs 137 | coinciding with required k/k CRI, kubelet, and other project dependencies 138 | * Shepherds should provide initial review of the containerd PRs 139 | * Shepherds should ensure that documentation for any new CRI API clearly 140 | articulates any guarantees that containerd must provide and any API 141 | behaviors that are not clear from the API declaration 142 | * Assist the liason(s) with reviews of the other KEP dependent PRs, such as CRI 143 | API changes, Kubelet changes, etc. 144 | * Communicating the status of the KEP clearly on the tracking issue which will 145 | be cross linked to the KEP issue document, PRs, and other SIG-Node tracking 146 | documents. 147 | * The shepherd role is not necessarily responsible for designing or 148 | implementing the KEP themselves -------------------------------------------------------------------------------- /go.mod: -------------------------------------------------------------------------------- 1 | module github.com/containerd/project 2 | 3 | go 1.23.1 4 | 5 | // required for project-checks action 6 | -------------------------------------------------------------------------------- /img/Advisories.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/containerd/project/9aabad31a38e5dd7b7c37d054fc207b250c51f29/img/Advisories.png -------------------------------------------------------------------------------- /img/Report-A-Vulnerability.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/containerd/project/9aabad31a38e5dd7b7c37d054fc207b250c51f29/img/Report-A-Vulnerability.png -------------------------------------------------------------------------------- /img/Security-Tab.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/containerd/project/9aabad31a38e5dd7b7c37d054fc207b250c51f29/img/Security-Tab.png --------------------------------------------------------------------------------