├── .ci └── static-checks.sh ├── .github └── workflows │ ├── PR-wip-checks.yaml │ ├── dco-check.yaml │ └── main.yml ├── AC-Meeting-Guidelines.md ├── Backport-Guide.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── Documentation-Review-Process.md ├── LICENSE ├── PR-Review-Guide.md ├── README.md ├── Rota-Process.md ├── VENDORING.md ├── VMT ├── KCSA.md ├── KCSA │ ├── KCSA-CVE-2019-5736.md │ ├── KCSA-CVE-2020-2023.md │ ├── KCSA-CVE-2020-2024.md │ ├── KCSA-CVE-2020-2025.md │ ├── KCSA-CVE-2020-2026.md │ ├── KCSA-CVE-2020-27151.md │ └── KCSA-CVE-2020-28914.md ├── VMT-process.png ├── VMT-process.svg ├── VMT.md └── templates │ ├── KCSA.md │ ├── KCSN.md │ ├── cve-request-email-private.md │ ├── cve-request-email-public.md │ ├── downstream-stakeholder-notification.md │ ├── impact-description.md │ ├── reception-embargo-reminder.md │ └── reception-incomplete-message.md ├── elections ├── README.md ├── arch-committee-2018-09 │ ├── 2018-09-Results.txt │ ├── EricErnst.txt │ ├── JonOlson.txt │ ├── KalyXin.txt │ ├── README.md │ └── WeiZhang.txt ├── arch-committee-2019-03 │ ├── README.md │ ├── Results.md │ ├── SamuelOrtiz.txt │ └── XuWang.txt ├── arch-committee-2019-09 │ ├── EricErnst.txt │ ├── HaominTsai.txt │ ├── JustinHe.txt │ ├── README.md │ └── Results.md ├── arch-committee-2020-02 │ ├── DaveGilbert.txt │ ├── README.md │ ├── Results.md │ ├── SamuelOrtiz.txt │ └── XuWang.txt ├── arch-committee-2020-09 │ ├── ArchanaShinde.txt │ ├── EricErnst.txt │ ├── FabianoFidencio.txt │ ├── JustinHe.txt │ ├── README.md │ └── Results.md ├── arch-committee-2021-02 │ ├── PengTao.txt │ ├── README.md │ ├── Results.md │ └── SamuelOrtiz.txt ├── arch-committee-2021-09 │ ├── ArchanaShinde.txt │ ├── EricErnst.txt │ ├── FabianoFidencio.txt │ ├── README.md │ └── Results.md ├── arch-committee-2022-03 │ ├── README.md │ ├── Results.md │ ├── SamuelOrtiz.txt │ └── TaoPeng.txt ├── arch-committee-2022-11 │ ├── ArchanaShinde.txt │ ├── EricErnst.txt │ ├── FabianoFidencio.txt │ ├── FengWang.txt │ ├── FupanLi.txt │ ├── GerryLiu.txt │ ├── README.md │ └── Results.md ├── arch-committee-2023-04 │ ├── ArchanaShinde.txt │ ├── FengWang.txt │ ├── JeremiPiotrowski.txt │ ├── README.md │ ├── Results.md │ ├── SamuelOrtiz.txt │ ├── SteveHorsman.txt │ └── TaoPeng.txt ├── arch-committee-2023-10 │ ├── FabianoFidencio.txt │ ├── FupanLi.txt │ ├── GerryLiu.txt │ ├── GregKurz.txt │ ├── JeremiPiotrowski.txt │ ├── README.md │ └── Results.md ├── arch-committee-2024-04 │ ├── AnastassiosNanos.txt │ ├── README.md │ ├── Results.md │ ├── SteveHorsman.txt │ ├── TaoPeng.txt │ └── ZvonkoKaiser.txt ├── arch-committee-2024-10 │ ├── AurelienBombo.txt │ ├── FupanLi.txt │ ├── GregKurz.txt │ ├── README.md │ └── Results.md ├── arch-committee-2025-04 │ ├── AnastassiosNanos.txt │ ├── README.md │ ├── Results.md │ ├── RuoqingHe.txt │ ├── SteveHorsman.txt │ ├── TaoPeng.txt │ └── ZvonkoKaiser.txt ├── process │ └── README.md └── tools │ ├── README.md │ └── generate_electorate.py ├── fig1-ci-cd-failure.png ├── fig2-ci-cd-log.png └── statusreports └── REPORT_TEMPLATE.md /.ci/static-checks.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # 3 | # Copyright (c) 2024 IBM Corporation 4 | # 5 | # SPDX-License-Identifier: Apache-2.0 6 | 7 | set -e 8 | 9 | export kata_repo="${kata_repo:-github.com/kata-containers/kata-containers}" 10 | export kata_repo_dir="$GOPATH/src/$kata_repo" 11 | export kata_default_branch="${kata_default_branch:-main}" 12 | 13 | 14 | clone_kata_repo() { 15 | if [ ! -d "${kata_repo_dir}" ]; then 16 | mkdir -p "${kata_repo_dir}" 17 | git clone "https://${kata_repo}.git" "${kata_repo_dir}" 18 | pushd "${kata_repo_dir}" || exit 19 | # Checkout to default branch 20 | git checkout "${kata_default_branch}" 21 | popd || exit 22 | fi 23 | } 24 | 25 | run_static_checks() 26 | { 27 | clone_kata_repo 28 | INSTALL_IN_GOPATH=false bash "${kata_repo_dir}/ci/install_yq.sh" 29 | bash "${kata_repo_dir}/tests/install_go.sh" -f -p 30 | bash "${kata_repo_dir}/tests/static-checks.sh" "github.com/kata-containers/community" 31 | } 32 | 33 | run_static_checks 34 | -------------------------------------------------------------------------------- /.github/workflows/PR-wip-checks.yaml: -------------------------------------------------------------------------------- 1 | name: Pull request WIP checks 2 | on: 3 | pull_request: 4 | types: 5 | - opened 6 | - synchronize 7 | - reopened 8 | - edited 9 | - labeled 10 | - unlabeled 11 | 12 | jobs: 13 | pr_wip_check: 14 | runs-on: ubuntu-24.04 15 | name: WIP Check 16 | steps: 17 | - name: WIP Check 18 | uses: tim-actions/wip-check@1c2a1ca6c110026b3e2297bb2ef39e1747b5a755 19 | with: 20 | labels: '["do-not-merge", "wip", "rfc"]' 21 | keywords: '["WIP", "wip", "RFC", "rfc", "dnm", "DNM", "do-not-merge"]' 22 | -------------------------------------------------------------------------------- /.github/workflows/dco-check.yaml: -------------------------------------------------------------------------------- 1 | name: DCO check 2 | on: 3 | pull_request: 4 | types: 5 | - opened 6 | - reopened 7 | - synchronize 8 | 9 | jobs: 10 | dco_check_job: 11 | runs-on: ubuntu-24.04 12 | name: DCO Check 13 | steps: 14 | - name: Get PR Commits 15 | id: 'get-pr-commits' 16 | uses: tim-actions/get-pr-commits@ed97a21c3f83c3417e67a4733ea76887293a2c8f 17 | with: 18 | token: ${{ secrets.GITHUB_TOKEN }} 19 | - name: DCO Check 20 | uses: tim-actions/dco@2fd0504dc0d27b33f542867c300c60840c6dcb20 21 | with: 22 | commits: ${{ steps.get-pr-commits.outputs.commits }} 23 | -------------------------------------------------------------------------------- /.github/workflows/main.yml: -------------------------------------------------------------------------------- 1 | on: ["pull_request"] 2 | name: Static checks 3 | jobs: 4 | static-checks: 5 | runs-on: ubuntu-24.04 6 | env: 7 | GOPATH: ${{ github.workspace }} 8 | steps: 9 | - name: Checkout code 10 | uses: actions/checkout@v4 11 | with: 12 | fetch-depth: 0 13 | path: ./src/github.com/${{ github.repository }} 14 | 15 | - name: Install system dependencies 16 | run: | 17 | sudo apt-get -y install moreutils hunspell hunspell-en-gb hunspell-en-us pandoc 18 | 19 | - name: Running static checks 20 | run: | 21 | export PATH=${GOPATH}/bin:${PATH} 22 | ./src/github.com/${{ github.repository }}/.ci/static-checks.sh 23 | -------------------------------------------------------------------------------- /AC-Meeting-Guidelines.md: -------------------------------------------------------------------------------- 1 | **Important:** 2 | 3 | Do **not** follow this process if you think you have discovered a vulnerability. 4 | Instead, please use the [VMT](https://github.com/kata-containers/community/blob/master/VMT/VMT.md) 5 | process. 6 | 7 | # Architecture Committee Meeting Guidelines 8 | 9 | The Architecture Committee (AC) recommends following a set of guidelines for 10 | raising issues and adding topics to the meeting agenda. 11 | 12 | ## Use a GitHub issue first 13 | 14 | For a project like Kata Containers, with contributors spanning across so many 15 | different time zones, asynchronous discussions and reviews are the preferred 16 | communication media. 17 | 18 | Directly starting a proposal or trying to resolve new technical issues through 19 | the AC meeting has many drawbacks: 20 | * It potentially leaves a large part of the community out of the initial 21 | dicussion. 22 | * It does not give the AC meeting audience enough time to think through 23 | the proposal and give constructive and well thought feedback. 24 | * It makes it hard to track and share the discussion outcome. 25 | 26 | As a consequence, the AC recommends using [GitHub issues](https://github.com/kata-containers/kata-containers/issues) 27 | at first before adding new items to the AC meetings agenda, especially 28 | if you think the topic could be discussed and resolved in less than two weeks. 29 | 30 | ## AC Agenda topics must be supported by a GitHub issue or a PR 31 | 32 | Except for a few cases listed in the next section, any topic brought to the AC 33 | meeting must be linked to a GitHub issue or a PR that should contain a 34 | `cc @kata-containers/architecture-committee` in order to notify AC members of 35 | the creation of a new AC meeting proposal. 36 | 37 | Unless the topic must be urgently discussed, the AC recommends waiting for one 38 | or two weeks before bringing the discussion to the AC meeting. That will give 39 | enough time for interested contributors to digest the issue or proposal before 40 | having a live discussion in the AC meeting. 41 | 42 | ### Exceptions 43 | 44 | * Announcements 45 | * Presentations 46 | * Call for reviews of articles, blog posts, etc. 47 | 48 | ## AC agenda topics should have well defined expectations 49 | 50 | When adding a topic to the agenda, one should have clearly defined expectations: 51 | **"What do I want to get from the community and the AC with that discussion?"**. 52 | 53 | For instance: 54 | * Are you looking for a possible **solution** to a problem exposed through 55 | GitHub or the mailing list? 56 | * Are you looking for a **resolution** of a conflict in a pull request? 57 | * Are you looking for a [**"go-nogo"**](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#submit-issues-before-prs) 58 | from the community in order to start working on something? 59 | * Are you looking for technical **feedback and guidelines** on a pending 60 | technical proposal? 61 | 62 | Answering those questions and clearly stating the expectations upfront will 63 | help with steering the AC meeting discussions in the right direction. 64 | -------------------------------------------------------------------------------- /Backport-Guide.md: -------------------------------------------------------------------------------- 1 | # Kata Containers stable backport workflow 2 | 3 | * [Introduction](#introduction) 4 | * [Assumptions](#assumptions) 5 | * [Graphical overview of backporting](#graphical-overview-of-backporting) 6 | * [Before the backport](#before-the-backport) 7 | * [After the backport](#after-the-backport) 8 | * [Backport Workflow](#backport-workflow) 9 | * [Setup](#setup) 10 | * [Locate commits to cherry pick](#locate-commits-to-cherry-pick) 11 | * [Apply the commits](#apply-the-commits) 12 | * [Check the result](#check-the-result) 13 | * [Raise a PR](#raise-a-pr) 14 | * [Further information](#further-information) 15 | 16 | ## Introduction 17 | 18 | This document provides a short guide explaining how to perform a backport. 19 | Backporting refers to applying changes to a stable branch from a newer branch. 20 | The changes comprise one or more commits in the form of a PR and the newer 21 | branch is generally the `main` branch. 22 | 23 | Since new features are not added to stable branches, backported changes are 24 | generally bug fixes and security fixes. See the 25 | [stable branch strategy](https://github.com/kata-containers/documentation/blob/master/Stable-Branch-Strategy.md) 26 | document for further details. 27 | 28 | > **Note:** This guide does not cover all eventualities that might be 29 | > encountered while performing a backport, and only documents one potential 30 | > Git based workflow. It does serve as a short introduction and reminder of 31 | > the basic stable backport process. 32 | 33 | The two branches used in the examples in this guide are: 34 | 35 | - The `main` branch (which contains all commits). 36 | - A `stable-1.2` branch which will be the target of the backport: commits will 37 | be selectively "copied" ("cherry-picked") into this branch from the `main` branch. 38 | 39 | ## Assumptions 40 | 41 | This document assumes an understanding of: 42 | 43 | - The `git(1)` tool. 44 | - The [standard PR workflow](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#pull-requests). 45 | - The [stable branch strategy](https://github.com/kata-containers/documentation/blob/master/Stable-Branch-Strategy.md). 46 | 47 | ## Graphical overview of backporting 48 | 49 | ### Before the backport 50 | 51 | Imagine that initially both the `main` branch and the stable branch 52 | (`stable-1.2`) contain only the commits `A`, `B` and `C`: 53 | 54 | ``` 55 | + (stable-1.2 branch) 56 | / 57 | A---B---C (main branch) 58 | ``` 59 | 60 | New commits (`D`, `E`, `F` and `G`) are added to the `main` branch: 61 | 62 | ``` 63 | + (stable-1.2 branch) 64 | / 65 | A---B---C---D---E---F---G (main branch) 66 | ``` 67 | 68 | Imagine that: 69 | 70 | - Commits `E` and `G` are bug or security fixes which need to be backported. 71 | - Commits `D` and `F` are new features which must *not* be backported. 72 | 73 | ### After the backport 74 | 75 | After the backporting: 76 | 77 | ``` 78 | +-----E-------G (stable-1.2 branch) 79 | / ^ ^ 80 | A---B---C---D---E---F---G (main branch) 81 | ``` 82 | 83 | After the backport, the `stable-1.2` branch contains commits `A`, `B` and 84 | `C`, `E` and `G`. 85 | 86 | ## Backport Workflow 87 | 88 | ### Auto-backporting 89 | Auto-backporting is a helpful feature than can be used to speed up the backport process. 90 | The project uses [Backport Action](https://github.com/marketplace/actions/backport-action) to handle the backporting and another GitHub workflow to automatically add the `auto-backport` label. 91 | 92 | The following PRs will automatically have the `auto-backport` label added: 93 | - PRs whose [associated issue](CONTRIBUTING.md#submit-issues-before-prs) has the `bug` label set. 94 | - PR contains `backport-needed` label 95 | 96 | PRs with the `no-backport-needed` label will automatically have their `auto-backport` label removed, superseding the above conditions. 97 | 98 | Additionally, the `auto-backport` label can be added or removed manually. 99 | > **Note:** The check for labels is triggered whenever a label is added or removed from the PR. 100 | 101 | The Backport Action executes the following steps: 102 | - `auto-backport` label is checked when the PR is merged. 103 | - The action will look for all labels of the form`backport-to-BRANCHNAME`. 104 | - The action will then attempt to generate a backport for each label, leaving a notification reporting success or failure. 105 | 106 | > **Note:** This does require labels to be made and added to the corresponding branches that one intends to backport to. 107 | 108 | Automatic backports should be reviewed for correctness. 109 | 110 | ### Manual Backporting 111 | The basic workflow involves: 112 | 113 | - Creating a new local branch from the stable tree you are targeting. 114 | - Selecting (or "cherry picking") the commits from your main branch PR into the stable branch. 115 | - Submitting your branch to GitHub as a PR against the stable branch (not to the `main` branch). 116 | 117 | ### Setup 118 | 119 | - Ensure your local repo is up to date: 120 | 121 | ```bash 122 | $ cd ${GOPATH}/src/github.com/kata-containers/runtime 123 | $ git fetch origin 124 | ``` 125 | 126 | Check the list of stable branches: 127 | 128 | ```bash 129 | $ git branch -r | grep origin/stable 130 | ``` 131 | 132 | - Create your branch to work on, based on the `stable-1.2` branch: 133 | 134 | ```bash 135 | $ git checkout -b my_1.2_pr_backport origin/stable-1.2 136 | ``` 137 | 138 | ### Locate commits to cherry pick 139 | 140 | To list all commits in the `main` branch which are not in the `stable-1.2` 141 | branch: 142 | 143 | ```bash 144 | $ git log --oneline --no-merges ..main 145 | ``` 146 | 147 | Make a note of the SHA values for the commits in the PR to backport. 148 | 149 | > **Note:** If your PR is in a local branch, substitute `main` for the name 150 | > of that branch. 151 | 152 | ### Apply the commits 153 | 154 | - Pull in your commits: 155 | 156 | If you are pulling the commits in from the `main` branch, you can add the `-x` 157 | argument to `git cherry-pick` to automatically add a reference in the 158 | commit to the original commits. This is strongly recommended to aid traceability. 159 | If you pick the commits from your local branch do *not* use `-x`; this 160 | potentially adds references to SHAs that only exist in your local branch, which 161 | is not useful for future tracability. 162 | 163 | It is also required that you add the `-s` signoff to the commits, if you did not 164 | create the original commits. 165 | 166 | ```bash 167 | $ git cherry-pick -x ... 168 | ``` 169 | 170 | > **Note:** You should only cherry pick the original commits - do **not** 171 | > cherry pick merge commits 172 | > (see [Locate commits to cherry pick](#locate-commits-to-cherry-pick)). 173 | 174 | You can cherry pick ranges of commits. Please see the `git-cherry-pick(1)` 175 | man page for more information. 176 | 177 | > **Note:** You do not need to open a new `Issue` or add an extra `Fixes: nnn` item 178 | > to the commits. They should re-use the `Fixes:` entry from the original commits, 179 | > so all related commits refer back to the common Issue. It does not matter that 180 | > the original `Issue` is closed, the references still work correctly. 181 | 182 | - Resolve any conflicts: 183 | 184 | You might encounter conflicts during your cherry pick, which need to be resolved 185 | before you continue. Follow standard practices for Git conflict resolution, and see 186 | the guidance printed by `git cherry-pick` on processing and applying those fixes. 187 | 188 | If you hit a conflict, any effects of `-x` to `cherry-pick` might not be 189 | applied. In this case, consider hand-adding the `main` SHA references and a note 190 | that you resolved a conflict to the commit message. 191 | 192 | ### Check the result 193 | 194 | - Test your changes: 195 | 196 | Before you push your changes, you should test that they work and nothing has been 197 | broken. No matter how small the change, running the test suite is always recommended. 198 | 199 | ### Raise a PR 200 | 201 | - Push your branch to your GitHub repo: 202 | 203 | ```bash 204 | $ git push my_remote my_1.2_pr_backport 205 | ``` 206 | 207 | - Submit a PR from your branch to *the stable branch*: 208 | 209 | When you submit your PR on GitHub, make sure to choose the stable branch that you 210 | based your branch on and are submitting to. This *should* be the same as the 211 | base branch for the PR. 212 | 213 | - Add a special comment to the *original* PR with a reference to the backport 214 | PR(s). See the [contributing guide](CONTRIBUTING.md#porting-comments) for 215 | further information. 216 | 217 | - Add the `backport` label to the PR to denote it is a backport. 218 | 219 | ## Further information 220 | 221 | For further information on porting, see the [contributing 222 | guide](CONTRIBUTING.md#porting). 223 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | ## Kata Containers Code of Conduct 2 | 3 | Kata Containers follows the [Open Infrastructure Foundation Code of Conduct](https://www.openstack.org/legal/community-code-of-conduct/). 4 | -------------------------------------------------------------------------------- /Documentation-Review-Process.md: -------------------------------------------------------------------------------- 1 | # Documentation review process 2 | 3 | * [Introduction](#introduction) 4 | * [The Documentation Team](#the-documentation-team) 5 | * [Default document review process](#default-document-review-process) 6 | * [Justification for different process](#justification-for-different-process) 7 | * [Users should always expect accurate Documentation](#users-should-always-expect-accurate-documentation) 8 | * [Some documentation PRs can be fast-tracked](#some-documentation-prs-can-be-fast-tracked) 9 | * [Formal doc reviews can be very time-intensive](#formal-doc-reviews-can-be-very-time-intensive) 10 | * [Decision Authority](#decision-authority) 11 | * [Determine if a full document review is required](#determine-if-a-full-document-review-is-required) 12 | * [Exempt](#exempt) 13 | * [Required](#required) 14 | * [Requesting a formal document review](#requesting-a-formal-document-review) 15 | * [Lightweight document review process](#lightweight-document-review-process) 16 | 17 | ## Introduction 18 | 19 | The process for reviewing documentation PRs is slightly different from 20 | [the general process for reviewing code PRs](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#reviewsPR-Review-Guide.md). 21 | This document explains the differences. 22 | 23 | ## The Documentation Team 24 | 25 | The Documentation Team is responsible for carrying out a full documentation 26 | review of a PRs containing documentation changes. Such a review includes 27 | checking the grammar, structure, consistency, and typographical correctness of 28 | the documentation changes. 29 | 30 | The following GitHub team lists the users who are members of the Documentation Team: 31 | 32 | - https://github.com/orgs/kata-containers/teams/documentation/members 33 | 34 | ## Default document review process 35 | 36 | [Project maintainers](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#project-maintainers) 37 | have the power to approve or reject PRs. 38 | 39 | If a Documentation Team review is required, the `CODEOWNERS` configuration will 40 | apply and the PR will be blocked until the required number of acks are 41 | obtained for the documentation changes. 42 | 43 | Technical writers from the Documentation Team will review the document 44 | changes and add comments explaining how the wording should be changed. It is 45 | then up to the PR creator to apply these changes to their original PR, 46 | rebasing as necessary to ensure a clean `git(1)` history. Once the creator has 47 | applied the changes they need to re-push their branch and add a comment to the 48 | PR asking for a re-review. This process continues indefinitely until the the 49 | Documentation Team is happy with the final result. 50 | 51 | ## Justification for different process 52 | 53 | The documentation review process is different than the code review process for 54 | the following reasons: 55 | 56 | ### Users should always expect accurate Documentation 57 | 58 | Just like code changes, some documentation changes have to be merged as soon 59 | as possible to ensure users have current and accurate information. 60 | 61 | Documentation changes tend to be more urgent though. For example, a "Priority 62 | 1" code issue needs to be fixed quickly. However it would also need to be 63 | documented clearly (and quickly). If the P1 issue *cannot* be fixed quickly, 64 | the documentation must still be updated as soon as possible to alert users of 65 | the issue and to provide suitable workarounds. 66 | 67 | If the documentation is *not* kept current, users have incorrect information 68 | and might create problems for themselves or become disaffected with the 69 | project entirely. 70 | 71 | In summary, do not let documentation PRs sit in the PR backlog for any longer 72 | than necessary. 73 | 74 | ### Some documentation PRs can be fast-tracked 75 | 76 | If a PR makes a minor change to one or more documents, passing to the 77 | Documentation Team for a formal review and approval might not be necessary. 78 | 79 | ### Formal doc reviews can be very time-intensive 80 | 81 | Since a full document review can be a slow and pain-staking process, and since 82 | the number of professional technical writers on the Documentation Team is 83 | relatively small compared to the number of developers, it makes sense to only 84 | perform such reviews on the documents that justify the effort. 85 | 86 | ## Decision Authority 87 | 88 | If a Documentation Team member believes a full review is required, their 89 | decision is final. 90 | 91 | In most other cases, a project maintainer will decide whether a full review is 92 | required or not. 93 | 94 | If project maintainers cannot decide whether the lightweight process should be 95 | followed, the full process should be used instead since the uncertainty 96 | implies "more eyes" should see the changes. 97 | 98 | ## Determine if a full document review is required 99 | 100 | ### Exempt 101 | 102 | If a PR contains documentation changes that **only** relate to one or more of 103 | the following categories, it does not need to be formally reviewed and 104 | approved by the Documentation Team: 105 | 106 | - Changes to code blocks 107 | 108 | The PR only modifies code blocks embedded in the document. 109 | 110 | - "Typo" fixes 111 | 112 | The PR only fixes spelling mistakes and whitespace issues. 113 | 114 | - Formatting 115 | 116 | The PR only modifies the layout of the existing text. For example, you 117 | update words to render them in a ``fixed font`` or change a 118 | [Note](https://github.com/kata-containers/documentation/blob/master/Documentation-Requirements.md#notes) 119 | to fit the standard formatting conventions. 120 | 121 | - URL fixes 122 | 123 | The PR only modifies URLs or updates the table of contents. 124 | 125 | - The PR only *removes* documentation. 126 | 127 | ### Required 128 | 129 | The following PR changes generally indicate a full document review is 130 | necessary: 131 | 132 | - A new document has been added by the PR. 133 | 134 | All documents should have an initial review unless they are extremely simple. 135 | 136 | ## Requesting a formal document review 137 | 138 | If a PR needs a full document review, add a comment to the PR like the 139 | following, which sends a mail to all members of the Documentation Team: 140 | 141 | ``` 142 | PTAL @kata-containers/documentation 143 | ``` 144 | 145 | ## Lightweight document review process 146 | 147 | 1. Obtain general agreement that 148 | a Document Team review [is not required](#decision-authority). 149 | 150 | 1. Ensure all other approvals and CI checks have been met. 151 | 152 | 1. Ensure the PR contains a note explaining why the PR does not justify a full review. 153 | 154 | 1. Request a project maintainer force-merges the PR. 155 | 156 | This operation bypasses the check that normally stops a PR from 157 | landing until the Documentation Team acks the PR. 158 | 159 | 1. The maintainer should notify the Documentation Team out of courtesy that 160 | the PR has been merged. 161 | 162 | This allows a follow-on "recovery PR" to be raised should the Documentation 163 | Team disagree on using the lightweight process. 164 | -------------------------------------------------------------------------------- /PR-Review-Guide.md: -------------------------------------------------------------------------------- 1 | * [High level considerations](#high-level-considerations) 2 | * [Security](#security) 3 | * [Reliability](#reliability) 4 | * [Performance](#performance) 5 | * [Maintenance](#maintenance) 6 | * [Usability](#usability) 7 | * [Specifics to consider](#specifics-to-consider) 8 | * [Basics](#basics) 9 | * [Layout and formatting](#layout-and-formatting) 10 | * [Design](#design) 11 | * [Code comments](#code-comments) 12 | * [Documentation](#documentation) 13 | * [Logging and debugging](#logging-and-debugging) 14 | * [Testing](#testing) 15 | * [Environments](#environments) 16 | * [Upgrades](#upgrades) 17 | * [Mandatory checks](#mandatory-checks) 18 | 19 | --- 20 | 21 | This document attempts to capture some of the points to consider when 22 | reviewing a [new code contribution](CONTRIBUTING.md) (a Pull Request (PR)) to 23 | ensure overall quality is high. 24 | 25 | ## High level considerations 26 | 27 | ### Security 28 | 29 | - Does the change introduce a potential security risk? 30 | - What additional checks resolve the potential security risk? 31 | 32 | ### Reliability 33 | 34 | - What happens on failure? Consider **every** possible failure. For example: 35 | - Are temporary files left on the disk? 36 | - Are any resources (e.g. memory and open files) leaked? 37 | 38 | - If the code crashes, what is the overall system impact? 39 | - Can the system be restarted and recovered? 40 | - Is [security](#security) compromised? 41 | 42 | ### Performance 43 | 44 | - Does this change negatively impact performance? 45 | - Can any calls block? If yes, there must be a log call before the blocking call explaining what is about to be done. 46 | 47 | ### Maintenance 48 | 49 | - How easy is this code to maintain: 50 | - By an experienced developer on the project? 51 | - By a developer with none or almost no experience of the code base or the project? 52 | 53 | ### Usability 54 | 55 | - Does the change improve usability or make it worse? 56 | - Can usability be improved further? 57 | 58 | ## Specifics to consider 59 | 60 | ### Basics 61 | 62 | - Consider *all* inputs and outputs. 63 | - What resources are being used (e.g. memory, disk, etc.)? Are the resources released? 64 | - Are all return values and arguments checked? 65 | - Are there any magic numbers? 66 | 67 | ### Layout and formatting 68 | 69 | - Is formatting and naming consistent? 70 | - Are there any spelling mistakes ("typos")? 71 | - Do all new files contain the required licence header? 72 | 73 | ### Design 74 | 75 | - Can the code be simplified or refactored? 76 | - Is the code "too clever"? Overly clever code can be fragile. Reject it unless there is a **very** good documented reason. 77 | - Is there a better (simpler) solution to the problem? 78 | - Is there any duplication? 79 | - Does the code "reinvent the wheel?" Is there a standard package you can use instead? 80 | - What assumptions does the code make? Are the assumptions valid and documented? 81 | - Does the code make sense? 82 | - Someone with minimal exposure to the codebase should be able to guess what the code is doing. 83 | 84 | ### Code comments 85 | 86 | - Is the code well commented? 87 | - Are all functions and function parameters documented. For `golang` programs, is their purpose obvious? 88 | - Does this change require an update to the README(s) or architecture docs, installation docs, or limitations docs? 89 | - Are any lines commented out? If yes, remove them. 90 | - Are there any `FIXME` or `TODO`'s? If yes, replace them with a full URL to an issue number tracking the work to be done. 91 | 92 | ### Documentation 93 | 94 | - Should the document update be applied to any *other* documents? 95 | For example, when a PR updates an installation guide, determine whether those changes apply to one or more of the other installation guides. 96 | - Does the PR make any of the following changes? If yes, determine if a documentation change is necessary: 97 | - New programs or scripts are added or removed. 98 | - New program or script options are added or removed. 99 | - New config options are added or removed. 100 | - New features are added or removed. 101 | - Existing bug(s) are fixed. 102 | 103 | ### Logging and debugging 104 | 105 | - Can someone debug this code from a logfile if it fails? 106 | - Are all fatal scenarios logged? 107 | - Are error messages and log calls useful and comprehensive? Ensure sensitive information is **not** displayed. 108 | 109 | ### Testing 110 | 111 | - Is the code easy to test? 112 | - Are there new unit tests? If not, why not? 113 | - What other classes of testing (e.g. integration, system, stress, fuzz) can someone write to check the code? 114 | 115 | ### Environments 116 | 117 | - Does the code work on all distributions? 118 | - Does the code work on all architectures? 119 | - What environments does your code run in? 120 | - Which user does the code run as? If it runs as the superuser, have clear documentation to explain why this is necessary. 121 | 122 | ### Upgrades 123 | 124 | - If the code logs internal state to a file or shared memory, how are upgrades handled? 125 | For example, if a new version introduces a new state file format, does the new version consume the old state file format files? 126 | - If upgrades cannot be handled, document this. 127 | 128 | ## Mandatory checks 129 | 130 | - Provide constructive comments on the code. 131 | - If you particularly like some aspect of the code, say so. 132 | - If you do not like something about the code, respectfully state what you do not like. 133 | - If you do not understand the code, say so because code should **always** be clear. 134 | 135 | - Ensure all automated checks pass. 136 | - Ensure the PR contains at least one `Fixes #XXX` commit message referencing an issue that this PR fixes. 137 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | * [About Kata Containers](#about-kata-containers) 4 | * [Community](#community) 5 | * [Join Us](#join-us) 6 | * [Users](#users) 7 | * [Contributors](#contributors) 8 | * [Review Team](#review-team) 9 | * [Resource Owners](#resource-owners) 10 | * [Governance](#governance) 11 | * [Developers](#developers) 12 | * [Contributor](#contributor) 13 | * [Committer](#committer) 14 | * [Admin](#admin) 15 | * [Owner](#owner) 16 | * [Architecture Committee](#architecture-committee) 17 | * [Architecture Committee Meetings](#architecture-committee-meetings) 18 | * [Vendoring code](#vendoring-code) 19 | * [Vulnerability Handling](#vulnerability-handling) 20 | * [Reporting Vulnerabilities](#reporting-vulnerabilities) 21 | * [Vulnerability Disclosure Process](#vulnerability-disclosure-process) 22 | * [Week in Review template](#week-in-review-template) 23 | 24 | # About Kata Containers 25 | 26 | Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. 27 | 28 | The Kata Containers project is designed to be architecture agnostic, run on multiple hypervisors and be compatible with the OCI specification and Kubernetes. 29 | 30 | Kata Containers combines technology from [Intel® Clear Containers](https://github.com/clearcontainers/runtime) and [Hyper runV](https://github.com/hyperhq/runv). The code is hosted on GitHub under the Apache 2 license and the project is managed by the Open Infrastructure Foundation. To learn more about the project and organizations backing the launch, visit https://www.katacontainers.io. 31 | 32 | # Community 33 | 34 | Kata Containers is working to build a global, diverse and collaborative community. Anyone who is interested in supporting the technology is welcome to participate. Learn how to contribute on the [Community pages](https://katacontainers.io/community/). We are seeking different expertise and skills, ranging from development, operations, documentation, marketing, community organization and product management. 35 | 36 | ## Join Us 37 | 38 | You can join our community on any of the following places: 39 | 40 | * Join our [mailing list](http://lists.katacontainers.io/). 41 | 42 | * Use the `irc.oftc.net` IRC server to join the discussions: 43 | * General discussions channel: [`#kata-general`](http://webchat.oftc.net/?channels=kata-general). 44 | * Development discussions channel: [`#kata-dev`](http://webchat.oftc.net/?channels=kata-dev). 45 | 46 | * Get an [invite to our Slack channel](https://bit.ly/3bbRXOV). 47 | and then [join us on Slack](https://katacontainers.slack.com/). 48 | 49 | * Follow us on [Twitter](https://twitter.com/KataContainers) or 50 | [Facebook](https://www.facebook.com/KataContainers). 51 | 52 | ## Users 53 | 54 | See [Kata Containers installation user guides](https://github.com/kata-containers/kata-containers/blob/main/docs/install/README.md) for details on how to install Kata Containers for your preferred distribution. 55 | 56 | ## Contributors 57 | 58 | See the [contributing guide](CONTRIBUTING.md) for details on how to contribute to the project. 59 | 60 | ## Review Team 61 | 62 | See the [rota documentation](Rota-Process.md). 63 | 64 | ## Resource Owners 65 | 66 | Details of which Kata Containers project resources are owned, managed or controlled by whom 67 | are detailed on the [Areas of Interest](https://github.com/kata-containers/community/wiki/Areas-of-interest) wiki page, under the [Resource Owners](https://github.com/kata-containers/community/wiki/Areas-of-interest#resource-owners) section. 68 | 69 | # Governance 70 | 71 | The Kata Containers project is governed according to the ["four opens"](https://openinfra.dev/four-opens/), which are open source, open design, open development, and open community. Technical decisions are made by technical contributors and a representative Architecture Committee. The community is committed to diversity, openness, and encouraging new contributors and leaders to rise up. 72 | 73 | ## Developers 74 | 75 | For Kata developers, there are several roles relevant to project governance: 76 | 77 | ### Contributor 78 | 79 | A Contributor to the Kata Containers project is someone who has had code merged within the last 12 months. Contributors are eligible to vote in the Architecture Committee elections. Contributors have read only access to the Kata Containers repos on GitHub. 80 | 81 | ### Committer 82 | 83 | Kata Containers Committers (as defined by the [kata-containers-committer team](https://github.com/orgs/kata-containers/teams/kata-containers-committer)) 84 | have the ability to merge code into the Kata Containers project. 85 | Committers are active Contributors and participants in the project. In order to become a Committer, you must be nominated by an established Committer and approved by quorum of the active Architecture Committee via an issue against the community repo 86 | e.g. https://github.com/kata-containers/community/issues/403. Committers have write access to the Kata Containers repos on GitHub, which 87 | gives the ability to approve PRs, trigger the CI and merge PRs. 88 | 89 | One of the requirements to be a committer is that you are an active Contributor to the project as adjudged by the above criteria. Assessing the list of active Contributors happens twice a year, 90 | lining up with the Architecture Committee election cycle. At that time, people who are in the kata-containers-committer team will also be reviewed, and a list of people, who are on the team, 91 | but who haven't been an active Contributor in the last 12 months will be created and shared with the Architecture Committee and community. 92 | After a short review period, to allow time to check for any errors, inactive team members will be removed. 93 | 94 | > [!Note] 95 | > See [issue #413](https://github.com/kata-containers/community/issues/413) for a potential change in how active contribution is assessed. 96 | 97 | ### Admin 98 | 99 | Kata Containers Admins (as defined by the [kata-containers-admin team](https://github.com/orgs/kata-containers/teams/kata-containers-admin) have admin access to 100 | the kata-containers repo, allowing them to do actions like, change the branch protection rules for repositories, delete a repository and manage the access of others. 101 | The Admin group is intentionally kept small, however, individuals can be granted temporary admin access to carry out tasks, like creating a secret that is used in a particular CI infrastructure. 102 | The Admin list is reviewed and updated after each Architecture Committee election and typically contains: 103 | - The Architecture Committee 104 | - Optionally, some specific people that the Architecture Committee agree on adding for a specific purpose (e.g. to manage the CI) 105 | 106 | ### Owner 107 | 108 | GitHub organization owners have complete admin access to the organization, and therefore this group is limited to a small number of individuals, for security reasons. 109 | The owners list is reviewed and updated after each Architecture Committee election and contains: 110 | - The Community Manager and one, or more extra people from the `OpenInfra Foundation` for redundancy and vacation cover 111 | - The Architecture Committee 112 | - Optionally, some specific people that the Architecture Committee agree on adding for a specific purpose (e.g. to help with repo/CI migration) 113 | 114 | ## Architecture Committee 115 | 116 | The Architecture Committee is responsible for architectural decisions, including standardization, and making final decisions if Committers disagree. It is comprised of 7 members, who are elected by Contributors. 117 | 118 | The current Architecture Committee members are: 119 | 120 | - `Anastassios Nanos` ([`ananos`](https://github.com/ananos)), [`Nubificus Ltd`](https://nubificus.co.uk). 121 | - `Aurelien Bombo` ([`sprt`](https://github.com/sprt)), [`Microsoft`](https://www.microsoft.com/en-us/). 122 | - `Fupan Li` ([`lifupan`](https://github.com/lifupan)), [`Ant Group`](https://www.antgroup.com/en). 123 | - `Greg Kurz` ([`gkurz`](https://github.com/gkurz)), [`Red Hat`](https://www.redhat.com). 124 | - `Ruoqing He` ([`RuoqingHe`](https://github.com/RuoqingHe)), [`ISCAS`](http://english.is.cas.cn). 125 | - `Steve Horsman` ([`stevenhorsman`](https://github.com/stevenhorsman)), [`IBM`](https://www.ibm.com). 126 | - `Zvonko Kaiser` ([`zvonkok`](https://github.com/zvonkok)), [`NVIDIA`](https://www.nvidia.com). 127 | 128 | Architecture Committee elections take place in the Autumn (3 seats available) and in the Spring (4 seats available). Anyone who has made contributions to the project will be eligible to run, and anyone who has had code merged into the Kata Containers project in the 12 months (a Contributor) before the election will be eligible to vote. There are no term limits, but in order to encourage diversity, no more than 2 of the 7 seats can be filled by any one organization. 129 | 130 | The exact size and model for the Architecture Committee may evolve over time based on the needs and growth of the project, but the governing body will always be committed to openness, diversity and the principle that technical decisions are made by technical Contributors. 131 | 132 | See [the elections documentation](elections) for further details. 133 | 134 | ### Architecture Committee Meetings 135 | 136 | The Architecture Committee meets every Thursday at 1300 UTC. Agenda & call info can be found [here](https://etherpad.opendev.org/p/Kata_Containers_Architecture_Committee_Mtgs). 137 | 138 | In order to efficiently organize the Architecture Committee (AC) meetings, maximize the benefits for the community, and be as inclusive as possible, the AC recommends following a set of [guidelines](AC-Meeting-Guidelines.md) for raising topics during the weekly meetings. 139 | 140 | # Vendoring code 141 | 142 | See the [vendoring documentation](VENDORING.md). 143 | 144 | # Vulnerability Handling 145 | 146 | Vulnerabilities in Kata are handled by the 147 | [Vulnerability Management Team (VMT)](VMT/VMT.md). 148 | There are generally two phases: 149 | - The reporting of a vulnerability to the VMT 150 | - Handling and disclosure of the vulnerability by the VMT 151 | 152 | ## Reporting Vulnerabilities 153 | 154 | Vulnerabilities in Kata should be reported using the 155 | [responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure) model. 156 | 157 | There are two methods available to report vulnerabilities to the Kata community: 158 | 159 | 1) Report via a private issue on the [Kata Containers launchpad](https://launchpad.net/katacontainers.io) 160 | 1) Email any member of the [Kata Containers architecture committee](#architecture-committee) directly 161 | 162 | When reporting a vulnerability via the launchpad: 163 | 164 | - You will need to create a launchpad login account. 165 | - Preferably, but at your discretion, create the report as "Private Security", so the VMT can assess and 166 | respond in a responsible manner. Only the VMT members will be able to view a "Private Security" tagged 167 | issue initially, until it is deemed OK to make it publicly visible. 168 | 169 | ## Vulnerability Disclosure Process 170 | 171 | Vulnerabilities in the Kata Container project are managed by the Kata Containers 172 | Vulnerability Management Team (VMT). Vulnerabilities are managed using a 173 | [responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure) model. 174 | 175 | Details of how to report a vulnerability, the process and procedures 176 | used for vulnerability management, and responsibilities of the VMT members 177 | can be found in the [VMT documentation](VMT/VMT.md). 178 | 179 | Previous Kata Containers Security Advisories are [listed on their own page](VMT/KCSA.md). 180 | 181 | # Week in Review template 182 | 183 | See the [week in review report template](statusreports/REPORT_TEMPLATE.md). 184 | -------------------------------------------------------------------------------- /VENDORING.md: -------------------------------------------------------------------------------- 1 | # Performing vendoring for the Kata Containers project 2 | 3 | * [Vendoring tool](#vendoring-tool) 4 | * [How to install and update `dep`](#how-to-install-and-update-dep) 5 | * [Overview of the main commands](#overview-of-the-main-commands) 6 | * [Vendoring use cases](#vendoring-use-cases) 7 | * [Initialize vendoring of the package](#initialize-vendoring-of-the-package) 8 | * [Pruning non-go files](#pruning-non-go-files) 9 | * [Vendor a newly imported package](#vendor-a-newly-imported-package) 10 | * [Update a vendored package](#update-a-vendored-package) 11 | * [Remove a vendored package](#remove-a-vendored-package) 12 | * [Test a pending pull request](#test-a-pending-pull-request) 13 | * [From the main repository](#from-the-main-repository) 14 | * [From a forked repository](#from-a-forked-repository) 15 | * [Miscellaneous](#miscellaneous) 16 | 17 | ## Vendoring tool 18 | 19 | [`dep`](https://github.com/golang/dep) is the vendoring tool chosen for this 20 | project because it is simple and powerful for some corner cases. Furthermore, 21 | this tool is expected to be the official vendoring tool for Golang. 22 | 23 | Ensure you use the latest version of the `dep` tool. See 24 | [How to install and update `dep`](#how-to-install-and-update-dep) for details. 25 | 26 | ### How to install and update `dep` 27 | 28 | Install or update this tool using the following command: 29 | ```bash 30 | $ go get -u github.com/golang/dep/cmd/dep 31 | ``` 32 | 33 | Make sure your `PATH` contains `$GOPATH/bin`: 34 | ```bash 35 | $ export PATH=$GOPATH/bin:$PATH 36 | ``` 37 | 38 | ### Overview of the main commands 39 | 40 | - `dep init`: Initialize a new project with manifest and lock files. 41 | - `dep ensure`: Ensure a dependency is safely vendored in the project. 42 | 43 | ## Vendoring use cases 44 | 45 | Here will be listed the different vendoring use cases a developer could 46 | encounter when developing for Kata Containers. 47 | 48 | ### Initialize vendoring of the package 49 | 50 | If no prior vendoring has been performed on the package, you need to 51 | initialize it with the following command: 52 | ```bash 53 | $ dep init 54 | ``` 55 | 56 | This should create a new directory named `vendor` at the root of your 57 | package, and two new files to manage the vendoring (i.e. `Gopkg.toml` 58 | and `Gopkg.lock`). 59 | 60 | `Gopkg.lock` is automatically re-generated by `dep` every time a new 61 | `dep ensure` command is issued. This file should not be modified by the 62 | developer. 63 | `Gopkg.toml` is automatically generated by `dep init` and can be modified 64 | in order to add a constraint on a package to follow a specific revision. 65 | 66 | The following is what `Gopkg.toml` should look like: 67 | ```toml 68 | # Gopkg.toml example 69 | # 70 | # Refer to https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md 71 | # for detailed Gopkg.toml documentation. 72 | # 73 | # required = ["github.com/user/thing/cmd/thing"] 74 | # ignored = ["github.com/user/project/pkgX", "bitbucket.org/user/project/pkgA/pkgY"] 75 | # 76 | # [[constraint]] 77 | # name = "github.com/user/project" 78 | # version = "1.0.0" 79 | # 80 | # [[constraint]] 81 | # name = "github.com/user/project2" 82 | # branch = "dev" 83 | # source = "github.com/myfork/project2" 84 | # 85 | # [[override]] 86 | # name = "github.com/x/y" 87 | # version = "2.4.0" 88 | # 89 | # [prune] 90 | # non-go = false 91 | # go-tests = true 92 | # unused-packages = true 93 | ``` 94 | 95 | This file contains all the information you need to modify it properly. 96 | 97 | At this point you can vendor any package needed from your code. 98 | 99 | ### Pruning non-go files 100 | 101 | `dep` provides the feature to remove all non-go files from your vendor tree 102 | during its prune phase. By default this is not enabled, but generally for 103 | Kata Containers repositories, we do enable this feature. If possible, modify your 104 | `[prune]` section to enable this feature: 105 | 106 | ```toml 107 | [prune] 108 | non-go = true 109 | go-tests = true 110 | unused-packages = true 111 | ``` 112 | 113 | ### Vendor a newly imported package 114 | 115 | The following case describes a situation when you add new code that relies 116 | on a package that has never been imported (e.g. `github.com/foo/bar`): 117 | ```bash 118 | $ dep ensure 119 | ``` 120 | 121 | At this point, only the required files will be copied into `vendor`. 122 | 123 | Additionally, you might want to ensure the vendored package refers to a 124 | specific version. This is called a constraint with `dep`. By modifying 125 | `Gopkg.toml`, you can decide to force the package `github.com/foo/bar` to 126 | point to the revision `f5742cb6`. The following is what the file should look 127 | like: 128 | ```toml 129 | [[constraint]] 130 | name = "github.com/foo/bar" 131 | revision = "f5742cb6" 132 | ``` 133 | 134 | Or, if you want to point to a specific version `1.2.4`: 135 | ```toml 136 | [[constraint]] 137 | name = "github.com/foo/bar" 138 | version = "1.2.4" 139 | ``` 140 | 141 | Or, if you want to point to a specific branch `work-dev`: 142 | ```toml 143 | [[constraint]] 144 | name = "github.com/foo/bar" 145 | branch = "work-dev" 146 | ``` 147 | 148 | Lastly, a powerful constraint is to specify if the source of the repository 149 | comes from a forked repository: 150 | ```toml 151 | [[constraint]] 152 | name = "github.com/foo/bar" 153 | branch = "fork-work-dev" 154 | source = "github.com/myfork/bar" 155 | ``` 156 | 157 | __Note:__ Constraining a package is important because this is the only way to 158 | be certain of the imported package version. This prevents any build failure 159 | that could result from a package change on the upstream. 160 | 161 | ### Update a vendored package 162 | 163 | The following case describes a situation where you add some code that relies 164 | on another version of a package already vendored. This is a simple case since 165 | the package is already part of the vendoring. You modify `Gopkg.toml` by 166 | updating the vendoring version: 167 | 168 | ```diff 169 | --- Gopkg.toml.orig 2018-01-23 09:04:54.160760426 -0800 170 | +++ Gopkg.toml.new 2018-01-23 09:05:09.164094911 -0800 171 | @@ -1,3 +1,3 @@ 172 | [[constraint]] 173 | name = "github.com/foo/bar" 174 | - revision = "f5742cb6" 175 | + revision = "a4be45c7" 176 | ``` 177 | 178 | Let `dep` update the vendoring by relying on this new revision: 179 | ```bash 180 | $ dep ensure 181 | ``` 182 | 183 | ### Remove a vendored package 184 | 185 | The following case describes a situation where you modify the existing 186 | code, no longer relying on a vendored package. Running the usual commands 187 | removes the vendored package from `vendor` directory and from 188 | `Gopkg.lock`: 189 | ```bash 190 | $ dep ensure 191 | ``` 192 | 193 | If a constraint is set in `Gopkg.toml`, it is your responsibility to remove 194 | the constraint manually from the file. 195 | 196 | ### Test a pending pull request 197 | 198 | The following case describes a situation where you need to perform testing 199 | on your code due to a pending pull request from a vendored package. 200 | The easiest and safest way to do that is to rely on a feature proposed 201 | by `dep` called `override`. This feature allows you to leave the constraints 202 | unmodified, but relies on a different version of the vendored package for 203 | testing purposes. 204 | 205 | #### From the main repository 206 | 207 | The pending pull request can be submitted to the main repository through a 208 | development branch `work-dev`. In this case, you will need to modify 209 | `Gopkg.toml` as follows: 210 | 211 | ```diff 212 | --- Gopkg.toml.orig 2018-01-23 09:04:54.160760426 -0800 213 | +++ Gopkg.toml.new 2018-01-23 09:06:49.735633780 -0800 214 | @@ -1,3 +1,7 @@ 215 | [[constraint]] 216 | name = "github.com/foo/bar" 217 | revision = "f5742cb6" 218 | + 219 | +[[override]] 220 | + name = "github.com/foo/bar" 221 | + branch = "work-dev" 222 | ``` 223 | 224 | #### From a forked repository 225 | 226 | The pending pull request can be submitted to a forked repository through a 227 | development branch called `work-dev`. In this case you will need to modify 228 | `Gopkg.toml` as follows: 229 | 230 | ```diff 231 | --- Gopkg.toml.orig 2018-01-23 09:04:54.160760426 -0800 232 | +++ Gopkg.toml.new 2018-01-23 09:09:58.475261707 -0800 233 | @@ -1,3 +1,8 @@ 234 | [[constraint]] 235 | name = "github.com/foo/bar" 236 | revision = "f5742cb6" 237 | + 238 | +[[override]] 239 | + name = "github.com/foo/bar" 240 | + branch = "work-dev" 241 | + source = "github.com/myfork/bar" 242 | ``` 243 | 244 | The previous case is more common because typically you do not have permissions 245 | to push directly to the main repository. 246 | 247 | ## Miscellaneous 248 | 249 | For additional information about vendoring, see 250 | "[Re-vendor PRs](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#re-vendor-prs)". 251 | -------------------------------------------------------------------------------- /VMT/KCSA.md: -------------------------------------------------------------------------------- 1 | # Kata Containers Security Advisories 2 | 3 | * [Kata Containers Security Advisories](#kata-containers-security-advisories) 4 | * [KCSA summary](#kcsa-summary) 5 | * [Determine Kata Containers version](#determine-kata-containers-version) 6 | * [Upgrade](#upgrade) 7 | 8 | ## KCSA summary 9 | 10 | This table lists all previously published Kata Containers Security Advisories ([KCSA]'s), newest first: 11 | 12 | | Date | [KCSA] | Affected Versions | Description | 13 | | ---------- | -------------------------------------------------- | ------------------ | --------------------------------------------------- | 14 | | 2020-12-03 | [KCSA-CVE-2020-27151](KCSA/KCSA-CVE-2020-27151.md) | < 1.11.5 | Executing host binaries using annotations | 15 | | 2020-11-17 | [KCSA-CVE-2020-28914](KCSA/KCSA-CVE-2020-28914.md) | < 1.11.5 | Improper file permissions for read-only volumes | 16 | | 2020-06-12 | [KCSA-CVE-2020-2026](KCSA/KCSA-CVE-2020-2026.md) | < 1.10.5, < 1.11.1 | Improper link resolution before file access | 17 | | 2020-06-12 | [KCSA-CVE-2020-2023](KCSA/KCSA-CVE-2020-2023.md) | < 1.11.1 | Execution with unnecessary privileges | 18 | | 2020-05-28 | [KCSA-CVE-2020-2025](KCSA/KCSA-CVE-2020-2025.md) | < 1.11.0 | Cloud Hypervisor guest image persists vulnerability | 19 | | 2020-05-28 | [KCSA-CVE-2020-2024](KCSA/KCSA-CVE-2020-2024.md) | < 1.11.0 | Improper link resolution vulnerability | 20 | | 2019-02-22 | [KCSA-CVE-2019-5736](KCSA/KCSA-CVE-2019-5736.md) | *not applicable* | `runc` container breakout | 21 | 22 | ## Determine Kata Containers version 23 | 24 | To determine which version of Kata Containers you are running, see the 25 | [upgrading document](https://github.com/kata-containers/kata-containers/blob/2.0-dev/docs/Upgrading.md#determine-current-version). 26 | 27 | ## Upgrade 28 | 29 | If you are running a version of Kata Containers affected by one or more [KCSA]'s, 30 | you are strongly encouraged to upgrade as soon as possible: 31 | 32 | - [Kata 1.x upgrading document](https://github.com/kata-containers/documentation/blob/master/Upgrading.md) 33 | - [Kata 2.x upgrading document](https://github.com/kata-containers/kata-containers/blob/2.0-dev/docs/Upgrading.md) 34 | 35 | 36 | [KCSA]: https://github.com/kata-containers/community/blob/master/VMT/VMT.md#acronyms 37 | -------------------------------------------------------------------------------- /VMT/KCSA/KCSA-CVE-2019-5736.md: -------------------------------------------------------------------------------- 1 | announcement-date: 2019-02-22 2 | 3 | id: KCSA-CVE-2019-5736 4 | 5 | title: CVE-2019-5736 `runc container breakout` assessment 6 | 7 | description: Impact of CVE-2019-5736 on Kata Containers 8 | 9 | potentially-affected-components: 10 | 11 | - components: `kata-agent` 12 | version: all 13 | 14 | vulnerabilities: 15 | 16 | - CVE-ID: CVE-2019-5736 17 | 18 | reporters: 19 | 20 | - name: `Graham Whaley` 21 | affiliation: VMT member 22 | reported: 23 | - Original report seen on dev@opencontainers.org 24 | - `oss-sec` posting: https://seclists.org/oss-sec/2019/q1/119 25 | - MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736 26 | 27 | issues: 28 | 29 | links: 30 | - https://github.com/kata-containers/community/issues/85 31 | 32 | reviews: 33 | - no fix required. No PR raised. 34 | 35 | reproduce: 36 | - Exploit does not effect Kata Containers. 37 | 38 | notes: 39 | - The CVE-2019-5736 does not affect Kata Containers. Kata Containers does use the 40 | runc libcontainer library as part of its `kata-agent` to launch container workloads, but 41 | the `kata-agent` executable is a permanently running application within the Kata Containers 42 | VM. Thus, the exit/re-execute cycle utilised by CVE-2019-5736 to execute the injected code 43 | is never undertaken. 44 | - It should be noted, if the exploit had escaped from the `kata-agent`, the exploit code 45 | would have been executing inside the Kata Containers VM as root, and would not have direct 46 | access to either the host system or other container/pods. 47 | - It is highly likely Kata Containers will vendor in and adopt all relevant libcontainer updates 48 | and changes, but given the "copying" nature of some fixes, a performance and resource impact 49 | review will be undertaken. 50 | -------------------------------------------------------------------------------- /VMT/KCSA/KCSA-CVE-2020-2023.md: -------------------------------------------------------------------------------- 1 | announcement-date: 2020-06-12 2 | 3 | id: KCSA-CVE-2020-2023 4 | 5 | title: Kata Containers Execution with Unnecessary Privileges 6 | 7 | description: A container can access the guest root file system device. 8 | This can be used to gain code execution on the guest and masquerade as `kata-agent`. 9 | 10 | affected-components: 11 | 12 | - components: `kata-agent` 13 | version: Before v1.11.1 14 | 15 | vulnerabilities: 16 | 17 | - CVE-ID: CVE-2020-2023 18 | 19 | reporters: 20 | 21 | - name: `Yuval Avrahami` 22 | affiliation: `Palo Alto Networks` 23 | reported: 24 | - CVE-2020-2023 25 | 26 | issues: 27 | 28 | links: 29 | - https://github.com/kata-containers/agent/issues/791 30 | - https://github.com/kata-containers/runtime/issues/2476 31 | - https://github.com/kata-containers/runtime/issues/2488 32 | 33 | reviews: 34 | 35 | v1.11.1: 36 | - https://github.com/kata-containers/agent/pull/792 37 | - https://github.com/kata-containers/runtime/pull/2477 38 | - https://github.com/kata-containers/runtime/pull/2487 39 | 40 | type: GitHub 41 | 42 | reproduce: 43 | 44 | - A malicious container can create a device file for the guest root filesystem 45 | device, and use it to modify the guest filesystem through utilities 46 | like [`debugfs`](https://linux.die.net/man/8/debugfs), potentially allowing 47 | a container-to-guest breakout: 48 | 49 | 1. Find the guest root filesystem device major and minor numbers by inspecting `/sys/dev/block`. 50 | 2. Use`mknod` to create a device file for the guest root filesystem device. 51 | 3. Use utilities such as `debugfs` to access the device file and modify the guest filesystem. 52 | 4. Attempt to gain code execution on the guest by overwriting crucial guest files (e.g. `kata-agent`, `libc`) 53 | 54 | When the guest filesystem is mounted with [DAX](https://www.kernel.org/doc/Documentation/filesystems/dax.txt), 55 | it's easier for the container to gain guest code execution. With DAX, 56 | changes made to the device immediately propagate to the pages used by guest 57 | processes. This means the container can inject code to guest processes by 58 | modifying the executables and libraries used by them. 59 | 60 | Without DAX, the malicious container can force changes made to the device to 61 | propagate to guest pages by exhausting memory, forcing the guest kernel to 62 | re-read the pages from the compromised device. The attack may fail if the 63 | container memory is limited by cgroups. 64 | 65 | notes: 66 | - The vulnerability can be used to compromise the guest and masquerade 67 | as the `kata-agent`. To exploit the issue, the container must 68 | possess `CAP_MKNOD` capability. 69 | All users are recommended to upgrade to mitigate guest breakout. 70 | -------------------------------------------------------------------------------- /VMT/KCSA/KCSA-CVE-2020-2024.md: -------------------------------------------------------------------------------- 1 | announcement-date: 2020-05-28 2 | 3 | id: KCSA-CVE-2020-2024 4 | 5 | title: Kata Containers improper link resolution vulnerability 6 | 7 | description: An improper link resolution vulnerability affects Kata Containers 8 | versions prior to 1.11.0. Upon container teardown, a malicious guest can trick 9 | the `kata-runtime` into unmount any mount point on the host and all mount 10 | points underneath it, potentiality resulting in a host DoS. 11 | 12 | affected-components: 13 | 14 | - components: `kata-runtime` 15 | version: Before v1.11.0 16 | 17 | vulnerabilities: 18 | 19 | - CVE-ID: CVE-2020-2024 20 | 21 | reporters: 22 | 23 | - name: `Yuval Avrahami` 24 | affiliation: `Palo Alto Networks` 25 | reported: 26 | - CVE-2020-2024 27 | 28 | issues: 29 | 30 | links: 31 | - https://github.com/kata-containers/runtime/issues/2474 32 | 33 | reviews: 34 | 35 | v1.11.0: 36 | - https://github.com/kata-containers/runtime/pull/2475 37 | 38 | type: GitHub 39 | 40 | reproduce: 41 | - When Kata Containers is configured with overlay2 as the storage driver, the 42 | attack follows the steps below (all actions are executed by the malicious 43 | guest): 44 | 1. Rename `/run/kata-containers/shared/containers/${ctr-id}` to `/run/kata-containers/shared/containers/${ctr-id}_original_` 45 | 2. Then, recreate `/run/kata-containers/shared/containers/${ctr-id}` 46 | 3. Create a `symlink` to the host target mount named `/run/kata-containers/shared/containers/${ctr-id}/rootfs` 47 | 48 | For devicemapper: 49 | 1. Unmount `/run/kata-containers/shared/containers/${ctr-id}` 50 | 2. Create a `symlink` to the host target mount named `/run/kata-containers/shared/containers/${ctr-id}/rootfs` 51 | 52 | notes: 53 | - The vulnerability can be used to attack the host by malicious containers 54 | that find other ways to gain control over the guest. And all users are 55 | recommended to upgrade. 56 | 57 | The unmount operation is done with the MNT_DETACH flag, meaning that mount 58 | points under the target mount will be unmounted as well. Because of that, 59 | if we target ‘/’ in our attack, then the host mounts underneath it (e.g., 60 | `/proc`, `/sys`, etc.) will be unmounted as well, resulting in the host being 61 | non-functional in most scenarios (e.g. being a `kubernetes` node), creating 62 | a Denial of Service. 63 | 64 | On `kubernetes`, a malicious guest can trigger multiple container deletions 65 | by simply killing the container processes running on it. With the default 66 | `kubernetes` restart policy, containers will be removed and recreated. This 67 | process can be repeated by the malicious guest several times to control 68 | multiple unmount operations on the host. 69 | -------------------------------------------------------------------------------- /VMT/KCSA/KCSA-CVE-2020-2025.md: -------------------------------------------------------------------------------- 1 | announcement-date: 2020-05-28 2 | 3 | id: KCSA-CVE-2020-2025 4 | 5 | title: Kata Containers with Cloud Hypervisor guest image persists vulnerability 6 | 7 | description: Kata Containers before 1.11.0 on Cloud Hypervisor persists guest 8 | filesystem changes to the underlying image file on the host. A malicious guest 9 | can overwrite the image file to gain control of all subsequent guest VMs. 10 | Since Kata Containers uses the same VM image file with all VMMs, this issue 11 | may also affect QEMU and Firecracker based guests. 12 | 13 | affected-components: 14 | 15 | - components: `kata-runtime` 16 | version: Before v1.11.0 17 | 18 | vulnerabilities: 19 | 20 | - CVE-ID: CVE-2020-2025 21 | 22 | reporters: 23 | 24 | - name: `Yuval Avrahami` 25 | affiliation: `Palo Alto Networks` 26 | reported: 27 | - CVE-2020-2025 28 | 29 | issues: 30 | 31 | links: 32 | - https://github.com/kata-containers/runtime/issues/2488 33 | 34 | reviews: 35 | 36 | v1.11.0: 37 | - https://github.com/kata-containers/runtime/pull/2487 38 | 39 | type: GitHub 40 | 41 | reproduce: 42 | - Create a Kata Container using Cloud Hypervisor 43 | - Create a new file on the guest rootfs 44 | - View the guest rootfs image on the host and the file can be seen there 45 | 46 | notes: 47 | - The vulnerability can be used to attack other guests by malicious containers 48 | that find other ways to gain control over the guest. And all users running 49 | Kata Containers on top of Cloud Hypervisor are recommended to upgrade. 50 | 51 | When running Kata Containers with Cloud Hypervisor, any change made to root 52 | filesystem device is written to the underlying `.img` file. Since the device 53 | is plugged as read-write, a malicious guest could write to it and the changes 54 | will propagate to the image file on the host. 55 | 56 | Compromising the guest image file allows an attacker to control all 57 | subsequent guests that run that image. Since, by default, the same guest 58 | image file is used by all VMMs (QEMU, Firecracker and Cloud Hypervisor), 59 | the next time any guest is executed, it will be malicious. This immediately 60 | compromises all subsequent container runs. Additionally, it can expose the 61 | host to attacks that require the guest to be malicious from the moment it 62 | boots. 63 | -------------------------------------------------------------------------------- /VMT/KCSA/KCSA-CVE-2020-2026.md: -------------------------------------------------------------------------------- 1 | announcement-date: 2020-06-12 2 | 3 | id: KCSA-CVE-2020-2026 4 | 5 | title: Kata Containers Improper Link Resolution Before File Access 6 | 7 | description: A malicious guest compromised before a container 8 | creation (e.g. a malicious guest image or a guest running multiple containers) 9 | can trick the `kata-runtime` into mounting the untrusted container filesystem 10 | on any host path, potentially allowing for code execution on the host. 11 | This issue affects: Kata Containers 1.11 versions earlier than 1.11.1; 12 | Kata Containers 1.10 versions earlier than 1.10.5. 13 | 14 | affected-components: 15 | 16 | - components: `kata-runtime` 17 | version: Before v1.11.1, v1.10.5 18 | 19 | vulnerabilities: 20 | 21 | - CVE-ID: CVE-2020-2026 22 | 23 | reporters: 24 | 25 | - name: `Yuval Avrahami` 26 | affiliation: `Palo Alto Networks` 27 | reported: 28 | - CVE-2020-2026 29 | 30 | issues: 31 | 32 | links: 33 | - https://github.com/kata-containers/runtime/issues/2712 34 | 35 | reviews: 36 | 37 | v1.11.0: 38 | - https://github.com/kata-containers/runtime/pull/2713 39 | 40 | type: GitHub 41 | 42 | reproduce: 43 | - A malicious guest compromised before a container creation (e.g. a malicious 44 | guest image or a guest running multiple containers) can trick the `kata-runtime` 45 | into mounting the untrusted container filesystem on any host path. 46 | 47 | When Kata Containers is configured with overlay2 as storage driver, 48 | a malicious guest can create a symbolic link in the shared directory at 49 | `/run/kata-containers/shared/containers/${ctrid}/rootfs` to a target directory 50 | on the host. Upon container creation, the `kata-runtime` will be tricked into 51 | bind mounting the container filesystem at the target directory on the host. 52 | 53 | To create the symbolic link the guest must know the container id as it’s a part 54 | of the mount’s target path. The first container in a sandbox is unique in that 55 | regard since its id is the sandbox id, which is known to the guest at the time of the mount. 56 | If a guest is compromised before the first container is added to it (e.g. a malicious guest image), 57 | it can execute the following attack in case of overlay file systems: 58 | 1. The malicious guest receives the `CreateSandbox` message and extracts the sandbox 59 | id from it. The first container id matches the sandbox id and is derived from that message. 60 | 2. The malicious guest creates the malicious symbolic link at the shared directory, 61 | at `/run/kata-containers/shared/containers/${first_ctrid}/rootfs` 62 | 3. The malicious guest returns a response for `CreateSandbox` 63 | 4. Once the `kata-runtime` on the host receives the `CreateSandbox` response, it tries to 64 | bind mount the container image at `/run/kata-containers/shared/sandbox/$sbx_id/${first_ctrid}/rootfs` 65 | 5. The malicious symbolic link redirects the mount operation to the target on the host. 66 | 67 | In case of non initial container images, the guest does not know the container id. 68 | In case of volume mounts and mounts related to platform-specific files such as 69 | `/etc/hosts`, the mounts are performed in the shared directory on paths that are not 70 | known to the guest. The guest would need to win a race condition between 71 | `ensureDestinationExists` function called by `kata-runtime` that creates the file or 72 | directory that is to be mounted on and bind mount done after calling `ensureDestinationExists`. 73 | 74 | Between those steps, the guest must replace the created file or directory 75 | with a symbolic link to a target on the host. 76 | 77 | notes: 78 | - Given that the container image is malicious, the guest can gain code execution 79 | on the host by mounting over directories such as /bin or /lib. Besides code 80 | execution, the host can be DOSed as well (by mounting over crucial directories). 81 | 82 | In the case of overlay2 mounts, once the container engine (e.g. Docker) 83 | removes the container, it might also delete the lower layers of the container 84 | filesystem, rendering the mount done through this attack empty. In the case 85 | of mounting the malicious container image over /bin, if no process tried running 86 | a binary from /bin before the container is removed, then /bin will become empty, 87 | and the attack fails. 88 | To deal with the above, an attacker could target /lib or /lib64, which 89 | contains libraries for dynamically linked binaries such as the `kata-runtime` itself. 90 | Under Docker for example, the `kata-runtime` will most likely be executed 91 | again in the process of spawning a container. The libraries loaded and 92 | executed by the `kata-runtime` process would then be malicious. 93 | 94 | With Kubernetes, there can be multiple containers in a guest, but the first is 95 | always the pause container. An attack redirecting the pause container is limited 96 | to a host DoS since the pause container image isn't malicious. 97 | An attack redirecting container volumes or platform-specific mounts is most 98 | likely limited to a DoS since the content of these mounts isn't malicious. 99 | -------------------------------------------------------------------------------- /VMT/KCSA/KCSA-CVE-2020-27151.md: -------------------------------------------------------------------------------- 1 | announcement-date: 2020-12-03 2 | 3 | id: KCSA-CVE-2020-27151 4 | 5 | title: Some `kata-runtime` annotations can execute arbitrary programs 6 | 7 | description: An insufficient validation of annotations affects Kata Containers 8 | prior to version 1.11.5, making it possible to execute arbitrary programs on the 9 | host. Unless specific filtering of the annotations is performed by the upper 10 | layers of the stack, it makes it possible for a user to send manifests that 11 | instruct `kata-runtime` to execute arbitrary code with the same privilege level as 12 | `kata-runtime` itself. 13 | 14 | affected-components: 15 | 16 | - components: `kata-runtime` 17 | 18 | - version: Before v1.11.5 19 | 20 | vulnerabilities: 21 | 22 | - CVE-ID: [CVE-2020-27151](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-27151) 23 | 24 | reporters: 25 | 26 | - name: `Christophe de Dinechin` 27 | 28 | - affiliation: Red Hat 29 | 30 | - reported: 31 | 32 | - [CVE-2020-27151](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-27151) 33 | 34 | issues: 35 | 36 | links: 37 | 38 | - original report: https://bugs.launchpad.net/katacontainers.io/+bug/1878234 39 | 40 | - version 1.11.4: https://github.com/kata-containers/runtime/issues/3004 41 | 42 | - version 2.0: https://github.com/kata-containers/kata-containers/issues/901 43 | 44 | reviews: 45 | 46 | Embargoed: 47 | 48 | - https://github.com/kata-containers/runtime-CVE-2020-27151/pull/1 49 | 50 | Public review: 51 | 52 | - https://github.com/kata-containers/runtime/pull/3005 53 | 54 | v2.0.0: 55 | 56 | - https://github.com/kata-containers/kata-containers/pull/902 57 | 58 | v1.12.0: 59 | 60 | - https://github.com/kata-containers/runtime/pull/3059 61 | 62 | v1.11.5: 63 | 64 | - https://github.com/kata-containers/runtime/pull/3058 65 | 66 | type: GitHub 67 | 68 | reproduce: 69 | 70 | - When using a Kubernetes with the Kata Containers runtime enabled, starting a 71 | pod with an annotation like the following will execute the binary called 72 | `/usr/local/bin/hello` and pass it arguments `arg1` and `arg2`. 73 | 74 | ``` 75 | io.katacontainers.config.hypervisor.virtio_fs_daemon: "/usr/local/bin/hello" 76 | io.katacontainers.config.hypervisor.virtio_fs_extra_args: "[ \"arg1\", \"arg2\" ]" 77 | ``` 78 | 79 | - As an illustration, passing `/usr/sbin/shutdown` as the binary name and `-h`, 80 | `now` as the arguments will shutdown the host machine instead of executing 81 | the container. 82 | 83 | notes: 84 | 85 | - The annotation corresponding to the `virtiofsd` path is the most susceptible 86 | to be exploited that way, because another annotation makes it possible to 87 | pass parameters to the binary being executed. 88 | 89 | - This vulnerability has been fixed in releases 1.12.0, 1.11.5 and 2.0 branch. 90 | The fixed versions provide annotation filters that can be configured by a 91 | system administrator, listing the names that are allowed for each of the 92 | binaries that `kata-runtime` is susceptible to launch. Additional filtering 93 | was added for the paths of host system files that `kata-runtime` needs to 94 | access, such as the location of the `/dev/random` device. 95 | -------------------------------------------------------------------------------- /VMT/KCSA/KCSA-CVE-2020-28914.md: -------------------------------------------------------------------------------- 1 | announcement-date: 2020-11-17 2 | 3 | id: KCSA-CVE-2020-28914 4 | 5 | title: Kata Containers Improper file permissions for read-only volumes 6 | 7 | description: An improper file permissions vulnerability affects Kata Containers 8 | prior to 1.11.5. When using a Kubernetes host-path volume and mounting 9 | either a file or directory into a container as readonly, the file/directory 10 | is mounted as read-only inside the container, but is still writable inside 11 | the guest. For a container breakout situation, a malicious guest can 12 | potentially modify or delete files/directories expected to be read-only. 13 | 14 | affected-components: 15 | 16 | - components: `kata-runtime` 17 | version: Before v1.11.5 18 | 19 | vulnerabilities: 20 | 21 | - CVE-ID: CVE-2020-28914 22 | 23 | reporters: 24 | 25 | - name: `Alex Chapman` 26 | affiliation: Independent Researcher 27 | reported: 28 | - CVE-2020-28914 29 | 30 | issues: 31 | 32 | links: 33 | - https://github.com/kata-containers/runtime/issues/3041 34 | - https://github.com/kata-containers/kata-containers/issues/1061 35 | 36 | reviews: 37 | 38 | v2.0.0: 39 | - https://github.com/kata-containers/kata-containers/pull/1062 40 | 41 | v1.12.0: 42 | - https://github.com/kata-containers/runtime/pull/3048 43 | 44 | v1.11.5: 45 | - https://github.com/kata-containers/runtime/pull/3051 46 | 47 | type: GitHub 48 | 49 | reproduce: 50 | 51 | - When using a Kubernetes host-path volume and mounting either a file or 52 | directory into a container with read-only: true, the file/directory is 53 | mounted as read-only inside the container, but is still writable inside 54 | the guest (but outside of the container). 55 | 56 | In case a container breakout were to occur, a malicious guest will be able to 57 | modify or delete files and directories that are expected to be read-only inside 58 | the guest. 59 | 1. Start a pod with a host-path volume passed as read-only to a container within the pod. 60 | 2. Start a debug shell to get root access within the guest and attempt 61 | to write to the read-only volume shared with the guest under 62 | `/run/kata-containers/shared/sandboxes/{pod-id}/{volume}/` 63 | 3. Though the volume is not writable within the container, the guest will be 64 | able to write to the volume or even delete it. 65 | 66 | notes: 67 | 68 | - If the read-only files/directories are shared across multiple 69 | pods on the same node, other pods will be able to see the modified/deleted files/directories. 70 | This vulnerability has been fixed in releases 1.12.0, 1.11.5 and 2.0 branch. 71 | 72 | -------------------------------------------------------------------------------- /VMT/VMT-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kata-containers/community/6023dab06b23e26e953804c476b69bf44d9371f2/VMT/VMT-process.png -------------------------------------------------------------------------------- /VMT/templates/KCSA.md: -------------------------------------------------------------------------------- 1 | # Kata Containers security advisory (KCSA) template 2 | 3 | The template used to construct the KCSA attached to a VMT Launchpad bug, and later 4 | potentially published. 5 | 6 | ``` 7 | announcement-date: YYYY-MM-DD 8 | 9 | id: KCSA-$NUM 10 | 11 | title: '$TITLE' 12 | 13 | description: '$DESCRIPTION_CONTENT' 14 | 15 | affected-components: 16 | 17 | - components: $COMPONENTS 18 | version: $AFFECTED_VERSIONS 19 | 20 | vulnerabilities: 21 | 22 | - cve-id: $CVE 23 | 24 | reporters: 25 | 26 | - name: '$CREDIT' 27 | affiliation: $CREDIT_AFFILIATION 28 | reported: 29 | - $CVE 30 | 31 | issues: 32 | 33 | links: 34 | - https://github.com/kata-containers/$COMPONENT/issues/$ISSUE_NR 35 | 36 | reviews: 37 | 38 | v1.2.3: 39 | - https://github.com/kata-containers/$COMPONENT/pull/$PR_NUMBER 40 | 41 | v2.3.4: 42 | - https://github.com/kata-containers/$COMPONENT/pull/$PR_NUMBER 43 | 44 | type: GitHub 45 | 46 | reproduce: 47 | - 'Any information on how to reproduce or verify if a system is affected' 48 | 49 | notes: 50 | - 'Optional note such as cross project version requirements, 51 | or details on how to reproduce and check for the vulnerability' 52 | ``` 53 | 54 | Once approved, the request will be added to the documentation repo and linked from the KCSA index page. It will then be emailed out. 55 | We send two separate emails, to avoid off-topic replies to `oss-security` list: 56 | 57 | ``` 58 | - To: 59 | - To: 60 | ``` 61 | 62 | Subject and content for both emails is identical: 63 | 64 | ``` 65 | - Subject: `\[KCSA-$NUM\] $TITLE ($CVE)` 66 | - Body: The KCSA markdown document 67 | ``` 68 | 69 | Notes: 70 | 71 | - Email must be GPG-signed. 72 | - $CVE must always be of the form CVE-YYYY-XXXX 73 | - $NUM is of the form YYYY-XX 74 | 75 | -------------------------------------------------------------------------------- /VMT/templates/KCSN.md: -------------------------------------------------------------------------------- 1 | # Kata Containers Security Note (KCSN) template 2 | 3 | Title (single sentence) 4 | --- 5 | 6 | ### Summary ### 7 | A few sentences describing the issue at a high level. 8 | 9 | ### Affected Services / Software ### 10 | A comma separated list of affected Kata components and releases. 11 | 12 | ### Discussion ### 13 | A detailed discussion of the problem. This should have enough detail 14 | that the person reading can determine if their deployment is affected, 15 | when the problem was introduced, and what types of attacks/problems that 16 | an affected deployment would be exposed to. 17 | 18 | ### Recommended Actions ### 19 | A detailed description of what can be done to remediate the problem (if 20 | possible). If the recommendation involves configuration changes, 21 | example snippets of configuration files should be included here. 22 | 23 | ### Contacts / References ### 24 | Author: 25 | This KCSN : 26 | Original Launchpad Bug : 27 | Mailing List : [Security] tag on kata-dev@lists.katacontainers.io 28 | CVE: 29 | -------------------------------------------------------------------------------- /VMT/templates/cve-request-email-private.md: -------------------------------------------------------------------------------- 1 | # CVE request email (private issues) template 2 | 3 | ``` 4 | - To: CNA 5 | - Subject: CVE request for vulnerability in Kata Containers $COMPONENTS 6 | 7 | A vulnerability was discovered in Kata Containers (see below). In order to 8 | ensure full traceability, we need a CVE number assigned that we can attach 9 | to private and public notifications. 10 | Please treat the following information as confidential until further public 11 | disclosure. 12 | 13 | $DESCRIPTION 14 | 15 | Thanks in advance, 16 | 17 | -- 18 | $VMT_COORDINATOR_NAME 19 | Kata Containers Vulnerability Management Team 20 | ``` 21 | 22 | Email must be GPG-signed and GPG-encrypted. 23 | -------------------------------------------------------------------------------- /VMT/templates/cve-request-email-public.md: -------------------------------------------------------------------------------- 1 | # CVE request email (public issues) template 2 | 3 | ``` 4 | - To: 5 | - Cc: 6 | - Subject: CVE request for vulnerability in Kata Containers $COMPONENTS 7 | 8 | A vulnerability was discovered in Kata Containers (see below). In order to 9 | ensure full traceability, we need a CVE number assigned that we can attach 10 | to further notifications. 11 | This issue is already public, although an advisory was not sent yet. 12 | 13 | $DESCRIPTION 14 | 15 | References: 16 | https://github.com/kata-containers/$COMPONENT/issues/$ISSUE_NR 17 | 18 | Thanks in advance, 19 | 20 | -- 21 | $VMT_COORDINATOR_NAME 22 | Kata Containers Vulnerability Management Team 23 | ``` 24 | 25 | Email must be GPG-signed but not encrypted. 26 | 27 | -------------------------------------------------------------------------------- /VMT/templates/downstream-stakeholder-notification.md: -------------------------------------------------------------------------------- 1 | # Downstream stakeholders notification email (private issues) template 2 | 3 | We send two separate emails, to avoid off-topic replies to Linux-distros: 4 | 5 | ``` 6 | - To: 7 | - To: 8 | ``` 9 | 10 | Subject and content for both emails is identical: 11 | 12 | ``` 13 | - *Subject:* \[pre-KCSA\] Vulnerability in Kata Containers $COMPONENTS ($CVE) 14 | 15 | This is an advance warning of a vulnerability discovered in 16 | Kata Containers, to give you, as downstream stakeholders, a chance to 17 | coordinate the release of fixes and reduce the vulnerability window. 18 | Please treat the following information as confidential until the 19 | proposed public disclosure date. 20 | 21 | $DESCRIPTION 22 | 23 | Proposed patch: See attached patches. 24 | Unless a flaw is discovered in them, these patches will be merged to 25 | their corresponding branches on the public disclosure date. 26 | 27 | CVE: $CVE 28 | 29 | Proposed public disclosure date/time: 30 | YYYY-MM-DD, 0000UTC 31 | Please do not make the issue public (or release public patches) 32 | before this coordinated embargo date. 33 | 34 | Original private report: 35 | https://bugs.launchpad.net/katacontainers.io/+bug/$NNNNNN 36 | For access to read and comment on this report, please reply to me 37 | with your Launchpad username and I will subscribe you. 38 | -- 39 | $VMT_COORDINATOR_NAME 40 | Kata Containers Vulnerability Management Team 41 | ``` 42 | 43 | Proposed patches are attached, email must be GPG-signed. 44 | Use something unique and descriptive for the patch attachment file names, for example `cve-2013-4183-master-agent.patch` or `cve-2013-4183-stable-1.2.1-agent.patch`. 45 | -------------------------------------------------------------------------------- /VMT/templates/impact-description.md: -------------------------------------------------------------------------------- 1 | # Impact description ($DESCRIPTION) template 2 | 3 | ``` 4 | Title: $TITLE 5 | Reporter: $CREDIT 6 | Projects: $COMPONENTS 7 | Affects: $AFFECTED_VERSIONS 8 | 9 | Description: 10 | $CREDIT reported a vulnerability in [project feature name]. 11 | By doing [action] a [actor] may [impact] resulting in [consequence]. 12 | Only [project deployment mode] are affected. 13 | ``` 14 | 15 | The AFFECTED_VERSIONS needs to stay valid after the fix is released. 16 | For example, when v1.2.1 and v1.3.2 are still security supported, the AFFECTED_VERSIONS of should read like this: 17 | 18 | ``` 19 | Affects: >=v1.2.0 <=v1.2.1, >=v1.3.2 <=v1.3.2 20 | ``` 21 | 22 | Once v1.2.x reaches end of life, that line becomes: 23 | 24 | ``` 25 | Affects: >=v1.3.2 <=v.1.3.2 26 | ``` 27 | 28 | If the oldest version affected is not easily identified, leave it open-ended: 29 | 30 | ``` 31 | Affects: <=v1.2.1 and ==v1.3.2 32 | ``` 33 | -------------------------------------------------------------------------------- /VMT/templates/reception-embargo-reminder.md: -------------------------------------------------------------------------------- 1 | # Reception embargo reminder (private issues) template 2 | 3 | ``` 4 | This issue is being treated as a potential security risk under embargo. 5 | Please do not make any public mention of embargoed (private) security 6 | vulnerabilities before their coordinated publication by the Kata 7 | Containers Vulnerability Management Team in the form of an official 8 | Kata Containers Security Advisory. This includes discussion of the bug 9 | or associated fixes in public forums such as mailing lists, code review 10 | systems and bug trackers. Please also avoid private disclosure to other 11 | individuals not already approved for access to this information, and 12 | provide this same reminder to those who are made aware of the issue 13 | prior to publication. All discussion should remain confined to this 14 | private bug report, and any proposed fixes should be added to the bug 15 | as attachments. 16 | ``` 17 | -------------------------------------------------------------------------------- /VMT/templates/reception-incomplete-message.md: -------------------------------------------------------------------------------- 1 | # Reception incomplete message (unconfirmed issues) template 2 | 3 | ``` 4 | Since this report concerns a possible security risk, an incomplete 5 | security advisory task has been added while the core security 6 | reviewers for the affected project or projects confirm the bug 7 | and discuss the scope of any vulnerability along with potential 8 | solutions. 9 | ``` 10 | -------------------------------------------------------------------------------- /elections/README.md: -------------------------------------------------------------------------------- 1 | * [Kata Containers Elections](#kata-containers-elections) 2 | * [Architecture Committee Elections](#architecture-committee-elections) 3 | * [Election Dates](#election-dates) 4 | * [Electorate](#electorate) 5 | * [Candidacy](#candidacy) 6 | * [Architecture Committee Responsibilities](#architecture-committee-responsibilities) 7 | * [System](#system) 8 | * [Previous elections](#previous-elections) 9 | 10 | # Kata Containers Elections 11 | 12 | This repository contains Kata Containers Elections reference documents 13 | and tooling to run elections. 14 | 15 | # Architecture Committee Elections 16 | 17 | The Kata Architecture Committee is comprised of seven seats, elected by the 18 | eligible community, and one Committee Chair, selected by the five 19 | Architecture Committee members. 20 | 21 | ## Election Dates 22 | 23 | The Architecture Committee elections take place every six months, as 24 | outlined in the 25 | [Architecture Committee section](https://github.com/kata-containers/community#architecture-committee) 26 | of the Community README. 27 | 28 | The election process begins three calendar weeks prior to the election. 29 | - One week for candidates to submit their candidacy 30 | - One week "debate period" for electorate to pose questions on the community 31 | mailing lists to learn the candidates platforms 32 | - One week for voting 33 | - Results announced 34 | 35 | ## Electorate 36 | 37 | [Contributors](https://github.com/kata-containers/community#contributor) 38 | (defined as anyone who has had code merged in the Kata Containers 39 | project in the last 12 months prior to the first day of the nomination period) 40 | are eligible to vote in Architecture Committee elections. 41 | 42 | ## Candidacy 43 | 44 | Anyone who has made contributions to the Kata Containers project is eligible 45 | to run. Candidates submit their candidacy by adding a text file to the 46 | corresponding election folder under the community repo with their interest 47 | and platform, and announcing their candidacy on the [community developer mailing 48 | list](http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev). 49 | 50 | There are no term limits for Architecture Committee seats, but in order to 51 | encourage diversity, no more than two of the five seats may be filled by 52 | members with the same company affiliation. If a third member would be in 53 | violation of the diverse affiliation rule, the seat is awarded to the next 54 | highest scoring candidate who would not violate the rule. Members who change 55 | affiliation between elections in a way that violates the diverse affiliation 56 | rule are not required to relinquish their seat, however, the rule will 57 | be enforced and applied in the following election. 58 | 59 | ## Architecture Committee Responsibilities 60 | 61 | Architecture Committee members guide the technical direction of the Kata 62 | Containers project. This includes, but is not limited to: 63 | - Serving the Kata technical community 64 | - Driving technical direction 65 | - Handling interactions with other governance bodies 66 | - Acting as the final call in technical disputes 67 | - Ensuring inclusive, open collaboration and development 68 | - Identifying gaps in technical direction or community health 69 | - Attending Architecture Committee meetings 70 | - Regular participation (and advanced notice of absences) in online 71 | Arch Committee meetings and in-person meetings is expected 72 | - Actively participates in Kata Containers design and development 73 | - Not restricted to code contributions, but active input and guidance 74 | is expected 75 | 76 | ## System 77 | 78 | The Architecture Committee election uses 79 | [CIVS with Condorcet method voting](https://civs.cs.cornell.edu/). 80 | You can find information about how to set up the voting on the 81 | related [OpenStack wiki](https://wiki.openstack.org/wiki/Election_Officiating_Guidelines#Running_the_election_itself). 82 | 83 | Due to CIVS policy, to vote in private CIVS polls, everyone in the 84 | electorate must opt in to email communication. CIVS has a 85 | [dedicated page](https://civs1.civs.us/cgi-bin/opt_in.pl) to register 86 | the email address they are using on GitHub. Once someone has 87 | opted into receiving e-mail from CIVS it should allow future 88 | ballots from any poll to be sent to the same e-mail address. 89 | 90 | ## Tools 91 | 92 | See the [election tools documentation](tools). 93 | 94 | ## Process 95 | 96 | See the [election process documentation](process) for details on 97 | the process that election officials need to follow to successfully 98 | execute the AC election. 99 | 100 | ## Current elections 101 | 102 | - April 2025 103 | - [election](arch-committee-2025-04) 104 | - [results](arch-committee-2025-04/Results.md) 105 | 106 | ## Previous elections 107 | 108 | - October 2024 109 | - [election](arch-committee-2024-10) 110 | - [results](arch-committee-2024-10/Results.md) 111 | 112 | - April 2024 113 | - [election](arch-committee-2024-04) 114 | - [results](arch-committee-2024-04/Results.md) 115 | 116 | - October 2023 117 | - [election](arch-committee-2023-10) 118 | - [results](arch-committee-2023-10/Results.md) 119 | 120 | - April 2023 121 | - [election](arch-committee-2023-04) 122 | - [results](arch-committee-2023-04/Results.md) 123 | 124 | - November 2022 125 | - [election](arch-committee-2022-11) 126 | - [results](arch-committee-2022-11/Results.md) 127 | 128 | - March 2022 129 | - [election](arch-committee-2022-03) 130 | - [results](arch-committee-2022-03/Results.md) 131 | 132 | - September 2021 133 | - [election](arch-committee-2021-09) 134 | - [results](arch-committee-2021-09/Results.md) 135 | 136 | - February 2021 137 | - [election](arch-committee-2021-02) 138 | - [results](arch-committee-2021-02/Results.md) 139 | 140 | - September 2020 141 | - [election](arch-committee-2020-09) 142 | - [results](arch-committee-2020-09/Results.md) 143 | 144 | - February 2020 145 | - [election](arch-committee-2020-02) 146 | - [results](arch-committee-2020-02/Results.md) 147 | 148 | - September 2019 149 | - [election](arch-committee-2019-09) 150 | - [results](arch-committee-2019-09/Results.md) 151 | 152 | - March 2019 153 | - [election](arch-committee-2019-03) 154 | - [results](arch-committee-2019-03/Results.md) 155 | 156 | - September 2018 157 | [election](arch-committee-2018-09) 158 | -------------------------------------------------------------------------------- /elections/arch-committee-2018-09/2018-09-Results.txt: -------------------------------------------------------------------------------- 1 | Architecture Committee Election 2 | September 10, 2018 3 | 4 | Results: 5 | 1) Eric Ernst (egernst) 6 | 2) Wei Zhang (WeiZhang555) 7 | 3) Jon Olson (jon) -------------------------------------------------------------------------------- /elections/arch-committee-2018-09/EricErnst.txt: -------------------------------------------------------------------------------- 1 | Name: Eric Ernst 2 | 3 | Email: eric.ernst@intel.com 4 | 5 | Background: 6 | 7 | I am a senior software engineer in Intel's Open Source Technology Center, acting both as a contributor 8 | as well as a technical lead for the Intel-team contributing to Kata Containers. Before Kata, I spent time working 9 | on Clear Containers, and prior to that spent a few years working on Linux kernel. 10 | 11 | Since the initial discussions of creating Kata started I have been an active contributor and advocate for the 12 | project, both in code and in the greater Kata community/ecosystem. While I do work within 13 | a silicon company, one of my primary goals for helping guide Kata has been developing a neutral and 14 | diverse contribution base. Aside from having a stable, compatible, and viable technical basis for the 15 | project, I think a healthy and robust community is key to sustained success. 16 | 17 | For me, working with end-users to understand use cases and seeing how Kata can be part of their solution 18 | is very exciting. I think this will be a big part of Kata as we continue to move forward. In addition, 19 | continued focus on scaling, ecosystem integration, performance, security and stability will be key to meeting 20 | user needs. I've also been focusing on making sure Kata fits into Kubernetes and the rest of the ecosystem, which 21 | Has been evolving over time. There is a lot to focus on! 22 | 23 | The journey to Kata 1.2 has been great, and I look forward to continuing to contribute to the project. 24 | -------------------------------------------------------------------------------- /elections/arch-committee-2018-09/JonOlson.txt: -------------------------------------------------------------------------------- 1 | Name: Jon Olson 2 | 3 | Email: jonolson@google.com 4 | 5 | Background: 6 | 7 | I am a staff software engineer at Google working on the core virtualization and 8 | I/O layer backing Google Compute Engine. My work is focused on resource 9 | footprint minimization as well as performance optimization and stability. Part 10 | of this work is improving our support for containerized workloads and ensuring 11 | it is aligned with the needs of our customer community (e.g., Kata users). 12 | 13 | My involvement with the Kata community has included being a regular attendee at 14 | the weekly Kata Arch Council meetings. To these meetings I’ve brought context 15 | from my work building and maintaining a hypervisor that supports long-lived 16 | workloads at scale, as well as the occasional PR for getting Kata running in 17 | GCE. I believe whole workload containment via virtualization is a key component 18 | to addressing the broad problem of container security. Having a strong, open 19 | solution to that problem is critical to ensuring all workloads can run 20 | securely, regardless of where they are deployed. 21 | 22 | I enjoy working with the Kata community to build such a solution, and look 23 | forward to many more core-hours of security contained workloads. 24 | -------------------------------------------------------------------------------- /elections/arch-committee-2018-09/KalyXin.txt: -------------------------------------------------------------------------------- 1 | Kata-containers Architecture Committee Candidacy Declaration 2 | 3 | Platform: Arm 4 | 5 | Candidate: Kaly Xin 6 | 7 | I'm working for Arm Electronic Technology (Shanghai) Co.Ltd. 8 | This candidacy is representing Arm company to be voted for one seat of the 9 | Kata-container architecture committee. 10 | 11 | My current role is Senior Engineering Manager in the Open Source Software Group 12 | and I lead a team working on virtualization and container technology on the Arm 13 | platform. I have more than 10 years of experience in virtualization, especially 14 | for hardware virtualization development including KVM and Xen. After that, I 15 | transferred focus to OS virtualization and container development. 16 | 17 | In recent years, my team started development on RunV project, one of the 18 | predecessors to Kata-containers, to enable and enhance the multi-arch support. 19 | Our focus areas included KVMtool support, performance profiling of the network 20 | and storage devices for virtual machines, and we also worked on stability and 21 | density improvements. For example, we identified a networking performance gap 22 | and improved throughput by 10x on both Arm and x86 platforms. Another example, 23 | we proposed and modified the synchronization mechanism between the hyperstart 24 | thread and VM. These and other contributions were all merged in RunV upstream. 25 | Some of them are already in Kata-container project too. 26 | 27 | For these collaborations, there were public blogs announced at 28 | https://blog.hyper.sh/arm_and_hyper.html and 29 | https://community.arm.com/iot/b/blog/posts/arm-and-hyper-hq-will-push-runv-for-the-future-of-container-security. 30 | We have met regularly with Hyper team to discuss the development issues and solutions 31 | of the project. 32 | 33 | When RunV evolved into kata-containers, we transferred our effort into this 34 | new joint project and contribute to it as ever. Initially, We found it couldn't 35 | run successfully with multi-arch as before, lots of current test cases and CI 36 | environment setting up are not for multi-arch in the first stage. We start to 37 | fix the compatibility issues for different architectures. We are also working on the 38 | public CI support for mutli-arch to ensure the ongoing reliability and stability 39 | of the project. During the process, we feel this new joint project is very open, 40 | friendly and full of vitality as before. That's so great to work in the community! 41 | 42 | Interests: 43 | 44 | We believe this is just the beginning for the Kata-containers project and that it 45 | will have much broader applicability across different architectures and use 46 | cases, especially within the emerging next-generation IoT and 5G era! These 47 | different use cases will generate new design requirements of the underlying 48 | architecture and we believe strongly that good multi-architecture support will 49 | be essential to position Kata-containers for broad adoption throughout the cloud 50 | native ecosystem. 51 | We look forward to driving these changes together, so the Kata-containers project 52 | can reach its full potential! 53 | 54 | -------------------------------------------------------------------------------- /elections/arch-committee-2018-09/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: September 2018 2 | 3 | There are three Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Wei Zhang`, `Tim Allclair`, and `Jessie Frazelle`. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * August 20, 1500 UTC - August 27, 2018 14:59 UTC: Candidate nominations open 12 | * August 27, 1500 UTC - September 3, 2018 14:59 UTC: Q&A/Debate period 13 | * September 3, 1500 UTC - September 10, 2018 14:59 UTC: Voting open 14 | * Week of September 11, 2018, results announced 15 | 16 | -------------------------------------------------------------------------------- /elections/arch-committee-2018-09/WeiZhang.txt: -------------------------------------------------------------------------------- 1 | Name: Wei Zhang 2 | 3 | Email: zhangwei555@huawei.com 4 | 5 | Introduction: 6 | 7 | I am now working as a Senior Engineer in Huawei Corporation, 8 | leading a team which is responsible for providing container solutions based on 9 | K8s/docker/kata-containers to other departments and Huawei Public Cloud. 10 | 11 | I was once a docker developer and now is an active kata contributor, and has been 12 | Architecture Committee Member for about eight months. Kata Containers is a great 13 | project which can help reduce some security concerns comparing to native container 14 | solution, and I don't think I need more words to elaborate how great it is because 15 | I believe all the readers of this file are familiar enough to Kata. :-) 16 | 17 | So I wish to renew my seat, and do more work to help kata community 18 | to make excellent open source project, and then make better product based on 19 | Kata to our customers. 20 | 21 | -------------------------------------------------------------------------------- /elections/arch-committee-2019-03/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: March 2019 2 | 3 | There are two Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Xu Wang` and `Samuel Ortiz`. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * February 12, 1500 UTC - February 17, 2019 14:59 UTC: Candidate nominations open 12 | * February 18, 1500 UTC - February 24, 2019 14:59 UTC: Q&A/Debate period 13 | * February 25, 1500 UTC - March 3, 2019 14:59 UTC: Voting open 14 | * Week of March 4, 2019, results announced 15 | 16 | -------------------------------------------------------------------------------- /elections/arch-committee-2019-03/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: March 2019 2 | 3 | Two nominations were received for the March 2019 elections: 4 | 5 | - [`Samuel Ortiz`](https://github.com/sameo) 6 | - [`Xu Wang`](https://github.com/gnawux) 7 | 8 | As the number of applications matched the number of available seats, the 9 | question and voting phases of the elections were bypassed, and the two 10 | applicants were (re-)admitted to the Architecture Committee on 2019-02-19 11 | for another 12 month term. 12 | -------------------------------------------------------------------------------- /elections/arch-committee-2019-03/SamuelOrtiz.txt: -------------------------------------------------------------------------------- 1 | Name: Samuel Ortiz 2 | 3 | Email: samuel.ortiz@intel.com 4 | 5 | Background: 6 | 7 | I am a software engineer at Intel where I work on different projects 8 | related to virtualization and containers: rust-vmm, NEMU and Kata 9 | Containers. I have been involved with Kata Containers for about 3 years 10 | now, as I started to work on what used to be Clear Containers before the 11 | 2.0 release. I was part of the small OSF-Hyper-Intel team that worked 12 | together to merge Clear Containers and runV into what today is Kata 13 | Containers. 14 | 15 | I deeply believe that Kata Containers is a key project for the cloud 16 | native ecosystem. Thanks to an ever growing community effort, we moved 17 | it from two diverging code bases to something that can now be deployed 18 | at scale. In order to reach that state we built a very versatile software 19 | architecture that can adapt to a large number of use cases. On one hand 20 | this architecture really put hardware virtualized container runtimes in 21 | the cloud native map, but on the other hand it added complexity and in 22 | some cases technical debt to our project. With new specifications and 23 | APIs (runtimeClass, containerd shim v2) truly taking vm based runtimes 24 | into account, I think it's time for us to work on simplifying and 25 | cleaning our feature bloat and push that into Kata Containers v2. 26 | This is what I'd like to focus on for the next few months and this is 27 | one of the main reason why I'd like to renew my seat at the 28 | Architecture Committee. 29 | -------------------------------------------------------------------------------- /elections/arch-committee-2019-03/XuWang.txt: -------------------------------------------------------------------------------- 1 | Name: Xu Wang 2 | 3 | Email: xu@hyper.sh 4 | 5 | Background: 6 | 7 | I am the CTO of hyper.sh, leading the Hyper team contributing to Kata Containers and related communities. 8 | Before Kata, our team and I worked on runV, which is one of the predecessors of Kata Containers. It was 9 | my great honor to involve the creating of the Kata Containers project and became a initial member of 10 | the Architecture Committee together with Samual Ortiz. 11 | 12 | After having Kata Containers announced, more and more people began to consider the container security as 13 | a solvable problem and several open source secure container runtime projects were released in the past 14 | year. And Kata Containers is becoming the de facto standard: we have had better integration with containerd 15 | via shimv2, and the better CRI-O integration is on its way; we have had more hypervisors support, such as 16 | firecracker and NEMU. 17 | 18 | For me, I focused on kubernetes integration efficiency and boot-time related topics in the past months, and 19 | had an eye on runtime benchmarks, multi-architecture support as well. In the future, I will pay more attention 20 | to both the runtime development and the documentation to help users to adopt Kata Containers. 21 | 22 | -------------------------------------------------------------------------------- /elections/arch-committee-2019-09/EricErnst.txt: -------------------------------------------------------------------------------- 1 | Name: Eric Ernst 2 | 3 | Email: eric.ernst@intel.com 4 | 5 | Background: 6 | 7 | I am a senior software engineer in Intel's Open Source Technology Center, acting both as a contributor 8 | as well as a technical lead for the Intel-team contributing to Kata Containers. Before Kata, I spent time working 9 | on Clear Containers, and prior to that spent a few years working on Linux kernel. 10 | 11 | Since the initial discussions of creating Kata started I have been an active contributor and advocate for the 12 | project, both in code and in the greater Kata community/ecosystem. While I do work within 13 | a silicon company, one of my primary goals for helping guide Kata has been developing a neutral and 14 | diverse contribution base. Aside from having a stable, compatible, and viable technical basis for the 15 | project, I think a healthy and robust community is key to sustained success. 16 | 17 | Over the last year, I have served as a member of the Kata Containers architecture committee. The project has 18 | matured a lot over the last year, with expanding production usage and user-base. Despite this, we still have a lot of room 19 | for development, continuing to improve our density and security profile, all while providing improved manageability 20 | and serviceability for users who are deploying Kata. Beyond this work, we will need to focus on attaining and addressing 21 | input from end-users, as well as adapting to and influencing the cloud native ecosystem. 22 | 23 | In other words, we still have a lot of fun work to do! I look forward to continuing to contribute to the project. 24 | -------------------------------------------------------------------------------- /elections/arch-committee-2019-09/HaominTsai.txt: -------------------------------------------------------------------------------- 1 | Name: Haomin Tsai 2 | 3 | Email: caihaomin@huawei.com 4 | 5 | Introduction: 6 | 7 | I am now working as a Senior Engineer in Huawei Corporation, leading a technical team 8 | to provide container solutions for other departments in our Corporation and Huawei Public Cloud. 9 | We focus on docker/containerd/kata-containers/linux kernel and other infrastructure technology. 10 | I am now working on Kunpeng Arch which based on arm64 extended. 11 | 12 | Before Kata, I was a docker/contaienrd developer and spent time working on operating system. 13 | In the early days of Kata's establishment, I participated in it. After that my team and I wishes 14 | to make a good product for more users. 15 | Last year, our product Huawei Cloud Container Instance(aka CCI) which based on Kata has a rapid growth. 16 | After this period of practice, we truely believe that Kata is really a good solution in production. 17 | We extended the use of the scene based on Kata and enhanced the scene 18 | including genetic calculation, AI calculation, CDN, big data and so on. 19 | 20 | Talking about community, a good community makes both developers and users comfortable. 21 | And I think Kata is one of these communitiesm, beyond this Kata even is going to become 22 | the cornerstone of cloud computing, not only in serverless/multi-tenant scene, 23 | but also in more general scenes. 24 | 25 | Next I want to talk a little about future. If I can be honored to take one of the seats, 26 | my goals are composed of two parts: 27 | First part, I want to promote our production practice which will make users more comfortable. 28 | Second part, our team are now working on Kunpeng Arch, 29 | and I think we have a further work to do for Kata based on Kunpeng. 30 | 31 | I hope I can get this seat and make contribution to the community. 32 | 33 | ^_^ 34 | 35 | BR~ 36 | Haomin 37 | 38 | 39 | 40 | -------------------------------------------------------------------------------- /elections/arch-committee-2019-09/JustinHe.txt: -------------------------------------------------------------------------------- 1 | Kata-containers Architecture Committee Candidacy Declaration 2 | 3 | Platform: Arm 4 | 5 | Candidate: Justin He 6 | 7 | I'm working for Arm Electronic Technology (Shanghai) Co.Ltd. 8 | This candidacy is representing Arm company to be voted for one seat of the 9 | Kata-container architecture committee. 10 | 11 | My current role is Staff Engineering in the Open Source Software Group and I 12 | am working on virtualization and container technology on the Arm 13 | platform. I have more than 10 years of experience in low level Linux software 14 | development, especially for linux kernel [1], DPDK on arm64 [2] and hardware 15 | virtualization development including KVM and qemu [3]. 16 | [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Jia+he 17 | [2] http://dpdk.org/browse/dpdk/log/?qt=author&q=Jia+He 18 | [3] https://git.qemu.org/qemu.git/?p=qemu.git&a=search&h=HEAD&st=author&s=jia+he 19 | 20 | In recent years, our team started development on RunV project, one of the 21 | predecessors to Kata-containers, to enable and enhance the multi-arch support. 22 | Our focus areas included KVMtool support, performance profiling of the network 23 | and storage devices for virtual machines, and we also worked on stability and 24 | density improvements. For example, our team enabled the memory hotplug support, 25 | vm template on Kata-containers project. As for virtio-fs support on arm64, we 26 | fixed a lot issues on persistent memory and DAX support. 27 | 28 | For these collaborations, there were public blogs announced at [4] and [5] 29 | [4] https://blog.hyper.sh/arm_and_hyper.html 30 | [5] https://community.arm.com/iot/b/blog/posts/arm-and-hyper-hq-will-push-runv-for-the-future-of-container-security. 31 | We have met regularly with Hyper team to discuss the development issues and 32 | solutions of the project. 33 | 34 | For conference presentation, our team members once attended Denver 2019 summit 35 | as speakers [4]: 36 | https://www.openstack.org/videos/summits/denver-2019/kata-containers-on-arm-lets-talk-about-our-progress 37 | 38 | Interests: 39 | We believe Kata-containers is a fast developping project and that it 40 | will have much broader applicability across different architectures and use 41 | cases, especially within the emerging next-generation IoT and 5G era! These 42 | different use cases will generate new design requirements of the underlying 43 | architecture and we believe strongly that good multi-architecture support will 44 | be essential to position Kata-containers for broad adoption throughout the cloud 45 | native ecosystem. 46 | 47 | We look forward to driving these changes together, so the Kata-containers project 48 | can reach its full potential! 49 | 50 | Cheers, 51 | Justin (Jia He) 52 | -------------------------------------------------------------------------------- /elections/arch-committee-2019-09/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: September 2019 2 | 3 | There are three Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Eric Ernst` @egernst, `Wei Zhang` @WeiZhang555 and `Jon Olson` @jon. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * September 3, 2019, elections officials confirmed: @raravena80 @lifupan @chavafg 12 | * September 3, 1500 UTC - September 12, 2019 14:59 UTC: Candidate nominations open 13 | * September, 12 1500 UTC - September 20, 2019 14:59 UTC: Q&A/Debate period 14 | * September 20, 1500 UTC - September 27, 2019 14:59 UTC: Voting open 15 | * Week of September 30, 2019, results announced 16 | -------------------------------------------------------------------------------- /elections/arch-committee-2019-09/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: September 2019 2 | 3 | Three nominations were received for the March 2019 elections: 4 | 5 | - [`Eric Ernst`](https://github.com/sameo) 6 | - [`Xaomin Tsai`](https://github.com/jshachm) 7 | - [`Justin He`](https://github.com/justin-he) 8 | 9 | As the number of applications matched the number of available seats, the 10 | question and voting phases of the elections were bypassed, and the two 11 | applicants were admitted to the Architecture Committee on 2019-09-12 12 | for another 12 month term. 13 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-02/DaveGilbert.txt: -------------------------------------------------------------------------------- 1 | Name: David Alan Gilbert 2 | 3 | Email: dgilbert@redhat.com 4 | 5 | Introduction: 6 | 7 | I'm a Principal Software Engineer working for Red Hat in our 8 | virtualization team. I've been working on QEMU for the past 9 | 6 years, mostly in live migration but more recently working 10 | on the virtiofs project. I'm a QEMU maintainer for live migration, 11 | virtiofs and the HMP monitor. 12 | 13 | My previous work with Kata has mainly been in relation to 14 | virtiofs and helping debug CI issues on Red Hat/CentOS and Fedora. 15 | 16 | My primary interest is ensuring that hypervisors (QEMU included) 17 | provide the necessary features to enable Kata to operate securely 18 | and efficiently. 19 | 20 | I'm keen to understand the real-world uses of Kata, how virtiofs is used 21 | in practice and resolving any usage difficulties in those deployments. 22 | 23 | I look forward to promoting the wider usage of Kata and pushing its 24 | usage in the general enterprise and more specialist areas such as 25 | telecommunication systems. 26 | 27 | Dave (IRC: davidgiluk) 28 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-02/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: February 2020 2 | 3 | There are two Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Xu Wang` and `Samuel Ortiz`. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * February 5, 1500 UTC - February 12, 2020 14:59 UTC: Candidate nominations open 12 | * February 13, 1500 UTC - February 23, 2020 14:59 UTC: Q&A/Debate period 13 | * February 24, 1500 UTC - March 1, 2020 14:59 UTC: Voting open 14 | * Week of March 2, 2020, results announced 15 | 16 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-02/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: February 2020 2 | 3 | Three nominations were received for the February 2020 elections: 4 | 5 | - [`David Alan Gilbert`](https://github.com/dagrh) 6 | - [`Samuel Ortiz`](https://github.com/sameo) 7 | - [`Xu Wang`](https://github.com/gnawux) 8 | 9 | Two seats were available, so elections were held. 10 | 11 | The nominees elected to the positions were: 12 | 13 | - [`Samuel Ortiz`](https://github.com/sameo) 14 | - [`Xu Wang`](https://github.com/gnawux) 15 | 16 | The two members were (re-)admitted to the Architecture Committee on 2020-03-02 17 | for another 12 month term. 18 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-02/SamuelOrtiz.txt: -------------------------------------------------------------------------------- 1 | Name: Samuel Ortiz 2 | 3 | Email: sameo@linux.intel.com 4 | 5 | Background: 6 | 7 | I am a Principal Software Engineer working for Intel, where I work on several 8 | projects related to virtualization and containers: Kata Containers, rust-vmm 9 | and Cloud Hypervisor. 10 | 11 | My journey with the Kata Containers project started back when I initially lead 12 | the Clear Containers project at Intel, a few years ago. Since then I have 13 | contributed to many different areas of the project, from core components like 14 | the virtcontainers package to integration work with the CRI-O and containerd 15 | projects. I was part of the initial Clear Container and RunV engineering 16 | efforts to merge the two projects and have been on the Kata Containers 17 | Architecture Committee since then. 18 | 19 | Over the past few months we've seen Kata Containers being deployed in several 20 | very large production environments, showing how strong and scalable the 21 | project has become. Such large deployments also bring new requirements for 22 | security, density and performance that we, as a community, need to look at 23 | and meet. I believe this can only be achieved with Kata supporting new security 24 | models and virtualization technologies, losing a few abstraction layers and 25 | features, and being more tightly integrated with the Cloud Native ecosystem. 26 | This is what I want to help push through Kata Containers 2.0, and this is why 27 | I'd like to renew my seat on the Kata Architecture Committee. 28 | 29 | Samuel. 30 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-02/XuWang.txt: -------------------------------------------------------------------------------- 1 | Name: Xu Wang 2 | 3 | Email: xu@hyper.sh, gnawux@antfin.com 4 | 5 | Background: 6 | 7 | I am a senior staff engineer of Ant Financial, a related company of Alibaba Group (BABA). I am leading 8 | the secure container development team in Ant Financial currently and working for the Cloud-Native 9 | open-source of Alibaba as a member of the Ali Open Source TOC. Our team has been working on not only 10 | contributing upstream, but also deploying Kata Containers in the productions since we joined Ant Financial. 11 | 12 | Before joining Ant Financial, Our team, the hyper.sh, had been keep contributing to Kata Containers 13 | and related communities since the day 0 of Kata. It was my great honor to involve the creating of the 14 | Kata Containers project and became a initial member of the Architecture Committee together with Samual Ortiz. 15 | 16 | In the past months, we celebrated the two year anniversary of Kata. Look back at the past two years, we have 17 | improved the isolation in the container world at the expense of some overhead. We believe the container world 18 | needs a better isolation solution without hurts on the application-centric nature of Cloud-Native. In 2020, 19 | I expect we could developing the virtualization technologies for Cloud Native in the 2.0 development cycle. 20 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-09/ArchanaShinde.txt: -------------------------------------------------------------------------------- 1 | Name: Archana Shinde 2 | 3 | Email: archana.m.shinde@intel.com 4 | 5 | Background: 6 | 7 | I am a software engineer at Intel working on Cloud technologies and have been an active contributor on the Kata Containers project since it's inception. I have been engaged in various aspects of the project from the initial design to driving its adoption in production use cases. I am invested in the open source community we have built over the years around the project and am very interested in pushing the project forward towards greater adoption. 8 | 9 | Over the years, I have played an active role in contributing towards the project code base as well as advocating the project in the greater open source community at various container events. In terms of code, I have made solid contributions towards implementing networking and storage solutions in Kata to make sure Kata works well with the rest of the container ecosystem. Some of the contributions I have made overs the years include implementing tcfilter and macvtap networking models, ipv6 networking stack support, integration with various CNI plugins, support for devicemapper leveraging block-based storage, as well as adding in support for time-synchronization to make sure we get meaningful traces with Kata among others. I have also contributed towards integration of Kata with container runtimes such as crio and making sure Kata meets e2e testing criteria with kubernetes. 10 | 11 | Going forward, we have quite a bit of exciting features coming up in the project including cloud hypervisor support, switch to virtio-fs from 9p and improved debuggability to name a few. I am interested in driving these forward as well as seeing through integration of Kata with other open source solutions stacks. 12 | I look forward to working on Kata's continuing success! 13 | 14 | -Archana Shinde 15 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-09/EricErnst.txt: -------------------------------------------------------------------------------- 1 | Name: Eric Ernst 2 | 3 | Email: eric.ernst@apple.com 4 | 5 | Background: 6 | 7 | I am a senior software engineer at Apple, focused on cloud infrastructure, and despite a couple of exciting employer changes this year, 8 | I continue to be very interested in this project, and engaged in the Kata community as a contributor. 9 | 10 | Since the initial discussions of creating Kata started I have been an active contributor and advocate for the 11 | project, both in code and in the greater Kata community/ecosystem. I am running again as I am very interested in this project's success in 12 | the ecosystem, and am focused on making sure Kata continues to be a production-ready solution for providing stronger container isolation. 13 | 14 | Over the last two years, I have served as a member of the Kata Containers architecture committee. As I stated last year, the project has 15 | matured a lot, with expanding production usage and user-base. Even more so now, we have a lot of important changes this year: 16 | Cloud Hypervisor VMM support, PodOverhead support in Kubernetes, cgroups-v2 support, cpuset support, rust-agent support, improved telemetry/observability, 17 | virtio-fs support. Each of these are important improvements that make the project more attractive and viable for production use cases. 18 | 19 | We still have a lot of interesting work to do, and I look forward to continuing to contribute to the project. 20 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-09/FabianoFidencio.txt: -------------------------------------------------------------------------------- 1 | Name: Fabiano Fidêncio 2 |   3 | Email: fabiano@fidencio.org 4 |   5 | Background: 6 |   7 | I am a Senior Software Engineer working for Red Hat's virtualization team, a 8 | tattoo canvas for abstract art, a music addict, and a big fan of old video 9 | games. 10 |   11 | In the past 6 months I have been dedicating a big chunk of my time contributing 12 | and helping to make the Kata Containers project solid across different 13 | communities, such as Fedora, CentOS, and CRI-O, supporting Kata Containers 14 | exposure and adoption in the enterprise Linux world. 15 | 16 | My involvement with Kata Containers has been quite intense in this period, 17 | from providing simple patches, doing code reviews on pretty much all 18 | components, fixing issues not only on Kata Containers but also in the 19 | communities surrounding the project, to becoming a point of contact for Fedora, 20 | CentOS, and RHEL related issues, always focusing on what could benefit the 21 | project and its community. 22 | 23 | To keep improving Kata Containers adoption, I recently became the CRI-O 24 | maintainer for the VM runtime type (used together with the "shim v2") and I am 25 | and will be enforcing Kata Containers play well also with one of the most 26 | widely used container runtimes in the Kubernetes ecosystem. 27 | 28 | My primary interest is to ensure that Kata Containers can be used in enterprise 29 | Linux solutions, which can be achieved by improving stability, debuggability, 30 | and out-of-the-box usage, everything done as a symbiotic process with an 31 | organic growth. Enforcing this growth will fundamentally benefit this community 32 | and the communities around this one. 33 | 34 | In order to make it possible, I plan to continue working in the integration 35 | bits, while keeping connecting and facilitating the communication between the 36 | Kata Containers community and the communities that both Red Hat and I are part 37 | of. 38 | 39 | The contributions I have participated in and I am the most proud to mention 40 | are: 41 | 42 | * Out-of-the-box virtio-fs support on Fedora, and CentOS; 43 | * Helping with the SELinux support on Kata Containers, CRI-O, and 44 | container-selinux projects; 45 | * Helping to educate & to onboard colleagues to the project, assisting them so 46 | they can get up to speed to start contributing with different pieces and also 47 | to become part of this community; 48 | * Helping to lower the maintenance burden by dropping OBS package builds in 49 | favor of kata-deploy usage (still in progress). 50 | 51 | Fabiano Fidêncio (IRC / Slack: fidencio) 52 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-09/JustinHe.txt: -------------------------------------------------------------------------------- 1 | Kata-containers Architecture Committee Candidacy Declaration 2 | 3 | Platform: Arm 4 | 5 | Candidate: Justin He 6 | 7 | I'm working for Arm Electronic Technology (Shanghai) Co.Ltd. 8 | This candidacy is representing Arm company to be voted for one seat of the 9 | Kata-container architecture committee. 10 | 11 | My current role is Principal Engineering in the Open Source Software Group and I 12 | am working on virtualization and container technology on the Arm platform. I 13 | have more than 10 years of experience in low level Linux software development, 14 | especially for linux kernel and hardware virtualization development including 15 | KVM and qemu. 16 | 17 | In recent years, our team started development on: 18 | - Enablement the Kata runtime for arm64 19 | - CI maintenance for Kata arm64 20 | - firecracker arm64 support 21 | - Cloud hypervisor arm64 enablement 22 | - Kubernetes integration test on arm64 23 | - Optimize the performance of Kata runtime/agent/vmm/kernel 24 | 25 | We believe Kata-containers is a fast developping project and that it will have 26 | much broader applicability across different architectures and use cases, 27 | especially within the emerging next-generation IoT and 5G era! These 28 | different use cases will generate new design requirements of the underlying 29 | architecture and we believe strongly that good multi-architecture support will 30 | be essential to position Kata-containers for broad adoption throughout the cloud 31 | native ecosystem. We still have strong interests in the future of Kata project 32 | and will keep enabling and tuning Kata in many aspects. 33 | 34 | We look forward to driving these changes together, so the Kata-containers project 35 | can reach its full potential! 36 | 37 | Cheers, 38 | Justin (Jia He) 39 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-09/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: September 2020 2 | 3 | There are three Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Eric Ernst`, `Xaomin Tsai` and `Justin He`. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * September 8 - Election officials confirmed: @Ricardo and @Fupan 12 | * September 9, 1500 UTC - September 17, 2020 14:59 UTC: Candidate nominations open 13 | * September 18, 1500 UTC - September 27, 2020 14:59 UTC: Q&A/Debate period 14 | * September 28, 1500 UTC - October 4, 2020 14:59 UTC: Voting open 15 | * October 5:results announced 16 | -------------------------------------------------------------------------------- /elections/arch-committee-2020-09/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: September 2020 2 | 3 | Four nominations were received for the September 2020 elections: 4 | 5 | - [`Archana Shinde`](https://github.com/amshinde) 6 | - [`Eric Ernst`](https://github.com/egernst) 7 | - [`Fabiano Fidêncio`](https://github.com/fidencio) 8 | - [`Justin He`](https://github.com/justin-he) 9 | 10 | Three seats were available, so elections were held. 11 | 12 | The nominees elected to the positions were: 13 | 14 | - [`Archana Shinde`](https://github.com/amshinde) 15 | - [`Eric Ernst`](https://github.com/egernst) 16 | - [`Fabiano Fidêncio`](https://github.com/fidencio) 17 | 18 | Congratulations to our new architecture committee members Fabiano and Archana and our continuing member Eric! 19 | 20 | -------------------------------------------------------------------------------- /elections/arch-committee-2021-02/PengTao.txt: -------------------------------------------------------------------------------- 1 | Name: Peng, Tao 2 | 3 | Email: bergwolf@hyper.sh, bergwolf@antgroup.com 4 | 5 | Background: 6 | 7 | Peng Tao is a staff engineer of Ant Group. In Ant Group, we have large deployments of Kubernetes 8 | and about 10K nodes of them are running Kata containers. Our team is responsible for the runtime 9 | and cloud-native storage of Ant Group. 10 | 11 | Peng Tao, toegther with Xu and other teammates, used to be the dev team of hyper.sh. The team was 12 | one of the creators of Kata Containers, and has kept working on Kata Containers since joining 13 | Ant Group. When the Kata Containers project was created, Peng Tao committed the first commit for it: 14 | 15 | https://github.com/kata-containers/proxy/commit/94a07ff010b80fad8235278032d0b58927d4f1d5 16 | 17 | And he was known as the release manager of the Kata 2.0 as well. 18 | 19 | In 2021, Ant Group has joined the Open Infrastructure and become a member of the board of directors. 20 | We commit our team will keep working with the Kata Community for the following release cycles. 21 | 22 | -------------------------------------------------------------------------------- /elections/arch-committee-2021-02/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: February 2021 2 | 3 | There are two Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Xu Wang` and `Samuel Ortiz`. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * February 24, 15:00 UTC - March 10, 2021 14:59 UTC: Candidate nominations open 12 | * March 11, 15:00 UTC - March 22, 2021 14:59 UTC: Q&A/Debate period 13 | * March 23, 15:00 UTC - March 29, 2021 14:59 UTC: Voting open 14 | * March 30, 2021, results announced 15 | -------------------------------------------------------------------------------- /elections/arch-committee-2021-02/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: February 2021 2 | 3 | Two nominations were received for the February 2021 elections: 4 | 5 | - [`Peng Tao`](https://github.com/bergwolf) 6 | - [`Samuel Ortiz`](https://github.com/sameo) 7 | 8 | Two seats were available, so elections were over sooner. 9 | 10 | The two members were (re-)admitted to the Architecture Committee on 2021-03-10 11 | for another 12 month term. 12 | -------------------------------------------------------------------------------- /elections/arch-committee-2021-02/SamuelOrtiz.txt: -------------------------------------------------------------------------------- 1 | Name: Samuel Ortiz 2 | 3 | Email: sameo@linux.intel.com 4 | 5 | Background: 6 | 7 | I am a Principal Software Engineer working for Intel, where I work on several 8 | projects related to virtualization and containers: Kata Containers, rust-vmm 9 | and Cloud Hypervisor. 10 | 11 | I started to work on Kata Containers a few years ago, back when I initially led 12 | the Clear Containers project at Intel. Since then I have contributed to many 13 | different areas of the project, from core components like the virtcontainers 14 | package to integration work with the CRI-O and containerd projects. 15 | 16 | Together with the folks from hyper.sh, we began the Kata Containers journey 17 | with the ambitious goal of providing stronger isolation to cloud native 18 | workloads, with minimal overhead. Three years ago, this was a fairly innovative 19 | approach and at some point I stopped counting the number of hours that Xu, Eric, 20 | Peng or myself spent at conferences, meetups or foundation booths demonstrating 21 | how Kata Containers met that promise. I believe it is now time to bring the next 22 | generation of hardware isolation and confidentiality technologies to the cloud 23 | native ecosystem, and in the upcoming months I'd like to help the Kata 24 | Containers project reach that goal. 25 | -------------------------------------------------------------------------------- /elections/arch-committee-2021-09/ArchanaShinde.txt: -------------------------------------------------------------------------------- 1 | Name: Archana Shinde 2 | 3 | Email: archana.m.shinde at intel.com 4 | 5 | Background: 6 | 7 | I work as a software engineer at Intel, with my primary focus being on open source technologies for cloud. I would like to announce my candidacy for the Kata Architecture committee elections. I have been deeply involved in the project in the past right from its inception and am very much invested in seeing the project thrive and be widely adopted in the future as well. 8 | 9 | I have been an active contributor in the project in the past assuming ownership of key aspects of the project including networking and storage. I have also been an advocate of the project in the greater open source community at various open source meetups and conferences. I have served as a member of the Kata architecture committee. I continue to be active in engaging with various organizations interested in evaluating Kata, helping them onboard and making sure Kata meets their production use case requirements. 10 | 11 | I have been absent from the project early this year due to personal time off. But I plan to swing back in action and continue my contributions this year:). I am particularly excited and interested in the Confidential Computing use case and would love to contribute my part in enabling this new threat model for Kata customers. 12 | 13 | I look forward to continuing to contribute to the success of Kata Containers! 14 | 15 | -Archana Shinde 16 | -------------------------------------------------------------------------------- /elections/arch-committee-2021-09/EricErnst.txt: -------------------------------------------------------------------------------- 1 | --- 2 | Name: Eric Ernst 3 | Email: eric_ernst at apple dot com 4 | 5 | Background: 6 | 7 | I am a software engineer at Apple, focused on cloud infrastructure, and I continue to be very invested in this project and engaged in the Kata community as a contributor. 8 | 9 | Since the initial discussions of creating Kata started, I have been an active contributor and advocate for the 10 | project, both in code and in the greater Kata community/ecosystem. I am running again as I am very interested in this project's success in the ecosystem, and am very focused on making sure Kata continues to be a stable, production-ready solution for providing stronger container isolation. 11 | 12 | Over the last couple of years, I have served as a member of the Kata Containers architecture committee. As I stated last year, the project has matured a lot, with expanding production usage and user-base. I think there's a lot of exciting work for our primary use cases, still. 13 | 14 | One area is improved integration with CRI/CNI/CSI/Kubelet. In particular, the work around providing VM-friendly devices where feasible, and updating the flow to provide sandbox details to the runtime to facilitate simpler life cycle management. Similarly, we have plenty of work to improve our performance efficiency, in both CPU utilization and memory footprint. 15 | 16 | We also have new use cases that are now feasible with encrypted VM memory becoming more widely available. This is exciting and requires very careful thought for the architecture of our project (and our integration with the rest of the stack) as we continue improving existing stable production use cases while also enabling a totally new threat model. 17 | 18 | We still have a lot of interesting work to do, and I look forward to continuing to contribute to the success of Kata Containers! 19 | 20 | --Eric 21 | 22 | -------------------------------------------------------------------------------- /elections/arch-committee-2021-09/FabianoFidencio.txt: -------------------------------------------------------------------------------- 1 | Name: Fabiano Fidêncio 2 | 3 | Email: fabiano@fidencio.org 4 | 5 | Background: 6 | 7 | I am a Software Engineer, a tattoo canvas for abstract art, a music addict, a 8 | goats and pigs instagram follower, and a big fan of old video games. 9 | 10 | In the past 18 months I dedicated a huge chunk of my professional and personal 11 | time contributing to the Kata Containers project and community, with a strong 12 | focus on helping Red Hat to build a product from the Kata Containers project. 13 | 14 | My involvement with Kata Containers has been intense. I've been involved on 15 | pretty much every part of the project, on projects Kata Containers interacts 16 | with. Moreover, I've already been serving the community as a current member of 17 | the Kata Containers Architecture Committee. 18 | 19 | In the enterprise world, I have worked on making the upstream project a Red 20 | Hat's downstream product, passing by Fedora, CentOS, Red Hat CoreOS, and 21 | OpenShift components. As a result of this effort Red Hat now has an official 22 | product which uses Kata Containers underneath. 23 | 24 | In the community space, I also have helped on a lot of different parts of the 25 | project. connected people to have their problems solved, mentored both 26 | newcomers and students into our community, led Architecture Committee meetings, 27 | led the last vPTG's Kata Containers session. I also went hands-on on CI, 28 | code-reviewing, development focusing on easing the adoption of the project, 29 | managed the past and current releases, and have been working as much as 30 | possible to grow this community in a healthy way. 31 | 32 | My main motivations are still to increase Kata Containers adoption in the 33 | industry, while ensuring the project is stable and easily consumable. This is 34 | more important now than ever as new players are adopting and contributing to 35 | the Kata Containers project. 36 | 37 | To make it possible, I plan to continue working in the integration bits, while 38 | connecting and facilitating the communication between the Kata Containers 39 | community and the communities that I am part of. 40 | 41 | On a side note, I'd like to mention that from November 1st, 2021, I'll be 42 | working for Intel, focusing on the Kata Containers project. 43 | 44 | Fabiano Fidêncio (IRC / Slack: fidencio) 45 | -------------------------------------------------------------------------------- /elections/arch-committee-2021-09/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: September 2021 2 | 3 | There are two Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Archana Shinde`, `Eric Ernst`, and `Fabiano Fidêncio` 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) for election process, declaring candidacy, and eligible voters. 7 | 8 | Election Dates: 9 | 10 | Candidacy open: September 8-16 11 | "Debate period": September 17-27 12 | Voting: September 28 - October 3 13 | Results: October 4 14 | 15 | * September 8, 15:00 UTC - September 16, 2021 14:59 UTC: Candidate nominations open 16 | * September 17, 15:00 UTC - September 27, 2021 14:59 UTC: Q&A/Debate period 17 | * September 28, 15:00 UTC - October 3, 2021 14:59 UTC: Voting open 18 | * October 4, 2021, results announced 19 | -------------------------------------------------------------------------------- /elections/arch-committee-2021-09/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: September 2021 2 | 3 | Three (3) nominations were received for the September 2021 elections: 4 | 5 | - [`Archana Shinde`](https://github.com/amshinde) 6 | - [`Eric Ernst`](https://github.com/egernst) 7 | - [`Fabiano Fidêncio`](https://github.com/fidencio) 8 | 9 | Three (3) seats were available, so elections were over sooner. 10 | 11 | The three members were re-admitted to the Architecture Committee on 2021-09-16 for another 12 month term. 12 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-03/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: March 2022 2 | 3 | There are two Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Peng Tao` and `Samuel Ortiz`. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * March 08, 15:00 UTC - March 15, 2022 14:59 UTC: Candidate nominations open 12 | * March 16, 15:00 UTC - March 23, 2022 14:59 UTC: Q&A/Debate period 13 | * March 24, 15:00 UTC - March 31, 2022 14:59 UTC: Voting open 14 | * April 01, 2022, results announced 15 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-03/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: March 2022 2 | 3 | Two nominations were received for the March 2022 elections: 4 | 5 | - [`Peng Tao`](https://github.com/bergwolf) 6 | - [`Samuel Ortiz`](https://github.com/sameo) 7 | 8 | Two seats were available, so elections were over sooner. 9 | 10 | The two members were (re-)admitted to the Architecture Committee on 2021-03-16 11 | for another 12 month term. 12 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-03/SamuelOrtiz.txt: -------------------------------------------------------------------------------- 1 | Name: Samuel Ortiz 2 | 3 | Email: samuel.e.ortiz@protonmail.com 4 | 5 | Background: 6 | 7 | I am a software engineer at Apple, where I work on container and virtualization 8 | related projects. 9 | 10 | More than 4 years ago, I attended the foundational meeting between us (I was 11 | working at Intel back then), Hyper and the OpenStack Foundation. We merged 12 | Clear Containers and Hyper Runv into what became Kata Containers a few months 13 | later. Even though I've been working on and contributing to many other open 14 | souce projects since then, the excitement I feel about Kata Containers, its 15 | community and its innovation potential, is intact. Running `uname -a` on a 16 | Kata Containers never gets old to me. Especially when the host operating 17 | system is not Linux ;-) 18 | 19 | Over the past year, I dedicated some of my time on a new cloud capability: 20 | Confidential Computing. This is a very disruptive technology, that redefines 21 | and expands the cloud threat model, and I truly believe that Kata Containers 22 | has the potential to become a foundational Confidential Computing software 23 | component. I think that Confidential Computing will eventually become the 24 | default security setting for cloud native applications, and in my mind that 25 | can only happen with the Kata Containers runtime. This is what I want to help 26 | this community achieve over the next couple of years. 27 | 28 | Another recent personal source of excitement for me is the ability to run 29 | Linux containers on top of non Linux host operating systems, like Darwin for 30 | example. This does not come easy, as we have spent all those years assuming 31 | we will always be walking on top of a cozy Linux kernel. In the upcoming 32 | months, I want to break that assumption and use the Darwin enablement as a 33 | forcing function to clean our code base through saner, OS-agnostic 34 | abstractions. 35 | 36 | Finally, I want to confess something: I love writing Rust code. It's not easy 37 | to admit, especially after initially cursing so much at the borrow checker. 38 | But I listened to it and learned, and my appreciation for the language and 39 | its unique features steadily grew to eventually become a favorite of mine. 40 | That's why I'm very excited about us writing a new Rust runtime, taking this 41 | rewrite as an opportunity to build a more integrated and efficient 42 | architecture. I want to make sure that we learn from both our mistakes and 43 | our victories, to build a new code base that synthesizes those learnings. 44 | And at the same time, knowing how steep the Rust learning curve can be, I 45 | also want to keep this new implementation accessible to our community and 46 | contributors. 47 | 48 | Cheers, 49 | Samuel 50 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-03/TaoPeng.txt: -------------------------------------------------------------------------------- 1 | Name: Tao Peng 2 | 3 | Email: bergwolf@hyper.sh, bergwolf@antgroup.com 4 | 5 | Background: 6 | 7 | I am a staff engineer at Ant Group. My primary focus is container 8 | infrastructure related technologies. 9 | 10 | I have been deeply engaged in Kata Containers since the start of the project, 11 | both in development and community. I continue to be very interested in the 12 | project and want to be part of the efforts to ensure its success. I have 13 | served as a member of the Kata architecture committee. And I'm running again in 14 | the new round of the architecture committee election. 15 | 16 | I have been an active contributor in the past in many different areas across the 17 | runtime and the agent. I served as a member of the vulnerability management team, 18 | the review team and the release management team. I also advocated the project in 19 | various open source events, conferences and meetups. 20 | 21 | Within Ant Group, our team is responsible for the large scale Kata Containers 22 | deployment in production. We have been pioneers in new features and new architectures 23 | of Kata. We believe it is very important to bridge production requirements and 24 | upstream development. We have been actively engaged in the upstream development 25 | in the past, and will continue to do so in the future. 26 | 27 | Since its foundation, Kata Containers has matured quite a bit with an expanding 28 | user-base. There are still a lot of exciting things to do. 29 | 30 | One area is better integration in the container ecosystem. It has been a goal of the 31 | project since the very beginning. And the current focus is the improved integration 32 | with CNI/CSI/CRI. We expect to have a more VM-friendly interfaces that will help to 33 | improve our performance and efficiency. 34 | 35 | Another exciting thing is the integrated rust runtime. It continues to innovate 36 | with cloud-native virtualization in mind and makes all Kata components work 37 | tightly together, further reduce Kata's resource overhead and management complexity. 38 | 39 | Last but not least, the Confidential Containers support expands the Kata Containers 40 | threat model from protecting the infrastructure to also protecting the workloads. 41 | It is a very appealing direction and attracts a lot of community interests. 42 | 43 | Kata Containers 3.0 release is paving its way to be a real thing. These features 44 | will certainly be important part of Kata 3.0. I look forward to continuing to 45 | contribute and help the project thrive. 46 | 47 | -Tao 48 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-11/ArchanaShinde.txt: -------------------------------------------------------------------------------- 1 | Name: Archana Shinde 2 | Email: archana.m.shinde@intel.com 3 | 4 | Background: 5 | 6 | I am a software engineer at Intel with a focus on open-source technologies for Cloud. I have been a contributor and maintainer since the very beginning of the project and continue to be engaged in the Kata community. 7 | 8 | I have served on the Kata Containers Architecture committee in the past and would like to announce my candidacy for the upcoming elections so that I can continue to make meaningful contributions to the project in the capacity of Kata AC member. 9 | 10 | In the last few months, I have spent time optimizing Kata performance in terms of storage and network by leveraging multi-queue support. I also introduced support for linux "io-uring" for async IO operations. I continue to track further improvements made both in linux and qemu in this area to bypass some of the virtue-queues and plan to add support for these for both qemu and cloud-hypervisor. I was also involved in helping out the ACRN folks for adding support for ACRN hypervisor to Kata 2.x in terms of code, design and review. Additionally, I made several improvements to the local kata-deploy build process so that all Kata artifacts can be generated locally without any issues in a nested docker setup. 11 | I have started making contributions to the kata-ctl tool in rust and plan to focus my energies on rust support and improving the test coverage for the rust codebase in Kata in the future. Adding rust support for cloud-hypervisor in Kata 3.x would be my primary focus over the next few months. 12 | 13 | I believe we have a lot of interesting features to be added to Kata in the near future and I look forward to play my part in Kata's continued success. 14 | 15 | Thanks, 16 | Archana Shinde 17 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-11/EricErnst.txt: -------------------------------------------------------------------------------- 1 | --- 2 | Name: Eric Ernst 3 | Email: eric_ernst at apple dot com 4 | 5 | Background: 6 | 7 | I am a software engineer at Apple, focused on cloud infrastructure, and I continue to be very invested in this project and have been engaged in the Kata community as a contributor and user. 8 | 9 | Since the initial discussions of creating Kata started, I have been an active contributor and advocate for the project, both in code and in the greater Kata community/ecosystem. I am running again as I am very interested in this project's success in the ecosystem, and am very focused on making sure Kata continues to be a stable, production-ready solution for providing stronger container isolation. 10 | 11 | Over the last year, I invested time ensuring that we have a solution for using virtio-blk for PVCs, ensuring we have overhead and sandbox sizing requirements available at Kata sandbox creation time, as well as introducing a method for setting IPtables in the guest to support virtual cluster use cases. One area I'm looking forward to driving this next year is finishing adding support for running shimv2 on Darwin. 12 | 13 | We still have a lot of interesting work to do, and I look forward to continuing to contribute to the success of Kata Containers! 14 | 15 | --Eric 16 | 17 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-11/FabianoFidencio.txt: -------------------------------------------------------------------------------- 1 | Name: Fabiano Fidêncio 2 | 3 | Email: fabiano@fidencio.org 4 | 5 | Background: 6 | 7 | I am a Software Engineer, a tattoo canvas for abstract art, a music addict, a 8 | goats and pigs instagram follower, and a big fan of old video games. 9 | 10 | In the past 30 months I dedicated a huge chunk of my professional and personal 11 | time contributing to the Kata Containers project and community, with a strong 12 | focus on trying to keep the community as healthy as possible, while recently 13 | also focusing on efforts in the Confidential Containers space. 14 | 15 | My involvement with Kata Containers has been intense, to say the least. I've 16 | been involved on pretty much every part of the project, and also on projects 17 | Kata Containers interacts with.  Moreover, I've already been serving the 18 | community as a current member of the Kata Containers Architecture Committee. 19 | 20 | In the enterprise world, while working for Intel, I've worked mostly on 21 | leveraging Intel's usage of Kata Containers, and also bringing Intel 22 | technologies to the project, such as the TDX support and integration work for 23 | Confidential Containers.  While I was still working for Red Hat,I worked on 24 | making the upstream project a Red Hat's downstream product, passing by Fedora, 25 | CentOS, Red Hat CoreOS, and OpenShift components, which led to the OpenShift 26 | Sandboxed Containers product, which uses Kata Containers underneath. 27 | 28 | In the community space, I also have helped on a lot of different parts of the 29 | project. connected people to have their problems solved, mentored both 30 | newcomers and students into our community, been leading Architecture Committee 31 | meetings, helped organise Kata Containers vPTG sessions, presented the project 32 | at conferences, worked together with OIF on getting Study Cases published, and 33 | helped increase the number of members in our community.  I also am hands-on on 34 | CI, code-reviewing, development focusing on easing the adoption of the project. 35 | I've managed a whole bunch of releases, and have been working as much as 36 | possible to grow this community in a healthy way. 37 | 38 | My main motivations are still to increase Kata Containers adoption in the 39 | industry, while ensuring the project is stable and easily consumable.  This is 40 | more important now than ever as new players are adopting and contributing to 41 | the Kata Containers project, and we're transitioning to the runtime-rs. 42 | 43 | To make it possible, I plan to continue working in the integration bits, while 44 | connecting and facilitating the communication between the Kata Containers 45 | community and the communities that I am part of. 46 | 47 | Fabiano Fidêncio (Slack: fidencio) 48 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-11/FengWang.txt: -------------------------------------------------------------------------------- 1 | Name: Feng Wang 2 | 3 | Email: feng.wang@databricks.com 4 | 5 | Background: 6 | 7 | 8 | I’m a software engineer at Databricks, where I work on the multi-cloud platform team. I became involved in the project 14 months ago and have been an active contributor and community member since then. 9 | 10 | 11 | At Databricks, Kata Containers has become a foundational piece that drives multiple production use cases. In the near future, we’re expecting to onboard more use cases to Kata Containers at an even larger scale. A stable and high quality Kata Container runtime is critical for our business. The way Databricks uses Kata Containers also tests its limits. Within the past 12 months, we have found several stability bugs, feature and performance gaps. 12 | 13 | 14 | My main motivation is to make Kata Containers more stable and further improve its production quality, which is also essential for increasing its industry adoption. We at Databricks also made several performance improvements on Kata Containers, which I’d love to bring upstream for performance sensitive workloads. I’m also interested in continuing improving the integration between Kata Containers and kubelet/CSI/CNI/CRI, especially on device/resource allocation. Last but not least, I’m very excited with the runtime-rs and would love to help make the migration smooth and uneventful. 15 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-11/FupanLi.txt: -------------------------------------------------------------------------------- 1 | Name: Fupan Li 2 | 3 | Email: lifupan@gmail.com 4 | 5 | Background: 6 | 7 | I’m one of the Kata Containers communities maintainer and active contributor since 2018, 8 | during the past few years, I developed the Kata Containers shimv2, which promoted Kata 9 | Containers from multi process model into only two process(shimv2 and vmm) model, at the 10 | same time, it made Kata Containers much more populated and adoptable in the k8s community. 11 | In addition, I’m the author of the rust version of the kata-agent, which bring Kata Containers 12 | from 1.0 to 2.0. Last but not lease, I’m the architecture and key developer of the rust version’s 13 | kata runtime, which had been opened and contributed to runtime-rs. 14 | 15 | In addition to that, I worked in Ant Group , which maintained the largest Kata Containers cluster, 16 | as an senior engineer, I’m responsible for the implementation and development of the kata container 17 | inside Ant, and I am confident that based on my development and land experience on the Ant Group, 18 | as well as the maintenance work of the community, I’d try my best to contribute much more to the 19 | Kata community. 20 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-11/GerryLiu.txt: -------------------------------------------------------------------------------- 1 | Name: Gerry Liu 2 | Email: gerry at linux dot alibaba dot com 3 | 4 | Background 5 | I’m a software engineer at Alibaba Cloud, working on Operating System and cloud infrastructure related technologies. I have rich development experiences about Linux kernel, container image acceleration, rust based micro-vm and confidential containers. 6 | 7 | Since 2019 I’m working on technologies related to Kata Containers, and is one of the advocators to rustify Kata Containers. I have also contributed to Kata agent-rs, runtime-rs, embedded Dragonball vmm and Nydus image acceleration service. During last year I have put much efforts to enable new features for Kata Containers: 8 | 1) introduced/contributed runtime-rs/Dragonball to Kata 3.0 9 | 2) enhanced td-shim and image-rs to support confidential containers 10 | 3) helped to integrate Nydus with Kata 11 | 4) put Kata into production with large deploy base 12 | 13 | In the coming year, I plan to cooperate with the community to work on following topics: 14 | 1) make runtime-rs/Dragonball as the default option 15 | 2) enhance Dragonball to support confidential containers 16 | 3) enhance Dragonball to better support GPUs, other accelerators and DPUs. 17 | 4) share more code base between Dragonball and Cloud Hypervisor 18 | 19 | And most importantly I will help to integrate Kata Containers into OpenAnolis Linux distribution and enlarge the user base:) 20 | 21 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-11/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: Nov 2022 2 | 3 | There are three Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Archana Shinde`, `Eric Ernst` and `Fabiano Fidêncio`. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * November 04, 15:00 UTC - November 11, 2022 14:59 UTC: Candidate nominations open 12 | * November 12, 15:00 UTC - November 21, 2022 14:59 UTC: Q&A/Debate period 13 | * November 22, 15:00 UTC - November 29, 2022 14:59 UTC: Voting open 14 | * November 30th, 2022, results announced 15 | -------------------------------------------------------------------------------- /elections/arch-committee-2022-11/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: Nov 2022 2 | 3 | Six nominations were received for the November 2022 elections: 4 | 5 | - [`Archana Shinde`](https://github.com/amshinde) 6 | - [`Eric Ernst`](https://github.com/egernst) 7 | - [`Fabiano Fidêncio`](https://github.com/fidencio) 8 | - [`Feng Wang`](https://github.com/fengwang666) 9 | - [`Fupan Li`](https://github.com/lifupan) 10 | - [`Gerry Liu`](https://github.com/jiangliu) 11 | 12 | Three seats were available, so elections were held. 13 | 14 | The nominees elected to the positions were: 15 | 16 | - [`Eric Ernst`](https://github.com/egernst) 17 | - [`Fabiano Fidêncio`](https://github.com/fidencio) 18 | - [`Gerry Liu`](https://github.com/jiangliu) 19 | 20 | Congratulations to our new architecture committee members `Gerry` and our continuing member `Eric` and `Fabiano`! 21 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-04/ArchanaShinde.txt: -------------------------------------------------------------------------------- 1 | Name: Archana Shinde 2 | Email: archana.m.shinde@intel.com 3 | Background: 4 | I am a software engineer at Intel with a focus on open-source technologies for Cloud. I have been an active contributor and maintainer since the inception of the project and continue to be engaged in various aspects of the project. 5 | I have served on the Kata Containers Architecture committee in the past and would like to announce my candidacy for the upcoming elections. 6 | Over the past few years, I have been involved in various areas of the project including storage, device and network support for the runtime, support for shimv2, optimizations around I/O and Kata integrations with various open source projects. As part of the vulnerability management team, I helped close any CVE's or security vulnerabilities opened by end users. I have also helped streamline our releases by leveraging GitHub actions and continue to be part of the release management team, contributing to making releases for the project. 7 | Intel has been a key contributor to the project. We at Intel continue to focus on Kata Containers along with Confidential Containers. 8 | For the future, I plan to focus on improving support for cloud-hypervisor project for runtime-rs and make it production ready. I also plan adding support for network/storage in rust for the rust kata-ctl tool and runtime-rs. I also intend to work to on improving device support for Intel devices for both runtime-rs and confidential containers runtime. 9 | I believe there are quite a few interesting features to be added to Kata in the near future and I look forward to contribute to the community. 10 | Thanks, 11 | Archana Shinde 12 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-04/FengWang.txt: -------------------------------------------------------------------------------- 1 | Name: Feng Wang 2 | 3 | Email: fwang@confluent.io 4 | 5 | Background: 6 | 7 | I’m a software engineer at Confluent, where I work at the compute platform team. 8 | I became involved in the Kata Containers project since August 2021 and have been 9 | an active contributor and community member since then. 10 | 11 | Over the past two years, I have contributed extensively to the Kata Containers 12 | project, including enabling non-root VMM support, support direct-volume mount, 13 | and fixed a number of critical bugs. Through these contributions, I have 14 | developed a deep understanding of the project and have gained valuable experience 15 | working with the Kata Containers community. 16 | 17 | My main motivation is to improve the production adoption of the project by making 18 | it more stable, performant, production mature and accessible. Kata Containers as 19 | the leading sandboxed container runtime has its unique position in the cloud 20 | native world. However, based on my last two years of experience working at two 21 | different companies trying to adopt Kata Containers in production, there still 22 | remain many challenges for companies to adopt Kata Containers in production, 23 | especially for small size companies. Thanks to its compatability with runtime shim 24 | interface, onboarding a workload to Kata Containers is relatively simple, but the 25 | effort to operate it in production is nontrivial. As a community, we can focus more 26 | on improving the production quality, ease of operation, and community support. 27 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-04/JeremiPiotrowski.txt: -------------------------------------------------------------------------------- 1 | Name: Jeremi Piotrowski 2 | 3 | Email: jpiotrowski@microsoft.com, jpiotrowski@linux.microsoft.com 4 | 5 | Background: 6 | 7 | I'm a software engineer at Microsoft, where I work within Azure. My primary 8 | focus has been contributing to open source projects within the Cloud Native 9 | space, but I do not draw the line there and try to improve any and every part 10 | of the stack involved in running containers. 11 | 12 | For the past year I have been lurking around the Confidential Containers 13 | community, getting more actively involved since the beginning of this year. So 14 | far, I have mostly been visible helping out with CoCo releases, as well as 15 | fixing bugs and submitting improvements to CoCo/Kata tests/CI. You may also 16 | have seen me answering questions on slack and helping others understand the 17 | Kata design or debugging issues. 18 | 19 | Microsoft relies on Kata Containers in some of our product offerings, with more 20 | to come. We sponsor both the Kata as well CoCo CI infrastructures. We are also 21 | active in adjacent projects like Cloud Hypervisor. Our goal within the Kata 22 | project is simple: contribute to making it more secure and suitable for an even 23 | wider range of use cases. Part of this is taking our learnings from years of 24 | running hardware isolated containers and confidential computing workloads in 25 | production and contributing them to the project, in a way that benefits all 26 | users. 27 | 28 | Joining the Kata Architecure Committee will give me a chance to better serve 29 | the community. Kata is a very dynamic and friendly project, and I'd like to 30 | contribute to that. I care about expanding the project test matrix and making 31 | testing both faster and more reliable, so that it is easier for new 32 | contributors to join the project. I also want to work within the AC to see if 33 | we can reconcile some of the extensions that the community has built up around 34 | Kata. 35 | 36 | Jeremi 37 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-04/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: Apr 2023 2 | 3 | There are four Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Peng Tao`, and `Samuel Ortiz`, with the 5 | addition of two brand new seats for this round. 6 | 7 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) 8 | for election process, declaring candidacy, and eligible voters. 9 | 10 | Election Dates: 11 | 12 | * April 05, 15:00 UTC - April 12, 2023 14:59 UTC: Candidate nominations open 13 | * April 13, 15:00 UTC - April 23, 2023 14:59 UTC: Q&A/Debate period 14 | * April 24, 15:00 UTC - May 01, 2023 14:59 UTC: Voting open 15 | * May 02, 2023, results announced 16 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-04/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: Apr 2023 2 | 3 | Six nominations were received for the April 2023 elections: 4 | 5 | - [`Archana Shinde`](https://github.com/amshinde) 6 | - [`Feng Wang`](https://github.com/fengwang666) 7 | - [`Jeremi Piotrowski`](https://github.com/jepio) 8 | - [`Samuel Ortiz`](https://github.com/sameo) 9 | - [`Steve Horsman`](https://github.com/stevenhorsman) 10 | - [`Tao Peng`](https://github.com/bergwolf) 11 | 12 | Four seats were available, so elections were held. 13 | 14 | The nominees elected to the positions were: 15 | 16 | - [`Feng Wang`](https://github.com/fengwang666) 17 | - [`Samuel Ortiz`](https://github.com/sameo) 18 | - [`Steve Horsman`](https://github.com/stevenhorsman) 19 | - [`Tao Peng`](https://github.com/bergwolf) 20 | 21 | Congratulations to our new architecture committee members `Feng` and `Steve`, 22 | and to our continuing members `Samuel` and `Tao`! 23 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-04/SamuelOrtiz.txt: -------------------------------------------------------------------------------- 1 | Name: Samuel Ortiz 2 | 3 | Email: samuel.e.ortiz@protonmail.com 4 | 5 | Background: 6 | 7 | I am a software engineer at Rivos, where I work on container, virtualization and 8 | confidential computing related projects. 9 | 10 | A few years ago, together with Hyper and the OpenStack Foundation, we created 11 | the Kata Containers project. I've really enjoyed seeing it growing into a wide, 12 | cross-industry project with such a large customer base. Over those years, I 13 | actively contributed to many parts of the project and tried to make the Kata 14 | community both a welcoming and technologically innovative place. 15 | 16 | A couple of years ago, together with some other Kata contributors, we started to 17 | build a new project with the goal of making a fairly complex and new technology, 18 | Confidential Computing, seamlessly accessible through the canonical cloud native 19 | software stack: Kubernetes and its flourishing ecosystem. Kata Containers was 20 | the obvious choice and an almost perfect fit as the foundation for the 21 | Confidential Containers project, and it proves to be a very solid base. As both 22 | a Confidential and Kata Containers contributor and community member, I want to 23 | continue reinforcing the symbiosis that we created between those 2 projects. I 24 | believe that renewing my AC member seat would allow me to continue helping those 25 | 2 projects benefiting from each others, and this what I intend to focus on for 26 | the upcoming year. 27 | 28 | Cheers, 29 | Samuel 30 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-04/SteveHorsman.txt: -------------------------------------------------------------------------------- 1 | Name: Steve Horsman 2 | 3 | Email: steven@uk.ibm.com 4 | 5 | Background: 6 | 7 | I am a software engineer at IBM, where I work on Confidential Computing and 8 | Cloud Platforms based on Z mainframe technology. 9 | 10 | I've been involved in the Kata Containers project since July 2021, when the 11 | development in the Confidential Containers started. My main focus has been 12 | working on the the CCv0 branch of kata-containers and tests, where I've helped 13 | add new features, test code, jobs, done many code reviews, helped with the CoCo 14 | release process and be one of the maintainers of the CCv0 branch to keep it 15 | synced up with the main branch. 16 | 17 | My focus going forward is to help be part of the bridge between the Kata 18 | Containers and Confidential Containers and work on how we can integrate 19 | the new Confidential Containers code into the main branch of Kata Containers 20 | in a way that adds value, and doesn't significantly compromise the existing 21 | users in performance, or stability. 22 | 23 | I also want to help be a part of improving the performance and reliability of 24 | the CI/CD process after having a lot of first hand experience of some of the 25 | challenges developers and reviewer can face trying to get new PRs tested and 26 | integrated. 27 | 28 | Steve -------------------------------------------------------------------------------- /elections/arch-committee-2023-04/TaoPeng.txt: -------------------------------------------------------------------------------- 1 | Name: Tao Peng 2 | 3 | Email: bergwolf@hyper.sh, bergwolf@antgroup.com 4 | 5 | Background: 6 | 7 | I am a staff engineer at Ant Group, where my primary focus is on cloud-native 8 | infrastructure related technologies, including both container runtimes and 9 | images. 10 | 11 | I have been an active contributor since the foundation of the Kata Containers 12 | project and even before that in the runV project. I am interested in many 13 | areas of the project, including runtime, agent, rust VMM, etc. I served as a 14 | member of the vulnerability management team, the release management team, and 15 | the architecture committee. Here, I would like to renew my seat in the 16 | architecture committee to continue my contribution to the Kata community. 17 | 18 | The Ant Group team is very dedicated to the Kata Containers project. We manage 19 | a large scale of Kata deployments in production and advocate for Kata online 20 | and offline wherever possible. We have been pioneers in new features as well 21 | as architecture improvements. We have been actively engaged in upstream 22 | development in the past and will continue to do so in the future. 23 | 24 | We released Kata 3.0 last year, bringing in many useful features like the rust 25 | runtime and dragonball-integrated VMM. Looking forward, I think there are more 26 | things to focus on, such as: 27 | 28 | 1. Rust runtime production-ready. We released the Rust runtime as a preview 29 | feature in 3.0. We should continue to improve and polish it to make it 30 | production-ready so that users can actually benefit from its simplified 31 | architecture. 32 | 33 | 2. Confidential container support. It has been developed in a separate dev 34 | branch for a long time, which brings a lot of maintenance burden and hides 35 | its radiance away from actual Kata users. We should put more effort into 36 | maturing the confidential container support and merge the code into the main 37 | branch sooner rather than later. 38 | 39 | 3. Service mesh support. Within the service mesh context, we have observed 40 | more challenges on the Kata threat model and security boundary. We need to 41 | find a solid solution to the problem and push forward both the secure 42 | container as well as the service mesh world. 43 | 44 | These are just three things on top of my mind. I certainly believe that we 45 | have more to do, and I look forward to continuing to contribute to the 46 | community and help it thrive. 47 | 48 | -Tao 49 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-10/FabianoFidencio.txt: -------------------------------------------------------------------------------- 1 | Name: Fabiano Fidêncio 2 | 3 | Email: fabiano@fidencio.org 4 | 5 | Background: 6 | 7 | I am a Software Engineer, a tattoo canvas for abstract art, a music addict, a 8 | goats and pigs instagram follower, and a big fan of old video games. 9 | 10 | In the past 3.5 years I dedicated a huge chunk of my professional and personal 11 | time contributing to the Kata Containers project and community, with a strong 12 | focus on trying to keep the community as healthy as possible, while also 13 | focusing on efforts in the Confidential Containers space, and trying to 14 | reconcile the two projects as much as possible. 15 | 16 | My involvement with Kata Containers has been intense, to say the least. I've 17 | been involved on pretty much every part of the project, and also on projects 18 | Kata Containers interacts with.  Moreover, I've already been serving the 19 | community as a current member of the Kata Containers Architecture Committee. 20 | 21 | In the enterprise world, while working for Intel, I've been working mostly on 22 | leveraging Intel's usage of Kata Containers, and also bringing Intel 23 | technologies to the project, such as the TDX support and integration work for 24 | Confidential Containers.  While I was still working for Red Hat,I worked on 25 | making the upstream project a Red Hat's downstream product, passing by Fedora, 26 | CentOS, Red Hat CoreOS, and OpenShift components, which led to the OpenShift 27 | Sandboxed Containers product, which uses Kata Containers underneath. 28 | 29 | In the community space, I also have helped on a lot of different parts of the 30 | project. connected people to have their problems solved, mentored both 31 | newcomers and students into our community, have led Architecture Committee 32 | meetings, helped organise Kata Containers vPTG sessions, presented the project 33 | at conferences, worked together with OIF on getting Study Cases published, and 34 | helped increase the number of members in our community.  I also am hands-on on 35 | CI, code-reviewing, development focusing on easing the adoption of the project. 36 | I've managed a whole bunch of releases, and have been working as much as 37 | possible to grow this community in a healthy way. 38 | 39 | Recently I've been leading the whole migration away from Jenkins to using 40 | GitHub Actions, which makes our CI more efficient, reliable, and our tests 41 | closer to the real life usage. 42 | 43 | My main motivations are still to increase Kata Containers adoption in the 44 | industry, while ensuring the project is stable and easily consumable.  This is 45 | more important now than ever as new players are adopting and contributing to 46 | the Kata Containers project, and we're transitioning to the runtime-rs. 47 | 48 | To make it possible, I plan to continue working in the integration bits, while 49 | connecting and facilitating the communication between the Kata Containers 50 | community and the communities that I am part of. 51 | 52 | Fabiano Fidêncio (Slack: fidencio) 53 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-10/FupanLi.txt: -------------------------------------------------------------------------------- 1 | Name: Fupan Li 2 | 3 | Email: lifupan@gmail.com 4 | 5 | Background: 6 | 7 | I’m one of the Kata Containers communities maintainer and active contributor since 2018, 8 | during the past few years, I developed the Kata Containers shimv2, which promoted Kata 9 | Containers from multi process model into only two process(shimv2 and vmm) model, at the 10 | same time, it made Kata Containers much more populated and adoptable in the k8s community. 11 | In addition, I’m the author of the rust version of the kata-agent, which bring Kata Containers 12 | from 1.0 to 2.0. Last but not lease, I’m the architecture and key developer of the rust version’s 13 | kata runtime, which had been opened and contributed to runtime-rs. 14 | 15 | In addition to that, I worked in Ant Group , which maintained the largest Kata Containers cluster, 16 | as an senior engineer, I’m responsible for the implementation and development of the kata container 17 | inside Ant, and I am confident that based on my development and land experience on the Ant Group, 18 | as well as the maintenance work of the community, I’d try my best to contribute much more to the 19 | Kata community. 20 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-10/GerryLiu.txt: -------------------------------------------------------------------------------- 1 | Name: Gerry Liu 2 | Email: gerry at linux dot alibaba dot com 3 | 4 | Background 5 | I am a software engineer at Alibaba Cloud, engaged in operating system and cloud infrastructure related technologies. I have extensive development experience with Linux kernels, container image acceleration, Rust-based micro-virtual machines, and confidential containers. I have been working on software technologies related to Kata Containers since 2019 and have made many contributions to the Kata agent-rs/runtime-rs, Dragonball vmm and Nydus Image Service projects. 6 | 7 | I am also one of the advocates of rustify Kata Containers. Over the past four years, I've helped rustifying Kata agent/runtime and Dragonball step by step. For my own personal interest, I like to refactor existing code to get better abstractions :) I've also put a lot of effort into getting Kata into production to support Function Computing, Container Services, Machine Learning/AI and database workloads. 8 | 9 | Last year, I contributed to the community in the following ways: 10 | 1) Refactor the storage object management subsystem in Kata runtime/agent. 11 | 2) Help integrating Nydus Image Service into Dragonball vmm. 12 | 3) Reconstruct Coco’s image management system to help merging Coco into the Kata main branch. 13 | 4) Enhance Nydus image service to better support Coco. 14 | 5) Put Kata related technologies into production and have a huge deployment base 15 | 16 | In the coming year, I plan to work with the community and focus on the following tasks: 17 | 1) Get runtime-rs ready for production 18 | 2) Get Dragonball ready for production 19 | 3) Better cooperation between Coco and Kata, mainly integrating Coco into the Kata main branch 20 | 4) Enhance Nydus Image Service to better support Kata 21 | 5) Enhance Dragonball to better support GPU, other accelerators and DPU. 22 | 23 | Gerry 24 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-10/GregKurz.txt: -------------------------------------------------------------------------------- 1 | Name: Greg Kurz 2 | 3 | Email: groug@kaod.org 4 | 5 | Background: 6 | 7 | I am a Senior Software Engineer at Red Hat. I work for the Openshift 8 | Sandboxed Containers project, which provides Kata Containers to the 9 | Openshift Container Platform. I initially joined the effort to share my 10 | expertise on system components involved in virtualization, most notably 11 | QEMU, but my interest now spans the full stack, in order to provide a 12 | well integrated and production grade software to end users. 13 | 14 | Being an open source enthousiast since the late 90s, with a strong focus 15 | on system programing, I have been involved in early implementations of 16 | containers in Linux (LXC). After a brief detour through a proprietary 17 | operating system, I came back even more convinced of the virtues of open 18 | source regarding software quality and personal development. I then spent 19 | nearly 10 years working in underlying virtualization technologies used by 20 | Kata Containers, especially QEMU where I actively contributed to IBM's POWER 21 | architecture support and acted as maintainer for the 9Pfs subsystem until 22 | today. 23 | 24 | I have developped over the years a strong appetite for "learning from" 25 | and "sharing with" people in open communities, with a peculiar interest 26 | in promoting good practices. The main piece I'd keep from my experience 27 | with QEMU and Linux, is the importance of accompanying and improving 28 | contributions so that new comers can fully benefit from the priceless 29 | expertise that was accumulated over the years. This is a key part for the 30 | success and sustainability of any community. 31 | 32 | I joined Kata Containers 2 years ago, as a developper first, but then 33 | quickly endorsed the roles of reviewer, maintainer and I got directly 34 | involved in several official releases. I am now ready to go one step 35 | further and join the Architecture Commitee in order to accompany the 36 | community even more on consolidating good practices and improving 37 | processes. This is crucial for the success of Kata Containers, now that 38 | it has become the de-facto vehicle to bring more and more virtualization 39 | features to the containers ecosystem, with its share of integration 40 | challenges. 41 | 42 | Greg 43 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-10/JeremiPiotrowski.txt: -------------------------------------------------------------------------------- 1 | Name: Jeremi Piotrowski 2 | 3 | Email: jpiotrowski@microsoft.com 4 | 5 | Background: 6 | 7 | I'm a software engineer at Microsoft, where I work within Azure. My primary 8 | focus is contributing to open source projects within the Cloud Native space, 9 | but I do not draw the line there and try to improve any and every part of the 10 | stack involved in running containers. 11 | 12 | For more than a year now I have been active in both the Kata Containers and 13 | Confidential Containers communities. I have been working in numerous areas most 14 | recently CI stability, and reviewing contributions (especially Cloud-Hypervisor 15 | related) to ensure the project can incorporate them in a timely manner. Other 16 | areas I've helped with are CoCo releases, CoCo development related to 17 | attestation (TDX and SNP) and bugfixes in Kata (cgroups and others). You may 18 | also have seen me answering questions on slack and helping others understand 19 | the Kata design or debugging issues. 20 | 21 | Microsoft relies on Kata Containers in some of our service offerings, with more 22 | to come. We sponsor both the Kata as well CoCo CI infrastructures. We are also 23 | active in adjacent projects like Cloud Hypervisor. Our goal within the Kata 24 | project is simple: contribute to the security and reliability of the project 25 | and help make it suitable for an even wider range of use cases. Part of this is 26 | taking our learnings from years of running hardware isolated containers and 27 | confidential computing workloads in production and contributing them to the 28 | project, in a way that benefits all users. 29 | 30 | Joining the Kata Architecure Committee will give me a chance to better serve 31 | the community. Kata is a very dynamic and friendly project, and I'd like to 32 | contribute directly to that. I care about making the project more robust as the 33 | codebase grows, improving our test and release processes and making it is 34 | easier for new contributors to join the project. I also want to work within the 35 | AC to see if we can reconcile some of the extensions that the community has 36 | built up around Kata. 37 | 38 | Jeremi 39 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-10/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: Oct 2023 2 | 3 | There are four Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Eric Ernst`, `Fabiano Fidêncio`, `Gerry Liu` and `Feng Wang` who stepped down early. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * October 03, 2023: Election officials confirmed @stevenhorsman 12 | * October 09, 15:00 UTC - October 16, 2023 14:59 UTC: Candidate nominations open 13 | * October 17, 15:00 UTC - October 24, 2023 14:59 UTC: Q&A/Debate period 14 | * October 26, 20:00 UTC - November 02, 2023 18:59 UTC: Voting open 15 | * November 03, 2023, results announced 16 | -------------------------------------------------------------------------------- /elections/arch-committee-2023-10/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: October 2023 2 | 3 | Six nominations were received for the October 2023 elections: 4 | 5 | 6 | - [`Fabiano Fidêncio`](https://github.com/fidencio) 7 | - [`Fupan Li`](https://github.com/lifupan) 8 | - [`Gerry Liu`](https://github.com/jiangliu) 9 | - [`Greg Kurz`](https://github.com/gkurz) 10 | - [`Jeremi Piotrowski`](https://github.com/jepio) 11 | - [`Zvonko Kaiser`](https://github.com/zvonkok) 12 | 13 | Four seats were available, so elections were held. 14 | 15 | The nominees elected to the positions were: 16 | 17 | - [`Fabiano Fidêncio`](https://github.com/fidencio) 18 | - [`Fupan Li`](https://github.com/lifupan) 19 | - [`Gerry Liu`](https://github.com/jiangliu) 20 | - [`Greg Kurz`](https://github.com/gkurz) 21 | 22 | Congratulations to our new architecture committee members `Fupan` and `Greg`, 23 | and to our continuing members `Fabiano` and `Gerry`! 24 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-04/AnastassiosNanos.txt: -------------------------------------------------------------------------------- 1 | Name: Anastassios Nanos 2 | 3 | Email: ananos@nubificus.co.uk 4 | 5 | Background: 6 | 7 | I am a Systems Researcher, with almost two decades of experience in systems software development. My journey in this field began with low-level system architecture and a drive to create efficient and robust systems software to accommodate high-performance application needs. Throughout my career, I had the privilege of working on various hypervisor projects, specializing in enhancing performance, security, and interoperability. Currently, I am juggling between academic and commercial projects, working on various aspects of the software stack to enable secure and efficient application execution in multi-tenant Cloud/Edge environments. 8 | 9 | My involvement with the Kata Containers project stems from a passion for pushing the boundaries of containers. I recognize the role hypervisor support plays in ensuring the project's success, and I am eager to lend my expertise to make it even more robust. From optimizing performance to fortifying security, and extending support to diverse hypervisor projects, I am committed to making (or keeping;-)) Kata Containers the de-facto microVM sandbox container runtime. As a team, we are involved in Kata<->Firecracker support, both in the go and rust runtime. 10 | 11 | If elected to the Kata Architecture Committee, my primary focus will be hypervisor support, particularly in the context of the runtime-rs port. 12 | 13 | A few thoughts: 14 | 15 | - Strengthening Hypervisor Support: I will collaborate with the community to identify areas for improvement in hypervisor support and work tirelessly to address them. This includes optimizing hypervisor interactions, enhancing compatibility with diverse hypervisor platforms, and implementing robust error handling mechanisms. 16 | 17 | - Advancing CI Stability: I recognize the critical role CI plays in maintaining the project's health and stability. I will prioritize efforts to enhance the CI pipeline, especially in the context of catching hypervisor-related corner cases, and ensure timely detection and resolution of issues related to new features and the runtime-rs integration. 18 | 19 | - Fostering Collaboration: I believe in the power of collaboration to drive innovation. As a committee member, I will actively engage with stakeholders, solicit feedback from the community, and foster a culture of open communication and collaboration. I will strive to keep the inclusive environment that the community has created, where diverse perspectives are valued, and all voices are heard. 20 | 21 | I am deeply committed to advancing the Kata Containers project. With your support, I am confident that together, we can achieve new milestones and drive the project to even greater success. 22 | 23 | cheers, 24 | Tassos 25 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-04/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: Apr 2024 2 | 3 | There are four Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Fabiano Fidêncio`, `Peng Tao`, `Samuel Ortiz` 5 | and `Steve Horsman`. 6 | 7 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) 8 | for election process, declaring candidacy, and eligible voters. 9 | 10 | Election Dates: 11 | 12 | * April 01, 2024: Election officials are confirmed: @sprt, @Apokleos 13 | * April 08, 15:00 UTC - April 15, 2024 14:59 UTC: Candidate nominations open 14 | * April 15, 15:00 UTC - April 22, 2024 14:59 UTC: Q&A/Debate period 15 | * April 22, 15:00 UTC - April 29, 2024 14:59 UTC: Voting open 16 | * April 30, 2024, results announced 17 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-04/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: Apr 2024 2 | 3 | Four nominations were received for the April 2024 elections: 4 | 5 | - [`Anastassios Nanos`](https://github.com/ananos) 6 | - [`Steve Horsman`](https://github.com/stevenhorsman) 7 | - [`Tao Peng`](https://github.com/bergwolf) 8 | - [`Zvonko Kaiser`](https://github.com/zvonkok) 9 | 10 | Four seats were available, and the architecture committee resulting from 11 | the above nominations would not contain more than two members of the 12 | same affiliation, so the voting phase was skipped and all the nominated 13 | individuals were appointed to the architecture committee. 14 | 15 | Congratulations to our new architecture committee members `Anastassios` 16 | and `Zvonko`, and to our continuing members `Steve` and `Tao`! 17 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-04/SteveHorsman.txt: -------------------------------------------------------------------------------- 1 | Name: Steve Horsman 2 | 3 | Email: steven@uk.ibm.com 4 | 5 | Background: 6 | 7 | I am a software engineer at IBM, where I work on Confidential Computing 8 | based on Z mainframe technology. 9 | 10 | I've been involved in the Kata Containers project since July 2021, when the 11 | development in the Confidential Containers started. My main focus has been 12 | working on the the CCv0 branch of kata-containers and tests, where I've helped 13 | add new features, test code, jobs, done many code reviews, helped with the CoCo 14 | release process and then helped to co-ordinate the migration of the CoCo 15 | function into the main branch in a proper way. In the last year I've served on 16 | the Architecture Committee. 17 | 18 | I've also been involved in helping with the CI and updated release process 19 | and I see my role going forwards to continue to be focused on the CoCo uses 20 | of kata and try and help bring between the community and help with CI 21 | stability and releases. I also look forward to some large changes in the near 22 | future like moving to containerd 2.0 and the transition to runtime-rs. 23 | 24 | Steve 25 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-04/TaoPeng.txt: -------------------------------------------------------------------------------- 1 | Name: Tao Peng 2 | 3 | Email: bergwolf@hyper.sh, bergwolf@antgroup.com 4 | 5 | Background: 6 | 7 | I am a staff engineer at Ant Group, where my primary focus is cloud-native 8 | infrastructure-related technologies, including both container runtimes and 9 | images. 10 | 11 | I have been an active contributor since the foundation of Kata Containers 12 | project back in 2017. I used to work on many areas of the project including 13 | architectural design, development, releasing management, security auditing, 14 | event organizing, and community promoting. I have served as a member of the 15 | architecture committee since 2021 and would like to renew my seat to continue 16 | my contribution to the community. 17 | 18 | In the coming year, there are still quite a lot of interesting things going on 19 | in the community, out of which my main focus would mostly be around: 20 | 21 | 1. Engaging more users. While Kata is getting more and more end users, it is 22 | also obvious that we are not getting enough feedback from them. The latest end-user 23 | survey is a good start. I would like to help engage more end users so 24 | that we can use their feedback to prioritize features of the project. 25 | 26 | 2. Collaboration with the confidential container project. Coco is certainly one 27 | of the most important downstream of Kata. While Coco has been doing great so far, 28 | it has been living in the shadow for too long. We should merge it into the main 29 | branch soonish and ensure the roadmap-wise longterm alignment of Coco and Kata. 30 | 31 | 3. PVM (Pagetable-based Virtual Machine) is a cutting-edge isolation technology 32 | developed by Ant Group and expands Kata's usage in nested VM environments. It 33 | is still in the process of being upstreamed in the Linux kernel community and I 34 | would devote part of my time to help integrate and promote it in the Kata 35 | community, especially to the SaaS/PaaS provider users of Kata who operate mostly 36 | in public cloud. 37 | 38 | Meanwhile, there is certainly more to do for the community and I look forward to 39 | continuing to serve the community and help it thrive. 40 | 41 | Cheers, 42 | Bergwolf 43 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-04/ZvonkoKaiser.txt: -------------------------------------------------------------------------------- 1 | Name: Zvonko Kaiser 2 | 3 | Email: zkaiser@nvidia.com 4 | 5 | Background: 6 | 7 | I am a software engineer at NVIDIA, where I work on all things cloud-native. 8 | At NVIDIA I am leading the Kata and Confidential Containers efforts and enabling 9 | Kata and Confidential Containers on all of our architectures, platforms and 10 | projects, ranging from embedded, edge devices to data centers and cloud. 11 | 12 | Over the last two years, I have been actively involved in Kata, contributing 13 | my expertise and dedication towards its success. As a passionate and experienced 14 | professional in the field, I strongly believe that my skills and insights can 15 | greatly benefit the AC's decision-making process. 16 | 17 | Here are a few reasons why I believe I am well-suited for this role: 18 | 19 | Extensive Technical Knowledge: With over ten years of experience in system 20 | software development/performance engineering and a strong background in 21 | virtualization from embedded to cloud, I possess a deep understanding of the 22 | technical aspects involved in our project. This knowledge allows me to provide 23 | valuable input and contribute to informed discussions within the committee. 24 | 25 | Additionally I have an broad experience and insight from various industry fields, 26 | ranging from robotics at the Fraunhofer Institute, automotive doing autonomous 27 | parking at Mercedes Research to mainframe and blade servers at IBM to cloud and 28 | Kubernetes at RedHat and NVIDIA. 29 | 30 | Especially in Kata I have added the virtualization reference architecture to 31 | support advanced use-cases like GPUDirect RDMA and GPUDirect GDS which is a must 32 | have for allmost all of the NVIDIA customers and internal projects leveraging 33 | Kata. Last year I added proper support for GPU, vGPU time-sliced, 34 | vGPU MIG-backed and this year my focus was on the confidential GPU support. 35 | 36 | Last but not least my insights through my work at NVIDIA on Confidential 37 | Computing and AI/ML use-cases will help me as a member of the AC to help guide 38 | the project to support important use-cases and requirements. 39 | 40 | Strong Leadership Abilities: Throughout my career, I have demonstrated effective 41 | leadership skills by successfully leading cross-functional teams and delivering 42 | complex projects on time and within budget. My ability to collaborate with 43 | diverse stakeholders ensures that decisions made by the committee align with 44 | both technical requirements and overall project goals. 45 | 46 | Commitment to Continuous Improvement: As a member of the AC, I will strive to 47 | drive innovation and promote best practices within our project. By staying 48 | up-to-date with emerging technologies and industry trends, I can help guide our 49 | software towards greater efficiency, scalability, and user satisfaction. 50 | 51 | Excellent Communication Skills: Effective communication is crucial for any 52 | committee's success. With my strong verbal and written communication abilities, 53 | I can facilitate productive discussions among committee members, ensuring that 54 | ideas are shared openly and transparently. 55 | 56 | I am excited about the opportunity to contribute further to this project's 57 | growth as a member of the AC. If given the chance, I will dedicate myself 58 | wholeheartedly to fulfilling my responsibilities with utmost professionalism. 59 | 60 | Thank you for considering my nomination. 61 | Mr. Z 62 | 63 | 64 | 65 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-10/AurelienBombo.txt: -------------------------------------------------------------------------------- 1 | Name: Aurelien Bombo 2 | 3 | Email: abombo@microsoft.com 4 | 5 | Background: 6 | 7 | I'm a software engineer at Microsoft, where I work on developing the 8 | Azure Linux OS for different offerings, including the Azure Kubernetes 9 | Service (AKS), and where my primary focus is to grow Kata Containers 10 | both outside and inside Microsoft. 11 | 12 | I joined the project at the beginning of last year, when I initially 13 | helped with the move from Jenkins to Github Actions in order to 14 | modernize the CI. Since then, I've been involved in both the Kata and 15 | CoCo communities, maintaining and strengthening our CI, reviewing 16 | contributions, and helping out cutting releases. 17 | 18 | Notably, as Microsoft sponsors the CI infrastructure for Kata and CoCo 19 | (as well as adjacent projects like Cloud Hypervisor), I've worked with 20 | Microsoft leadership to unlock $54,000 of funding for Azure resources 21 | for testing. Separately, I've worked with Github to upgrade our 22 | concurrent free runner limit from 20 to 100, significantly speeding up 23 | our CI at no extra cost. In everyday operations, I make it a point to 24 | ensure our CI usage continuously gives us a safe operating margin in 25 | terms of costs, and I bring my expertise in helping the community 26 | maintain the health of the test infrastructure relying on AKS. 27 | 28 | More recently, I've been leading a mentorship program with Boston 29 | University, in which a team of five students is working on turning our 30 | CI dashboard prototype into a production solution, as well as adding 31 | more automation to our CI. I've also been working more closely with 32 | the CoCo community to enable confidential storage features. 33 | 34 | In the next year, I plan to keep executing on these priorities and to 35 | further stabilize and strengthen Kata. As the project matures, a logical 36 | next step that I'd like to explore is advertising it around different 37 | online communities and increasing the reach and growth of the project 38 | this way. 39 | 40 | Aurelien 41 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-10/FupanLi.txt: -------------------------------------------------------------------------------- 1 | Name: Fupan Li 2 | 3 | Email: lifupan@gmail.com 4 | 5 | Background: 6 | 7 | I’m one of the Kata Containers communities maintainer and active contributor since 2018, 8 | during the past few years, I developed the Kata Containers shimv2, which promoted Kata 9 | Containers from multi process model into only two process(shimv2 and vmm) model, at the 10 | same time, it made Kata Containers much more populated and adoptable in the k8s community. 11 | In addition, I’m the author of the rust version of the kata-agent, which bring Kata Containers 12 | from 1.0 to 2.0. Last but not lease, I’m the architecture and key developer of the rust version’s 13 | kata runtime, which had been opened and contributed to runtime-rs. 14 | 15 | I was elected as a Kata AC member last year and have served the Kata community for a year. During 16 | this year, I actively promoted the maturity of Kata rust runtime and it has reached the requirements 17 | of product-level stability. 18 | 19 | In addition to that, I worked in Ant Group, which maintained the largest Kata Containers cluster, 20 | as an senior engineer, I’m responsible for the implementation and development of the kata container 21 | inside Ant, and I am confident that based on my development and land experience on the Ant Group, 22 | as well as the maintenance work of the community, I’d try my best to contribute much more to the 23 | Kata community. 24 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-10/GregKurz.txt: -------------------------------------------------------------------------------- 1 | Name: Greg Kurz 2 | 3 | Email: groug@kaod.org 4 | 5 | Background: 6 | 7 | I am a Senior Software Engineer at Red Hat. I work for the Openshift 8 | Sandboxed Containers project, which provides Kata Containers to the 9 | Openshift Container Platform. I initially joined the effort to share my 10 | expertise on system components involved in virtualization, most notably 11 | QEMU, but my interest now spans the full stack, in order to provide a 12 | well integrated and production grade software to end users. 13 | 14 | I joined Kata Containers 3 years ago, as a developper first, but then 15 | quickly endorsed the roles of reviewer, maintainer and I got directly 16 | involved in several official releases. I've served on the Architecture 17 | Committee for a year, helping with CI, releases and providing guidance 18 | on good coding practices during reviews. I want to continue the effort, 19 | with a focus on the upcomfing transition to runtime-rs and CI improvements. 20 | 21 | Greg 22 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-10/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: Oct 2024 2 | 3 | There are three Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Fupan Li`, `Gerry Liu` and `Greg Kurz`. 5 | 6 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) 7 | for election process, declaring candidacy, and eligible voters. 8 | 9 | Election Dates: 10 | 11 | * September 23, 2024: Election officials are confirmed: @Apokleos, @stevenhorsman 12 | * October 01, 15:00 UTC - October 15, 2024 14:59 UTC: Candidate nominations open 13 | * October 15, 15:00 UTC - October 22, 2024 14:59 UTC: Q&A/Debate period 14 | * October 22, 15:00 UTC - October 29, 2024 14:59 UTC: Voting open 15 | * October 29, 2024, results announced 16 | -------------------------------------------------------------------------------- /elections/arch-committee-2024-10/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: Oct 2024 2 | 3 | Four nominations were received for the October 2024 elections, however 4 | one of the candidates withdrew before the voting period. The final 5 | candidate list is: 6 | 7 | - [`Aurelien Bombo`](https://github.com/sprt) 8 | - [`Fupan Li`](https://github.com/lifupan) 9 | - [`Greg Kurz`](https://github.com/gkurz) 10 | 11 | Three seats were available, and the architecture committee resulting from 12 | the above nominations would not contain more than two members of the 13 | same affiliation, so the voting phase was skipped and all the nominated 14 | individuals were appointed to the architecture committee. 15 | 16 | Congratulations to our new architecture committee member `Aurélien` 17 | and to our continuing members `Fupan` and `Greg`! 18 | 19 | -------------------------------------------------------------------------------- /elections/arch-committee-2025-04/AnastassiosNanos.txt: -------------------------------------------------------------------------------- 1 | Name: Anastassios Nanos 2 | 3 | Email: ananos@nubificus.co.uk 4 | 5 | Background: 6 | 7 | I am a Systems Researcher, with almost two decades of experience in systems software development. My journey in this field began with low-level system architecture and a drive to create efficient and robust systems software to accommodate high-performance application needs. Throughout my career, I had the privilege of working on various hypervisor projects, specializing in enhancing performance, security, and interoperability. Currently, I am juggling between academic and commercial projects, working on various aspects of the software stack to enable secure and efficient application execution in multi-tenant Cloud/Edge environments. 8 | 9 | My involvement with the Kata Containers project stems from a passion for pushing the boundaries of containers. I recognize the role hypervisor support plays in ensuring the project's success, and I am eager to share my expertise to make it even more robust. From optimizing performance to fortifying security, and extending support to diverse hypervisor projects, I am committed to making (or keeping;-)) Kata Containers the de-facto microVM sandbox container runtime. As a team, we are involved in Kata<->Firecracker support, both in the go and rust runtime. 10 | 11 | If honored to be a member of the kata AC for another year, my primary focus will (still) be hypervisor support, particularly in the context of the runtime-rs port and ARM64 support. Facilitating the execution of hardware-accelerated workloads is something I will try to pursue as well. Finally, establishing a robust baseline for performance metrics is key to extending the project's adoption. This is something we have been discussing for quite some time and it seems we are almost ready to dig into the actual implementation. 12 | 13 | A few thoughts: 14 | 15 | - Advancing CI Stability: I recognize the critical role CI plays in maintaining the project's health and stability. I will prioritize efforts to enhance the CI pipeline, especially in the context of adding tests for Firecracker, catching hypervisor-related corner cases, and ensure timely detection and resolution of issues related to new features and the runtime-rs integration. 16 | 17 | - Fostering Collaboration: I believe in the power of collaboration to drive innovation. As a committee member, I will actively engage with stakeholders, solicit feedback from the community, and foster a culture of open communication and collaboration (even if this means more travel, and more talks! :D). I will strive to keep the inclusive environment that the community has created, where diverse perspectives are valued, and all voices are heard. 18 | 19 | I am deeply committed to advancing the Kata Containers project. With your support, I am confident that together, we can achieve new milestones and drive the project to even greater success. 20 | 21 | cheers, 22 | Tassos 23 | -------------------------------------------------------------------------------- /elections/arch-committee-2025-04/README.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Elections: Apr 2025 2 | 3 | There are four Architecture Committee seats up for election. The seats up for 4 | election are currently filled by `Anastassios Nanos`, `Peng Tao`, `Steve Horsman` 5 | and `Zvonko Kaiser`. 6 | 7 | Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) 8 | for election process, declaring candidacy, and eligible voters. 9 | 10 | Election Dates: 11 | 12 | * March 31, 2025: Election officials are confirmed: @sprt, @Apokleos 13 | * April 07, 15:00 UTC - April 14, 2025 14:59 UTC: Candidate nominations open 14 | * April 14, 15:00 UTC - April 21, 2025 14:59 UTC: Q&A/Debate period 15 | * April 21, 15:00 UTC - April 28, 2025 14:59 UTC: Voting open 16 | * April 28, 2025, results announced 17 | -------------------------------------------------------------------------------- /elections/arch-committee-2025-04/Results.md: -------------------------------------------------------------------------------- 1 | # Architecture Committee Election Results: Apr 2025 2 | 3 | There were 5 nominations received for the April 2025 elections: 4 | 5 | - [`Anastassios Nanos`](https://github.com/ananos) 6 | - [`Peng Tao`](https://github.com/bergwolf) 7 | - [`Steve Horsman`](https://github.com/stevenhorsman) 8 | - [`Ruoqing He`](https://github.com/RuoqingHe) 9 | - [`Zvonko Kaiser`](https://github.com/zvonkok) 10 | 11 | Four seats were available, so elections were held. 12 | 13 | The nominees elected to the positions were: 14 | 15 | - [`Anastassios Nanos`](https://github.com/ananos) 16 | - [`Steve Horsman`](https://github.com/stevenhorsman) 17 | - [`Ruoqing He`](https://github.com/RuoqingHe) 18 | - [`Zvonko Kaiser`](https://github.com/zvonkok) 19 | 20 | Congratulations to our new architecture committee member `Ruoqing`, 21 | and to our continuing members `Anastassios`, `Steve` and `Zvonk`! -------------------------------------------------------------------------------- /elections/arch-committee-2025-04/RuoqingHe.txt: -------------------------------------------------------------------------------- 1 | Name: Ruoqing He 2 | 3 | Email: heruoqing@iscas.ac.cn 4 | 5 | Background: 6 | 7 | I'm a software engineer at Institute of Software, Chinese Academy of Sciences, 8 | and my focus is virtualization and cloud-native on RISC-V architecture. More 9 | specifically, the software stack related/connected to and includes Kata 10 | Containers. 11 | 12 | I walked all the way up from rust-vmm -> cloud-hypervisor -> Kata Contaienrs, 13 | laid down the RISC-V CI infrastructures and introduced RISC-V architecture 14 | support, while actively maintaining them. Besides, we have been working on 15 | dragonball too since last year, those works will be put up and receive reviews 16 | in a few months after we figured out how to deal with and upgrade the rust-vmm 17 | dependencies correctly and elegantly. 18 | 19 | As for the RISC-V infrastructure, we are closely working with RISC-V hardware 20 | vendors, testing our works on their FPGA, QEMU and prototypes even before those 21 | products are manufactured. So for sure, we will get a hold on them when they 22 | (RISC-V hardware capable of running Kata Containers software stack) are made 23 | available to the market. As of now, we are maintaining the RISC-V runners we 24 | have in Kata community. With that being said, I would be actively playing with 25 | and maintaining our CI as of those connected/going to be connected machines, to 26 | establish solid ground for RISC-V work to stably progress. 27 | 28 | In the year ahead we are going to have real hardware that is capable of 29 | building, testing, and running full Kata Containers software stack, which would 30 | be an important milestone for both Kata and RISC-V. I will be pushing the 31 | following forward: 32 | 33 | - Extend/Upgrade the runner matrix in Kata self-hosted RISC-V runners: 34 | Currently, we are using machines without hypervisor extension solely for 35 | building, and my goal is always align with other architectures to build, test, 36 | and run on self-hosted machines. 37 | 38 | - Expand RISC-V support for Kata components: This is my primary focus in our 39 | community, I will continue to work out, stabilize and maintain RISC-V 40 | architecture support all over the place. 41 | 42 | - Explore RISC-V Confidential Containers: Looking for works could/should be 43 | done in both coco community and integrating them to Kata, and catching up the 44 | developments of CoVE here. 45 | 46 | - Advocate Kata Containers: I have been talking about Kata Containers more than 47 | ten times in the past year, to developers, end users, and the public. I 48 | talked about Kata on RISC-V in FOSDEM 2025 [1] in Feb 2025, and I will bring 49 | this topic to RISC-V Summit Europe 2025 in May 2025. 50 | 51 | apart from those, I will be committed to helping maintaining our CI 52 | infrastructure, reviewing/unblocking PRs and contributing like predecessors and 53 | current ACs/maintainers/contributors in our community did. 54 | 55 | Cheers, 56 | Ruoqing 57 | 58 | [1] https://fosdem.org/2025/schedule/event/fosdem-2025-4156-from-rust-vmm-to-katacontainers-the-development-of-h-ext-based-software-ecosystem/ 59 | 60 | -------------------------------------------------------------------------------- /elections/arch-committee-2025-04/SteveHorsman.txt: -------------------------------------------------------------------------------- 1 | Name: Steve Horsman 2 | 3 | Email: steven@uk.ibm.com 4 | 5 | Background: 6 | 7 | I am a software engineer at IBM, where I work on Confidential Computing 8 | based on Z mainframe technology. 9 | 10 | I've been involved in the Kata Containers project since July 2021, when the 11 | development in the Confidential Containers started. My main focus has been 12 | working on CoCo features, CI and helping with the Kata Containers releases. 13 | In the last two years I've served on the Architecture Committee. 14 | 15 | Some of the activities that I'm keen to help drive in the next year are: 16 | - Helping onboard new members and platforms to the community 17 | - Trying to help drive more "professional" standards in kata-containers, 18 | like regularly running security scans, ensuring our crates and modules are 19 | kept up-to-date and driving our CVE backlog down 20 | - Helping to improve our CI process and get faster and more targeted testing 21 | 22 | I'm also looking forward to seeing what happens with the move to containerd 2.0 23 | and with runtime-rs enhancements. 24 | 25 | Steve 26 | -------------------------------------------------------------------------------- /elections/arch-committee-2025-04/TaoPeng.txt: -------------------------------------------------------------------------------- 1 | Name: Tao Peng 2 | 3 | Email: bergwolf@hyper.sh, bergwolf@antgroup.com 4 | 5 | Background: 6 | 7 | I am a staff engineer at Ant Group, where my primary focus is cloud-native 8 | infrastructure-related technologies, including both container runtimes and 9 | images. 10 | 11 | I have been an active member of the Kata Containers community since 2017. 12 | I worked on many areas of the project, including architectural design, 13 | development, releasing management, security auditing, event organizing, and 14 | community promoting. I've been part of the architecture Committee since 2021, 15 | and I'd be honored to continue serving the community. 16 | 17 | In the past years, the community has done tremendous work to bring a fast, 18 | secure and production-ready container runtime to the world. In the coming year, 19 | my main focus will mostly be around: 20 | 21 | 1. runtime-rs maturity and adoption. We've been developing runtime-rs for 22 | quite some time. It is faster, more stable, and more memory efficient. It is 23 | now time to look at a realistic timeline to make it default and share it with 24 | a wider range of Kata Containers users. 25 | 26 | 2. PVM (Pagetable-based Virtual Machine) is a cutting-edge isolation technology 27 | developed by Ant Group and expands Kata's usage in nested VM environments by 28 | removing the nested VT hardware requirement. While it is still in the process 29 | of being upstreamed in the Linux kernel community, we've been deploying it on 30 | a large scale internally, and there are community users around as well. I'd like 31 | to help integrate and promote it both in the Kata community and in the wider 32 | kernel community. 33 | 34 | I sincerely look forward to continuing to serve the Kata community and helping 35 | it thrives. 36 | 37 | Cheers, 38 | Bergwolf 39 | -------------------------------------------------------------------------------- /elections/arch-committee-2025-04/ZvonkoKaiser.txt: -------------------------------------------------------------------------------- 1 | Name: Zvonko Kaiser 2 | 3 | Email: zkaiser@nvidia.com 4 | 5 | Background: 6 | 7 | I would be honored to continue serving on the Architecture Committee and further 8 | contribute to our shared goals. I am a principal engineer at NVIDIA, focusing on 9 | cloud-native development and leading Kata and Confidential Containers efforts 10 | across various architectures—from embedded and edge devices to data centers and 11 | cloud platforms. Over the last four years, I’ve been deeply involved in Kata, 12 | bringing my expertise and dedication to help it flourish. 13 | 14 | Throughout my career, I’ve gained extensive technical knowledge in system 15 | software development, performance engineering, and virtualization—experience 16 | that spans robotics at the Fraunhofer Institute, automotive research at 17 | Mercedes, mainframe and blade servers at IBM, and cloud/Kubernetes roles at 18 | RedHat and NVIDIA. In Kata, I helped introduce the virtualization reference 19 | architecture to support advanced GPU use cases like GPUDirect RDMA and GPUDirect 20 | GDS. I also added GPU, vGPU (time-sliced and MIG-backed) support, and recently 21 | focused on confidential GPU capabilities. All of these efforts have aimed to 22 | expand Kata’s features and better serve the wider community. 23 | 24 | Collaboration and teamwork are at the heart of my approach. I have led 25 | cross-functional teams and worked with diverse stakeholders to ensure open 26 | communication and consensus-driven decisions. I stay up-to-date with emerging 27 | technologies and industry trends, continually seeking ways to enhance 28 | efficiency, scalability, and user satisfaction in our projects. 29 | 30 | Looking ahead, I am excited to help guide our work into the secure AI era. By 31 | strengthening confidential computing, advancing GPU virtualization technologies, 32 | and aligning with robust security standards, I believe we can ensure that our 33 | project remains at the forefront of modern AI use cases—empowering developers 34 | and users alike with trusted, scalable solutions. 35 | 36 | If given the opportunity, I will continue promoting innovation, community 37 | engagement, and transparency within the Architecture Committee. Thank you for 38 | considering my nomination, and I look forward to helping guide our work to even 39 | greater success. 40 | 41 | Sincerely, 42 | Mr. Z -------------------------------------------------------------------------------- /elections/process/README.md: -------------------------------------------------------------------------------- 1 | # Election Process 2 | 3 | The election process is administered and guided by 4 | the Election Officials. 5 | 6 | This group is responsible for working with the 7 | Architecture Committee (AC) on the election timeline, 8 | performing the preparation steps and carrying out all 9 | required communications. 10 | 11 | ## Pick election officials 12 | Election officials should not run in the election themselves. 13 | Ideally they should also have no interest in the election 14 | outcome (to preserve neutrality) but that is generally 15 | harder to achieve. 16 | 17 | Election officials should be identified by no later than a 18 | week prior to the start of the election. 19 | 20 | # Selecting Election Dates 21 | Things to keep in mind when selecting election dates: 22 | 23 | - Try to avoid overlapping with big in-person events 24 | in the interest for the community or major public holidays 25 | - Allow enough time for the contributors to decide if they 26 | are planning to run, and fulfill all the requirements to be 27 | able to participate 28 | - Allow at least a week for nomination and campaign periods 29 | - The current AC needs to approve the timeline once there 30 | is a proposal 31 | 32 | # Preparation 33 | As early as possible but at least a month before election 34 | starts: 35 | 36 | - Edit elections details (timeline, elected positions, deadlines) 37 | in the [community repo](https://github.com/kata-containers/community/tree/main/elections) 38 | - Create the PR to update the information on GitHub 39 | 40 | A couple of weeks before election starts: 41 | 42 | - Post information about the upcoming election on the 43 | kata-dev mailing list and on Slack 44 | - Generate an initial electorate list and share it with the 45 | AC and community to ensure that the list contains all active 46 | contributors 47 | 48 | # During the election 49 | ## AC Nomination Round 50 | When AC nomination period starts: 51 | 52 | - Send Kata AC Nomination period started email to kata-dev 53 | - Announce the start of the nomination period on Slack 54 | - Generate the final electorate list 55 | 56 | Email and Slack announcement tips: 57 | - Introduce yourself as election official 58 | - Announce start of process 59 | - List seats up for reelection 60 | - Provide timeline overview 61 | - Describe candidacy process 62 | - Describe voting eligibility 63 | - Link to references from kata-containers/community 64 | - Example email from an earlier cycle: [draft Etherpad](https://etherpad.opendev.org/p/r.256a531373da9595cf4c3af45bd58782) 65 | 66 | During the AC Candidacy round: 67 | - Election officials review the nominations on GitHub 68 | - A couple of days before the candidacy submission ends send 69 | reminders to the mailing list and Slack 70 | - Mention this is the last call for candidate nomination 71 | - Mention specifically the nomination deadline, and the 72 | full timeline 73 | - Example email from an earlier cycle: 74 | [September 2020 Kata Containers Architecture Committee elections candidate nomination reminder](https://lists.katacontainers.io/pipermail/kata-dev/2020-September/001512.html) 75 | 76 | When AC Candidacy submission ends: 77 | 78 | - Send Kata AC election - Nomination period ended email 79 | 80 | Once the email deadline is reached: 81 | 82 | - Check if there are enough candidate to run the election 83 | - If yes, generate the electorate rolls and move forward with 84 | the next steps of the process 85 | - If not, reach out to the AC and have the active members 86 | (whose seats are not up for re-election) officiate the results 87 | before the last steps of administration 88 | 89 | # AC Campaigning 90 | The AC election includes a period after the candidates are defined 91 | but before the election, for candidates to answer questions from 92 | the community. 93 | 94 | The questions will be hosted in the Community repo's 95 | [discussions board](https://github.com/kata-containers/community/discussions) 96 | and tagged with the election date/name for ease of searching. 97 | 98 | Open this with Kata AC election - Campaign period started email, and 99 | also announce it on Slack. 100 | 101 | # AC Election Round 102 | Before AC Election begins: 103 | 104 | - Create CIVS page 105 | - Title the poll:

Kata Architecture Committee Election Poll 106 | - Enable detailed ballot reporting 107 | - Send to other officials to verify 108 | - Check number of seats 109 | - Check closing date 110 | 111 | 112 | When AC Election begins: 113 | 114 | - Upload rolls 115 | - CIVS has a maximum number of electorate emails you can upload at a time without 116 | crashing, limit to 500 at a time 117 | - Send Kata AC election - Voting period started email, and announce the start 118 | of the voting period on Slack 119 | 120 | A couple of days before the AC Election ends: 121 | 122 | - Send Kata AC election - Voting period started reminder email and Slack 123 | note 124 | 125 | Ending the Kata AC Election: 126 | 127 | - Close the election and send Kata AC election - Voting period ended email, and 128 | announcement on Slack 129 | - Update the list of AC members and their terms on GitHub and create a PR 130 | - Send Kata AC Election Results email and Slack update 131 | -------------------------------------------------------------------------------- /elections/tools/README.md: -------------------------------------------------------------------------------- 1 | 2 | # Election Tools 3 | 4 | This directory contains tools that can help generate the Kata Containers eligible 5 | electorate details. 6 | 7 | ## `generate_electorate.py` 8 | 9 | The `generate_electorate.py` tool gathers data from GitHub and generates a `YAML` 10 | dataset containing the details of the eligible electorate for a defined date range. 11 | 12 | This tool needs the following python libraries: 13 | 14 | * `pytz` 15 | * `github3.py` 16 | * `pyyaml` 17 | 18 | To install them in a virtual environment do something like: 19 | 20 | ```bash 21 | $ python3 -m venv .venv 22 | $ .venv/bin/pip install pytz github3.py pyyaml 23 | ``` 24 | 25 | Before running the tool you will need to create a 26 | [GitHub API token](https://github.blog/2013-05-16-personal-api-tokens/) 27 | 28 | replace `__API_TOKEN__` in the script with your personal token. 29 | 30 | Also update the election start and end times to cover the period being 31 | examined for this election period. The lines to edit look like: 32 | 33 | ```python 34 | start_time = datetime.datetime(2018, 1, 1, 0, 0, 0, tzinfo=pytz.UTC) 35 | end_time = datetime.datetime(2018, 8, 1, 0, 0, 0, tzinfo=pytz.UTC) 36 | ``` 37 | 38 | Then run the tool with: 39 | 40 | ```bash 41 | $ .venv/bin/python ./generate_electorate.py 42 | ``` 43 | 44 | The code looks at all commits in all Kata Containers repos *except* 45 | `kata-containers/linux` and `kata-containers/qemu`. As both of these are forks 46 | (in the GitHub sense) they'll have lots of contributors that may not be Kata 47 | contributors. 48 | 49 | For contributors that have more than one email address it picks one as default 50 | but supplies all the others so we can be smarter about where to send the 51 | emails. 52 | 53 | The sources for email addresses are: 54 | * GitHub account 55 | * Git commit data 56 | * Look for a `Signed-Off-By` line in the commit message 57 | 58 | The GitHub login is always stored so that is the primary identifier. 59 | 60 | ## Output results 61 | 62 | As the script runs it prints a summary on `stdout`. When the script has completed it places the 63 | generated data into a file called `electorate.yaml`. Use this file to send the bulk email notification 64 | to the eligible electorate. 65 | -------------------------------------------------------------------------------- /elections/tools/generate_electorate.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | 3 | # 4 | # Copyright (c) 2023 Kata Contributors 5 | # 6 | # SPDX-License-Identifier: Apache-2.0 7 | # 8 | # Description: Generate a list of kata contributors by extracting contact 9 | # information from GitHub 10 | 11 | import datetime 12 | import pytz 13 | import re 14 | import yaml 15 | 16 | from collections import OrderedDict 17 | from github3 import login 18 | 19 | 20 | class AuthorSet(set): 21 | pass 22 | 23 | 24 | def _authorset_representer(dumper, data): 25 | return dumper.represent_list(sorted(list(data))) 26 | 27 | 28 | class Author(object): 29 | def __init__(self, id, name=None, email=None): 30 | self.id = id 31 | self.name = name 32 | self._emails = set() 33 | if email: 34 | self._emails.add(email) 35 | self.commit_count = 0 36 | 37 | @property 38 | def email(self): 39 | emails = list(self._emails or []) 40 | if emails: 41 | # This is horrible simplistic and probably wont work long term. 42 | return sorted(emails)[0] 43 | return None 44 | 45 | @email.setter 46 | def email(self, email): 47 | self._emails.add(email) 48 | 49 | def __eq__(self, other): 50 | return self.id == other.id 51 | 52 | def __lt__(self, other): 53 | return self.id < other.id 54 | 55 | def __hash__(self): 56 | return hash(self.id) 57 | 58 | 59 | def _author_representer(dumper, data): 60 | o_dict = OrderedDict(github_id=data.id, 61 | name=data.name, 62 | email=data.email, 63 | # _emails is a private member and we probably 64 | # shouldn't do this but it might be needed for 65 | # post-processing 66 | emails=list(data._emails), 67 | commit_count=data.commit_count) 68 | return dumper.represent_dict(o_dict.items()) 69 | 70 | 71 | dco_re = re.compile('signed.off.by[: ]*(?P[^<]*)<(?P.*)>$', 72 | re.IGNORECASE | re.MULTILINE) 73 | # Get a token GitHub Personal API token see: 74 | # https://blog.github.com/2013-05-16-personal-api-tokens/ 75 | # for more information. 76 | gh = login(token='__API_TOKEN__') 77 | org = gh.organization('kata-containers') 78 | # Example dates for testing. 79 | start_time = datetime.datetime(2018, 1, 1, 0, 0, 0, tzinfo=pytz.UTC) 80 | end_time = datetime.datetime(2018, 8, 1, 0, 0, 0, tzinfo=pytz.UTC) 81 | # ... Or run just include all commits 82 | # start_time = end_time = None 83 | # All commits 84 | number = -1 85 | projects = [] 86 | ignored_repos = [ 87 | 'cgroups-rs', 88 | 'dbs-snapshot', 89 | 'edk2', 90 | 'qemu', 91 | 'linux', 92 | 'project-infra', 93 | 'govmm', 94 | 'resolve-pr-refs', 95 | 'is-organization-member', 96 | 'osbuilder', 97 | 'proxy', 98 | 'runtime', 99 | 'shim', 100 | 'packaging', 101 | 'ksm-throttler', 102 | 'documentation', 103 | 'agent', 104 | 'slash-command-action', 105 | 'tests-1', 106 | 'kata-containers-github-actions-tests', 107 | 'kata-containers-cache-kernel', 108 | 'kata-containers-2', 109 | 'kata-containers-1', 110 | ] 111 | 112 | author_cache = {} 113 | for repo in org.repositories(): 114 | # Skip these repos as they are not a core part of the project, and are 115 | # forked/imported so contain many contributors from outside the project. 116 | if str(repo).split("/")[1] in ignored_repos: 117 | print('Skipping repo %s' % (repo)) 118 | continue 119 | print('Looking for changes in %s between %s and %s' % 120 | (repo, start_time, end_time)) 121 | 122 | authors = AuthorSet() 123 | for branch in repo.branches(): 124 | for commit in repo.commits(sha=branch.name, since=start_time, until=end_time, 125 | number=number): 126 | if commit.author is None: 127 | if commit.commit.author is None: 128 | print('Skipping %s in %s as it has no author. Did this merge via GitHub?' % 129 | (commit, repo)) 130 | continue 131 | 132 | author_id = commit.commit.author.get('email') 133 | print('%s in %s as has no author. Using email (%s) as the author id' % 134 | (commit, repo, author_id)) 135 | else: 136 | author_id = commit.author.login 137 | 138 | if author_id not in author_cache: 139 | if commit.author is None: 140 | author = Author(author_id, email=author_id, 141 | name=commit.commit.author.get('name')) 142 | else: 143 | _author = gh.user(commit.author.login) 144 | author = Author(_author.login, email=_author.email, 145 | name=_author.name) 146 | 147 | author_cache[author_id] = author 148 | 149 | author = author_cache[author_id] 150 | author.commit_count += 1 151 | 152 | # If the GitHub account doesn't have a name or email address 153 | # the author *may* have included it in their git config. 154 | if author.email is None and commit.commit.author.get('email'): 155 | author.email = commit.commit.author.get('email') 156 | if author.name is None and commit.commit.author.get('name'): 157 | author.name = commit.commit.author.get('name') 158 | 159 | # last ditch effort did the author use a valid email address in the 160 | # DCO line? 161 | match = dco_re.search(commit.message) 162 | if match: 163 | if ((author.email is None or 164 | 'users.noreply.github.com' in author.email) and 165 | match.group('email')): 166 | author.email = match.group('email') 167 | if author.name is None and match.group('name'): 168 | author.name = match.group('name') 169 | authors.add(author) 170 | projects.append({str(repo): authors}) 171 | 172 | # Dark YAML voodoo 173 | yaml.Dumper.ignore_aliases = lambda *args: True 174 | yaml.Dumper.add_representer(AuthorSet, _authorset_representer) 175 | yaml.Dumper.add_representer(Author, _author_representer) 176 | with open('electorate.yaml', 'w') as f: 177 | yaml.dump(projects, f, default_flow_style=False, default_style='', 178 | explicit_start=True) 179 | -------------------------------------------------------------------------------- /fig1-ci-cd-failure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kata-containers/community/6023dab06b23e26e953804c476b69bf44d9371f2/fig1-ci-cd-failure.png -------------------------------------------------------------------------------- /fig2-ci-cd-log.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kata-containers/community/6023dab06b23e26e953804c476b69bf44d9371f2/fig2-ci-cd-log.png -------------------------------------------------------------------------------- /statusreports/REPORT_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # [YYYY-MM-DD] Week in Review 2 | 3 | ### Notable Pull Requests/Issues 4 | 5 | - Was something significant merged in the last week? [Resolves #115](https://example.com/resolved/pull/request) 6 | - Was a PR submitted for a significant change? [In Progress #120](https://example.com/pull/request) 7 | - Is there new/dynamic conversation happening about a PR/issue that readers should look at? [Issue #100](https://example.com/open/issue) 8 | 9 | ### Mailing List Discussions 10 | 11 | - Discussions happening that readers should look at (summarize and point to ML archives) 12 | 13 | ### Community Updates 14 | 15 | - Is someone presenting a talk? 16 | - Noteworthy Kata news? (i.e. "Became an OCI member this week") 17 | --------------------------------------------------------------------------------