diff --git a/.ci/static-checks.sh b/.ci/static-checks.sh new file mode 100755 index 0000000000..087575460f --- /dev/null +++ b/.ci/static-checks.sh @@ -0,0 +1,33 @@ +#!/bin/bash +# +# Copyright (c) 2024 IBM Corporation +# +# SPDX-License-Identifier: Apache-2.0 + +set -e + +export kata_repo="${kata_repo:-github.com/kata-containers/kata-containers}" +export kata_repo_dir="$GOPATH/src/$kata_repo" +export kata_default_branch="${kata_default_branch:-main}" + + +clone_kata_repo() { + if [ ! -d "${kata_repo_dir}" ]; then + mkdir -p "${kata_repo_dir}" + git clone "https://${kata_repo}.git" "${kata_repo_dir}" + pushd "${kata_repo_dir}" || exit + # Checkout to default branch + git checkout "${kata_default_branch}" + popd || exit + fi +} + +run_static_checks() +{ + clone_kata_repo + INSTALL_IN_GOPATH=false bash "${kata_repo_dir}/ci/install_yq.sh" + bash "${kata_repo_dir}/tests/install_go.sh" -f -p + bash "${kata_repo_dir}/tests/static-checks.sh" "github.com/kata-containers/community" +} + +run_static_checks diff --git a/.github/workflows/PR-wip-checks.yaml b/.github/workflows/PR-wip-checks.yaml index 3b13b31605..f5b1b96478 100644 --- a/.github/workflows/PR-wip-checks.yaml +++ b/.github/workflows/PR-wip-checks.yaml @@ -9,20 +9,13 @@ on: - labeled - unlabeled -permissions: - contents: read - -concurrency: - group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} - cancel-in-progress: true - jobs: pr_wip_check: - runs-on: ubuntu-22.04 + runs-on: ubuntu-24.04 name: WIP Check steps: - name: WIP Check - uses: tim-actions/wip-check@1c2a1ca6c110026b3e2297bb2ef39e1747b5a755 # master (2021-06-10) + uses: tim-actions/wip-check@1c2a1ca6c110026b3e2297bb2ef39e1747b5a755 with: labels: '["do-not-merge", "wip", "rfc"]' keywords: '["WIP", "wip", "RFC", "rfc", "dnm", "DNM", "do-not-merge"]' diff --git a/.github/workflows/dco-check.yaml b/.github/workflows/dco-check.yaml new file mode 100644 index 0000000000..803d880d6e --- /dev/null +++ b/.github/workflows/dco-check.yaml @@ -0,0 +1,22 @@ +name: DCO check +on: + pull_request: + types: + - opened + - reopened + - synchronize + +jobs: + dco_check_job: + runs-on: ubuntu-24.04 + name: DCO Check + steps: + - name: Get PR Commits + id: 'get-pr-commits' + uses: tim-actions/get-pr-commits@ed97a21c3f83c3417e67a4733ea76887293a2c8f + with: + token: ${{ secrets.GITHUB_TOKEN }} + - name: DCO Check + uses: tim-actions/dco@2fd0504dc0d27b33f542867c300c60840c6dcb20 + with: + commits: ${{ steps.get-pr-commits.outputs.commits }} diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml new file mode 100644 index 0000000000..d78c970c3f --- /dev/null +++ b/.github/workflows/main.yml @@ -0,0 +1,22 @@ +on: ["pull_request"] +name: Static checks +jobs: + static-checks: + runs-on: ubuntu-24.04 + env: + GOPATH: ${{ github.workspace }} + steps: + - name: Checkout code + uses: actions/checkout@v4 + with: + fetch-depth: 0 + path: ./src/github.com/${{ github.repository }} + + - name: Install system dependencies + run: | + sudo apt-get -y install moreutils hunspell hunspell-en-gb hunspell-en-us pandoc + + - name: Running static checks + run: | + export PATH=${GOPATH}/bin:${PATH} + ./src/github.com/${{ github.repository }}/.ci/static-checks.sh diff --git a/AC-Meeting-Guidelines.md b/AC-Meeting-Guidelines.md new file mode 100644 index 0000000000..ce58df9f0b --- /dev/null +++ b/AC-Meeting-Guidelines.md @@ -0,0 +1,63 @@ +**Important:** + +Do **not** follow this process if you think you have discovered a vulnerability. +Instead, please use the [VMT](https://github.com/kata-containers/community/blob/master/VMT/VMT.md) +process. + +# Architecture Committee Meeting Guidelines + +The Architecture Committee (AC) recommends following a set of guidelines for +raising issues and adding topics to the meeting agenda. + +## Use a GitHub issue first + +For a project like Kata Containers, with contributors spanning across so many +different time zones, asynchronous discussions and reviews are the preferred +communication media. + +Directly starting a proposal or trying to resolve new technical issues through +the AC meeting has many drawbacks: +* It potentially leaves a large part of the community out of the initial + dicussion. +* It does not give the AC meeting audience enough time to think through + the proposal and give constructive and well thought feedback. +* It makes it hard to track and share the discussion outcome. + +As a consequence, the AC recommends using [GitHub issues](https://github.com/kata-containers/kata-containers/issues) +at first before adding new items to the AC meetings agenda, especially +if you think the topic could be discussed and resolved in less than two weeks. + +## AC Agenda topics must be supported by a GitHub issue or a PR + +Except for a few cases listed in the next section, any topic brought to the AC +meeting must be linked to a GitHub issue or a PR that should contain a +`cc @kata-containers/architecture-committee` in order to notify AC members of +the creation of a new AC meeting proposal. + +Unless the topic must be urgently discussed, the AC recommends waiting for one +or two weeks before bringing the discussion to the AC meeting. That will give +enough time for interested contributors to digest the issue or proposal before +having a live discussion in the AC meeting. + +### Exceptions + +* Announcements +* Presentations +* Call for reviews of articles, blog posts, etc. + +## AC agenda topics should have well defined expectations + +When adding a topic to the agenda, one should have clearly defined expectations: +**"What do I want to get from the community and the AC with that discussion?"**. + +For instance: +* Are you looking for a possible **solution** to a problem exposed through + GitHub or the mailing list? +* Are you looking for a **resolution** of a conflict in a pull request? +* Are you looking for a [**"go-nogo"**](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#submit-issues-before-prs) + from the community in order to start working on something? +* Are you looking for technical **feedback and guidelines** on a pending + technical proposal? + +Answering those questions and clearly stating the expectations upfront will +help with steering the AC meeting discussions in the right direction. diff --git a/Backport-Guide.md b/Backport-Guide.md new file mode 100644 index 0000000000..d31c194ae2 --- /dev/null +++ b/Backport-Guide.md @@ -0,0 +1,222 @@ +# Kata Containers stable backport workflow + +* [Introduction](#introduction) +* [Assumptions](#assumptions) +* [Graphical overview of backporting](#graphical-overview-of-backporting) + * [Before the backport](#before-the-backport) + * [After the backport](#after-the-backport) +* [Backport Workflow](#backport-workflow) + * [Setup](#setup) + * [Locate commits to cherry pick](#locate-commits-to-cherry-pick) + * [Apply the commits](#apply-the-commits) + * [Check the result](#check-the-result) + * [Raise a PR](#raise-a-pr) +* [Further information](#further-information) + +## Introduction + +This document provides a short guide explaining how to perform a backport. +Backporting refers to applying changes to a stable branch from a newer branch. +The changes comprise one or more commits in the form of a PR and the newer +branch is generally the `main` branch. + +Since new features are not added to stable branches, backported changes are +generally bug fixes and security fixes. See the +[stable branch strategy](https://github.com/kata-containers/documentation/blob/master/Stable-Branch-Strategy.md) +document for further details. + +> **Note:** This guide does not cover all eventualities that might be +> encountered while performing a backport, and only documents one potential +> Git based workflow. It does serve as a short introduction and reminder of +> the basic stable backport process. + +The two branches used in the examples in this guide are: + +- The `main` branch (which contains all commits). +- A `stable-1.2` branch which will be the target of the backport: commits will + be selectively "copied" ("cherry-picked") into this branch from the `main` branch. + +## Assumptions + +This document assumes an understanding of: + +- The `git(1)` tool. +- The [standard PR workflow](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#pull-requests). +- The [stable branch strategy](https://github.com/kata-containers/documentation/blob/master/Stable-Branch-Strategy.md). + +## Graphical overview of backporting + +### Before the backport + +Imagine that initially both the `main` branch and the stable branch +(`stable-1.2`) contain only the commits `A`, `B` and `C`: + +``` + + (stable-1.2 branch) + / +A---B---C (main branch) +``` + +New commits (`D`, `E`, `F` and `G`) are added to the `main` branch: + +``` + + (stable-1.2 branch) + / +A---B---C---D---E---F---G (main branch) +``` + +Imagine that: + +- Commits `E` and `G` are bug or security fixes which need to be backported. +- Commits `D` and `F` are new features which must *not* be backported. + +### After the backport + +After the backporting: + +``` + +-----E-------G (stable-1.2 branch) + / ^ ^ +A---B---C---D---E---F---G (main branch) +``` + +After the backport, the `stable-1.2` branch contains commits `A`, `B` and +`C`, `E` and `G`. + +## Backport Workflow + +### Auto-backporting +Auto-backporting is a helpful feature than can be used to speed up the backport process. +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. + +The following PRs will automatically have the `auto-backport` label added: +- PRs whose [associated issue](CONTRIBUTING.md#submit-issues-before-prs) has the `bug` label set. +- PR contains `backport-needed` label + +PRs with the `no-backport-needed` label will automatically have their `auto-backport` label removed, superseding the above conditions. + +Additionally, the `auto-backport` label can be added or removed manually. +> **Note:** The check for labels is triggered whenever a label is added or removed from the PR. + +The Backport Action executes the following steps: +- `auto-backport` label is checked when the PR is merged. +- The action will look for all labels of the form`backport-to-BRANCHNAME`. +- The action will then attempt to generate a backport for each label, leaving a notification reporting success or failure. + +> **Note:** This does require labels to be made and added to the corresponding branches that one intends to backport to. + +Automatic backports should be reviewed for correctness. + +### Manual Backporting +The basic workflow involves: + +- Creating a new local branch from the stable tree you are targeting. +- Selecting (or "cherry picking") the commits from your main branch PR into the stable branch. +- Submitting your branch to GitHub as a PR against the stable branch (not to the `main` branch). + +### Setup + +- Ensure your local repo is up to date: + + ```bash + $ cd ${GOPATH}/src/github.com/kata-containers/runtime + $ git fetch origin + ``` + + Check the list of stable branches: + + ```bash + $ git branch -r | grep origin/stable + ``` + +- Create your branch to work on, based on the `stable-1.2` branch: + + ```bash + $ git checkout -b my_1.2_pr_backport origin/stable-1.2 + ``` + +### Locate commits to cherry pick + +To list all commits in the `main` branch which are not in the `stable-1.2` +branch: + +```bash +$ git log --oneline --no-merges ..main +``` + +Make a note of the SHA values for the commits in the PR to backport. + +> **Note:** If your PR is in a local branch, substitute `main` for the name +> of that branch. + +### Apply the commits + +- Pull in your commits: + + If you are pulling the commits in from the `main` branch, you can add the `-x` + argument to `git cherry-pick` to automatically add a reference in the + commit to the original commits. This is strongly recommended to aid traceability. + If you pick the commits from your local branch do *not* use `-x`; this + potentially adds references to SHAs that only exist in your local branch, which + is not useful for future tracability. + + It is also required that you add the `-s` signoff to the commits, if you did not + create the original commits. + + ```bash + $ git cherry-pick -x ... + ``` + + > **Note:** You should only cherry pick the original commits - do **not** + > cherry pick merge commits + > (see [Locate commits to cherry pick](#locate-commits-to-cherry-pick)). + + You can cherry pick ranges of commits. Please see the `git-cherry-pick(1)` + man page for more information. + + > **Note:** You do not need to open a new `Issue` or add an extra `Fixes: nnn` item + > to the commits. They should re-use the `Fixes:` entry from the original commits, + > so all related commits refer back to the common Issue. It does not matter that + > the original `Issue` is closed, the references still work correctly. + +- Resolve any conflicts: + + You might encounter conflicts during your cherry pick, which need to be resolved + before you continue. Follow standard practices for Git conflict resolution, and see + the guidance printed by `git cherry-pick` on processing and applying those fixes. + + If you hit a conflict, any effects of `-x` to `cherry-pick` might not be + applied. In this case, consider hand-adding the `main` SHA references and a note + that you resolved a conflict to the commit message. + +### Check the result + +- Test your changes: + + Before you push your changes, you should test that they work and nothing has been + broken. No matter how small the change, running the test suite is always recommended. + +### Raise a PR + +- Push your branch to your GitHub repo: + + ```bash + $ git push my_remote my_1.2_pr_backport + ``` + +- Submit a PR from your branch to *the stable branch*: + + When you submit your PR on GitHub, make sure to choose the stable branch that you + based your branch on and are submitting to. This *should* be the same as the + base branch for the PR. + +- Add a special comment to the *original* PR with a reference to the backport + PR(s). See the [contributing guide](CONTRIBUTING.md#porting-comments) for + further information. + +- Add the `backport` label to the PR to denote it is a backport. + +## Further information + +For further information on porting, see the [contributing +guide](CONTRIBUTING.md#porting). diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index ecec016c33..78cddb618e 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,3 +1,7 @@ ## Kata Containers Code of Conduct +<<<<<<< HEAD Kata Containers follows the [OpenStack Foundation Code of Conduct](https://www.openstack.org/legal/community-code-of-conduct/). +======= +Kata Containers follows the [Open Infrastructure Foundation Code of Conduct](https://www.openstack.org/legal/community-code-of-conduct/). +>>>>>>> 6023dab06b23e26e953804c476b69bf44d9371f2 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c14210fdbe..3d8f06ccc0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,982 @@ +<<<<<<< HEAD # Contributing ## This repo is part of [Kata Containers](https://katacontainers.io) For details on how to contribute to the Kata Containers project, please see the main [contributing document](https://github.com/kata-containers/community/blob/main/CONTRIBUTING.md). +======= +# Contribute to the Kata Containers project + +* [Code of Conduct](#code-of-conduct) +* [Pull requests](#pull-requests) +* [GitHub basic setup](#github-basic-setup) + * [Prerequisites](#prerequisites) + * [Contributor roles](#contributor-roles) + * [Golang coding style](#golang-coding-style) + * [Rustlang coding style](#rustlang-coding-style) + * [Certificate of Origin](#certificate-of-origin) +* [GitHub best practices](#github-best-practices) + * [Submit issues before PRs](#submit-issues-before-prs) + * [Issue tracking](#issue-tracking) + * [Closing issues](#closing-issues) +* [GitHub workflow](#github-workflow) + * [Configure your environment](#configure-your-environment) + * [GitHub labels and keywords that block PRs](#github-labels-and-keywords-that-block-prs) +* [Re-vendor PRs](#re-vendor-prs) +* [Use static checks for validation](#use-static-checks-for-validation) + * [Fix failed static checks after submitting PRs](#fix-failed-static-checks-after-submitting-prs) + * [Kata runtime static checks](#kata-runtime-static-checks) +* [Porting](#porting) + * [Porting labels](#porting-labels) + * [Stable branch backports](#stable-branch-backports) + * [Porting issue numbers](#porting-issue-numbers) + * [Porting comments](#porting-comments) + * [Forward ports](#forward-ports) + * [Porting examples](#porting-examples) +* [Patch format](#patch-format) + * [General format](#general-format) + * [Subsystem](#subsystem) + * [Best practices for patches](#best-practices-for-patches) + * [Verification](#verification) + * [Examples](#examples) +* [Reviews](#reviews) + * [Review Examples](#review-examples) +* [Continuous Integration](#continuous-integration) +* [Contact](#contact) +* [Project maintainers](#project-maintainers) + +The Kata Containers project is an open source project licensed under the +[Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0). + +It comprises a number of repositories under the [GitHub Kata +Containers organisation](https://github.com/kata-containers). Unless +explicitly stated otherwise, all the Kata Containers repositories follow the +process documented here. + +## Code of Conduct + +All contributors must agree to the project [code of conduct](CODE_OF_CONDUCT.md). + +## Pull requests + +All the repositories accept contributions via [GitHub Pull requests (PR)](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests). Submit PRs by following the [GitHub workflow](#github-workflow). + +## GitHub basic setup + +To get started, complete the prerequisites below. + +### Prerequisites + +- Review [Contributor roles](#contributor-roles) that require special Git + configuration. + +- [Set up Git](https://help.github.com/en/github/getting-started-with-github/set-up-git). + + >**Note:** The email address you specify must match the email address you + >use to sign-off commits. + +- [Fork and Clone](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) the relevant repository at the + [Kata Containers Project](https://github.com/kata-containers). + + Example: Your local clone should show `your-github-username`, as follows. + `https://github.com/${your-github-username}/community`. + +### Contributor roles + +Special Git configuration is required for these contributors: + +* [Golang coding style](#golang-coding-style) +* [Rustlang coding style](#rustlang-coding-style) +* [Kata runtime static checks](#kata-runtime-static-checks) + +For all other contributor roles, follow the standard configuration, shown in +Prerequisites. + +### Golang coding style + +* Review [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments) to avoid common `Golang` errors. +* Use `gofmt` to fix any mechanical style issues. + +### Rustlang coding style + +* Use `rustfmt` to fix any mechanical style issues. `Rustfmt` uses a style which conforms to the +[Rust Style Guide](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/guide.md). +* Use `clippy` to catch common mistakes and improve your Rust code. + +You can install the above tools as follows. + +```sh +$ rustup component add rustfmt clippy +``` + +### Certificate of Origin + +In order to get a clear contribution chain of trust we use the [signed-off-by +language](https://ltsi.linuxfoundation.org/software/signed-off-process/) +used by the Linux kernel project. + +## GitHub best practices + +### Submit issues before PRs + +Raise a GitHub issue **before** starting work on a PR. + +* Our process requires an issue to be associated with every PR (see [patch format](#patch-format)) + +* If you are a new contributor, create an issue and add a comment stating +that you intend to work on the issue. This notifies our team of the work you +plan to do. + +### Issue tracking + +To report a bug that is not already documented, please open a GitHub issue for the repository in question. + +If it is unclear which repository to raise your query against, first try to +get in [contact](#contact) with us. If in doubt, raise the issue +[here](https://github.com/kata-containers/community/issues/new) and we will +help you to handle the query by routing it to the correct area for resolution. + +### Closing issues + +Our tooling requires adding a `Fixes` comment to at least one commit in the PR, which triggers GitHub to automatically close the issue once the PR is merged: + +``` +pod: Remove token from Cmd structure + +The token and pid data will be hold by the new Process structure and +they are related to a container. + +Fixes #123 + +Signed-off-by: Sebastien Boeuf +``` + +The issue is automatically closed by GitHub when the +[commit message](https://help.github.com/articles/closing-issues-via-commit-messages/) is parsed. + +## GitHub workflow + +Kata Containers employs certain augmentations to a +[standard GitHub workflow](https://guides.github.com/introduction/flow/). +In this section, we explain these augmentations in more detail. Follow these guidelines when contributing to Kata Containers repositories, except where noted below. + +* Complete the [GitHub basic setup](#github-basic-setup) above before continuing. + +* Ensure each PR only covers one topic. If you mix up different items in + your patches or PR, they will likely need to be reworked. + +* Follow a [topic branch method](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches) for development. + +* Follow carefully the [patch format](#patch-format) for PRs. + +* Apply the appropriate GitHub labels to your PR. This + is particularly relevant to maintain [Stable branch backports](#stable-branch-backports). See also [GitHub labels and keywords that block PRs](#github-labels-and-keywords-that-block-prs) + + >**Note:** External contributors should use keywords, explained in the + >link above. Labels may not be visible to external contributors. + +* [Rebase](https://help.github.com/en/github/using-git/about-git-rebase) + commits on your branch and `force push` after each cycle of feedback. + +### Configure your environment + +Most [Kata Containers repositories](https://github.com/kata-containers) +contain code written in the [Go language (golang)](https://golang.org/). Go +requires all code to be put inside the directory specified by the `$GOPATH` +variable. Follow this example to put the code in the standard location. + +```sh +$ export GOPATH=${GOPATH:-$HOME/go} +$ mkdir -p "$GOPATH" +``` + +For further details on `golang`, refer to the +[requirements section of the Kata Developer Guide](https://github.com/kata-containers/kata-containers/blob/main/docs/Developer-Guide.md#requirements-to-build-individual-components). + +>*Note*: If you intend to make minor edits, it's acceptable +> to simply fork and clone without adding the GOPATH variable. + +#### Fork and clone + +In this example, we configure a Git environment to contribute to this very +`Community` repo. We create a sample branch, incorporate reviewer feedback, and rebase our commits. + +1. Fork the [upstream repository](https://help.github.com/articles/cloning-a-repository): + +1. [Clone your forked copy of the upstream repository](https://help.github.com/articles/cloning-a-repository): + +1. While on your *forked copy*, select the green button `Clone or download` + and copy the URL. + +1. Run the commands below and **paste the copied URL** (previous step), + so your real GitHub user name replaces `your-github-username` below. + +```sh +$ dir="$GOPATH/src/github.com/kata-containers" +$ mkdir -p "$dir" +$ cd "$dir" +$ git clone https://github.com/{your-github-username}/community +$ cd community +``` + +>**Note:** Cloning a forked repository automatically gives a remote `origin`. + +#### Configure the upstream remote + +Next, add the remote `upstream`. Configuring this remote allows you to +synchronize your forked copy, `origin`, with the `upstream`. The +`upstream` URL varies by repository. We use the `upstream` from the Community for this example. + +1. Change directory into `community`. + +1. Set the remote `upstream` as follows. + + ```sh + $ git remote add upstream https://github.com/kata-containers/community + ``` + +1. Run `git remote -v`. Your remotes should appear similar to these: + + ``` + origin https://github.com/your-github-username/community.git (fetch) + origin https://github.com/your-github-username/community.git (push) + upstream https://github.com/kata-containers/community (fetch) + upstream https://github.com/kata-containers/community (push) + ``` + +For more details, see how to [set up a git remote](https://help.github.com/articles/configuring-a-remote-for-a-fork). + +#### Create a topic branch + +1. Create a new "topic branch" to do your work on: + + ``` + $ git checkout -b fix-contrib-bugs + ``` + + >**Warning:** *Never* make changes directly to the `main` branch + >--*always* create a new "topic branch" for PR work. + +1. Make some editorial changes. In this example, we modify the file that + you are reading. + + ``` + $ $EDITOR CONTRIBUTING.md + ``` + + >**Note:** If editing in Windows make sure that all documents end with LF + > and not CRLF. The CI system will fail if carriage returns are in the + > document. Many editors support the ability to change this. There is a + > tool called dos2unix available on Git Bash for Windows and also available + > on Linux systems that can convert files to LF endings. See the + > [Configuring Git to handle line endings](https://docs.github.com/en/github/getting-started-with-github/getting-started-with-git/configuring-git-to-handle-line-endings) + > guide for more details on how to configure `git` to automatically insert + > the correct line endings. + +1. Commit your changes to the current (`fix-contrib-bugs`) branch. Assure + you use the correct [patch format](#patch-format): + + ``` + $ git commit -as + ``` + +1. Push your local `fix-contrib-bugs` branch to your remote fork: + + ``` + $ git push -u origin fix-contrib-bugs + ``` + + >**Note:** The `-u` option tells `git` to "link" your local clone with + > your remote fork so that it knows from now on that the local repository + > and the remote fork refer to "the same" upstream repository. Strictly + >speaking, this option is only required the first time you call `git push` + >for a new clone. + +1. Create the PR: + - Browse to https://github.com/kata-containers/community. + - Click the "Compare & pull request" button that appears. + - Click the "Create pull request" button. + + >**Note:** You do not need to change any of the defaults on this page. + +#### Update your PR based on review comments + +Suppose you received some reviewer feedback that asked you to make some +changes to your PR. You updated your local branch and committed those +review changes by creating three commits. There are now four commits in your +local branch: the original commit you created for the PR and three other +commits you created to apply the review changes to your branch. Your branch +now looks something like this: + +```sh +$ git log main.. --oneline --decorate=no +4928d57 docs: Fix typos and fold long lines +829c6c8 apply review feedback changes +7c9b1b2 remove blank lines +60e2b2b doh - missed one +``` + +>**Note:** The `git log` command compares your current branch +>(`fix-contrib-bugs`) with the `main` branch and lists all the commits, +>one per line. + +#### Git rebase if multiple commits + +Since all four commits are related to *the same change*, it makes sense to +combine all four commits into a *single commit* on your PR. You need to +[git rebase](https://help.github.com/github/using-git/about-git-rebase) +multiple commits on your branch. Follow these steps. + +1. Update the `main` branch in your local copy of the upstream + repository: + + ``` + $ cd $GOPATH/src/github.com/kata-containers/community + $ git checkout main + $ git pull --rebase upstream main + ``` + + The previous command downloads all the latest changes from the upstream + repository and adds them to your *local copy*. + +1. Now, switch back to your PR branch: + + ``` + $ git checkout fix-contrib-bugs + ``` + +1. Rebase your changes against the `main` branch. + + ```sh + $ git rebase -i main + ``` + + Example output: + + ```sh + pick 2e335ac docs: Fix typos and fold long lines + pick 6d6deb0 apply review feedback changes + pick 23bc01d remove blank lines + pick 3a4ba3f doh - missed one + ``` + +1. In your editor, read the comments at the bottom of the screen. + Do not modify the first line, `pick 2e335ac docs: Fix typos ...`. Instead, revise `pick` to `squash` at the start of all following lines. + + Example output: + + ```sh + pick 2e335ac docs: Fix typos and fold long lines + squash 6d6deb0 apply review feedback changes + squash 23bc01d remove blank lines + squash 3a4ba3f doh - missed one + ``` + +1. Save your changes and quit the editor. Git puts you *back* into your + editor. You will see all the commit *messages*. + +1. At top is your first commit, which should be in the + [correct format](#patch-format). Keep your first commit and delete + all the following commits, as appropriate, based on + the review feedback. + +1. Save the file and quit the editor. Once this operation completes, the four + commits will have been converted into a single new commit. Check this by + running the `git log` command again: + + ```sh + $ git log main.. --oneline --decorate=no + 3ea3aef docs: Fix typo + ``` + +1. Force push your updated local `fix-contrib-bugs` branch to `origin` + remote: + + ```sh + $ git push -f origin fix-contrib-bugs + ``` + +>**Note:** Not only does this command upload your changes to your fork, it +>also includes the *latest upstream changes* to your fork since you ran +>`git pull --rebase upstream main` on the main branch and then merged +>those changes into your PR branch. This ensures your fork is now "up to +>date" with the upstream repository. The `-f` option is a "force push". Since +>you created a new commit using `git rebase`, you must "overwrite" the old +>copy of your branch in your fork on GitHub. + +Your PR is now updated on GitHub. To ensure team members are aware of this, +leave a message on the PR stating something like, "Review feedback applied". +This notification allows the team to once again review your PR more quickly. + +### GitHub labels and keywords that block PRs + +Kata Containers CI systems have two methods that allow marking +PRs to prevent them being merged. This practice is often used during +development. The two methods are: 1) Use +[GitHub labels](https://help.github.com/articles/about-labels/) +or; 2) Use keywords in the PR subject line. The keywords can appear anywhere +in the subject line. + +The following table summarises some common scenarios and appropriate use +of labels or keywords: + +| Scenario | GitHub label | PR description contains | +| -------- | ------------ | ----------------------- | +| PR created "as an idea" and feedback sought | `rfc` | RFC | +| PR incomplete - needs more work or rework | `do-not-merge` `wip` | WIP | +| PR should not be merged (has all required "acks", but needs more reviewer input) | `do-not-merge` | | +| PR is a "work In progress", raised to get early feedback | `wip` | WIP | +| PR is complete but depends on another so should not be merged (yet) | `do-not-merge` | | + +If any of the values in the table above are set on a PR, it will be +automatically blocked from merging. + +>**Note:** Often during discussions, the abbreviated and full terms are +>used interchangeably. For instance, often `DNM` is used in discussions as +>shorthand for `do-not-merge`. The CI systems only recognise the above +>phrases as shown. + +## Re-vendor PRs + +If you raise a PR to update the vendored copy of one or more golang packages, +after running the +[`dep`](https://github.com/kata-containers/community/blob/main/VENDORING.md) command, ensure you add any modified files under the `vendor/` directory to Git before committing the changes: + +```sh +$ git add vendor/ +``` + +There are two critical pieces of information you need to add to the commit +body: + +- A brief explanation why the re-vendor is required. + + For example, you should state if an important bug fix or new feature is + required, or if a particular commit is needed. + +- The range of commits being added for these third-party packages. + + It is possible that re-vendoring a particular package will also result in + updates to other dependent packages. However, it is important to include + the commit range (even if it is big) for the primary package(s) the + re-vendor PR is raised for. + + These details allow for easier troubleshooting if the re-vendor PR + introduces bug or behavioral changes. + + Generate the list of new commits added to the primary re-vendored + package by comparing the previous and latest commits for the package being re-vendored. + + The following example lists the steps you should take if a new version of + `libcontainer` (part of the `runc` repository) is required: + + 1. Determine the previous and latest commits for the package by looking at + the `diff` of the `Gopkg.toml` file in your branch. + + 1. Run the commands below: + + ```bash + $ go get -d -u github.com/opencontainers/runc + $ cd $GOPATH/src/github.com/opencontainers/runc + $ old_commit="..." + $ new_commit="..." + $ git log --no-merges --abbrev-commit --pretty=oneline "${old_commit}..${new_commit}" | sed 's/^/ /g' + ``` + + Paste the output of the previous command directly into the commit "as-is". + Note that the four space indent added by the `sed` command is used to force + GitHub to render the list in a fixed-width font, which makes it easier to + read. + +For additional information on using the `dep` tool, see +"[Performing vendoring for the Kata Containers project](https://github.com/kata-containers/community/blob/main/VENDORING.md)". + +## Use static checks for validation + +* Kata Containers utilizes [Continuous Integration (CI)](#continuous-integration) to automatically check every PR. + +* We strongly encourage you to run the same CI tests on individual PRs, using [static checks](https://github.com/kata-containers/tests/blob/main/.ci/static-checks.sh) + +In repositories where a `Makefile` is present, you can execute +static checks for testing and development. To do so, invoke the `make check` and `make test` rules, after developer mode is enabled. + +```sh +$ export KATA_DEV_MODE=true +$ make check +$ make test +``` +Running these checks should result in **no errors**. If errors are reported, fix them before submitting your PR. + +To replicate the static checks performed by the CI system: + +- [x] Ensure you have a "clean" source tree, as the checks cover all files + present. Checks might fail if you have extra files or your files are out of date in your tree. + +- [x] Ensure [`golangci-lint`](https://github.com/golangci/golangci-lint) is +current or has not been previously installed (the static check scripts will +install it if necessary). Changing the linters used or the Kata +Containers code base can produce spurious errors that do not fail inside the +CI systems. + +### Fix failed static checks after submitting PRs + +Some submitted PRs fail to pass static checks. After such a PR fails, +view its build logs to determine the cause of failure. + +1. At the bottom of the PR, if a message appears, "Some checks were not + successful," select "Details", as shown below. + + ![Failed CI-CD](fig1-ci-cd-failure.png) + +1. Upon entering the Travis CI* web page, select the first number that + appears below "Build jobs." + +1. Scroll to the bottom of the build log and view the `ERROR` message(s). + In the example below, the `ERROR` reads: `... no + signed-off-by specified`. This is a requirement. To fix, use the signed-off-by method while pushing a commit. See [Patch format]( + #patch-format) for more details. + + ![Build log error messages](fig2-ci-cd-log.png) + +### Kata runtime static checks + +If working on `kata-runtime`, first ensure you run `make` and `make install` +in the `virtcontainers` subdirectory, as shown below. For more information, +see [virtcontainers](https://github.com/kata-containers/kata-containers/blob/main/src/runtime/virtcontainers/documentation/Developers.md#testing). + +```bash +$ pushd runtime/virtcontainers +$ make +$ sudo -E PATH=$PATH make install +$ popd +``` + +>**Note:** The final `popd` is required to return to the top-level directory +>from where other build rules can be executed. + +## Porting + +Porting applies a patch set to an older ("backport") or a newer +("forward-port") branch or repository. + +Backporting is necessary to ensure that older -- but still maintained -- +releases benefit from bug fixes already applied to newer releases. + +Forward porting is necessary where there are multiple development streams and +bug fixes or new features have been applied to the older stream, but not the +newer one. + +> **Note:** +> +> Stable branches are considered maintenance branches, not development +> branches. Bug fixes must land in a newer development branch before landing +> in a stable branch to ensure the changes have been tested thoroughly before +> being applied to a stable release (maintenance) branch. + +Porting is performed with a new PR meaning porting PRs *must* have an +associated "parent" PR (the original bug fix or feature PR). + +Every PR must indicate whether it should be ported in either direction; +*backwards* (backport) or *forwards* (forward port). This is achieved by +adding up to two labels per PR which signal the porting requirements for the +PR. + +The [stable branch backports](#stable-branch-backports) section provides +information on the sorts of changes which should be backported. + +### Porting labels + +The table below lists all valid combinations of GitHub labels. Every PR must +be labelled as shown in the table row that most closely corresponds to the +type of PR the user is raising. + +> **Notes:** +> +> - The porting labels are enforced by a +> [GitHub action](https://github.com/kata-containers/.github/blob/main/scripts/pr-porting-checks.sh). +> This means that *PRs that do not have a valid set of porting labels cannot be merged*. +> - The "Common PR type" column in the table shows the most likely type of PR, but +> this is just a guide. +> - A `backport` or `forward-port` labelled PR **must** have an associated +> parent PR which caused the backport or forward port PR to be raised. + +| PR summary | Common PR type | Backport label | Forward port label | Notes | +|-|-|-|-|-| +| A "standalone" PR | Feature | `no-backport-needed` | `no-forward-port-needed` | PR does not need to be ported. For example, a PR used to add a new feature to the latest release. | +| PR that needs to be backported only | Bug fix | `needs-backport` | `no-forward-port-needed` | | +| PR that needs to be forward ported only | Bug fix or feature | `no-backport-needed` | `needs-forward-port` | | +| PR that needs to be ported backwards *and* forwards | Bug fix | `needs-backport` | `needs-forward-port` | For example a Kata 1.x PR that needs to be ported to Kata 2.0 *and* to one or more Kata 1.x stable branches. | +| A backport PR | Bug fix | `backport` | | PR to actually make the backport changes.

Must have an associated "parent" PR.

Title **must** contain original PRs title. | +| A forward port PR | Bug fix or feature | | `forward-port` | PR to actually make the forward port changes.

Must have an associated "parent" PR.

Title **must** contain original PRs title. | + +If you are not a member of the GitHub repository the PR is raised in, you may +not be able to see the GitHub labels. In this scenario, please add a comment +asking for the porting labels to be applied. + +Forward port and backport PRs by definition should not be raised in isolation: +there must be an existing PR that caused the porting PR to be raised. + +If you know whether a PR should be backported or forward ported, please add +a comment on the PR if you are unable to add the appropriate labels. If you do +not know whether a PR should be backported or forward ported, the community +will work with you to identify any porting requirements and to help with +porting activities. + +### Stable branch backports + +Kata Containers maintains a number of stable branch releases. Bug fixes to +the main branch are selectively applied to (or "backported") these stable branches. + +In order to aid identification of commits that potentially should be +backported to the stable branches, all PRs submitted must be labeled with +one or more of the following labels. At least one label that is *not* +`stable-candidate` must be included. + +| Label | Meaning | +| ----- | ------- | +| `bug` | A bug fix, which will potentially be a backport candidate | +| `cleanup` | A cleanup, which will likely not be backported | +| `feature` | A new feature/enhancement, that will likely not be backported | +| `stable-candidate` | A PR selected for backporting - very likely a bug fix | +| `vendor` | A golang vendor update. Might be considered for backport if the vendor update includes critical bug fixes | + +In the event that a bug fix PR is selected for backporting to the stable +branches, the `stable-candidate` label is added if not already present, and +the original author of the PR is asked if they will submit the relevant +backport PRs. For a quick guide on how to perform and submit a backport, see +the [Backport Guide](Backport-Guide.md) in this repository. + +### Porting issue numbers + +For ports that are within the same repository (for example a stable backport +to a 1.x PR), specify the same issue number as the original PR in the "fixes +comment". See the [patch format](#patch-format) section for further details. + +For ports in different repositories, create a new issue, referencing the +original issue URL in the issue text. + +### Porting comments + +Issues and PRs can only be linked if they are within the same repository. +Since Kata 2.x uses a new central repository, it is essential to add a special +comment to the **original PR** when new port PRs are created. + +| Port type | Port comment format | +|-|-| +| backport | `backport PR: ` | +| forward port| `forward port PR: ` | + +> **Notes:** +> +> - The special comments **must** appear at the start of a line. +> +> - The special comments are used by tooling to check that porting has been +> completed correctly. +> +> - Although these comments strictly make the `backport` and `forward-port` +> labels redundant, these labels are useful for general reporting since +> users can search for "all port PRs in a particular repository" for +> example. + +### Forward ports + +Forward ports tend to be much less common than backports. However, +consolidating a number of standalone repositories into a single repository for +the Kata 2.0 development effort introduced a potential forward port +requirement. At the time, both Kata 1.x and 2.0 versions were being developed +in parallel. This meant that lots of PRs raised in the Kata 1.x repositories +needed to be forward ported to the Kata 2.0 repository (since this was to be +the next major release and needed to contain all bug fixes and features where +possible). + +| Initial PR raised | PR type | Backport? | Forward port? | +|-|-|-|-| +| Particular 1.x repository | bug fix | stable branches | 2.0 repository | +| Particular 1.x repository | feature | | 2.0 repository | +| The 2.0 repository | bug fix | 1.x (and maybe stable branches) | - | +| The 2.0 repository | feature | | - | + +### Porting examples + +#### Backport and forward port example + +Imagine that you have just raised a new PR on a Kata 1.x repository. The PR +contains three commits: + +- A commit to fix a "typo" in a comment. +- A commit that changes the way a container is destroyed (and updates the tests). +- A commit that updates the documentation explaining the new contain + destruction behaviour. + +Since the PR is not adding any new functionality and since it is correcting +problems with existing code, it can be considered a bug fix PR. Bug fixes +should generally be backported. However, this PR was raised in a Kata 1.x +repository meaning it should also potentially be forward-ported to the Kata +2.0 repository. + +Looking at the tables in the [porting labels](#porting-labels) and the [stable +branch backports](#stable-branch-backports) sections shows that this PR needs +to be labelled with the following labels: + +- `needs-backport` +- `needs-forward-port` +- `stable-candidate` + +Once this PR is approved and is merged in the Kata 1.x repository, it should +now be backported and forward ported: + +- Backport: Raise new PRs on the currently maintained stable releases + + - These PRs should be labelled with the `backport` label. + - The commit message should mention the original PR. + - The commit message should reference the *original* issue number in the + ["fixes" comment](#patch-format). + +- Forward port: Raise a new PR on the Kata 2.0 repository + + - This PR should be labelled with the `forward-port` label. + - The commit message should mention the original PR. + - A new issue should be used for the PR and the original issue URL + referenced in the issue text. + +- Add [porting comments](#porting-comments) to the *original PR* with two comments, + one for each port: + + ``` + backport PR: https://github.com/kata-containers/runtime/pull/XXX + forward port PR: https://github.com/kata-containers/kata-containers/pull/YYY + ``` + +#### Double backport example + +Imagine that you have just raised a new PR on the Kata 2.x repository. The PR +fixes a nasty runtime bug, and adds some new unit tests to guarantee no future +regression. + +This is a pure bug fix PR. There is no "newer" branch or version, so it is not +possible to forward port. However, since the PR is an important bug fix, it +should be backported, both to Kata 1.x *and* the Kata 1.x stable branches. + +Looking at the tables in the [porting labels](#porting-labels) and the [stable +branch backports](#stable-branch-backports) sections shows that this PR needs +to be labelled with the following labels: + +- `needs-backport` +- `no-forward-port-needed` +- `stable-candidate` + +Once this PR is approved and is merged in the Kata 2.0 repository, it should +now be backported *twice*: + +- Kata 1.x: Raise a new PR on the Kata 1.x runtime repository + + - This PR should be labelled with the `backport` label. + - The commit message should mention the original PR. + +- Stable backports: Raise new PRs on each of the currently maintained stable + branches in the Kata 1.x runtime repository + + - These PRs should be labelled with the `backport` label. + - The commit message should mention the original PR. + - The commit message should reference the issue number used in the + ["fixes" comment](#patch-format) for the 1.x PR + (since that is in the same repository). + +- Add [porting comments](#porting-comments) to the *original PR* with two comments, + one for each port: + + ``` + backport PR: https://github.com/kata-containers/runtime/pull/XXX + backport PR: https://github.com/kata-containers/runtime/pull/YYY + ``` + +## Patch format + +### General format + +Beside the `Signed-off-by` footer, we expect each patch to comply with the +following format: + +``` +subsystem: One line change summary + +More detailed explanation of your changes (why and how) +that spans as many lines as required. + +A "Fixes #XXX" comment listing the GitHub issue this change resolves. +This comment is required for the main patch in a sequence. See the following examples. + +Signed-off-by: Contributors Name +``` + +#### Pull request format + +As shown above, pull requests must adhere to these guidelines: + +* Preface the PR title with the appropriate keyword found in [Subsystem](#subsystem) + +* Ensure PR title length is 75 characters or fewer, including whichever + `subsystem` term is used. + +* Ensure the PR body line length is 150 characters or fewer. + +The body of the message is **not** a continuation of the subject line and is +not used to extend the subject line beyond its character limit. The subject +line is a complete sentence and the body is a complete, standalone paragraph. + +Additionally, PR body line length is not checked for special lines: + +* Lines that do not start with an alphabetic character + +* Sign-off lines (as to not penalize long names) + +* Lines without spaces + +These should allow contributors to pass checks while including relevant +information **if needed**. + +### Subsystem + +The "subsystem" describes the area of the code that the change applies to. +It does not have to match a particular directory name in the source tree +because it is a "hint" to the reader. The subsystem is generally a single +word. Although the subsystem must be specified, it is not validated. The +author decides what is a relevant subsystem for each patch. + +Examples: + +| Subsystem | Description | +|--|--| +| `build` | `Makefile` or configuration script change | +| `cli` | Change affecting command line options or commands | +| `docs` | Documentation change | +| `logging` | Logging change | +| `vendor` | [Re-vendoring](#re-vendor-prs) change | + +To see the subsystem values chosen for existing commits: + +``` +$ git log --no-merges --pretty="%s" | cut -d: -f1 | sort -u +``` + +### Best practices for patches + +We recommend that each patch fixes one thing. Smaller patches are easier to +review, more likely to be accepted and merged, and more conducive for +identifying problems during review. + +A PR can contain multiple patches. These patches should generally be related +to the [main patch](#main-patch) and the overall goal of the PR. However, it +is also acceptable to include additional or +[supplementary patches](#supplementary-patch) for things such as: + +- Formatting (or whitespace) fixes +- Comment improvements +- Tidy up work +- Refactoring to simplify the codebase + +### Verification + +Correct formatting of the PR patches is verified using the commit-message-check GitHub Action. + +### Examples + +#### Main patch + +The following is an example of a full patch description for the main change that shows the required "`Fixes #XXX`" comment, which references the GitHub issue this patch resolves: + +``` +pod: Remove token from Cmd structure + +The token and pid data will be hold by the new Process structure and +they are related to a container. + +Fixes: #123 + +Signed-off-by: Sebastien Boeuf +``` + +#### Supplementary patch + +If a PR contains multiple patches, [only one of those patches](#main-patch) needs to specify the "`Fixes #XXX`" comment. Supplementary patches have an identical format to the main patch, but do not need to specify a "`Fixes #XXX`" +comment. + +Example: + +``` +image-builder: Fix incorrect error message + +Fixed an error message which was referring to an incorrect rootfs +variable name. + +Signed-off-by: James O. D. Hunt +``` + +## Reviews + +Before your PRs are merged into the main code base, they are reviewed. We +encourage anybody to review any PR and leave feedback. + +See the [PR review guide](PR-Review-Guide.md) for tips on performing a +careful review. + +We use the GitHub [Required Reviews](https://help.github.com/articles/approving-a-pull-request-with-required-reviews/) +system for reviewers to note if they agree or disagree with a PR. To have +an acknowledgment or "nack" registered with GitHub, you **must** use the +GitHub "Review changes" dialog to leave feedback. Notes left only in the +comments fields, whilst sometimes useful, will not get registered +in the acknowledgment counting system. + +Documentation PRs can sometimes use a modified process explained in the +[Documentation Review Process](Documentation-Review-Process.md) guide. + +### Review Examples + +The following is an example of a valid "ack", as long as +the "Approve" box is ticked in the Review changes dialog: + +``` +Excellent work - thanks for your contribution. + +lgtm +``` + +## Continuous Integration + +The Kata Containers project has a gating process to prevent introducing +regressions. When your PR is submitted, a Continuous Integration (CI) system +will run different checks on different platforms, based upon your changes. Currently Kata uses [Jenkins](http://jenkins.katacontainers.io) +for testing your changes. + +Some of the checks are: + +- Static analysis checks. +- Unit tests. +- Functional tests. +- Integration tests. + +The Jenkins jobs will wait to be triggered. A maintainer must add a `/test` +comment on the PR to let the CI jobs run. + +All CI jobs must pass in order to merge your PR. + +## Contact + +The Kata Containers community can be reached +[through various channels](README.md#join-us). + +## Project maintainers + +The Kata Containers project maintainers are the people accepting or +rejecting any PR. Although [anyone can review PRs](#reviews), only the +acknowledgement (or "ack") from an Approver counts towards the approval of a PR. + +Approvers are listed in GitHub teams, one for each repository. The project +uses the +[GitHub required status checks](https://help.github.com/en/articles/enabling-required-status-checks) +along with the [GitHub `CODEOWNERS`file](https://help.github.com/en/articles/about-code-owners) to specify who can approve PRs. All repositories are configured to require: + +- Two approvals from the repository-specific approval team. + +- One [documentation team](https://github.com/orgs/kata-containers/teams/documentation/members) approval if the PR modifies documentation. +>>>>>>> 6023dab06b23e26e953804c476b69bf44d9371f2 diff --git a/Documentation-Review-Process.md b/Documentation-Review-Process.md new file mode 100644 index 0000000000..83ee30f10a --- /dev/null +++ b/Documentation-Review-Process.md @@ -0,0 +1,163 @@ +# Documentation review process + +* [Introduction](#introduction) +* [The Documentation Team](#the-documentation-team) +* [Default document review process](#default-document-review-process) +* [Justification for different process](#justification-for-different-process) + * [Users should always expect accurate Documentation](#users-should-always-expect-accurate-documentation) + * [Some documentation PRs can be fast-tracked](#some-documentation-prs-can-be-fast-tracked) + * [Formal doc reviews can be very time-intensive](#formal-doc-reviews-can-be-very-time-intensive) +* [Decision Authority](#decision-authority) +* [Determine if a full document review is required](#determine-if-a-full-document-review-is-required) + * [Exempt](#exempt) + * [Required](#required) +* [Requesting a formal document review](#requesting-a-formal-document-review) +* [Lightweight document review process](#lightweight-document-review-process) + +## Introduction + +The process for reviewing documentation PRs is slightly different from +[the general process for reviewing code PRs](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#reviewsPR-Review-Guide.md). +This document explains the differences. + +## The Documentation Team + +The Documentation Team is responsible for carrying out a full documentation +review of a PRs containing documentation changes. Such a review includes +checking the grammar, structure, consistency, and typographical correctness of +the documentation changes. + +The following GitHub team lists the users who are members of the Documentation Team: + +- https://github.com/orgs/kata-containers/teams/documentation/members + +## Default document review process + +[Project maintainers](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#project-maintainers) +have the power to approve or reject PRs. + +If a Documentation Team review is required, the `CODEOWNERS` configuration will +apply and the PR will be blocked until the required number of acks are +obtained for the documentation changes. + +Technical writers from the Documentation Team will review the document +changes and add comments explaining how the wording should be changed. It is +then up to the PR creator to apply these changes to their original PR, +rebasing as necessary to ensure a clean `git(1)` history. Once the creator has +applied the changes they need to re-push their branch and add a comment to the +PR asking for a re-review. This process continues indefinitely until the the +Documentation Team is happy with the final result. + +## Justification for different process + +The documentation review process is different than the code review process for +the following reasons: + +### Users should always expect accurate Documentation + +Just like code changes, some documentation changes have to be merged as soon +as possible to ensure users have current and accurate information. + +Documentation changes tend to be more urgent though. For example, a "Priority +1" code issue needs to be fixed quickly. However it would also need to be +documented clearly (and quickly). If the P1 issue *cannot* be fixed quickly, +the documentation must still be updated as soon as possible to alert users of +the issue and to provide suitable workarounds. + +If the documentation is *not* kept current, users have incorrect information +and might create problems for themselves or become disaffected with the +project entirely. + +In summary, do not let documentation PRs sit in the PR backlog for any longer +than necessary. + +### Some documentation PRs can be fast-tracked + +If a PR makes a minor change to one or more documents, passing to the +Documentation Team for a formal review and approval might not be necessary. + +### Formal doc reviews can be very time-intensive + +Since a full document review can be a slow and pain-staking process, and since +the number of professional technical writers on the Documentation Team is +relatively small compared to the number of developers, it makes sense to only +perform such reviews on the documents that justify the effort. + +## Decision Authority + +If a Documentation Team member believes a full review is required, their +decision is final. + +In most other cases, a project maintainer will decide whether a full review is +required or not. + +If project maintainers cannot decide whether the lightweight process should be +followed, the full process should be used instead since the uncertainty +implies "more eyes" should see the changes. + +## Determine if a full document review is required + +### Exempt + +If a PR contains documentation changes that **only** relate to one or more of +the following categories, it does not need to be formally reviewed and +approved by the Documentation Team: + +- Changes to code blocks + + The PR only modifies code blocks embedded in the document. + +- "Typo" fixes + + The PR only fixes spelling mistakes and whitespace issues. + +- Formatting + + The PR only modifies the layout of the existing text. For example, you + update words to render them in a ``fixed font`` or change a + [Note](https://github.com/kata-containers/documentation/blob/master/Documentation-Requirements.md#notes) + to fit the standard formatting conventions. + +- URL fixes + + The PR only modifies URLs or updates the table of contents. + +- The PR only *removes* documentation. + +### Required + +The following PR changes generally indicate a full document review is +necessary: + +- A new document has been added by the PR. + + All documents should have an initial review unless they are extremely simple. + +## Requesting a formal document review + +If a PR needs a full document review, add a comment to the PR like the +following, which sends a mail to all members of the Documentation Team: + +``` +PTAL @kata-containers/documentation +``` + +## Lightweight document review process + +1. Obtain general agreement that + a Document Team review [is not required](#decision-authority). + +1. Ensure all other approvals and CI checks have been met. + +1. Ensure the PR contains a note explaining why the PR does not justify a full review. + +1. Request a project maintainer force-merges the PR. + + This operation bypasses the check that normally stops a PR from + landing until the Documentation Team acks the PR. + +1. The maintainer should notify the Documentation Team out of courtesy that + the PR has been merged. + + This allows a follow-on "recovery PR" to be raised should the Documentation + Team disagree on using the lightweight process. diff --git a/PR-Review-Guide.md b/PR-Review-Guide.md new file mode 100644 index 0000000000..b91e58514d --- /dev/null +++ b/PR-Review-Guide.md @@ -0,0 +1,136 @@ +* [High level considerations](#high-level-considerations) + * [Security](#security) + * [Reliability](#reliability) + * [Performance](#performance) + * [Maintenance](#maintenance) + * [Usability](#usability) +* [Specifics to consider](#specifics-to-consider) + * [Basics](#basics) + * [Layout and formatting](#layout-and-formatting) + * [Design](#design) + * [Code comments](#code-comments) + * [Documentation](#documentation) + * [Logging and debugging](#logging-and-debugging) + * [Testing](#testing) + * [Environments](#environments) + * [Upgrades](#upgrades) +* [Mandatory checks](#mandatory-checks) + +--- + +This document attempts to capture some of the points to consider when +reviewing a [new code contribution](CONTRIBUTING.md) (a Pull Request (PR)) to +ensure overall quality is high. + +## High level considerations + +### Security + +- Does the change introduce a potential security risk? + - What additional checks resolve the potential security risk? + +### Reliability + +- What happens on failure? Consider **every** possible failure. For example: + - Are temporary files left on the disk? + - Are any resources (e.g. memory and open files) leaked? + +- If the code crashes, what is the overall system impact? + - Can the system be restarted and recovered? + - Is [security](#security) compromised? + +### Performance + +- Does this change negatively impact performance? +- Can any calls block? If yes, there must be a log call before the blocking call explaining what is about to be done. + +### Maintenance + +- How easy is this code to maintain: + - By an experienced developer on the project? + - By a developer with none or almost no experience of the code base or the project? + +### Usability + +- Does the change improve usability or make it worse? +- Can usability be improved further? + +## Specifics to consider + +### Basics + +- Consider *all* inputs and outputs. +- What resources are being used (e.g. memory, disk, etc.)? Are the resources released? +- Are all return values and arguments checked? +- Are there any magic numbers? + +### Layout and formatting + +- Is formatting and naming consistent? +- Are there any spelling mistakes ("typos")? +- Do all new files contain the required licence header? + +### Design + +- Can the code be simplified or refactored? + - Is the code "too clever"? Overly clever code can be fragile. Reject it unless there is a **very** good documented reason. +- Is there a better (simpler) solution to the problem? +- Is there any duplication? +- Does the code "reinvent the wheel?" Is there a standard package you can use instead? +- What assumptions does the code make? Are the assumptions valid and documented? +- Does the code make sense? + - Someone with minimal exposure to the codebase should be able to guess what the code is doing. + +### Code comments + +- Is the code well commented? +- Are all functions and function parameters documented. For `golang` programs, is their purpose obvious? +- Does this change require an update to the README(s) or architecture docs, installation docs, or limitations docs? +- Are any lines commented out? If yes, remove them. +- 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. + +### Documentation + +- Should the document update be applied to any *other* documents? + For example, when a PR updates an installation guide, determine whether those changes apply to one or more of the other installation guides. +- Does the PR make any of the following changes? If yes, determine if a documentation change is necessary: + - New programs or scripts are added or removed. + - New program or script options are added or removed. + - New config options are added or removed. + - New features are added or removed. + - Existing bug(s) are fixed. + +### Logging and debugging + +- Can someone debug this code from a logfile if it fails? +- Are all fatal scenarios logged? +- Are error messages and log calls useful and comprehensive? Ensure sensitive information is **not** displayed. + +### Testing + +- Is the code easy to test? +- Are there new unit tests? If not, why not? +- What other classes of testing (e.g. integration, system, stress, fuzz) can someone write to check the code? + +### Environments + +- Does the code work on all distributions? +- Does the code work on all architectures? +- What environments does your code run in? +- Which user does the code run as? If it runs as the superuser, have clear documentation to explain why this is necessary. + +### Upgrades + +- If the code logs internal state to a file or shared memory, how are upgrades handled? +For example, if a new version introduces a new state file format, does the new version consume the old state file format files? +- If upgrades cannot be handled, document this. + +## Mandatory checks + +- Provide constructive comments on the code. + - If you particularly like some aspect of the code, say so. + - If you do not like something about the code, respectfully state what you do not like. + - If you do not understand the code, say so because code should **always** be clear. + +- Ensure all automated checks pass. +- Ensure the PR contains at least one `Fixes #XXX` commit message referencing an issue that this PR fixes. diff --git a/README.md b/README.md index 6db98ed2da..6af2521c12 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,4 @@ +<<<<<<< HEAD [![CI | Publish Kata Containers payload](https://github.com/kata-containers/kata-containers/actions/workflows/payload-after-push.yaml/badge.svg)](https://github.com/kata-containers/kata-containers/actions/workflows/payload-after-push.yaml) [![Kata Containers Nightly CI](https://github.com/kata-containers/kata-containers/actions/workflows/ci-nightly.yaml/badge.svg)](https://github.com/kata-containers/kata-containers/actions/workflows/ci-nightly.yaml) @@ -161,3 +162,188 @@ See the [metrics documentation](tests/metrics/README.md). ## Glossary of Terms See the [glossary of terms](https://github.com/kata-containers/kata-containers/wiki/Glossary) related to Kata Containers. +======= + + +* [About Kata Containers](#about-kata-containers) +* [Community](#community) + * [Join Us](#join-us) + * [Users](#users) + * [Contributors](#contributors) + * [Review Team](#review-team) + * [Resource Owners](#resource-owners) +* [Governance](#governance) + * [Developers](#developers) + * [Contributor](#contributor) + * [Committer](#committer) + * [Admin](#admin) + * [Owner](#owner) + * [Architecture Committee](#architecture-committee) + * [Architecture Committee Meetings](#architecture-committee-meetings) +* [Vendoring code](#vendoring-code) +* [Vulnerability Handling](#vulnerability-handling) + * [Reporting Vulnerabilities](#reporting-vulnerabilities) + * [Vulnerability Disclosure Process](#vulnerability-disclosure-process) +* [Week in Review template](#week-in-review-template) + +# About Kata Containers + +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. + +The Kata Containers project is designed to be architecture agnostic, run on multiple hypervisors and be compatible with the OCI specification and Kubernetes. + +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. + +# Community + +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. + +## Join Us + +You can join our community on any of the following places: + +* Join our [mailing list](http://lists.katacontainers.io/). + +* Use the `irc.oftc.net` IRC server to join the discussions: + * General discussions channel: [`#kata-general`](http://webchat.oftc.net/?channels=kata-general). + * Development discussions channel: [`#kata-dev`](http://webchat.oftc.net/?channels=kata-dev). + +* Get an [invite to our Slack channel](https://bit.ly/3bbRXOV). + and then [join us on Slack](https://katacontainers.slack.com/). + +* Follow us on [Twitter](https://twitter.com/KataContainers) or + [Facebook](https://www.facebook.com/KataContainers). + +## Users + +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. + +## Contributors + +See the [contributing guide](CONTRIBUTING.md) for details on how to contribute to the project. + +## Review Team + +See the [rota documentation](Rota-Process.md). + +## Resource Owners + +Details of which Kata Containers project resources are owned, managed or controlled by whom +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. + +# Governance + +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. + +## Developers + +For Kata developers, there are several roles relevant to project governance: + +### Contributor + +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. + +### Committer + +Kata Containers Committers (as defined by the [kata-containers-committer team](https://github.com/orgs/kata-containers/teams/kata-containers-committer)) +have the ability to merge code into the Kata Containers project. +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 +e.g. https://github.com/kata-containers/community/issues/403. Committers have write access to the Kata Containers repos on GitHub, which +gives the ability to approve PRs, trigger the CI and merge PRs. + +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, +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, +but who haven't been an active Contributor in the last 12 months will be created and shared with the Architecture Committee and community. +After a short review period, to allow time to check for any errors, inactive team members will be removed. + +> [!Note] +> See [issue #413](https://github.com/kata-containers/community/issues/413) for a potential change in how active contribution is assessed. + +### Admin + +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 +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. +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. +The Admin list is reviewed and updated after each Architecture Committee election and typically contains: +- The Architecture Committee +- Optionally, some specific people that the Architecture Committee agree on adding for a specific purpose (e.g. to manage the CI) + +### Owner + +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. +The owners list is reviewed and updated after each Architecture Committee election and contains: +- The Community Manager and one, or more extra people from the `OpenInfra Foundation` for redundancy and vacation cover +- The Architecture Committee +- Optionally, some specific people that the Architecture Committee agree on adding for a specific purpose (e.g. to help with repo/CI migration) + +## Architecture Committee + +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. + +The current Architecture Committee members are: + +- `Anastassios Nanos` ([`ananos`](https://github.com/ananos)), [`Nubificus Ltd`](https://nubificus.co.uk). +- `Aurelien Bombo` ([`sprt`](https://github.com/sprt)), [`Microsoft`](https://www.microsoft.com/en-us/). +- `Fupan Li` ([`lifupan`](https://github.com/lifupan)), [`Ant Group`](https://www.antgroup.com/en). +- `Greg Kurz` ([`gkurz`](https://github.com/gkurz)), [`Red Hat`](https://www.redhat.com). +- `Ruoqing He` ([`RuoqingHe`](https://github.com/RuoqingHe)), [`ISCAS`](http://english.is.cas.cn). +- `Steve Horsman` ([`stevenhorsman`](https://github.com/stevenhorsman)), [`IBM`](https://www.ibm.com). +- `Zvonko Kaiser` ([`zvonkok`](https://github.com/zvonkok)), [`NVIDIA`](https://www.nvidia.com). + +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. + +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. + +See [the elections documentation](elections) for further details. + +### Architecture Committee Meetings + +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). + +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. + +# Vendoring code + +See the [vendoring documentation](VENDORING.md). + +# Vulnerability Handling + +Vulnerabilities in Kata are handled by the +[Vulnerability Management Team (VMT)](VMT/VMT.md). +There are generally two phases: +- The reporting of a vulnerability to the VMT +- Handling and disclosure of the vulnerability by the VMT + +## Reporting Vulnerabilities + +Vulnerabilities in Kata should be reported using the +[responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure) model. + +There are two methods available to report vulnerabilities to the Kata community: + +1) Report via a private issue on the [Kata Containers launchpad](https://launchpad.net/katacontainers.io) +1) Email any member of the [Kata Containers architecture committee](#architecture-committee) directly + +When reporting a vulnerability via the launchpad: + +- You will need to create a launchpad login account. +- Preferably, but at your discretion, create the report as "Private Security", so the VMT can assess and + respond in a responsible manner. Only the VMT members will be able to view a "Private Security" tagged + issue initially, until it is deemed OK to make it publicly visible. + +## Vulnerability Disclosure Process + +Vulnerabilities in the Kata Container project are managed by the Kata Containers +Vulnerability Management Team (VMT). Vulnerabilities are managed using a +[responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure) model. + +Details of how to report a vulnerability, the process and procedures +used for vulnerability management, and responsibilities of the VMT members +can be found in the [VMT documentation](VMT/VMT.md). + +Previous Kata Containers Security Advisories are [listed on their own page](VMT/KCSA.md). + +# Week in Review template + +See the [week in review report template](statusreports/REPORT_TEMPLATE.md). +>>>>>>> 6023dab06b23e26e953804c476b69bf44d9371f2 diff --git a/Rota-Process.md b/Rota-Process.md new file mode 100644 index 0000000000..063d50433f --- /dev/null +++ b/Rota-Process.md @@ -0,0 +1,327 @@ +# Kata Rota Process + +* [Introduction](#introduction) +* [Kata Review Team](#kata-review-team) +* [The rota](#the-rota) +* [Who can join?](#who-can-join) +* [How can I participate?](#how-can-i-participate) +* [Preparation](#preparation) + * [Reviewing documentation changes](#reviewing-documentation-changes) +* [Tasks](#tasks) + * [Talk to each other](#talk-to-each-other) + * [PRs](#prs) + * [Review PR backlog](#review-pr-backlog) + * [Triggering a CI run](#triggering-a-ci-run) + * [CI results](#ci-results) + * [Stale PRs](#stale-prs) + * [Temporarily blocking a PR from landing](#temporarily-blocking-a-pr-from-landing) + * [Stable branches](#stable-branches) + * [Issues](#issues) + * [Review issues](#review-issues) + * [Issue labels](#issue-labels) + * [Issue triage](#issue-triage) + * [General process](#general-process) + * [Test stability](#test-stability) + * [Weekly Summary](#weekly-summary) + +## Introduction + +This document explains the structure and roles of the Kata Review Team. + +## Kata Review Team + +The Kata Containers project runs a [rolling rota of members and volunteers](#the-rota) +who donate their time to assess, review, move forward, and reduce any PR and +issue backlogs across the repositories. + +Informally, this team is sometimes referred to as the "Kat Herding Team". + +## The rota + +The rota is maintained in the +[community wiki](https://github.com/kata-containers/community/wiki/Review-Team-Rota), +which is updated frequently. + +## Who can join? + +Anybody can participate. You do **not** have to be a subject matter expert or Kata +expert to help. All contributions are welcome. + +Joining the team is a great way to expand your knowledge of the project and +your skill set. Sometimes all you need to move a PR forward is for a community +member to read the list of open PRs and ask the appropriate subject matter +expert to review or help with the relevant PR. + +Note that you must agree to our [code of conduct](CODE_OF_CONDUCT.md) +if you want to become involved. + +## How can I participate? + +To participate and be added to the [the rota](#the-rota), +notify the Kata team through one of the contact methods listed on +https://katacontainers.io before you edit this page. Be sure to include your +contact details in the Rota table, preferably your GitHub name. + +## Preparation + +Before you join the team, we strongly recommend that you read the +[contribution guide](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md). +We suggest you also read the +[PR review guide](https://github.com/kata-containers/community/blob/master/PR-Review-Guide.md) +for tips to consider as you review [pull requests](#prs). + +### Reviewing documentation changes + +We suggest you read the +[documentation requirements](https://github.com/kata-containers/documentation/blob/master/Documentation-Requirements.md) +and +[documentation review process](https://github.com/kata-containers/community/blob/master/Documentation-Review-Process.md) +to help you review documentation changes. + +## Tasks + +This section lists which activities the team should focus on. + +### Talk to each other + +If you are on the review team, we suggest you hang out on +[Slack or IRC](README.md#join-us) in order to chat with each other. Nobody +knows everything so do not hesitate to ask other folks on the team if you need +help. + +There is a useful wiki page that +[lists areas of interest for various members of the community](https://github.com/kata-containers/community/wiki/Areas-of-interest). + +We also have a +[central GitHub `CODEOWNERS` file](https://github.com/kata-containers/.github/blob/master/CODEOWNERS). +This [file type](https://help.github.com/en/articles/about-code-owners) +defines individuals or teams that are responsible for code in a repository. +This can help identify the appropriate group of people to contact about +certain file changes. + +### PRs + +#### Review PR backlog + +See [the GitHub reports](https://github.com/kata-containers/community/wiki/Review-Team-Rota#finding-the-open-prs) +for a list of open PRs. + +Read +[the reviews section in the contributing guide](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#reviews) +to learn how to "ack" a PR. + +##### Triggering a CI run + +See the [Controlling the CI](https://github.com/kata-containers/community/wiki/Controlling-the-CI) document. + +##### CI results + +When you review a PR, look at any CI failures shown at the bottom of the PR +page. If any CI tests fail, review the logs to see if there are obvious +issues. + +Add a comment and a brief summary of the error message or issue to explain +which CIs failed. + +##### Stale PRs + +If a PR has not been touched for a while, add a comment to ask the author if +they intend to update the pull request. + +If the author does not respond, we may decide to use the +[assisted PR workflow](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#assisted-pr-workflow), +which you can also take part in. + +##### Temporarily blocking a PR from landing + +See [this section in the contributing guide](CONTRIBUTING.md#temporarily-blocking-a-pr). + +##### Stable branches + +If a PR is just a fix, add the `stable-candidate` label and ask the author to +backport the fix to the last two +[stable branches](https://github.com/kata-containers/documentation/blob/master/Stable-Branch-Strategy.md). + +### Issues + +#### Review issues + +See [the GitHub report](https://github.com/kata-containers/community/wiki/Review-Team-Rota#finding-new-issues) +for a list of issues that need a review. + +##### Issue labels + +All the repositories use a +[standard set](https://github.com/kata-containers/tests/blob/master/cmd/github-labels/labels.yaml.in) +of GitHub labels. For example, here are the `runtime` repositories labels: + +- https://github.com/kata-containers/runtime/issues/labels + +Review the list and become familiar with the labels, and then read on. + +> **Notes:** +> +> - All labels have a description to explain their use. +> +> - There *are* a lot of labels but only to cover as many scenarios as +> possible. Most issues only need a small number of labels to be +> applied to them. + +##### Issue triage + +Read each new issue carefully. Each issue is an arbitrary description of the +problem or request, so we want to add meaningful labels to each for easier +categorization and search. + +If you are unsure of which labels to apply to an issue, talk to the rest of +the [Rota team](#talk-to-each-other) or just ask +[on Slack/IRC](https://github.com/kata-containers/community#join-us). + +Here is some general advice: + +- Security issue + + Use the + [Vulnerability Management Process (VMP)](https://github.com/kata-containers/community/blob/master/VMT/VMT.md) + to handle serious security issues. + + However, [immediately contact the team](https://github.com/kata-containers/community#join-us) + for advice if you notice a user has raised a normal issue (i.e. does not + follow the VMP) that appears to be a security issue. The `security` label + should be added to the issue if it does not need to follow the VMP. + +- "Crasher bug" + + If an issue reports a crash or catastrophic error scenario add one or more + of the following relevant labels: + + - `crash` + - `data-loss` + - `hang` + - `resource-leak` + - `unreliable` + + If you add one of the previous labels, + [contact the team](https://github.com/kata-containers/community#join-us) + to make them aware of the issues as soon as possible. + +- Top priority + + Add the `highest-priority` label to flag and alert the team of extremely + urgent issues. This indicates to the team that the issue should be fixed as + soon as possible. + +- Release gating + + Add the `release-gating` label if you think the issue should be fixed before + the next release. + +- Important medium / long term task + + Add the `highest-severity` label if the issue is very important but not + time-critical. + +- Simple task for new contributors + + Add the `good-first-issue` label if you think the issue is simple with a + quick resolution and "self-contained." This marks it as suitable for a new + contributor. + +- Invalid + + Add the `invalid` label if you think the issue is not appropriate. + +- Duplicate + + Add the `duplicate` label along with a comment referencing the original + issue if you find a duplicated issue. + +- Limitation + + Add the `limitation` label if the issue describes a system limitation. + + If the issue is a + [known limitation](https://github.com/kata-containers/documentation/blob/master/Limitations.md), + close the issue with a comment referencing the original limitation issue + number so the issue author understands why the issue was closed. + +- Teams + + Add one of the `team/*` labels if you know which team the issue should be + assigned to. Note, while some team names are the same as the + [respective repository](https://github.com/kata-containers), + some are general (e.g. `team/developer`). + + Add a comment to include the name of the team (use the `@team-name` syntax) + if you know the GitHub team a particular label relates to. All teams are + listed [here](https://github.com/orgs/kata-containers/teams). + [Contact the team](README.md#join-us) if you do not have access to this list. + They will either grant you access or tell you which team to specify. + +- Related project + + Add one of the `related/*` labels if the issue relates to another project. + +- Issue is lacking something + + Add one of the the `needs-*` labels if you think the issue is incomplete + somehow. + +##### General process + +We use +[GitHub issue templates](https://github.com/kata-containers/.github/tree/master/.github/ISSUE_TEMPLATE) +to help guide users to raising the correct type of issue. All these templates +also automatically add a `needs-review` label to the issues. + +The idea of this label is to highlight issues that have *not* yet been +reviewed by the team. + +Therefore, after you review an issue with this label, which potentially +results in the application of additional labels, *remove* the `needs-review` +label to signal that the issue has been reviewed. + +### Test stability + +The more PRs you look at, the more likely you are to notice patterns or +anomalies of CI test failures. +[Raising issues in the `tests` repository](https://github.com/kata-containers/tests/issues/new) +helps us to identify "flaky" tests and prioritize the problematic bugs that +make review/merges slower. + +Search for the key failure message in all issues (open and closed) before you +raise an issue. This allows you to see if the issue has been raised before: + +- https://github.com/kata-containers + + Enter an error message in the search box and press enter. + +If an issue has already been raised, add a comment on the PR to reference it. +If it has not, raise a new issue and provide details of the failure. Add a PR +comment to reference it. + +### Weekly Summary + +The Team should discuss amongst themselves and nominate someone to write a +brief summary of what the team accomplished in the week. Post the summary to +[the public mailing list](README.md#join-us). + +Even if the week is quiet, a brief email is beneficial to show the community +that we continue to progress PRs. + +While there is no strict format for the weekly summary, it should mention +significant PRs that have landed or been progressed. The summary does not need +to be highly detailed or particularly long but it does help to include PR URLs +to allow readers to find out further information. + +The following link provides a template if you prefer to use one: + +- https://github.com/kata-containers/community/blob/master/statusreports/REPORT_TEMPLATE.md + +Other things to consider adding to the summary include: + +- Were you particularly impressed with a piece of work (or team work)? +- Did you face any particular problems? +- Is there anything that can be done to make the process easier? + +You can look at previous weekly reports on the mailing list for examples. diff --git a/VENDORING.md b/VENDORING.md new file mode 100644 index 0000000000..01d5bf8b13 --- /dev/null +++ b/VENDORING.md @@ -0,0 +1,250 @@ +# Performing vendoring for the Kata Containers project + +* [Vendoring tool](#vendoring-tool) + * [How to install and update `dep`](#how-to-install-and-update-dep) + * [Overview of the main commands](#overview-of-the-main-commands) +* [Vendoring use cases](#vendoring-use-cases) + * [Initialize vendoring of the package](#initialize-vendoring-of-the-package) + * [Pruning non-go files](#pruning-non-go-files) + * [Vendor a newly imported package](#vendor-a-newly-imported-package) + * [Update a vendored package](#update-a-vendored-package) + * [Remove a vendored package](#remove-a-vendored-package) + * [Test a pending pull request](#test-a-pending-pull-request) + * [From the main repository](#from-the-main-repository) + * [From a forked repository](#from-a-forked-repository) +* [Miscellaneous](#miscellaneous) + +## Vendoring tool + +[`dep`](https://github.com/golang/dep) is the vendoring tool chosen for this +project because it is simple and powerful for some corner cases. Furthermore, +this tool is expected to be the official vendoring tool for Golang. + +Ensure you use the latest version of the `dep` tool. See +[How to install and update `dep`](#how-to-install-and-update-dep) for details. + +### How to install and update `dep` + +Install or update this tool using the following command: +```bash +$ go get -u github.com/golang/dep/cmd/dep +``` + +Make sure your `PATH` contains `$GOPATH/bin`: +```bash +$ export PATH=$GOPATH/bin:$PATH +``` + +### Overview of the main commands + +- `dep init`: Initialize a new project with manifest and lock files. +- `dep ensure`: Ensure a dependency is safely vendored in the project. + +## Vendoring use cases + +Here will be listed the different vendoring use cases a developer could +encounter when developing for Kata Containers. + +### Initialize vendoring of the package + +If no prior vendoring has been performed on the package, you need to +initialize it with the following command: +```bash +$ dep init +``` + +This should create a new directory named `vendor` at the root of your +package, and two new files to manage the vendoring (i.e. `Gopkg.toml` +and `Gopkg.lock`). + +`Gopkg.lock` is automatically re-generated by `dep` every time a new +`dep ensure` command is issued. This file should not be modified by the +developer. +`Gopkg.toml` is automatically generated by `dep init` and can be modified +in order to add a constraint on a package to follow a specific revision. + +The following is what `Gopkg.toml` should look like: +```toml +# Gopkg.toml example +# +# Refer to https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md +# for detailed Gopkg.toml documentation. +# +# required = ["github.com/user/thing/cmd/thing"] +# ignored = ["github.com/user/project/pkgX", "bitbucket.org/user/project/pkgA/pkgY"] +# +# [[constraint]] +# name = "github.com/user/project" +# version = "1.0.0" +# +# [[constraint]] +# name = "github.com/user/project2" +# branch = "dev" +# source = "github.com/myfork/project2" +# +# [[override]] +# name = "github.com/x/y" +# version = "2.4.0" +# +# [prune] +# non-go = false +# go-tests = true +# unused-packages = true +``` + +This file contains all the information you need to modify it properly. + +At this point you can vendor any package needed from your code. + +### Pruning non-go files + +`dep` provides the feature to remove all non-go files from your vendor tree +during its prune phase. By default this is not enabled, but generally for +Kata Containers repositories, we do enable this feature. If possible, modify your +`[prune]` section to enable this feature: + +```toml + [prune] + non-go = true + go-tests = true + unused-packages = true +``` + +### Vendor a newly imported package + +The following case describes a situation when you add new code that relies +on a package that has never been imported (e.g. `github.com/foo/bar`): +```bash +$ dep ensure +``` + +At this point, only the required files will be copied into `vendor`. + +Additionally, you might want to ensure the vendored package refers to a +specific version. This is called a constraint with `dep`. By modifying +`Gopkg.toml`, you can decide to force the package `github.com/foo/bar` to +point to the revision `f5742cb6`. The following is what the file should look +like: +```toml +[[constraint]] + name = "github.com/foo/bar" + revision = "f5742cb6" +``` + +Or, if you want to point to a specific version `1.2.4`: +```toml +[[constraint]] + name = "github.com/foo/bar" + version = "1.2.4" +``` + +Or, if you want to point to a specific branch `work-dev`: +```toml +[[constraint]] + name = "github.com/foo/bar" + branch = "work-dev" +``` + +Lastly, a powerful constraint is to specify if the source of the repository +comes from a forked repository: +```toml +[[constraint]] + name = "github.com/foo/bar" + branch = "fork-work-dev" + source = "github.com/myfork/bar" +``` + +__Note:__ Constraining a package is important because this is the only way to +be certain of the imported package version. This prevents any build failure +that could result from a package change on the upstream. + +### Update a vendored package + +The following case describes a situation where you add some code that relies +on another version of a package already vendored. This is a simple case since +the package is already part of the vendoring. You modify `Gopkg.toml` by +updating the vendoring version: + +```diff +--- Gopkg.toml.orig 2018-01-23 09:04:54.160760426 -0800 ++++ Gopkg.toml.new 2018-01-23 09:05:09.164094911 -0800 +@@ -1,3 +1,3 @@ + [[constraint]] + name = "github.com/foo/bar" +- revision = "f5742cb6" ++ revision = "a4be45c7" +``` + +Let `dep` update the vendoring by relying on this new revision: +```bash +$ dep ensure +``` + +### Remove a vendored package + +The following case describes a situation where you modify the existing +code, no longer relying on a vendored package. Running the usual commands +removes the vendored package from `vendor` directory and from +`Gopkg.lock`: +```bash +$ dep ensure +``` + +If a constraint is set in `Gopkg.toml`, it is your responsibility to remove +the constraint manually from the file. + +### Test a pending pull request + +The following case describes a situation where you need to perform testing +on your code due to a pending pull request from a vendored package. +The easiest and safest way to do that is to rely on a feature proposed +by `dep` called `override`. This feature allows you to leave the constraints +unmodified, but relies on a different version of the vendored package for +testing purposes. + +#### From the main repository + +The pending pull request can be submitted to the main repository through a +development branch `work-dev`. In this case, you will need to modify +`Gopkg.toml` as follows: + +```diff +--- Gopkg.toml.orig 2018-01-23 09:04:54.160760426 -0800 ++++ Gopkg.toml.new 2018-01-23 09:06:49.735633780 -0800 +@@ -1,3 +1,7 @@ + [[constraint]] + name = "github.com/foo/bar" + revision = "f5742cb6" ++ ++[[override]] ++ name = "github.com/foo/bar" ++ branch = "work-dev" +``` + +#### From a forked repository + +The pending pull request can be submitted to a forked repository through a +development branch called `work-dev`. In this case you will need to modify +`Gopkg.toml` as follows: + +```diff +--- Gopkg.toml.orig 2018-01-23 09:04:54.160760426 -0800 ++++ Gopkg.toml.new 2018-01-23 09:09:58.475261707 -0800 +@@ -1,3 +1,8 @@ + [[constraint]] + name = "github.com/foo/bar" + revision = "f5742cb6" ++ ++[[override]] ++ name = "github.com/foo/bar" ++ branch = "work-dev" ++ source = "github.com/myfork/bar" +``` + +The previous case is more common because typically you do not have permissions +to push directly to the main repository. + +## Miscellaneous + +For additional information about vendoring, see +"[Re-vendor PRs](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#re-vendor-prs)". diff --git a/VMT/KCSA.md b/VMT/KCSA.md new file mode 100644 index 0000000000..adcb1ce4af --- /dev/null +++ b/VMT/KCSA.md @@ -0,0 +1,36 @@ +# Kata Containers Security Advisories + +* [Kata Containers Security Advisories](#kata-containers-security-advisories) + * [KCSA summary](#kcsa-summary) + * [Determine Kata Containers version](#determine-kata-containers-version) + * [Upgrade](#upgrade) + +## KCSA summary + +This table lists all previously published Kata Containers Security Advisories ([KCSA]'s), newest first: + +| Date | [KCSA] | Affected Versions | Description | +| ---------- | -------------------------------------------------- | ------------------ | --------------------------------------------------- | +| 2020-12-03 | [KCSA-CVE-2020-27151](KCSA/KCSA-CVE-2020-27151.md) | < 1.11.5 | Executing host binaries using annotations | +| 2020-11-17 | [KCSA-CVE-2020-28914](KCSA/KCSA-CVE-2020-28914.md) | < 1.11.5 | Improper file permissions for read-only volumes | +| 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 | +| 2020-06-12 | [KCSA-CVE-2020-2023](KCSA/KCSA-CVE-2020-2023.md) | < 1.11.1 | Execution with unnecessary privileges | +| 2020-05-28 | [KCSA-CVE-2020-2025](KCSA/KCSA-CVE-2020-2025.md) | < 1.11.0 | Cloud Hypervisor guest image persists vulnerability | +| 2020-05-28 | [KCSA-CVE-2020-2024](KCSA/KCSA-CVE-2020-2024.md) | < 1.11.0 | Improper link resolution vulnerability | +| 2019-02-22 | [KCSA-CVE-2019-5736](KCSA/KCSA-CVE-2019-5736.md) | *not applicable* | `runc` container breakout | + +## Determine Kata Containers version + +To determine which version of Kata Containers you are running, see the +[upgrading document](https://github.com/kata-containers/kata-containers/blob/2.0-dev/docs/Upgrading.md#determine-current-version). + +## Upgrade + +If you are running a version of Kata Containers affected by one or more [KCSA]'s, +you are strongly encouraged to upgrade as soon as possible: + +- [Kata 1.x upgrading document](https://github.com/kata-containers/documentation/blob/master/Upgrading.md) +- [Kata 2.x upgrading document](https://github.com/kata-containers/kata-containers/blob/2.0-dev/docs/Upgrading.md) + + +[KCSA]: https://github.com/kata-containers/community/blob/master/VMT/VMT.md#acronyms diff --git a/VMT/KCSA/KCSA-CVE-2019-5736.md b/VMT/KCSA/KCSA-CVE-2019-5736.md new file mode 100644 index 0000000000..18b783bda5 --- /dev/null +++ b/VMT/KCSA/KCSA-CVE-2019-5736.md @@ -0,0 +1,49 @@ +announcement-date: 2019-02-22 + +id: KCSA-CVE-2019-5736 + +title: CVE-2019-5736 `runc container breakout` assessment + +description: Impact of CVE-2019-5736 on Kata Containers + +potentially-affected-components: + + - components: `kata-agent` + version: all + +vulnerabilities: + + - CVE-ID: CVE-2019-5736 + +reporters: + + - name: `Graham Whaley` + affiliation: VMT member + reported: + - Original report seen on dev@opencontainers.org + - `oss-sec` posting: https://seclists.org/oss-sec/2019/q1/119 + - MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736 + +issues: + + links: + - https://github.com/kata-containers/community/issues/85 + + reviews: + - no fix required. No PR raised. + +reproduce: + - Exploit does not effect Kata Containers. + +notes: + - The CVE-2019-5736 does not affect Kata Containers. Kata Containers does use the + runc libcontainer library as part of its `kata-agent` to launch container workloads, but + the `kata-agent` executable is a permanently running application within the Kata Containers + VM. Thus, the exit/re-execute cycle utilised by CVE-2019-5736 to execute the injected code + is never undertaken. + - It should be noted, if the exploit had escaped from the `kata-agent`, the exploit code + would have been executing inside the Kata Containers VM as root, and would not have direct + access to either the host system or other container/pods. + - It is highly likely Kata Containers will vendor in and adopt all relevant libcontainer updates + and changes, but given the "copying" nature of some fixes, a performance and resource impact + review will be undertaken. diff --git a/VMT/KCSA/KCSA-CVE-2020-2023.md b/VMT/KCSA/KCSA-CVE-2020-2023.md new file mode 100644 index 0000000000..1d1b033359 --- /dev/null +++ b/VMT/KCSA/KCSA-CVE-2020-2023.md @@ -0,0 +1,69 @@ +announcement-date: 2020-06-12 + +id: KCSA-CVE-2020-2023 + +title: Kata Containers Execution with Unnecessary Privileges + +description: A container can access the guest root file system device. +This can be used to gain code execution on the guest and masquerade as `kata-agent`. + +affected-components: + + - components: `kata-agent` + version: Before v1.11.1 + +vulnerabilities: + + - CVE-ID: CVE-2020-2023 + +reporters: + + - name: `Yuval Avrahami` + affiliation: `Palo Alto Networks` + reported: + - CVE-2020-2023 + +issues: + + links: + - https://github.com/kata-containers/agent/issues/791 + - https://github.com/kata-containers/runtime/issues/2476 + - https://github.com/kata-containers/runtime/issues/2488 + + reviews: + + v1.11.1: + - https://github.com/kata-containers/agent/pull/792 + - https://github.com/kata-containers/runtime/pull/2477 + - https://github.com/kata-containers/runtime/pull/2487 + + type: GitHub + +reproduce: + + - A malicious container can create a device file for the guest root filesystem + device, and use it to modify the guest filesystem through utilities + like [`debugfs`](https://linux.die.net/man/8/debugfs), potentially allowing + a container-to-guest breakout: + + 1. Find the guest root filesystem device major and minor numbers by inspecting `/sys/dev/block`. + 2. Use`mknod` to create a device file for the guest root filesystem device. + 3. Use utilities such as `debugfs` to access the device file and modify the guest filesystem. + 4. Attempt to gain code execution on the guest by overwriting crucial guest files (e.g. `kata-agent`, `libc`) + + When the guest filesystem is mounted with [DAX](https://www.kernel.org/doc/Documentation/filesystems/dax.txt), + it's easier for the container to gain guest code execution. With DAX, + changes made to the device immediately propagate to the pages used by guest + processes. This means the container can inject code to guest processes by + modifying the executables and libraries used by them. + + Without DAX, the malicious container can force changes made to the device to + propagate to guest pages by exhausting memory, forcing the guest kernel to + re-read the pages from the compromised device. The attack may fail if the + container memory is limited by cgroups. + +notes: + - The vulnerability can be used to compromise the guest and masquerade + as the `kata-agent`. To exploit the issue, the container must + possess `CAP_MKNOD` capability. + All users are recommended to upgrade to mitigate guest breakout. diff --git a/VMT/KCSA/KCSA-CVE-2020-2024.md b/VMT/KCSA/KCSA-CVE-2020-2024.md new file mode 100644 index 0000000000..d8e3ab01a8 --- /dev/null +++ b/VMT/KCSA/KCSA-CVE-2020-2024.md @@ -0,0 +1,68 @@ +announcement-date: 2020-05-28 + +id: KCSA-CVE-2020-2024 + +title: Kata Containers improper link resolution vulnerability + +description: An improper link resolution vulnerability affects Kata Containers +versions prior to 1.11.0. Upon container teardown, a malicious guest can trick +the `kata-runtime` into unmount any mount point on the host and all mount +points underneath it, potentiality resulting in a host DoS. + +affected-components: + + - components: `kata-runtime` + version: Before v1.11.0 + +vulnerabilities: + + - CVE-ID: CVE-2020-2024 + +reporters: + + - name: `Yuval Avrahami` + affiliation: `Palo Alto Networks` + reported: + - CVE-2020-2024 + +issues: + + links: + - https://github.com/kata-containers/runtime/issues/2474 + + reviews: + + v1.11.0: + - https://github.com/kata-containers/runtime/pull/2475 + + type: GitHub + +reproduce: + - When Kata Containers is configured with overlay2 as the storage driver, the + attack follows the steps below (all actions are executed by the malicious + guest): + 1. Rename `/run/kata-containers/shared/containers/${ctr-id}` to `/run/kata-containers/shared/containers/${ctr-id}_original_` + 2. Then, recreate `/run/kata-containers/shared/containers/${ctr-id}` + 3. Create a `symlink` to the host target mount named `/run/kata-containers/shared/containers/${ctr-id}/rootfs` + + For devicemapper: + 1. Unmount `/run/kata-containers/shared/containers/${ctr-id}` + 2. Create a `symlink` to the host target mount named `/run/kata-containers/shared/containers/${ctr-id}/rootfs` + +notes: + - The vulnerability can be used to attack the host by malicious containers + that find other ways to gain control over the guest. And all users are + recommended to upgrade. + + The unmount operation is done with the MNT_DETACH flag, meaning that mount + points under the target mount will be unmounted as well. Because of that, + if we target ‘/’ in our attack, then the host mounts underneath it (e.g., + `/proc`, `/sys`, etc.) will be unmounted as well, resulting in the host being + non-functional in most scenarios (e.g. being a `kubernetes` node), creating + a Denial of Service. + + On `kubernetes`, a malicious guest can trigger multiple container deletions + by simply killing the container processes running on it. With the default + `kubernetes` restart policy, containers will be removed and recreated. This + process can be repeated by the malicious guest several times to control + multiple unmount operations on the host. diff --git a/VMT/KCSA/KCSA-CVE-2020-2025.md b/VMT/KCSA/KCSA-CVE-2020-2025.md new file mode 100644 index 0000000000..c29e72d026 --- /dev/null +++ b/VMT/KCSA/KCSA-CVE-2020-2025.md @@ -0,0 +1,62 @@ +announcement-date: 2020-05-28 + +id: KCSA-CVE-2020-2025 + +title: Kata Containers with Cloud Hypervisor guest image persists vulnerability + +description: Kata Containers before 1.11.0 on Cloud Hypervisor persists guest +filesystem changes to the underlying image file on the host. A malicious guest +can overwrite the image file to gain control of all subsequent guest VMs. +Since Kata Containers uses the same VM image file with all VMMs, this issue +may also affect QEMU and Firecracker based guests. + +affected-components: + + - components: `kata-runtime` + version: Before v1.11.0 + +vulnerabilities: + + - CVE-ID: CVE-2020-2025 + +reporters: + + - name: `Yuval Avrahami` + affiliation: `Palo Alto Networks` + reported: + - CVE-2020-2025 + +issues: + + links: + - https://github.com/kata-containers/runtime/issues/2488 + + reviews: + + v1.11.0: + - https://github.com/kata-containers/runtime/pull/2487 + + type: GitHub + +reproduce: + - Create a Kata Container using Cloud Hypervisor + - Create a new file on the guest rootfs + - View the guest rootfs image on the host and the file can be seen there + +notes: + - The vulnerability can be used to attack other guests by malicious containers + that find other ways to gain control over the guest. And all users running + Kata Containers on top of Cloud Hypervisor are recommended to upgrade. + + When running Kata Containers with Cloud Hypervisor, any change made to root + filesystem device is written to the underlying `.img` file. Since the device + is plugged as read-write, a malicious guest could write to it and the changes + will propagate to the image file on the host. + + Compromising the guest image file allows an attacker to control all + subsequent guests that run that image. Since, by default, the same guest + image file is used by all VMMs (QEMU, Firecracker and Cloud Hypervisor), + the next time any guest is executed, it will be malicious. This immediately + compromises all subsequent container runs. Additionally, it can expose the + host to attacks that require the guest to be malicious from the moment it + boots. diff --git a/VMT/KCSA/KCSA-CVE-2020-2026.md b/VMT/KCSA/KCSA-CVE-2020-2026.md new file mode 100644 index 0000000000..4947216912 --- /dev/null +++ b/VMT/KCSA/KCSA-CVE-2020-2026.md @@ -0,0 +1,98 @@ +announcement-date: 2020-06-12 + +id: KCSA-CVE-2020-2026 + +title: Kata Containers Improper Link Resolution Before File Access + +description: A malicious guest compromised before a container +creation (e.g. a malicious guest image or a guest running multiple containers) +can trick the `kata-runtime` into mounting the untrusted container filesystem + on any host path, potentially allowing for code execution on the host. +This issue affects: Kata Containers 1.11 versions earlier than 1.11.1; +Kata Containers 1.10 versions earlier than 1.10.5. + +affected-components: + + - components: `kata-runtime` + version: Before v1.11.1, v1.10.5 + +vulnerabilities: + + - CVE-ID: CVE-2020-2026 + +reporters: + + - name: `Yuval Avrahami` + affiliation: `Palo Alto Networks` + reported: + - CVE-2020-2026 + +issues: + + links: + - https://github.com/kata-containers/runtime/issues/2712 + + reviews: + + v1.11.0: + - https://github.com/kata-containers/runtime/pull/2713 + + type: GitHub + +reproduce: + - A malicious guest compromised before a container creation (e.g. a malicious + guest image or a guest running multiple containers) can trick the `kata-runtime` + into mounting the untrusted container filesystem on any host path. + + When Kata Containers is configured with overlay2 as storage driver, + a malicious guest can create a symbolic link in the shared directory at + `/run/kata-containers/shared/containers/${ctrid}/rootfs` to a target directory + on the host. Upon container creation, the `kata-runtime` will be tricked into + bind mounting the container filesystem at the target directory on the host. + + To create the symbolic link the guest must know the container id as it’s a part + of the mount’s target path. The first container in a sandbox is unique in that + regard since its id is the sandbox id, which is known to the guest at the time of the mount. + If a guest is compromised before the first container is added to it (e.g. a malicious guest image), + it can execute the following attack in case of overlay file systems: + 1. The malicious guest receives the `CreateSandbox` message and extracts the sandbox + id from it. The first container id matches the sandbox id and is derived from that message. + 2. The malicious guest creates the malicious symbolic link at the shared directory, + at `/run/kata-containers/shared/containers/${first_ctrid}/rootfs` + 3. The malicious guest returns a response for `CreateSandbox` + 4. Once the `kata-runtime` on the host receives the `CreateSandbox` response, it tries to + bind mount the container image at `/run/kata-containers/shared/sandbox/$sbx_id/${first_ctrid}/rootfs` + 5. The malicious symbolic link redirects the mount operation to the target on the host. + + In case of non initial container images, the guest does not know the container id. + In case of volume mounts and mounts related to platform-specific files such as + `/etc/hosts`, the mounts are performed in the shared directory on paths that are not + known to the guest. The guest would need to win a race condition between + `ensureDestinationExists` function called by `kata-runtime` that creates the file or + directory that is to be mounted on and bind mount done after calling `ensureDestinationExists`. + + Between those steps, the guest must replace the created file or directory + with a symbolic link to a target on the host. + +notes: + - Given that the container image is malicious, the guest can gain code execution + on the host by mounting over directories such as /bin or /lib. Besides code + execution, the host can be DOSed as well (by mounting over crucial directories). + + In the case of overlay2 mounts, once the container engine (e.g. Docker) + removes the container, it might also delete the lower layers of the container + filesystem, rendering the mount done through this attack empty. In the case + of mounting the malicious container image over /bin, if no process tried running + a binary from /bin before the container is removed, then /bin will become empty, + and the attack fails. + To deal with the above, an attacker could target /lib or /lib64, which + contains libraries for dynamically linked binaries such as the `kata-runtime` itself. + Under Docker for example, the `kata-runtime` will most likely be executed + again in the process of spawning a container. The libraries loaded and + executed by the `kata-runtime` process would then be malicious. + + With Kubernetes, there can be multiple containers in a guest, but the first is + always the pause container. An attack redirecting the pause container is limited + to a host DoS since the pause container image isn't malicious. + An attack redirecting container volumes or platform-specific mounts is most + likely limited to a DoS since the content of these mounts isn't malicious. diff --git a/VMT/KCSA/KCSA-CVE-2020-27151.md b/VMT/KCSA/KCSA-CVE-2020-27151.md new file mode 100644 index 0000000000..0983346ad7 --- /dev/null +++ b/VMT/KCSA/KCSA-CVE-2020-27151.md @@ -0,0 +1,94 @@ +announcement-date: 2020-12-03 + +id: KCSA-CVE-2020-27151 + +title: Some `kata-runtime` annotations can execute arbitrary programs + +description: An insufficient validation of annotations affects Kata Containers +prior to version 1.11.5, making it possible to execute arbitrary programs on the +host. Unless specific filtering of the annotations is performed by the upper +layers of the stack, it makes it possible for a user to send manifests that +instruct `kata-runtime` to execute arbitrary code with the same privilege level as +`kata-runtime` itself. + +affected-components: + + - components: `kata-runtime` + + - version: Before v1.11.5 + +vulnerabilities: + + - CVE-ID: [CVE-2020-27151](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-27151) + +reporters: + + - name: `Christophe de Dinechin` + + - affiliation: Red Hat + + - reported: + + - [CVE-2020-27151](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-27151) + +issues: + + links: + + - original report: https://bugs.launchpad.net/katacontainers.io/+bug/1878234 + + - version 1.11.4: https://github.com/kata-containers/runtime/issues/3004 + + - version 2.0: https://github.com/kata-containers/kata-containers/issues/901 + + reviews: + + Embargoed: + + - https://github.com/kata-containers/runtime-CVE-2020-27151/pull/1 + + Public review: + + - https://github.com/kata-containers/runtime/pull/3005 + + v2.0.0: + + - https://github.com/kata-containers/kata-containers/pull/902 + + v1.12.0: + + - https://github.com/kata-containers/runtime/pull/3059 + + v1.11.5: + + - https://github.com/kata-containers/runtime/pull/3058 + + type: GitHub + +reproduce: + + - When using a Kubernetes with the Kata Containers runtime enabled, starting a + pod with an annotation like the following will execute the binary called + `/usr/local/bin/hello` and pass it arguments `arg1` and `arg2`. + +``` + io.katacontainers.config.hypervisor.virtio_fs_daemon: "/usr/local/bin/hello" + io.katacontainers.config.hypervisor.virtio_fs_extra_args: "[ \"arg1\", \"arg2\" ]" +``` + + - As an illustration, passing `/usr/sbin/shutdown` as the binary name and `-h`, + `now` as the arguments will shutdown the host machine instead of executing + the container. + +notes: + + - The annotation corresponding to the `virtiofsd` path is the most susceptible + to be exploited that way, because another annotation makes it possible to + pass parameters to the binary being executed. + + - This vulnerability has been fixed in releases 1.12.0, 1.11.5 and 2.0 branch. + The fixed versions provide annotation filters that can be configured by a + system administrator, listing the names that are allowed for each of the + binaries that `kata-runtime` is susceptible to launch. Additional filtering + was added for the paths of host system files that `kata-runtime` needs to + access, such as the location of the `/dev/random` device. diff --git a/VMT/KCSA/KCSA-CVE-2020-28914.md b/VMT/KCSA/KCSA-CVE-2020-28914.md new file mode 100644 index 0000000000..115974cf87 --- /dev/null +++ b/VMT/KCSA/KCSA-CVE-2020-28914.md @@ -0,0 +1,71 @@ +announcement-date: 2020-11-17 + +id: KCSA-CVE-2020-28914 + +title: Kata Containers Improper file permissions for read-only volumes + +description: An improper file permissions vulnerability affects Kata Containers +prior to 1.11.5. When using a Kubernetes host-path volume and mounting +either a file or directory into a container as readonly, the file/directory +is mounted as read-only inside the container, but is still writable inside +the guest. For a container breakout situation, a malicious guest can +potentially modify or delete files/directories expected to be read-only. + +affected-components: + + - components: `kata-runtime` + version: Before v1.11.5 + +vulnerabilities: + + - CVE-ID: CVE-2020-28914 + +reporters: + + - name: `Alex Chapman` + affiliation: Independent Researcher + reported: + - CVE-2020-28914 + +issues: + + links: + - https://github.com/kata-containers/runtime/issues/3041 + - https://github.com/kata-containers/kata-containers/issues/1061 + + reviews: + + v2.0.0: + - https://github.com/kata-containers/kata-containers/pull/1062 + + v1.12.0: + - https://github.com/kata-containers/runtime/pull/3048 + + v1.11.5: + - https://github.com/kata-containers/runtime/pull/3051 + + type: GitHub + +reproduce: + + - When using a Kubernetes host-path volume and mounting either a file or + directory into a container with read-only: true, the file/directory is + mounted as read-only inside the container, but is still writable inside + the guest (but outside of the container). + + In case a container breakout were to occur, a malicious guest will be able to + modify or delete files and directories that are expected to be read-only inside + the guest. + 1. Start a pod with a host-path volume passed as read-only to a container within the pod. + 2. Start a debug shell to get root access within the guest and attempt + to write to the read-only volume shared with the guest under + `/run/kata-containers/shared/sandboxes/{pod-id}/{volume}/` + 3. Though the volume is not writable within the container, the guest will be + able to write to the volume or even delete it. + +notes: + + - If the read-only files/directories are shared across multiple + pods on the same node, other pods will be able to see the modified/deleted files/directories. + This vulnerability has been fixed in releases 1.12.0, 1.11.5 and 2.0 branch. + diff --git a/VMT/VMT-process.png b/VMT/VMT-process.png new file mode 100644 index 0000000000..cc13e6d166 Binary files /dev/null and b/VMT/VMT-process.png differ diff --git a/VMT/VMT-process.svg b/VMT/VMT-process.svg new file mode 100644 index 0000000000..a1482a858a --- /dev/null +++ b/VMT/VMT-process.svg @@ -0,0 +1,880 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + KCSA bugtask status + PublishKCSA + VMT + + + + + VMT + + + + Devs + + + + External + + Key + + + + + Time + + + + diff --git a/VMT/VMT.md b/VMT/VMT.md new file mode 100644 index 0000000000..58874f3cbe --- /dev/null +++ b/VMT/VMT.md @@ -0,0 +1,217 @@ +# Vulnerability Management Process + +> The Kata Containers vulnerability management policy is derived from the [OpenStack Vulnerability Management Process](https://security.openstack.org/vmt-process.html) and licensed under the [Creative Commons Attribution 3.0 Unported License](https://creativecommons.org/licenses/by/3.0/legalcode) + +The Kata Containers Vulnerability Management Team (VMT) is responsible for coordinating the progressive disclosure of a vulnerability. + +Members of the team are independent and security-minded folks who ensure that vulnerabilities are dealt with in a timely manner and that downstream stakeholders are notified in a coordinated and fair manner. +Where a member of the team is employed by a downstream stakeholder, the member does not give their employer prior notice of any vulnerabilities. +In order to reduce the risk of accidental disclosure of vulnerability in the early stages, membership of this team is intentionally limited to a small number of people. + +# Acronyms + +To aid reading this document it helps to understand some key acronyms: + +| Acronym | Description | +| -------- | --------------------------------------------------------------- | +| CNA | [CVE Numbering Authority](https://cve.mitre.org/cve/cna.html) | +| CVE | [Common Vulnerabilities and Exposures](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures) | +| KCSA | Kata Containers Security Advisory | +| KCSN | Kata Containers Security Note | +| PR | [A GitHub Pull Request](https://help.github.com/articles/about-pull-requests/) | +| VMT | The Kata Containers Vulnerability Management Team | + +# Supported versions + +The VMT coordinates patches fixing vulnerabilities in +[supported stable branches of Kata Containers](https://github.com/kata-containers/documentation/blob/master/Stable-Branch-Strategy.md#branch-management), +in addition to the master branch (next version under development). + +# Process + +Each security bug is assigned a VMT *coordinator* (a member from the VMT) that will drive the fixing and disclosure process. +Here are the steps followed. + +![VMT process workflow](VMT-process.png) + +## Reception + +A report is received via the [Kata Containers Launchpad](https://launchpad.net/katacontainers.io). New reports should be created as a "Private Bug", thus initially restricting visibility +to the VMT members and the reporter. + +The first steps performed by the VMT are: + +* Confirm the validity of the report. +* Prefix the description with an [embargo reminder](templates/reception-embargo-reminder.md). +* Create and fill out a Kata Containers Security Advisory ([KCSA](templates/KCSA.md)) document, and attach it to the report. +* If the KCSA or report are *Incomplete*, add an [incomplete reception message](templates/reception-incomplete-message.md) in a comment. +* Once the VMT confirms a KCSA is warranted, the KCSA Issue status will be set to *Confirmed*. +* If the need for a KCSA is challenged, the KCSA Issue status should be set back to *Incomplete* until that question is resolved. + +For some lower-risk issues or problems which may only be easy to solve in future releases, the KCSA Issue will be set to *Opinion* and the core security reviewers for Kata Containers will be subscribed to determine whether they wish to issue a Kata Containers Security Note (KCSN) (these reports may still sometimes remain under embargo until the KCSN is issued). +If no KCSA is warranted and there is no benefit to a KCSN then the KCSA Issue will be set to *Won't Fix* or *Invalid* (depending on the specific situation) and the bug state switched from *Private Security* to *Public*, optionally adding the *security* bug tag if the report concerns a potential security hardening opportunity. + +If a Kata Containers Security Note (KCSN) is warranted, one should be written and posted to the [Kata Containers Security Note](templates/KCSN.md) document. + +The specifics are indexed in the [report taxonomy](#incident-report-taxonomy) and [task status](#kcsa-task-status) tables. + +## Patch development + +For a private report, the reporter and the affected project's core security review teams, plus anyone they deem necessary to develop and validate a fix, are added to the Launchpad bug subscription list. +A fix is proposed as a patch to the current master branch (as well as any affected supported branches) and attached to the Launchpad bug, **not sent to the public code review system**. + +For public reports, there is no need to directly subscribe anyone and patches can be submitted directly to the code review system instead as Pull Requests (PR). + +If project-side delays are encountered at this or any subsequent stage of the process, the VMT and other interested parties may reach out to all or any of the following [Open Infrastructure Foundation](https://openinfra.dev/about/) members: + +- @ttx +- @fungi + +## Patch review + +For a private report, once the initial patch has been attached to the bug, core reviewers on the subscription list from the project in question should review it and suggest updates or pre-approve it for merging. +Privately-developed patches need to be pre-approved so that they can be fast-tracked through public code review later at disclosure time. + +For public reports, Kata Containers usual public code review and approval processes apply. + +## Draft impact description + +In the mean time, the VMT coordinator prepares a vulnerability description that will be communicated to downstream stakeholders, and will serve as the basis for the Security Advisory (KCSA) that will be finally published. + +The description should properly credit the reporter, specify affected versions (including unsupported ones) and accurately describe impact and mitigation mechanisms. +The VMT coordinator should use the [Downstream stakeholder notification](templates/downstream-stakeholder-notification.md) template. +Once the description is posted, the KCSA Issue status should be switched to *Triaged*. + +## Review impact description + +The description is validated by the reporter and the [Architecture Committee](https://github.com/kata-containers/community#architecture-committee). + +### Send CVE request + +To ensure full traceability, obtaining a CVE assignment is attempted before the issue is communicated to a larger public. +This is generally done as the patch gets nearer to final approval. + +The KCSA Issue status is set to *In progress* and the approved impact description is submitted through [MITRE's CVE Request form](https://cveform.mitre.org/). +The *request type* is `Request a CVE ID`, the *e-mail address* should be that of the requester (generally the assigned VMT coordinator in the case of reports officially managed by the VMT), and for embargoed reports the coordinator's OpenPGP key should be pasted into the field provided. + +In the *required* section set the checkboxes indicating the product is not [CVE Numbering Authority](https://cve.mitre.org/cve/cna.html) (CNA) covered and that no prior CVE ID has been assigned, select an appropriate *vulnerability type* (using `Other or Unknown` to enter a freeform type if there is nothing relevant on the drop-down), set the *vendor* to `Kata Containers`, and the *product* and *version* fields to match the `$COMPONENTS` and `$AFFECTED_VERSIONS` from the impact description. +In the *optional* section set the radio button for *confirmed/acknowledged* to `Yes`, choose an appropriate *attack type* in the drop-down (often this is `Context-dependent` for our cases), check the relevant *impact* checkboxes, attempt to fill in the *affected components* and *attack vector* fields if possible, paste in the *suggested description* from the prose of the impact description (usually omitting the first sentence as it's redundant with other fields), put the `$CREDIT` details in the *discoverer/credits* field, and the Issue URL (along with the public Issue and PR URLs for patches if already public) in the *references* field. +If the report is still private, note that in the *additional information* field like `This report is currently under embargo and no disclosure date has been scheduled at this time.` + +At the bottom of the page, fill in the *security code* and click the *submit request* button. +If some fields contain invalid data they will be highlighted red; correct these, update the *security code* and *submit request* again until you get a confirmation page. + +## Get assigned CVE + +MITRE returns the assigned CVE. +It is added to the Launchpad bug in the comment field, and the Issue is retitled to "$TITLE ($CVE)". + + +## Embargoed disclosure + +Once the patches are approved and the CVE is assigned, a signed email with the vulnerability description is sent to the downstream stakeholders. +The disclosure date is set to 3-5 business days, excluding Monday/Friday and holiday periods, at 0000 UTC. +No stakeholder is supposed to deploy public patches before disclosure date. + +Once the email is sent, the KCSA Issue status should be set to *Fix committed*. +At that point we can also add downstream stakeholders to the Launchpad bug, if they have an appropriate Launchpad account. + +For non-embargoed, public vulnerabilities no separate downstream advance notification is sent. +Instead, the KCSA Issue is set to *Fix committed* status once the CVE assignment is received and KCSA drafting begins immediately. + +## Open bug, Push patch + +In preparation for this, make sure you have a core developer and a stable maintainer available to help pushing the fix at disclosure time. + +On the disclosure hour, open bug, push patches to GitHub PR for review on master and supported stable branches, fast-track approvals (referencing the bug). + +Embargo reminder can be removed at that point. + +[MITRE's CVE Request form](https://cveform.mitre.org/) should be used again at this point, but instead select a *request type* of `Notify CVE about a publication` and fill in the coordinator's *e-mail address*, provide a *link to the advisory* (Use the links from the [Kata Containers Security Advisories page](KCSA.md) if this is a formal KCSA), the *CVE IDs* covered, and the *date published*. +Once more, fill in the *security code* at the bottom of the page and *submit request*. + +## Publish KCSA + +Shortly after pushing the patches (potentially waiting for the first test runs to complete), publish the advisory to the [Kata Containers development mailing list](mailto:kata-dev@lists.katacontainers.io) and slack channels, and add the issue to the [list of KCSA's](KCSA.md). +Wait until all patches are merged to supported branches before setting the KCSA Issue status to *Fix released*. + +## All patches merged + +Patches approved in code review do not necessarily merge immediately, but should be tracked closely until they do. +Subsequent security point releases of affected software may then be tagged if warranted. + +# Incident Report Taxonomy + +The VMT is now using this classification list in order to assist vulnerability report triage, especially whenever a bug does not warrant an advisory. + +| Classes | Outcome | Description | +| -------- | --------- | ----------------------------------------- | +| Class A | KCSA | A vulnerability to be fixed in master and all supported releases | +| Class B1 | KCSN | A vulnerability that can only be fixed in master, security note for stable branches, e.g., default config value is insecure +| Class B2 | KCSN | A vulnerability without a complete fix yet, security note for all versions, e.g., poor architecture / design +| Class B3 | KCSN | A vulnerability in experimental or debugging features not intended for production use +| Class C1 | Potential | Not considered a practical vulnerability | (but some people might assign a CVE for it), e.g. one depending on UUID guessing +| Class C2 | Potential | A vulnerability, but not in Kata Containers supported code, e.g., in a dependency +| Class D | Potential | Not a vulnerability, just a bug with (some) security implications, e.g., strengthening opportunities +| Class E | | Neither a vulnerability nor hardening opportunity +| Class Y | | Vulnerability only found in development release +| Class Z | | When due process fails | + +# KCSA Task status + +Here is a summary of the different KCSA task status meanings. These statuses +are set in the Launchpad bug or GitHub Issues using Labels: + +| Status | Meaning | +| ------------- | ------------------------------------------------ | +| Incomplete | It is still unclear whenever the bug warrants an advisory +| Confirmed | The vulnerability is confirmed, impact description is in progress +| Triaged | Impact description has been submitted for review | +| In Progress | CVE has been requested | +| Fix committed | Pre-KCSA has been communicated | +| Fix released | All patches have been merged | +| Opinion | Issue is likely a Class B/C/D, waiting for KCSN | +| Won't Fix | Doesn't fit with the project plans, sorry | +| Invalid | Class E and Z, not a bug or vulnerability. No further action to be taken + +# Extent of Disclosure + +The science of vulnerability management is somewhere around being able to assess impact and severity of a report, being able to design security patches, being an obsessive process-following perfectionist and respecting the rule of lesser disclosure. + +Lesser disclosure is about disclosing the vulnerability details to an increasing number of people over time, but only to the people that are necessary to reach the next step. +The diagram above shows "disclosure extent" across the various steps of the process. + +Vulnerability reporters retain final control over the disclosure of their findings. +If for some reason they are uncomfortable with our process, their choice of disclosure terms prevails. + +## Embargo exceptions + +To keep the embargo period short and effective, the VMT may choose to open GitHub Issues. +Issues that take too much time to be fixed (e.g., more than 2 weeks) or Issues that require a complex patch are usually better solved in the open. + +Whenever such a case occurs, the Kata Containers [Architecture Committee](https://github.com/kata-containers/community#architecture-committee) is subscribed to the Launchpad bug in order to discuss whether or not it's imperative to keep that particular bug private. + +The same process is followed if an embargoed issue is, accidentally or not, leaked to the public. In all likelihood that Issue will then be moved to the Public state. + +## Downstream stakeholders + +Kata Containers as an upstream project is used in a number of distributions, products, private and public service offerings that are negatively affected by vulnerabilities. +In the spirit of [responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure), this ecosystem, collectively known as the downstream stakeholders, needs to be warned in advance to be able to prepare patches and roll them out in a coordinated fashion on disclosure day. +The embargo period is kept voluntarily small (3-5 business days), as a middle ground between keeping the vulnerability under cover for too long and not giving a chance to downstream stakeholders to react. + +If you are currently not a referenced stakeholder and think you should definitely be included on that email distribution list, please submit a [Launchpad bug](https://launchpad.net/katacontainers.io) with a rationale for your addition. + +# Templates + +A number of templates are provided for, and recommended for use in, the workflow for processing vulnerabilities. Those templates are referenced below. + +| Template | +| --------------------------------------------------------------- | +| [Reception incomplete message (unconfirmed issues)](templates/reception-incomplete-message.md) | +| [Reception embargo reminder (private issues)](templates/reception-embargo-reminder.md) | +| [Impact description ($DESCRIPTION)](templates/impact-description.md) | +| [CVE request email (private issues)](templates/cve-request-email-private.md) | +| [CVE request email (public issues)](templates/cve-request-email-public.md) | +| [Downstream stakeholders notification email (private issues)](templates/downstream-stakeholder-notification.md) | +| [Kata Containers security advisories (KCSA)](templates/KCSA.md) | +| [Kata Containers security notes (KCSN)](templates/KCSN.md) | diff --git a/VMT/templates/KCSA.md b/VMT/templates/KCSA.md new file mode 100644 index 0000000000..2ff065525e --- /dev/null +++ b/VMT/templates/KCSA.md @@ -0,0 +1,74 @@ +# Kata Containers security advisory (KCSA) template + +The template used to construct the KCSA attached to a VMT Launchpad bug, and later +potentially published. + +``` +announcement-date: YYYY-MM-DD + +id: KCSA-$NUM + +title: '$TITLE' + +description: '$DESCRIPTION_CONTENT' + +affected-components: + + - components: $COMPONENTS + version: $AFFECTED_VERSIONS + +vulnerabilities: + + - cve-id: $CVE + +reporters: + + - name: '$CREDIT' + affiliation: $CREDIT_AFFILIATION + reported: + - $CVE + +issues: + + links: + - https://github.com/kata-containers/$COMPONENT/issues/$ISSUE_NR + + reviews: + + v1.2.3: + - https://github.com/kata-containers/$COMPONENT/pull/$PR_NUMBER + + v2.3.4: + - https://github.com/kata-containers/$COMPONENT/pull/$PR_NUMBER + + type: GitHub + +reproduce: + - 'Any information on how to reproduce or verify if a system is affected' + +notes: + - 'Optional note such as cross project version requirements, + or details on how to reproduce and check for the vulnerability' +``` + +Once approved, the request will be added to the documentation repo and linked from the KCSA index page. It will then be emailed out. +We send two separate emails, to avoid off-topic replies to `oss-security` list: + +``` +- To: +- To: +``` + +Subject and content for both emails is identical: + +``` +- Subject: `\[KCSA-$NUM\] $TITLE ($CVE)` +- Body: The KCSA markdown document +``` + +Notes: + +- Email must be GPG-signed. +- $CVE must always be of the form CVE-YYYY-XXXX +- $NUM is of the form YYYY-XX + diff --git a/VMT/templates/KCSN.md b/VMT/templates/KCSN.md new file mode 100644 index 0000000000..3a61294162 --- /dev/null +++ b/VMT/templates/KCSN.md @@ -0,0 +1,28 @@ +# Kata Containers Security Note (KCSN) template + +Title (single sentence) +--- + +### Summary ### +A few sentences describing the issue at a high level. + +### Affected Services / Software ### +A comma separated list of affected Kata components and releases. + +### Discussion ### +A detailed discussion of the problem. This should have enough detail +that the person reading can determine if their deployment is affected, +when the problem was introduced, and what types of attacks/problems that +an affected deployment would be exposed to. + +### Recommended Actions ### +A detailed description of what can be done to remediate the problem (if +possible). If the recommendation involves configuration changes, +example snippets of configuration files should be included here. + +### Contacts / References ### +Author: +This KCSN : +Original Launchpad Bug : +Mailing List : [Security] tag on kata-dev@lists.katacontainers.io +CVE: diff --git a/VMT/templates/cve-request-email-private.md b/VMT/templates/cve-request-email-private.md new file mode 100644 index 0000000000..2d39a5d479 --- /dev/null +++ b/VMT/templates/cve-request-email-private.md @@ -0,0 +1,22 @@ +# CVE request email (private issues) template + +``` +- To: CNA +- Subject: CVE request for vulnerability in Kata Containers $COMPONENTS + +A vulnerability was discovered in Kata Containers (see below). In order to +ensure full traceability, we need a CVE number assigned that we can attach +to private and public notifications. +Please treat the following information as confidential until further public +disclosure. + +$DESCRIPTION + +Thanks in advance, + +-- +$VMT_COORDINATOR_NAME +Kata Containers Vulnerability Management Team +``` + +Email must be GPG-signed and GPG-encrypted. diff --git a/VMT/templates/cve-request-email-public.md b/VMT/templates/cve-request-email-public.md new file mode 100644 index 0000000000..31d3563a59 --- /dev/null +++ b/VMT/templates/cve-request-email-public.md @@ -0,0 +1,26 @@ +# CVE request email (public issues) template + +``` +- To: +- Cc: +- Subject: CVE request for vulnerability in Kata Containers $COMPONENTS + +A vulnerability was discovered in Kata Containers (see below). In order to +ensure full traceability, we need a CVE number assigned that we can attach +to further notifications. +This issue is already public, although an advisory was not sent yet. + +$DESCRIPTION + +References: +https://github.com/kata-containers/$COMPONENT/issues/$ISSUE_NR + +Thanks in advance, + +-- +$VMT_COORDINATOR_NAME +Kata Containers Vulnerability Management Team +``` + +Email must be GPG-signed but not encrypted. + diff --git a/VMT/templates/downstream-stakeholder-notification.md b/VMT/templates/downstream-stakeholder-notification.md new file mode 100644 index 0000000000..aa288be198 --- /dev/null +++ b/VMT/templates/downstream-stakeholder-notification.md @@ -0,0 +1,44 @@ +# Downstream stakeholders notification email (private issues) template + +We send two separate emails, to avoid off-topic replies to Linux-distros: + +``` +- To: +- To: +``` + +Subject and content for both emails is identical: + +``` +- *Subject:* \[pre-KCSA\] Vulnerability in Kata Containers $COMPONENTS ($CVE) + +This is an advance warning of a vulnerability discovered in +Kata Containers, to give you, as downstream stakeholders, a chance to +coordinate the release of fixes and reduce the vulnerability window. +Please treat the following information as confidential until the +proposed public disclosure date. + +$DESCRIPTION + +Proposed patch: See attached patches. +Unless a flaw is discovered in them, these patches will be merged to +their corresponding branches on the public disclosure date. + +CVE: $CVE + +Proposed public disclosure date/time: +YYYY-MM-DD, 0000UTC +Please do not make the issue public (or release public patches) +before this coordinated embargo date. + +Original private report: +https://bugs.launchpad.net/katacontainers.io/+bug/$NNNNNN +For access to read and comment on this report, please reply to me +with your Launchpad username and I will subscribe you. +-- +$VMT_COORDINATOR_NAME +Kata Containers Vulnerability Management Team +``` + +Proposed patches are attached, email must be GPG-signed. +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`. diff --git a/VMT/templates/impact-description.md b/VMT/templates/impact-description.md new file mode 100644 index 0000000000..7b2c8c34d4 --- /dev/null +++ b/VMT/templates/impact-description.md @@ -0,0 +1,32 @@ +# Impact description ($DESCRIPTION) template + +``` +Title: $TITLE +Reporter: $CREDIT +Projects: $COMPONENTS +Affects: $AFFECTED_VERSIONS + +Description: +$CREDIT reported a vulnerability in [project feature name]. +By doing [action] a [actor] may [impact] resulting in [consequence]. +Only [project deployment mode] are affected. +``` + +The AFFECTED_VERSIONS needs to stay valid after the fix is released. +For example, when v1.2.1 and v1.3.2 are still security supported, the AFFECTED_VERSIONS of should read like this: + +``` +Affects: >=v1.2.0 <=v1.2.1, >=v1.3.2 <=v1.3.2 +``` + +Once v1.2.x reaches end of life, that line becomes: + +``` +Affects: >=v1.3.2 <=v.1.3.2 +``` + +If the oldest version affected is not easily identified, leave it open-ended: + +``` +Affects: <=v1.2.1 and ==v1.3.2 +``` diff --git a/VMT/templates/reception-embargo-reminder.md b/VMT/templates/reception-embargo-reminder.md new file mode 100644 index 0000000000..64e617d865 --- /dev/null +++ b/VMT/templates/reception-embargo-reminder.md @@ -0,0 +1,16 @@ +# Reception embargo reminder (private issues) template + +``` +This issue is being treated as a potential security risk under embargo. +Please do not make any public mention of embargoed (private) security +vulnerabilities before their coordinated publication by the Kata +Containers Vulnerability Management Team in the form of an official +Kata Containers Security Advisory. This includes discussion of the bug +or associated fixes in public forums such as mailing lists, code review +systems and bug trackers. Please also avoid private disclosure to other +individuals not already approved for access to this information, and +provide this same reminder to those who are made aware of the issue +prior to publication. All discussion should remain confined to this +private bug report, and any proposed fixes should be added to the bug +as attachments. +``` diff --git a/VMT/templates/reception-incomplete-message.md b/VMT/templates/reception-incomplete-message.md new file mode 100644 index 0000000000..e51688073b --- /dev/null +++ b/VMT/templates/reception-incomplete-message.md @@ -0,0 +1,9 @@ +# Reception incomplete message (unconfirmed issues) template + +``` +Since this report concerns a possible security risk, an incomplete +security advisory task has been added while the core security +reviewers for the affected project or projects confirm the bug +and discuss the scope of any vulnerability along with potential +solutions. +``` diff --git a/elections/README.md b/elections/README.md new file mode 100644 index 0000000000..c2e94ac673 --- /dev/null +++ b/elections/README.md @@ -0,0 +1,157 @@ +* [Kata Containers Elections](#kata-containers-elections) + * [Architecture Committee Elections](#architecture-committee-elections) + * [Election Dates](#election-dates) + * [Electorate](#electorate) + * [Candidacy](#candidacy) + * [Architecture Committee Responsibilities](#architecture-committee-responsibilities) + * [System](#system) + * [Previous elections](#previous-elections) + +# Kata Containers Elections + +This repository contains Kata Containers Elections reference documents +and tooling to run elections. + +# Architecture Committee Elections + +The Kata Architecture Committee is comprised of seven seats, elected by the +eligible community, and one Committee Chair, selected by the five +Architecture Committee members. + +## Election Dates + +The Architecture Committee elections take place every six months, as +outlined in the +[Architecture Committee section](https://github.com/kata-containers/community#architecture-committee) +of the Community README. + +The election process begins three calendar weeks prior to the election. +- One week for candidates to submit their candidacy +- One week "debate period" for electorate to pose questions on the community +mailing lists to learn the candidates platforms +- One week for voting +- Results announced + +## Electorate + +[Contributors](https://github.com/kata-containers/community#contributor) +(defined as anyone who has had code merged in the Kata Containers +project in the last 12 months prior to the first day of the nomination period) +are eligible to vote in Architecture Committee elections. + +## Candidacy + +Anyone who has made contributions to the Kata Containers project is eligible +to run. Candidates submit their candidacy by adding a text file to the +corresponding election folder under the community repo with their interest +and platform, and announcing their candidacy on the [community developer mailing +list](http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev). + +There are no term limits for Architecture Committee seats, but in order to +encourage diversity, no more than two of the five seats may be filled by +members with the same company affiliation. If a third member would be in +violation of the diverse affiliation rule, the seat is awarded to the next +highest scoring candidate who would not violate the rule. Members who change +affiliation between elections in a way that violates the diverse affiliation +rule are not required to relinquish their seat, however, the rule will +be enforced and applied in the following election. + +## Architecture Committee Responsibilities + +Architecture Committee members guide the technical direction of the Kata +Containers project. This includes, but is not limited to: +- Serving the Kata technical community + - Driving technical direction + - Handling interactions with other governance bodies + - Acting as the final call in technical disputes + - Ensuring inclusive, open collaboration and development + - Identifying gaps in technical direction or community health +- Attending Architecture Committee meetings + - Regular participation (and advanced notice of absences) in online + Arch Committee meetings and in-person meetings is expected +- Actively participates in Kata Containers design and development + - Not restricted to code contributions, but active input and guidance + is expected + +## System + +The Architecture Committee election uses +[CIVS with Condorcet method voting](https://civs.cs.cornell.edu/). +You can find information about how to set up the voting on the +related [OpenStack wiki](https://wiki.openstack.org/wiki/Election_Officiating_Guidelines#Running_the_election_itself). + +Due to CIVS policy, to vote in private CIVS polls, everyone in the +electorate must opt in to email communication. CIVS has a +[dedicated page](https://civs1.civs.us/cgi-bin/opt_in.pl) to register +the email address they are using on GitHub. Once someone has +opted into receiving e-mail from CIVS it should allow future +ballots from any poll to be sent to the same e-mail address. + +## Tools + +See the [election tools documentation](tools). + +## Process + +See the [election process documentation](process) for details on +the process that election officials need to follow to successfully +execute the AC election. + +## Current elections + +- April 2025 + - [election](arch-committee-2025-04) + - [results](arch-committee-2025-04/Results.md) + +## Previous elections + +- October 2024 + - [election](arch-committee-2024-10) + - [results](arch-committee-2024-10/Results.md) + +- April 2024 + - [election](arch-committee-2024-04) + - [results](arch-committee-2024-04/Results.md) + +- October 2023 + - [election](arch-committee-2023-10) + - [results](arch-committee-2023-10/Results.md) + +- April 2023 + - [election](arch-committee-2023-04) + - [results](arch-committee-2023-04/Results.md) + +- November 2022 + - [election](arch-committee-2022-11) + - [results](arch-committee-2022-11/Results.md) + +- March 2022 + - [election](arch-committee-2022-03) + - [results](arch-committee-2022-03/Results.md) + +- September 2021 + - [election](arch-committee-2021-09) + - [results](arch-committee-2021-09/Results.md) + +- February 2021 + - [election](arch-committee-2021-02) + - [results](arch-committee-2021-02/Results.md) + +- September 2020 + - [election](arch-committee-2020-09) + - [results](arch-committee-2020-09/Results.md) + +- February 2020 + - [election](arch-committee-2020-02) + - [results](arch-committee-2020-02/Results.md) + +- September 2019 + - [election](arch-committee-2019-09) + - [results](arch-committee-2019-09/Results.md) + +- March 2019 + - [election](arch-committee-2019-03) + - [results](arch-committee-2019-03/Results.md) + +- September 2018 + [election](arch-committee-2018-09) diff --git a/elections/arch-committee-2018-09/2018-09-Results.txt b/elections/arch-committee-2018-09/2018-09-Results.txt new file mode 100644 index 0000000000..a68b40110d --- /dev/null +++ b/elections/arch-committee-2018-09/2018-09-Results.txt @@ -0,0 +1,7 @@ +Architecture Committee Election +September 10, 2018 + +Results: +1) Eric Ernst (egernst) +2) Wei Zhang (WeiZhang555) +3) Jon Olson (jon) \ No newline at end of file diff --git a/elections/arch-committee-2018-09/EricErnst.txt b/elections/arch-committee-2018-09/EricErnst.txt new file mode 100644 index 0000000000..6a4a968452 --- /dev/null +++ b/elections/arch-committee-2018-09/EricErnst.txt @@ -0,0 +1,23 @@ +Name: Eric Ernst + +Email: eric.ernst@intel.com + +Background: + +I am a senior software engineer in Intel's Open Source Technology Center, acting both as a contributor +as well as a technical lead for the Intel-team contributing to Kata Containers. Before Kata, I spent time working +on Clear Containers, and prior to that spent a few years working on Linux kernel. + +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. While I do work within +a silicon company, one of my primary goals for helping guide Kata has been developing a neutral and +diverse contribution base. Aside from having a stable, compatible, and viable technical basis for the +project, I think a healthy and robust community is key to sustained success. + +For me, working with end-users to understand use cases and seeing how Kata can be part of their solution +is very exciting. I think this will be a big part of Kata as we continue to move forward. In addition, +continued focus on scaling, ecosystem integration, performance, security and stability will be key to meeting +user needs. I've also been focusing on making sure Kata fits into Kubernetes and the rest of the ecosystem, which +Has been evolving over time. There is a lot to focus on! + +The journey to Kata 1.2 has been great, and I look forward to continuing to contribute to the project. diff --git a/elections/arch-committee-2018-09/JonOlson.txt b/elections/arch-committee-2018-09/JonOlson.txt new file mode 100644 index 0000000000..708223e2dd --- /dev/null +++ b/elections/arch-committee-2018-09/JonOlson.txt @@ -0,0 +1,23 @@ +Name: Jon Olson + +Email: jonolson@google.com + +Background: + +I am a staff software engineer at Google working on the core virtualization and +I/O layer backing Google Compute Engine. My work is focused on resource +footprint minimization as well as performance optimization and stability. Part +of this work is improving our support for containerized workloads and ensuring +it is aligned with the needs of our customer community (e.g., Kata users). + +My involvement with the Kata community has included being a regular attendee at +the weekly Kata Arch Council meetings. To these meetings I’ve brought context +from my work building and maintaining a hypervisor that supports long-lived +workloads at scale, as well as the occasional PR for getting Kata running in +GCE. I believe whole workload containment via virtualization is a key component +to addressing the broad problem of container security. Having a strong, open +solution to that problem is critical to ensuring all workloads can run +securely, regardless of where they are deployed. + +I enjoy working with the Kata community to build such a solution, and look +forward to many more core-hours of security contained workloads. diff --git a/elections/arch-committee-2018-09/KalyXin.txt b/elections/arch-committee-2018-09/KalyXin.txt new file mode 100644 index 0000000000..989cfd746c --- /dev/null +++ b/elections/arch-committee-2018-09/KalyXin.txt @@ -0,0 +1,53 @@ +Kata-containers Architecture Committee Candidacy Declaration + +Platform: Arm + +Candidate: Kaly Xin + +I'm working for Arm Electronic Technology (Shanghai) Co.Ltd. +This candidacy is representing Arm company to be voted for one seat of the +Kata-container architecture committee. + +My current role is Senior Engineering Manager in the Open Source Software Group +and I lead a team working on virtualization and container technology on the Arm +platform. I have more than 10 years of experience in virtualization, especially +for hardware virtualization development including KVM and Xen. After that, I +transferred focus to OS virtualization and container development. + +In recent years, my team started development on RunV project, one of the +predecessors to Kata-containers, to enable and enhance the multi-arch support. +Our focus areas included KVMtool support, performance profiling of the network +and storage devices for virtual machines, and we also worked on stability and +density improvements. For example, we identified a networking performance gap +and improved throughput by 10x on both Arm and x86 platforms. Another example, +we proposed and modified the synchronization mechanism between the hyperstart +thread and VM. These and other contributions were all merged in RunV upstream. +Some of them are already in Kata-container project too. + +For these collaborations, there were public blogs announced at +https://blog.hyper.sh/arm_and_hyper.html and +https://community.arm.com/iot/b/blog/posts/arm-and-hyper-hq-will-push-runv-for-the-future-of-container-security. +We have met regularly with Hyper team to discuss the development issues and solutions +of the project. + +When RunV evolved into kata-containers, we transferred our effort into this +new joint project and contribute to it as ever. Initially, We found it couldn't +run successfully with multi-arch as before, lots of current test cases and CI +environment setting up are not for multi-arch in the first stage. We start to +fix the compatibility issues for different architectures. We are also working on the +public CI support for mutli-arch to ensure the ongoing reliability and stability +of the project. During the process, we feel this new joint project is very open, +friendly and full of vitality as before. That's so great to work in the community! + +Interests: + +We believe this is just the beginning for the Kata-containers project and that it +will have much broader applicability across different architectures and use +cases, especially within the emerging next-generation IoT and 5G era! These +different use cases will generate new design requirements of the underlying +architecture and we believe strongly that good multi-architecture support will +be essential to position Kata-containers for broad adoption throughout the cloud +native ecosystem. +We look forward to driving these changes together, so the Kata-containers project +can reach its full potential! + diff --git a/elections/arch-committee-2018-09/README.md b/elections/arch-committee-2018-09/README.md new file mode 100644 index 0000000000..0788770ba3 --- /dev/null +++ b/elections/arch-committee-2018-09/README.md @@ -0,0 +1,15 @@ +# Architecture Committee Elections: September 2018 + +There are three Architecture Committee seats up for election. The seats up for +election are currently filled by `Wei Zhang`, `Tim Allclair`, and `Jessie Frazelle`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* August 20, 1500 UTC - August 27, 2018 14:59 UTC: Candidate nominations open +* August 27, 1500 UTC - September 3, 2018 14:59 UTC: Q&A/Debate period +* September 3, 1500 UTC - September 10, 2018 14:59 UTC: Voting open +* Week of September 11, 2018, results announced + diff --git a/elections/arch-committee-2018-09/WeiZhang.txt b/elections/arch-committee-2018-09/WeiZhang.txt new file mode 100644 index 0000000000..7517101092 --- /dev/null +++ b/elections/arch-committee-2018-09/WeiZhang.txt @@ -0,0 +1,20 @@ +Name: Wei Zhang + +Email: zhangwei555@huawei.com + +Introduction: + +I am now working as a Senior Engineer in Huawei Corporation, +leading a team which is responsible for providing container solutions based on +K8s/docker/kata-containers to other departments and Huawei Public Cloud. + +I was once a docker developer and now is an active kata contributor, and has been +Architecture Committee Member for about eight months. Kata Containers is a great +project which can help reduce some security concerns comparing to native container +solution, and I don't think I need more words to elaborate how great it is because +I believe all the readers of this file are familiar enough to Kata. :-) + +So I wish to renew my seat, and do more work to help kata community +to make excellent open source project, and then make better product based on +Kata to our customers. + diff --git a/elections/arch-committee-2019-03/README.md b/elections/arch-committee-2019-03/README.md new file mode 100644 index 0000000000..53877845bf --- /dev/null +++ b/elections/arch-committee-2019-03/README.md @@ -0,0 +1,15 @@ +# Architecture Committee Elections: March 2019 + +There are two Architecture Committee seats up for election. The seats up for +election are currently filled by `Xu Wang` and `Samuel Ortiz`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* February 12, 1500 UTC - February 17, 2019 14:59 UTC: Candidate nominations open +* February 18, 1500 UTC - February 24, 2019 14:59 UTC: Q&A/Debate period +* February 25, 1500 UTC - March 3, 2019 14:59 UTC: Voting open +* Week of March 4, 2019, results announced + diff --git a/elections/arch-committee-2019-03/Results.md b/elections/arch-committee-2019-03/Results.md new file mode 100644 index 0000000000..1125f07b10 --- /dev/null +++ b/elections/arch-committee-2019-03/Results.md @@ -0,0 +1,11 @@ +# Architecture Committee Election Results: March 2019 + +Two nominations were received for the March 2019 elections: + +- [`Samuel Ortiz`](https://github.com/sameo) +- [`Xu Wang`](https://github.com/gnawux) + +As the number of applications matched the number of available seats, the +question and voting phases of the elections were bypassed, and the two +applicants were (re-)admitted to the Architecture Committee on 2019-02-19 +for another 12 month term. diff --git a/elections/arch-committee-2019-03/SamuelOrtiz.txt b/elections/arch-committee-2019-03/SamuelOrtiz.txt new file mode 100644 index 0000000000..52956c740e --- /dev/null +++ b/elections/arch-committee-2019-03/SamuelOrtiz.txt @@ -0,0 +1,28 @@ +Name: Samuel Ortiz + +Email: samuel.ortiz@intel.com + +Background: + +I am a software engineer at Intel where I work on different projects +related to virtualization and containers: rust-vmm, NEMU and Kata +Containers. I have been involved with Kata Containers for about 3 years +now, as I started to work on what used to be Clear Containers before the +2.0 release. I was part of the small OSF-Hyper-Intel team that worked +together to merge Clear Containers and runV into what today is Kata +Containers. + +I deeply believe that Kata Containers is a key project for the cloud +native ecosystem. Thanks to an ever growing community effort, we moved +it from two diverging code bases to something that can now be deployed +at scale. In order to reach that state we built a very versatile software +architecture that can adapt to a large number of use cases. On one hand +this architecture really put hardware virtualized container runtimes in +the cloud native map, but on the other hand it added complexity and in +some cases technical debt to our project. With new specifications and +APIs (runtimeClass, containerd shim v2) truly taking vm based runtimes +into account, I think it's time for us to work on simplifying and +cleaning our feature bloat and push that into Kata Containers v2. +This is what I'd like to focus on for the next few months and this is +one of the main reason why I'd like to renew my seat at the +Architecture Committee. diff --git a/elections/arch-committee-2019-03/XuWang.txt b/elections/arch-committee-2019-03/XuWang.txt new file mode 100644 index 0000000000..7c12a48c11 --- /dev/null +++ b/elections/arch-committee-2019-03/XuWang.txt @@ -0,0 +1,21 @@ +Name: Xu Wang + +Email: xu@hyper.sh + +Background: + +I am the CTO of hyper.sh, leading the Hyper team contributing to Kata Containers and related communities. +Before Kata, our team and I worked on runV, which is one of the predecessors of Kata Containers. It was +my great honor to involve the creating of the Kata Containers project and became a initial member of +the Architecture Committee together with Samual Ortiz. + +After having Kata Containers announced, more and more people began to consider the container security as +a solvable problem and several open source secure container runtime projects were released in the past +year. And Kata Containers is becoming the de facto standard: we have had better integration with containerd +via shimv2, and the better CRI-O integration is on its way; we have had more hypervisors support, such as +firecracker and NEMU. + +For me, I focused on kubernetes integration efficiency and boot-time related topics in the past months, and +had an eye on runtime benchmarks, multi-architecture support as well. In the future, I will pay more attention +to both the runtime development and the documentation to help users to adopt Kata Containers. + diff --git a/elections/arch-committee-2019-09/EricErnst.txt b/elections/arch-committee-2019-09/EricErnst.txt new file mode 100644 index 0000000000..a1fa243c53 --- /dev/null +++ b/elections/arch-committee-2019-09/EricErnst.txt @@ -0,0 +1,23 @@ +Name: Eric Ernst + +Email: eric.ernst@intel.com + +Background: + +I am a senior software engineer in Intel's Open Source Technology Center, acting both as a contributor +as well as a technical lead for the Intel-team contributing to Kata Containers. Before Kata, I spent time working +on Clear Containers, and prior to that spent a few years working on Linux kernel. + +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. While I do work within +a silicon company, one of my primary goals for helping guide Kata has been developing a neutral and +diverse contribution base. Aside from having a stable, compatible, and viable technical basis for the +project, I think a healthy and robust community is key to sustained success. + +Over the last year, I have served as a member of the Kata Containers architecture committee. The project has +matured a lot over the last year, with expanding production usage and user-base. Despite this, we still have a lot of room +for development, continuing to improve our density and security profile, all while providing improved manageability +and serviceability for users who are deploying Kata. Beyond this work, we will need to focus on attaining and addressing +input from end-users, as well as adapting to and influencing the cloud native ecosystem. + +In other words, we still have a lot of fun work to do! I look forward to continuing to contribute to the project. diff --git a/elections/arch-committee-2019-09/HaominTsai.txt b/elections/arch-committee-2019-09/HaominTsai.txt new file mode 100644 index 0000000000..985677ec51 --- /dev/null +++ b/elections/arch-committee-2019-09/HaominTsai.txt @@ -0,0 +1,39 @@ +Name: Haomin Tsai + +Email: caihaomin@huawei.com + +Introduction: + +I am now working as a Senior Engineer in Huawei Corporation, leading a technical team +to provide container solutions for other departments in our Corporation and Huawei Public Cloud. +We focus on docker/containerd/kata-containers/linux kernel and other infrastructure technology. +I am now working on Kunpeng Arch which based on arm64 extended. + +Before Kata, I was a docker/contaienrd developer and spent time working on operating system. +In the early days of Kata's establishment, I participated in it. After that my team and I wishes +to make a good product for more users. +Last year, our product Huawei Cloud Container Instance(aka CCI) which based on Kata has a rapid growth. +After this period of practice, we truely believe that Kata is really a good solution in production. +We extended the use of the scene based on Kata and enhanced the scene +including genetic calculation, AI calculation, CDN, big data and so on. + +Talking about community, a good community makes both developers and users comfortable. +And I think Kata is one of these communitiesm, beyond this Kata even is going to become +the cornerstone of cloud computing, not only in serverless/multi-tenant scene, + but also in more general scenes. + +Next I want to talk a little about future. If I can be honored to take one of the seats, +my goals are composed of two parts: +First part, I want to promote our production practice which will make users more comfortable. +Second part, our team are now working on Kunpeng Arch, +and I think we have a further work to do for Kata based on Kunpeng. + +I hope I can get this seat and make contribution to the community. + +^_^ + +BR~ +Haomin + + + diff --git a/elections/arch-committee-2019-09/JustinHe.txt b/elections/arch-committee-2019-09/JustinHe.txt new file mode 100644 index 0000000000..35165c4061 --- /dev/null +++ b/elections/arch-committee-2019-09/JustinHe.txt @@ -0,0 +1,51 @@ +Kata-containers Architecture Committee Candidacy Declaration + +Platform: Arm + +Candidate: Justin He + +I'm working for Arm Electronic Technology (Shanghai) Co.Ltd. +This candidacy is representing Arm company to be voted for one seat of the +Kata-container architecture committee. + +My current role is Staff Engineering in the Open Source Software Group and I +am working on virtualization and container technology on the Arm +platform. I have more than 10 years of experience in low level Linux software +development, especially for linux kernel [1], DPDK on arm64 [2] and hardware +virtualization development including KVM and qemu [3]. +[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Jia+he +[2] http://dpdk.org/browse/dpdk/log/?qt=author&q=Jia+He +[3] https://git.qemu.org/qemu.git/?p=qemu.git&a=search&h=HEAD&st=author&s=jia+he + +In recent years, our team started development on RunV project, one of the +predecessors to Kata-containers, to enable and enhance the multi-arch support. +Our focus areas included KVMtool support, performance profiling of the network +and storage devices for virtual machines, and we also worked on stability and +density improvements. For example, our team enabled the memory hotplug support, +vm template on Kata-containers project. As for virtio-fs support on arm64, we +fixed a lot issues on persistent memory and DAX support. + +For these collaborations, there were public blogs announced at [4] and [5] +[4] https://blog.hyper.sh/arm_and_hyper.html +[5] https://community.arm.com/iot/b/blog/posts/arm-and-hyper-hq-will-push-runv-for-the-future-of-container-security. +We have met regularly with Hyper team to discuss the development issues and +solutions of the project. + +For conference presentation, our team members once attended Denver 2019 summit +as speakers [4]: +https://www.openstack.org/videos/summits/denver-2019/kata-containers-on-arm-lets-talk-about-our-progress + +Interests: +We believe Kata-containers is a fast developping project and that it +will have much broader applicability across different architectures and use +cases, especially within the emerging next-generation IoT and 5G era! These +different use cases will generate new design requirements of the underlying +architecture and we believe strongly that good multi-architecture support will +be essential to position Kata-containers for broad adoption throughout the cloud +native ecosystem. + +We look forward to driving these changes together, so the Kata-containers project +can reach its full potential! + +Cheers, +Justin (Jia He) diff --git a/elections/arch-committee-2019-09/README.md b/elections/arch-committee-2019-09/README.md new file mode 100644 index 0000000000..6eaeb058e9 --- /dev/null +++ b/elections/arch-committee-2019-09/README.md @@ -0,0 +1,15 @@ +# Architecture Committee Elections: September 2019 + +There are three Architecture Committee seats up for election. The seats up for +election are currently filled by `Eric Ernst` @egernst, `Wei Zhang` @WeiZhang555 and `Jon Olson` @jon. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* September 3, 2019, elections officials confirmed: @raravena80 @lifupan @chavafg +* September 3, 1500 UTC - September 12, 2019 14:59 UTC: Candidate nominations open +* September, 12 1500 UTC - September 20, 2019 14:59 UTC: Q&A/Debate period +* September 20, 1500 UTC - September 27, 2019 14:59 UTC: Voting open +* Week of September 30, 2019, results announced diff --git a/elections/arch-committee-2019-09/Results.md b/elections/arch-committee-2019-09/Results.md new file mode 100644 index 0000000000..ac0594a48d --- /dev/null +++ b/elections/arch-committee-2019-09/Results.md @@ -0,0 +1,12 @@ +# Architecture Committee Election Results: September 2019 + +Three nominations were received for the March 2019 elections: + +- [`Eric Ernst`](https://github.com/sameo) +- [`Xaomin Tsai`](https://github.com/jshachm) +- [`Justin He`](https://github.com/justin-he) + +As the number of applications matched the number of available seats, the +question and voting phases of the elections were bypassed, and the two +applicants were admitted to the Architecture Committee on 2019-09-12 +for another 12 month term. diff --git a/elections/arch-committee-2020-02/DaveGilbert.txt b/elections/arch-committee-2020-02/DaveGilbert.txt new file mode 100644 index 0000000000..e16c5668e4 --- /dev/null +++ b/elections/arch-committee-2020-02/DaveGilbert.txt @@ -0,0 +1,27 @@ +Name: David Alan Gilbert + +Email: dgilbert@redhat.com + +Introduction: + +I'm a Principal Software Engineer working for Red Hat in our +virtualization team. I've been working on QEMU for the past +6 years, mostly in live migration but more recently working +on the virtiofs project. I'm a QEMU maintainer for live migration, +virtiofs and the HMP monitor. + +My previous work with Kata has mainly been in relation to +virtiofs and helping debug CI issues on Red Hat/CentOS and Fedora. + +My primary interest is ensuring that hypervisors (QEMU included) +provide the necessary features to enable Kata to operate securely +and efficiently. + +I'm keen to understand the real-world uses of Kata, how virtiofs is used +in practice and resolving any usage difficulties in those deployments. + +I look forward to promoting the wider usage of Kata and pushing its +usage in the general enterprise and more specialist areas such as +telecommunication systems. + +Dave (IRC: davidgiluk) diff --git a/elections/arch-committee-2020-02/README.md b/elections/arch-committee-2020-02/README.md new file mode 100644 index 0000000000..bf3baaa404 --- /dev/null +++ b/elections/arch-committee-2020-02/README.md @@ -0,0 +1,15 @@ +# Architecture Committee Elections: February 2020 + +There are two Architecture Committee seats up for election. The seats up for +election are currently filled by `Xu Wang` and `Samuel Ortiz`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* February 5, 1500 UTC - February 12, 2020 14:59 UTC: Candidate nominations open +* February 13, 1500 UTC - February 23, 2020 14:59 UTC: Q&A/Debate period +* February 24, 1500 UTC - March 1, 2020 14:59 UTC: Voting open +* Week of March 2, 2020, results announced + diff --git a/elections/arch-committee-2020-02/Results.md b/elections/arch-committee-2020-02/Results.md new file mode 100644 index 0000000000..e400bc1f97 --- /dev/null +++ b/elections/arch-committee-2020-02/Results.md @@ -0,0 +1,17 @@ +# Architecture Committee Election Results: February 2020 + +Three nominations were received for the February 2020 elections: + +- [`David Alan Gilbert`](https://github.com/dagrh) +- [`Samuel Ortiz`](https://github.com/sameo) +- [`Xu Wang`](https://github.com/gnawux) + +Two seats were available, so elections were held. + +The nominees elected to the positions were: + +- [`Samuel Ortiz`](https://github.com/sameo) +- [`Xu Wang`](https://github.com/gnawux) + +The two members were (re-)admitted to the Architecture Committee on 2020-03-02 +for another 12 month term. diff --git a/elections/arch-committee-2020-02/SamuelOrtiz.txt b/elections/arch-committee-2020-02/SamuelOrtiz.txt new file mode 100644 index 0000000000..c89e1cca3d --- /dev/null +++ b/elections/arch-committee-2020-02/SamuelOrtiz.txt @@ -0,0 +1,29 @@ +Name: Samuel Ortiz + +Email: sameo@linux.intel.com + +Background: + +I am a Principal Software Engineer working for Intel, where I work on several +projects related to virtualization and containers: Kata Containers, rust-vmm +and Cloud Hypervisor. + +My journey with the Kata Containers project started back when I initially lead +the Clear Containers project at Intel, a few years ago. Since then I have +contributed to many different areas of the project, from core components like +the virtcontainers package to integration work with the CRI-O and containerd +projects. I was part of the initial Clear Container and RunV engineering +efforts to merge the two projects and have been on the Kata Containers +Architecture Committee since then. + +Over the past few months we've seen Kata Containers being deployed in several +very large production environments, showing how strong and scalable the +project has become. Such large deployments also bring new requirements for +security, density and performance that we, as a community, need to look at +and meet. I believe this can only be achieved with Kata supporting new security +models and virtualization technologies, losing a few abstraction layers and +features, and being more tightly integrated with the Cloud Native ecosystem. +This is what I want to help push through Kata Containers 2.0, and this is why +I'd like to renew my seat on the Kata Architecture Committee. + +Samuel. diff --git a/elections/arch-committee-2020-02/XuWang.txt b/elections/arch-committee-2020-02/XuWang.txt new file mode 100644 index 0000000000..94bc596fc3 --- /dev/null +++ b/elections/arch-committee-2020-02/XuWang.txt @@ -0,0 +1,19 @@ +Name: Xu Wang + +Email: xu@hyper.sh, gnawux@antfin.com + +Background: + +I am a senior staff engineer of Ant Financial, a related company of Alibaba Group (BABA). I am leading +the secure container development team in Ant Financial currently and working for the Cloud-Native +open-source of Alibaba as a member of the Ali Open Source TOC. Our team has been working on not only +contributing upstream, but also deploying Kata Containers in the productions since we joined Ant Financial. + +Before joining Ant Financial, Our team, the hyper.sh, had been keep contributing to Kata Containers +and related communities since the day 0 of Kata. It was my great honor to involve the creating of the +Kata Containers project and became a initial member of the Architecture Committee together with Samual Ortiz. + +In the past months, we celebrated the two year anniversary of Kata. Look back at the past two years, we have +improved the isolation in the container world at the expense of some overhead. We believe the container world +needs a better isolation solution without hurts on the application-centric nature of Cloud-Native. In 2020, +I expect we could developing the virtualization technologies for Cloud Native in the 2.0 development cycle. diff --git a/elections/arch-committee-2020-09/ArchanaShinde.txt b/elections/arch-committee-2020-09/ArchanaShinde.txt new file mode 100644 index 0000000000..ea05f30e0a --- /dev/null +++ b/elections/arch-committee-2020-09/ArchanaShinde.txt @@ -0,0 +1,14 @@ +Name: Archana Shinde + +Email: archana.m.shinde@intel.com + +Background: + +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. + +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. + +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. +I look forward to working on Kata's continuing success! + +-Archana Shinde diff --git a/elections/arch-committee-2020-09/EricErnst.txt b/elections/arch-committee-2020-09/EricErnst.txt new file mode 100644 index 0000000000..c5999ac529 --- /dev/null +++ b/elections/arch-committee-2020-09/EricErnst.txt @@ -0,0 +1,19 @@ +Name: Eric Ernst + +Email: eric.ernst@apple.com + +Background: + +I am a senior software engineer at Apple, focused on cloud infrastructure, and despite a couple of exciting employer changes this year, +I continue to be very interested in this project, and engaged in the Kata community as a contributor. + +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 focused on making sure Kata continues to be a production-ready solution for providing stronger container isolation. + +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 +matured a lot, with expanding production usage and user-base. Even more so now, we have a lot of important changes this year: +Cloud Hypervisor VMM support, PodOverhead support in Kubernetes, cgroups-v2 support, cpuset support, rust-agent support, improved telemetry/observability, +virtio-fs support. Each of these are important improvements that make the project more attractive and viable for production use cases. + +We still have a lot of interesting work to do, and I look forward to continuing to contribute to the project. diff --git a/elections/arch-committee-2020-09/FabianoFidencio.txt b/elections/arch-committee-2020-09/FabianoFidencio.txt new file mode 100644 index 0000000000..f2edc89c0f --- /dev/null +++ b/elections/arch-committee-2020-09/FabianoFidencio.txt @@ -0,0 +1,51 @@ +Name: Fabiano Fidêncio +  +Email: fabiano@fidencio.org +  +Background: +  +I am a Senior Software Engineer working for Red Hat's virtualization team, a +tattoo canvas for abstract art, a music addict, and a big fan of old video +games. +  +In the past 6 months I have been dedicating a big chunk of my time contributing +and helping to make the Kata Containers project solid across different +communities, such as Fedora, CentOS, and CRI-O, supporting Kata Containers +exposure and adoption in the enterprise Linux world. + +My involvement with Kata Containers has been quite intense in this period, +from providing simple patches, doing code reviews on pretty much all +components, fixing issues not only on Kata Containers but also in the +communities surrounding the project, to becoming a point of contact for Fedora, +CentOS, and RHEL related issues, always focusing on what could benefit the +project and its community. + +To keep improving Kata Containers adoption, I recently became the CRI-O +maintainer for the VM runtime type (used together with the "shim v2") and I am +and will be enforcing Kata Containers play well also with one of the most +widely used container runtimes in the Kubernetes ecosystem. + +My primary interest is to ensure that Kata Containers can be used in enterprise +Linux solutions, which can be achieved by improving stability, debuggability, +and out-of-the-box usage, everything done as a symbiotic process with an +organic growth. Enforcing this growth will fundamentally benefit this community +and the communities around this one. + +In order to make it possible, I plan to continue working in the integration +bits, while keeping connecting and facilitating the communication between the +Kata Containers community and the communities that both Red Hat and I are part +of. + +The contributions I have participated in and I am the most proud to mention +are: + +* Out-of-the-box virtio-fs support on Fedora, and CentOS; +* Helping with the SELinux support on Kata Containers, CRI-O, and + container-selinux projects; +* Helping to educate & to onboard colleagues to the project, assisting them so + they can get up to speed to start contributing with different pieces and also + to become part of this community; +* Helping to lower the maintenance burden by dropping OBS package builds in + favor of kata-deploy usage (still in progress). + +Fabiano Fidêncio (IRC / Slack: fidencio) diff --git a/elections/arch-committee-2020-09/JustinHe.txt b/elections/arch-committee-2020-09/JustinHe.txt new file mode 100644 index 0000000000..f61eb86a4f --- /dev/null +++ b/elections/arch-committee-2020-09/JustinHe.txt @@ -0,0 +1,38 @@ +Kata-containers Architecture Committee Candidacy Declaration + +Platform: Arm + +Candidate: Justin He + +I'm working for Arm Electronic Technology (Shanghai) Co.Ltd. +This candidacy is representing Arm company to be voted for one seat of the +Kata-container architecture committee. + +My current role is Principal Engineering in the Open Source Software Group and I +am working on virtualization and container technology on the Arm platform. I +have more than 10 years of experience in low level Linux software development, +especially for linux kernel and hardware virtualization development including +KVM and qemu. + +In recent years, our team started development on: + - Enablement the Kata runtime for arm64 + - CI maintenance for Kata arm64 + - firecracker arm64 support + - Cloud hypervisor arm64 enablement + - Kubernetes integration test on arm64 + - Optimize the performance of Kata runtime/agent/vmm/kernel + +We believe Kata-containers is a fast developping project and that it will have +much broader applicability across different architectures and use cases, +especially within the emerging next-generation IoT and 5G era! These +different use cases will generate new design requirements of the underlying +architecture and we believe strongly that good multi-architecture support will +be essential to position Kata-containers for broad adoption throughout the cloud +native ecosystem. We still have strong interests in the future of Kata project +and will keep enabling and tuning Kata in many aspects. + +We look forward to driving these changes together, so the Kata-containers project +can reach its full potential! + +Cheers, +Justin (Jia He) diff --git a/elections/arch-committee-2020-09/README.md b/elections/arch-committee-2020-09/README.md new file mode 100644 index 0000000000..3f57b2aeb0 --- /dev/null +++ b/elections/arch-committee-2020-09/README.md @@ -0,0 +1,15 @@ +# Architecture Committee Elections: September 2020 + +There are three Architecture Committee seats up for election. The seats up for +election are currently filled by `Eric Ernst`, `Xaomin Tsai` and `Justin He`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* September 8 - Election officials confirmed: @Ricardo and @Fupan +* September 9, 1500 UTC - September 17, 2020 14:59 UTC: Candidate nominations open +* September 18, 1500 UTC - September 27, 2020 14:59 UTC: Q&A/Debate period +* September 28, 1500 UTC - October 4, 2020 14:59 UTC: Voting open +* October 5:results announced diff --git a/elections/arch-committee-2020-09/Results.md b/elections/arch-committee-2020-09/Results.md new file mode 100644 index 0000000000..40c4c3bea5 --- /dev/null +++ b/elections/arch-committee-2020-09/Results.md @@ -0,0 +1,19 @@ +# Architecture Committee Election Results: September 2020 + +Four nominations were received for the September 2020 elections: + +- [`Archana Shinde`](https://github.com/amshinde) +- [`Eric Ernst`](https://github.com/egernst) +- [`Fabiano Fidêncio`](https://github.com/fidencio) +- [`Justin He`](https://github.com/justin-he) + +Three seats were available, so elections were held. + +The nominees elected to the positions were: + +- [`Archana Shinde`](https://github.com/amshinde) +- [`Eric Ernst`](https://github.com/egernst) +- [`Fabiano Fidêncio`](https://github.com/fidencio) + +Congratulations to our new architecture committee members Fabiano and Archana and our continuing member Eric! + diff --git a/elections/arch-committee-2021-02/PengTao.txt b/elections/arch-committee-2021-02/PengTao.txt new file mode 100644 index 0000000000..3b0f5dd2ce --- /dev/null +++ b/elections/arch-committee-2021-02/PengTao.txt @@ -0,0 +1,21 @@ +Name: Peng, Tao + +Email: bergwolf@hyper.sh, bergwolf@antgroup.com + +Background: + +Peng Tao is a staff engineer of Ant Group. In Ant Group, we have large deployments of Kubernetes +and about 10K nodes of them are running Kata containers. Our team is responsible for the runtime +and cloud-native storage of Ant Group. + +Peng Tao, toegther with Xu and other teammates, used to be the dev team of hyper.sh. The team was +one of the creators of Kata Containers, and has kept working on Kata Containers since joining +Ant Group. When the Kata Containers project was created, Peng Tao committed the first commit for it: + +https://github.com/kata-containers/proxy/commit/94a07ff010b80fad8235278032d0b58927d4f1d5 + +And he was known as the release manager of the Kata 2.0 as well. + +In 2021, Ant Group has joined the Open Infrastructure and become a member of the board of directors. +We commit our team will keep working with the Kata Community for the following release cycles. + diff --git a/elections/arch-committee-2021-02/README.md b/elections/arch-committee-2021-02/README.md new file mode 100644 index 0000000000..00d4eca040 --- /dev/null +++ b/elections/arch-committee-2021-02/README.md @@ -0,0 +1,14 @@ +# Architecture Committee Elections: February 2021 + +There are two Architecture Committee seats up for election. The seats up for +election are currently filled by `Xu Wang` and `Samuel Ortiz`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* February 24, 15:00 UTC - March 10, 2021 14:59 UTC: Candidate nominations open +* March 11, 15:00 UTC - March 22, 2021 14:59 UTC: Q&A/Debate period +* March 23, 15:00 UTC - March 29, 2021 14:59 UTC: Voting open +* March 30, 2021, results announced diff --git a/elections/arch-committee-2021-02/Results.md b/elections/arch-committee-2021-02/Results.md new file mode 100644 index 0000000000..694f7f32da --- /dev/null +++ b/elections/arch-committee-2021-02/Results.md @@ -0,0 +1,11 @@ +# Architecture Committee Election Results: February 2021 + +Two nominations were received for the February 2021 elections: + +- [`Peng Tao`](https://github.com/bergwolf) +- [`Samuel Ortiz`](https://github.com/sameo) + +Two seats were available, so elections were over sooner. + +The two members were (re-)admitted to the Architecture Committee on 2021-03-10 +for another 12 month term. diff --git a/elections/arch-committee-2021-02/SamuelOrtiz.txt b/elections/arch-committee-2021-02/SamuelOrtiz.txt new file mode 100644 index 0000000000..8df1179418 --- /dev/null +++ b/elections/arch-committee-2021-02/SamuelOrtiz.txt @@ -0,0 +1,24 @@ +Name: Samuel Ortiz + +Email: sameo@linux.intel.com + +Background: + +I am a Principal Software Engineer working for Intel, where I work on several +projects related to virtualization and containers: Kata Containers, rust-vmm +and Cloud Hypervisor. + +I started to work on Kata Containers a few years ago, back when I initially led +the Clear Containers project at Intel. Since then I have contributed to many +different areas of the project, from core components like the virtcontainers +package to integration work with the CRI-O and containerd projects. + +Together with the folks from hyper.sh, we began the Kata Containers journey +with the ambitious goal of providing stronger isolation to cloud native +workloads, with minimal overhead. Three years ago, this was a fairly innovative +approach and at some point I stopped counting the number of hours that Xu, Eric, +Peng or myself spent at conferences, meetups or foundation booths demonstrating +how Kata Containers met that promise. I believe it is now time to bring the next +generation of hardware isolation and confidentiality technologies to the cloud +native ecosystem, and in the upcoming months I'd like to help the Kata +Containers project reach that goal. diff --git a/elections/arch-committee-2021-09/ArchanaShinde.txt b/elections/arch-committee-2021-09/ArchanaShinde.txt new file mode 100644 index 0000000000..b2155b4cd3 --- /dev/null +++ b/elections/arch-committee-2021-09/ArchanaShinde.txt @@ -0,0 +1,15 @@ +Name: Archana Shinde + +Email: archana.m.shinde at intel.com + +Background: + +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. + +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. + +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. + +I look forward to continuing to contribute to the success of Kata Containers! + +-Archana Shinde diff --git a/elections/arch-committee-2021-09/EricErnst.txt b/elections/arch-committee-2021-09/EricErnst.txt new file mode 100644 index 0000000000..ca54412a93 --- /dev/null +++ b/elections/arch-committee-2021-09/EricErnst.txt @@ -0,0 +1,21 @@ +--- +Name: Eric Ernst +Email: eric_ernst at apple dot com + +Background: + +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. + +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. + +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. + +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. + +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. + +We still have a lot of interesting work to do, and I look forward to continuing to contribute to the success of Kata Containers! + +--Eric + diff --git a/elections/arch-committee-2021-09/FabianoFidencio.txt b/elections/arch-committee-2021-09/FabianoFidencio.txt new file mode 100644 index 0000000000..bd2e8a2fe5 --- /dev/null +++ b/elections/arch-committee-2021-09/FabianoFidencio.txt @@ -0,0 +1,44 @@ +Name: Fabiano Fidêncio + +Email: fabiano@fidencio.org + +Background: + +I am a Software Engineer, a tattoo canvas for abstract art, a music addict, a +goats and pigs instagram follower, and a big fan of old video games. + +In the past 18 months I dedicated a huge chunk of my professional and personal +time contributing to the Kata Containers project and community, with a strong +focus on helping Red Hat to build a product from the Kata Containers project. + +My involvement with Kata Containers has been intense. I've been involved on +pretty much every part of the project, on projects Kata Containers interacts +with. Moreover, I've already been serving the community as a current member of +the Kata Containers Architecture Committee. + +In the enterprise world, I have worked on making the upstream project a Red +Hat's downstream product, passing by Fedora, CentOS, Red Hat CoreOS, and +OpenShift components. As a result of this effort Red Hat now has an official +product which uses Kata Containers underneath. + +In the community space, I also have helped on a lot of different parts of the +project. connected people to have their problems solved, mentored both +newcomers and students into our community, led Architecture Committee meetings, +led the last vPTG's Kata Containers session. I also went hands-on on CI, +code-reviewing, development focusing on easing the adoption of the project, +managed the past and current releases, and have been working as much as +possible to grow this community in a healthy way. + +My main motivations are still to increase Kata Containers adoption in the +industry, while ensuring the project is stable and easily consumable. This is +more important now than ever as new players are adopting and contributing to +the Kata Containers project. + +To make it possible, I plan to continue working in the integration bits, while +connecting and facilitating the communication between the Kata Containers +community and the communities that I am part of. + +On a side note, I'd like to mention that from November 1st, 2021, I'll be +working for Intel, focusing on the Kata Containers project. + +Fabiano Fidêncio (IRC / Slack: fidencio) diff --git a/elections/arch-committee-2021-09/README.md b/elections/arch-committee-2021-09/README.md new file mode 100644 index 0000000000..e6be88eec5 --- /dev/null +++ b/elections/arch-committee-2021-09/README.md @@ -0,0 +1,18 @@ +# Architecture Committee Elections: September 2021 + +There are two Architecture Committee seats up for election. The seats up for +election are currently filled by `Archana Shinde`, `Eric Ernst`, and `Fabiano Fidêncio` + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) for election process, declaring candidacy, and eligible voters. + +Election Dates: + +Candidacy open: September 8-16 +"Debate period": September 17-27 +Voting: September 28 - October 3 +Results: October 4 + +* September 8, 15:00 UTC - September 16, 2021 14:59 UTC: Candidate nominations open +* September 17, 15:00 UTC - September 27, 2021 14:59 UTC: Q&A/Debate period +* September 28, 15:00 UTC - October 3, 2021 14:59 UTC: Voting open +* October 4, 2021, results announced diff --git a/elections/arch-committee-2021-09/Results.md b/elections/arch-committee-2021-09/Results.md new file mode 100644 index 0000000000..74d658a375 --- /dev/null +++ b/elections/arch-committee-2021-09/Results.md @@ -0,0 +1,11 @@ +# Architecture Committee Election Results: September 2021 + +Three (3) nominations were received for the September 2021 elections: + +- [`Archana Shinde`](https://github.com/amshinde) +- [`Eric Ernst`](https://github.com/egernst) +- [`Fabiano Fidêncio`](https://github.com/fidencio) + +Three (3) seats were available, so elections were over sooner. + +The three members were re-admitted to the Architecture Committee on 2021-09-16 for another 12 month term. diff --git a/elections/arch-committee-2022-03/README.md b/elections/arch-committee-2022-03/README.md new file mode 100644 index 0000000000..0cf1732fd4 --- /dev/null +++ b/elections/arch-committee-2022-03/README.md @@ -0,0 +1,14 @@ +# Architecture Committee Elections: March 2022 + +There are two Architecture Committee seats up for election. The seats up for +election are currently filled by `Peng Tao` and `Samuel Ortiz`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/master/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* March 08, 15:00 UTC - March 15, 2022 14:59 UTC: Candidate nominations open +* March 16, 15:00 UTC - March 23, 2022 14:59 UTC: Q&A/Debate period +* March 24, 15:00 UTC - March 31, 2022 14:59 UTC: Voting open +* April 01, 2022, results announced diff --git a/elections/arch-committee-2022-03/Results.md b/elections/arch-committee-2022-03/Results.md new file mode 100644 index 0000000000..c883f82b8e --- /dev/null +++ b/elections/arch-committee-2022-03/Results.md @@ -0,0 +1,11 @@ +# Architecture Committee Election Results: March 2022 + +Two nominations were received for the March 2022 elections: + +- [`Peng Tao`](https://github.com/bergwolf) +- [`Samuel Ortiz`](https://github.com/sameo) + +Two seats were available, so elections were over sooner. + +The two members were (re-)admitted to the Architecture Committee on 2021-03-16 +for another 12 month term. diff --git a/elections/arch-committee-2022-03/SamuelOrtiz.txt b/elections/arch-committee-2022-03/SamuelOrtiz.txt new file mode 100644 index 0000000000..f319c1189d --- /dev/null +++ b/elections/arch-committee-2022-03/SamuelOrtiz.txt @@ -0,0 +1,49 @@ +Name: Samuel Ortiz + +Email: samuel.e.ortiz@protonmail.com + +Background: + +I am a software engineer at Apple, where I work on container and virtualization +related projects. + +More than 4 years ago, I attended the foundational meeting between us (I was +working at Intel back then), Hyper and the OpenStack Foundation. We merged +Clear Containers and Hyper Runv into what became Kata Containers a few months +later. Even though I've been working on and contributing to many other open +souce projects since then, the excitement I feel about Kata Containers, its +community and its innovation potential, is intact. Running `uname -a` on a +Kata Containers never gets old to me. Especially when the host operating +system is not Linux ;-) + +Over the past year, I dedicated some of my time on a new cloud capability: +Confidential Computing. This is a very disruptive technology, that redefines +and expands the cloud threat model, and I truly believe that Kata Containers +has the potential to become a foundational Confidential Computing software +component. I think that Confidential Computing will eventually become the +default security setting for cloud native applications, and in my mind that +can only happen with the Kata Containers runtime. This is what I want to help +this community achieve over the next couple of years. + +Another recent personal source of excitement for me is the ability to run +Linux containers on top of non Linux host operating systems, like Darwin for +example. This does not come easy, as we have spent all those years assuming +we will always be walking on top of a cozy Linux kernel. In the upcoming +months, I want to break that assumption and use the Darwin enablement as a +forcing function to clean our code base through saner, OS-agnostic +abstractions. + +Finally, I want to confess something: I love writing Rust code. It's not easy +to admit, especially after initially cursing so much at the borrow checker. +But I listened to it and learned, and my appreciation for the language and +its unique features steadily grew to eventually become a favorite of mine. +That's why I'm very excited about us writing a new Rust runtime, taking this +rewrite as an opportunity to build a more integrated and efficient +architecture. I want to make sure that we learn from both our mistakes and +our victories, to build a new code base that synthesizes those learnings. +And at the same time, knowing how steep the Rust learning curve can be, I +also want to keep this new implementation accessible to our community and +contributors. + +Cheers, +Samuel diff --git a/elections/arch-committee-2022-03/TaoPeng.txt b/elections/arch-committee-2022-03/TaoPeng.txt new file mode 100644 index 0000000000..bd7b1b12d2 --- /dev/null +++ b/elections/arch-committee-2022-03/TaoPeng.txt @@ -0,0 +1,47 @@ +Name: Tao Peng + +Email: bergwolf@hyper.sh, bergwolf@antgroup.com + +Background: + +I am a staff engineer at Ant Group. My primary focus is container +infrastructure related technologies. + +I have been deeply engaged in Kata Containers since the start of the project, +both in development and community. I continue to be very interested in the +project and want to be part of the efforts to ensure its success. I have +served as a member of the Kata architecture committee. And I'm running again in +the new round of the architecture committee election. + +I have been an active contributor in the past in many different areas across the +runtime and the agent. I served as a member of the vulnerability management team, +the review team and the release management team. I also advocated the project in +various open source events, conferences and meetups. + +Within Ant Group, our team is responsible for the large scale Kata Containers +deployment in production. We have been pioneers in new features and new architectures +of Kata. We believe it is very important to bridge production requirements and +upstream development. We have been actively engaged in the upstream development +in the past, and will continue to do so in the future. + +Since its foundation, Kata Containers has matured quite a bit with an expanding +user-base. There are still a lot of exciting things to do. + +One area is better integration in the container ecosystem. It has been a goal of the +project since the very beginning. And the current focus is the improved integration +with CNI/CSI/CRI. We expect to have a more VM-friendly interfaces that will help to +improve our performance and efficiency. + +Another exciting thing is the integrated rust runtime. It continues to innovate +with cloud-native virtualization in mind and makes all Kata components work +tightly together, further reduce Kata's resource overhead and management complexity. + +Last but not least, the Confidential Containers support expands the Kata Containers +threat model from protecting the infrastructure to also protecting the workloads. +It is a very appealing direction and attracts a lot of community interests. + +Kata Containers 3.0 release is paving its way to be a real thing. These features +will certainly be important part of Kata 3.0. I look forward to continuing to +contribute and help the project thrive. + +-Tao diff --git a/elections/arch-committee-2022-11/ArchanaShinde.txt b/elections/arch-committee-2022-11/ArchanaShinde.txt new file mode 100644 index 0000000000..0a8ff2118b --- /dev/null +++ b/elections/arch-committee-2022-11/ArchanaShinde.txt @@ -0,0 +1,16 @@ +Name: Archana Shinde +Email: archana.m.shinde@intel.com + +Background: + +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. + +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. + +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. +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. + +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. + +Thanks, +Archana Shinde diff --git a/elections/arch-committee-2022-11/EricErnst.txt b/elections/arch-committee-2022-11/EricErnst.txt new file mode 100644 index 0000000000..50f7327a4d --- /dev/null +++ b/elections/arch-committee-2022-11/EricErnst.txt @@ -0,0 +1,16 @@ +--- +Name: Eric Ernst +Email: eric_ernst at apple dot com + +Background: + +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. + +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. + +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. + +We still have a lot of interesting work to do, and I look forward to continuing to contribute to the success of Kata Containers! + +--Eric + diff --git a/elections/arch-committee-2022-11/FabianoFidencio.txt b/elections/arch-committee-2022-11/FabianoFidencio.txt new file mode 100644 index 0000000000..b408d7368a --- /dev/null +++ b/elections/arch-committee-2022-11/FabianoFidencio.txt @@ -0,0 +1,47 @@ +Name: Fabiano Fidêncio + +Email: fabiano@fidencio.org + +Background: + +I am a Software Engineer, a tattoo canvas for abstract art, a music addict, a +goats and pigs instagram follower, and a big fan of old video games. + +In the past 30 months I dedicated a huge chunk of my professional and personal +time contributing to the Kata Containers project and community, with a strong +focus on trying to keep the community as healthy as possible, while recently +also focusing on efforts in the Confidential Containers space. + +My involvement with Kata Containers has been intense, to say the least. I've +been involved on pretty much every part of the project, and also on projects +Kata Containers interacts with.  Moreover, I've already been serving the +community as a current member of the Kata Containers Architecture Committee. + +In the enterprise world, while working for Intel, I've worked mostly on +leveraging Intel's usage of Kata Containers, and also bringing Intel +technologies to the project, such as the TDX support and integration work for +Confidential Containers.  While I was still working for Red Hat,I worked on +making the upstream project a Red Hat's downstream product, passing by Fedora, +CentOS, Red Hat CoreOS, and OpenShift components, which led to the OpenShift +Sandboxed Containers product, which uses Kata Containers underneath. + +In the community space, I also have helped on a lot of different parts of the +project. connected people to have their problems solved, mentored both +newcomers and students into our community, been leading Architecture Committee +meetings, helped organise Kata Containers vPTG sessions, presented the project +at conferences, worked together with OIF on getting Study Cases published, and +helped increase the number of members in our community.  I also am hands-on on +CI, code-reviewing, development focusing on easing the adoption of the project. +I've managed a whole bunch of releases, and have been working as much as +possible to grow this community in a healthy way. + +My main motivations are still to increase Kata Containers adoption in the +industry, while ensuring the project is stable and easily consumable.  This is +more important now than ever as new players are adopting and contributing to +the Kata Containers project, and we're transitioning to the runtime-rs. + +To make it possible, I plan to continue working in the integration bits, while +connecting and facilitating the communication between the Kata Containers +community and the communities that I am part of. + +Fabiano Fidêncio (Slack: fidencio) diff --git a/elections/arch-committee-2022-11/FengWang.txt b/elections/arch-committee-2022-11/FengWang.txt new file mode 100644 index 0000000000..2960a44522 --- /dev/null +++ b/elections/arch-committee-2022-11/FengWang.txt @@ -0,0 +1,14 @@ +Name: Feng Wang + +Email: feng.wang@databricks.com + +Background: + + +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. + + +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. + + +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. diff --git a/elections/arch-committee-2022-11/FupanLi.txt b/elections/arch-committee-2022-11/FupanLi.txt new file mode 100644 index 0000000000..22553e4488 --- /dev/null +++ b/elections/arch-committee-2022-11/FupanLi.txt @@ -0,0 +1,19 @@ +Name: Fupan Li + +Email: lifupan@gmail.com + +Background: + +I’m one of the Kata Containers communities maintainer and active contributor since 2018, +during the past few years, I developed the Kata Containers shimv2, which promoted Kata +Containers from multi process model into only two process(shimv2 and vmm) model, at the +same time, it made Kata Containers much more populated and adoptable in the k8s community. +In addition, I’m the author of the rust version of the kata-agent, which bring Kata Containers +from 1.0 to 2.0. Last but not lease, I’m the architecture and key developer of the rust version’s +kata runtime, which had been opened and contributed to runtime-rs. + +In addition to that, I worked in Ant Group , which maintained the largest Kata Containers cluster, +as an senior engineer, I’m responsible for the implementation and development of the kata container +inside Ant, and I am confident that based on my development and land experience on the Ant Group, +as well as the maintenance work of the community, I’d try my best to contribute much more to the +Kata community. diff --git a/elections/arch-committee-2022-11/GerryLiu.txt b/elections/arch-committee-2022-11/GerryLiu.txt new file mode 100644 index 0000000000..3c5fdc8fc2 --- /dev/null +++ b/elections/arch-committee-2022-11/GerryLiu.txt @@ -0,0 +1,20 @@ +Name: Gerry Liu +Email: gerry at linux dot alibaba dot com + +Background +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. + +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: +1) introduced/contributed runtime-rs/Dragonball to Kata 3.0 +2) enhanced td-shim and image-rs to support confidential containers +3) helped to integrate Nydus with Kata +4) put Kata into production with large deploy base + +In the coming year, I plan to cooperate with the community to work on following topics: +1) make runtime-rs/Dragonball as the default option +2) enhance Dragonball to support confidential containers +3) enhance Dragonball to better support GPUs, other accelerators and DPUs. +4) share more code base between Dragonball and Cloud Hypervisor + +And most importantly I will help to integrate Kata Containers into OpenAnolis Linux distribution and enlarge the user base:) + diff --git a/elections/arch-committee-2022-11/README.md b/elections/arch-committee-2022-11/README.md new file mode 100644 index 0000000000..39b118f86d --- /dev/null +++ b/elections/arch-committee-2022-11/README.md @@ -0,0 +1,14 @@ +# Architecture Committee Elections: Nov 2022 + +There are three Architecture Committee seats up for election. The seats up for +election are currently filled by `Archana Shinde`, `Eric Ernst` and `Fabiano Fidêncio`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* November 04, 15:00 UTC - November 11, 2022 14:59 UTC: Candidate nominations open +* November 12, 15:00 UTC - November 21, 2022 14:59 UTC: Q&A/Debate period +* November 22, 15:00 UTC - November 29, 2022 14:59 UTC: Voting open +* November 30th, 2022, results announced diff --git a/elections/arch-committee-2022-11/Results.md b/elections/arch-committee-2022-11/Results.md new file mode 100644 index 0000000000..84deff2255 --- /dev/null +++ b/elections/arch-committee-2022-11/Results.md @@ -0,0 +1,20 @@ +# Architecture Committee Election Results: Nov 2022 + +Six nominations were received for the November 2022 elections: + +- [`Archana Shinde`](https://github.com/amshinde) +- [`Eric Ernst`](https://github.com/egernst) +- [`Fabiano Fidêncio`](https://github.com/fidencio) +- [`Feng Wang`](https://github.com/fengwang666) +- [`Fupan Li`](https://github.com/lifupan) +- [`Gerry Liu`](https://github.com/jiangliu) + +Three seats were available, so elections were held. + +The nominees elected to the positions were: + +- [`Eric Ernst`](https://github.com/egernst) +- [`Fabiano Fidêncio`](https://github.com/fidencio) +- [`Gerry Liu`](https://github.com/jiangliu) + +Congratulations to our new architecture committee members `Gerry` and our continuing member `Eric` and `Fabiano`! diff --git a/elections/arch-committee-2023-04/ArchanaShinde.txt b/elections/arch-committee-2023-04/ArchanaShinde.txt new file mode 100644 index 0000000000..94763dc510 --- /dev/null +++ b/elections/arch-committee-2023-04/ArchanaShinde.txt @@ -0,0 +1,11 @@ +Name: Archana Shinde +Email: archana.m.shinde@intel.com +Background: +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. +I have served on the Kata Containers Architecture committee in the past and would like to announce my candidacy for the upcoming elections. +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. +Intel has been a key contributor to the project. We at Intel continue to focus on Kata Containers along with Confidential Containers. +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. +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. +Thanks, +Archana Shinde diff --git a/elections/arch-committee-2023-04/FengWang.txt b/elections/arch-committee-2023-04/FengWang.txt new file mode 100644 index 0000000000..0a1d5443f0 --- /dev/null +++ b/elections/arch-committee-2023-04/FengWang.txt @@ -0,0 +1,26 @@ +Name: Feng Wang + +Email: fwang@confluent.io + +Background: + +I’m a software engineer at Confluent, where I work at the compute platform team. +I became involved in the Kata Containers project since August 2021 and have been +an active contributor and community member since then. + +Over the past two years, I have contributed extensively to the Kata Containers +project, including enabling non-root VMM support, support direct-volume mount, +and fixed a number of critical bugs. Through these contributions, I have +developed a deep understanding of the project and have gained valuable experience +working with the Kata Containers community. + +My main motivation is to improve the production adoption of the project by making +it more stable, performant, production mature and accessible. Kata Containers as +the leading sandboxed container runtime has its unique position in the cloud +native world. However, based on my last two years of experience working at two +different companies trying to adopt Kata Containers in production, there still +remain many challenges for companies to adopt Kata Containers in production, +especially for small size companies. Thanks to its compatability with runtime shim +interface, onboarding a workload to Kata Containers is relatively simple, but the +effort to operate it in production is nontrivial. As a community, we can focus more +on improving the production quality, ease of operation, and community support. diff --git a/elections/arch-committee-2023-04/JeremiPiotrowski.txt b/elections/arch-committee-2023-04/JeremiPiotrowski.txt new file mode 100644 index 0000000000..c7a8dba567 --- /dev/null +++ b/elections/arch-committee-2023-04/JeremiPiotrowski.txt @@ -0,0 +1,36 @@ +Name: Jeremi Piotrowski + +Email: jpiotrowski@microsoft.com, jpiotrowski@linux.microsoft.com + +Background: + +I'm a software engineer at Microsoft, where I work within Azure. My primary +focus has been contributing to open source projects within the Cloud Native +space, but I do not draw the line there and try to improve any and every part +of the stack involved in running containers. + +For the past year I have been lurking around the Confidential Containers +community, getting more actively involved since the beginning of this year. So +far, I have mostly been visible helping out with CoCo releases, as well as +fixing bugs and submitting improvements to CoCo/Kata tests/CI. You may also +have seen me answering questions on slack and helping others understand the +Kata design or debugging issues. + +Microsoft relies on Kata Containers in some of our product offerings, with more +to come. We sponsor both the Kata as well CoCo CI infrastructures. We are also +active in adjacent projects like Cloud Hypervisor. Our goal within the Kata +project is simple: contribute to making it more secure and suitable for an even +wider range of use cases. Part of this is taking our learnings from years of +running hardware isolated containers and confidential computing workloads in +production and contributing them to the project, in a way that benefits all +users. + +Joining the Kata Architecure Committee will give me a chance to better serve +the community. Kata is a very dynamic and friendly project, and I'd like to +contribute to that. I care about expanding the project test matrix and making +testing both faster and more reliable, so that it is easier for new +contributors to join the project. I also want to work within the AC to see if +we can reconcile some of the extensions that the community has built up around +Kata. + +Jeremi diff --git a/elections/arch-committee-2023-04/README.md b/elections/arch-committee-2023-04/README.md new file mode 100644 index 0000000000..925adb2a6e --- /dev/null +++ b/elections/arch-committee-2023-04/README.md @@ -0,0 +1,15 @@ +# Architecture Committee Elections: Apr 2023 + +There are four Architecture Committee seats up for election. The seats up for +election are currently filled by `Peng Tao`, and `Samuel Ortiz`, with the +addition of two brand new seats for this round. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* April 05, 15:00 UTC - April 12, 2023 14:59 UTC: Candidate nominations open +* April 13, 15:00 UTC - April 23, 2023 14:59 UTC: Q&A/Debate period +* April 24, 15:00 UTC - May 01, 2023 14:59 UTC: Voting open +* May 02, 2023, results announced diff --git a/elections/arch-committee-2023-04/Results.md b/elections/arch-committee-2023-04/Results.md new file mode 100644 index 0000000000..0621fbc214 --- /dev/null +++ b/elections/arch-committee-2023-04/Results.md @@ -0,0 +1,22 @@ +# Architecture Committee Election Results: Apr 2023 + +Six nominations were received for the April 2023 elections: + +- [`Archana Shinde`](https://github.com/amshinde) +- [`Feng Wang`](https://github.com/fengwang666) +- [`Jeremi Piotrowski`](https://github.com/jepio) +- [`Samuel Ortiz`](https://github.com/sameo) +- [`Steve Horsman`](https://github.com/stevenhorsman) +- [`Tao Peng`](https://github.com/bergwolf) + +Four seats were available, so elections were held. + +The nominees elected to the positions were: + +- [`Feng Wang`](https://github.com/fengwang666) +- [`Samuel Ortiz`](https://github.com/sameo) +- [`Steve Horsman`](https://github.com/stevenhorsman) +- [`Tao Peng`](https://github.com/bergwolf) + +Congratulations to our new architecture committee members `Feng` and `Steve`, +and to our continuing members `Samuel` and `Tao`! diff --git a/elections/arch-committee-2023-04/SamuelOrtiz.txt b/elections/arch-committee-2023-04/SamuelOrtiz.txt new file mode 100644 index 0000000000..44a09bb4d3 --- /dev/null +++ b/elections/arch-committee-2023-04/SamuelOrtiz.txt @@ -0,0 +1,29 @@ +Name: Samuel Ortiz + +Email: samuel.e.ortiz@protonmail.com + +Background: + +I am a software engineer at Rivos, where I work on container, virtualization and +confidential computing related projects. + +A few years ago, together with Hyper and the OpenStack Foundation, we created +the Kata Containers project. I've really enjoyed seeing it growing into a wide, +cross-industry project with such a large customer base. Over those years, I +actively contributed to many parts of the project and tried to make the Kata +community both a welcoming and technologically innovative place. + +A couple of years ago, together with some other Kata contributors, we started to +build a new project with the goal of making a fairly complex and new technology, +Confidential Computing, seamlessly accessible through the canonical cloud native +software stack: Kubernetes and its flourishing ecosystem. Kata Containers was +the obvious choice and an almost perfect fit as the foundation for the +Confidential Containers project, and it proves to be a very solid base. As both +a Confidential and Kata Containers contributor and community member, I want to +continue reinforcing the symbiosis that we created between those 2 projects. I +believe that renewing my AC member seat would allow me to continue helping those +2 projects benefiting from each others, and this what I intend to focus on for +the upcoming year. + +Cheers, +Samuel diff --git a/elections/arch-committee-2023-04/SteveHorsman.txt b/elections/arch-committee-2023-04/SteveHorsman.txt new file mode 100644 index 0000000000..753405a30d --- /dev/null +++ b/elections/arch-committee-2023-04/SteveHorsman.txt @@ -0,0 +1,28 @@ +Name: Steve Horsman + +Email: steven@uk.ibm.com + +Background: + +I am a software engineer at IBM, where I work on Confidential Computing and +Cloud Platforms based on Z mainframe technology. + +I've been involved in the Kata Containers project since July 2021, when the +development in the Confidential Containers started. My main focus has been +working on the the CCv0 branch of kata-containers and tests, where I've helped +add new features, test code, jobs, done many code reviews, helped with the CoCo +release process and be one of the maintainers of the CCv0 branch to keep it +synced up with the main branch. + +My focus going forward is to help be part of the bridge between the Kata +Containers and Confidential Containers and work on how we can integrate +the new Confidential Containers code into the main branch of Kata Containers +in a way that adds value, and doesn't significantly compromise the existing +users in performance, or stability. + +I also want to help be a part of improving the performance and reliability of +the CI/CD process after having a lot of first hand experience of some of the +challenges developers and reviewer can face trying to get new PRs tested and +integrated. + +Steve \ No newline at end of file diff --git a/elections/arch-committee-2023-04/TaoPeng.txt b/elections/arch-committee-2023-04/TaoPeng.txt new file mode 100644 index 0000000000..f7353fea03 --- /dev/null +++ b/elections/arch-committee-2023-04/TaoPeng.txt @@ -0,0 +1,48 @@ +Name: Tao Peng + +Email: bergwolf@hyper.sh, bergwolf@antgroup.com + +Background: + +I am a staff engineer at Ant Group, where my primary focus is on cloud-native +infrastructure related technologies, including both container runtimes and +images. + +I have been an active contributor since the foundation of the Kata Containers +project and even before that in the runV project. I am interested in many +areas of the project, including runtime, agent, rust VMM, etc. I served as a +member of the vulnerability management team, the release management team, and +the architecture committee. Here, I would like to renew my seat in the +architecture committee to continue my contribution to the Kata community. + +The Ant Group team is very dedicated to the Kata Containers project. We manage +a large scale of Kata deployments in production and advocate for Kata online +and offline wherever possible. We have been pioneers in new features as well +as architecture improvements. We have been actively engaged in upstream +development in the past and will continue to do so in the future. + +We released Kata 3.0 last year, bringing in many useful features like the rust +runtime and dragonball-integrated VMM. Looking forward, I think there are more +things to focus on, such as: + +1. Rust runtime production-ready. We released the Rust runtime as a preview +feature in 3.0. We should continue to improve and polish it to make it +production-ready so that users can actually benefit from its simplified +architecture. + +2. Confidential container support. It has been developed in a separate dev +branch for a long time, which brings a lot of maintenance burden and hides +its radiance away from actual Kata users. We should put more effort into +maturing the confidential container support and merge the code into the main +branch sooner rather than later. + +3. Service mesh support. Within the service mesh context, we have observed +more challenges on the Kata threat model and security boundary. We need to +find a solid solution to the problem and push forward both the secure +container as well as the service mesh world. + +These are just three things on top of my mind. I certainly believe that we +have more to do, and I look forward to continuing to contribute to the +community and help it thrive. + +-Tao diff --git a/elections/arch-committee-2023-10/FabianoFidencio.txt b/elections/arch-committee-2023-10/FabianoFidencio.txt new file mode 100644 index 0000000000..c8d839b71d --- /dev/null +++ b/elections/arch-committee-2023-10/FabianoFidencio.txt @@ -0,0 +1,52 @@ +Name: Fabiano Fidêncio + +Email: fabiano@fidencio.org + +Background: + +I am a Software Engineer, a tattoo canvas for abstract art, a music addict, a +goats and pigs instagram follower, and a big fan of old video games. + +In the past 3.5 years I dedicated a huge chunk of my professional and personal +time contributing to the Kata Containers project and community, with a strong +focus on trying to keep the community as healthy as possible, while also +focusing on efforts in the Confidential Containers space, and trying to +reconcile the two projects as much as possible. + +My involvement with Kata Containers has been intense, to say the least. I've +been involved on pretty much every part of the project, and also on projects +Kata Containers interacts with.  Moreover, I've already been serving the +community as a current member of the Kata Containers Architecture Committee. + +In the enterprise world, while working for Intel, I've been working mostly on +leveraging Intel's usage of Kata Containers, and also bringing Intel +technologies to the project, such as the TDX support and integration work for +Confidential Containers.  While I was still working for Red Hat,I worked on +making the upstream project a Red Hat's downstream product, passing by Fedora, +CentOS, Red Hat CoreOS, and OpenShift components, which led to the OpenShift +Sandboxed Containers product, which uses Kata Containers underneath. + +In the community space, I also have helped on a lot of different parts of the +project. connected people to have their problems solved, mentored both +newcomers and students into our community, have led Architecture Committee +meetings, helped organise Kata Containers vPTG sessions, presented the project +at conferences, worked together with OIF on getting Study Cases published, and +helped increase the number of members in our community.  I also am hands-on on +CI, code-reviewing, development focusing on easing the adoption of the project. +I've managed a whole bunch of releases, and have been working as much as +possible to grow this community in a healthy way. + +Recently I've been leading the whole migration away from Jenkins to using +GitHub Actions, which makes our CI more efficient, reliable, and our tests +closer to the real life usage. + +My main motivations are still to increase Kata Containers adoption in the +industry, while ensuring the project is stable and easily consumable.  This is +more important now than ever as new players are adopting and contributing to +the Kata Containers project, and we're transitioning to the runtime-rs. + +To make it possible, I plan to continue working in the integration bits, while +connecting and facilitating the communication between the Kata Containers +community and the communities that I am part of. + +Fabiano Fidêncio (Slack: fidencio) diff --git a/elections/arch-committee-2023-10/FupanLi.txt b/elections/arch-committee-2023-10/FupanLi.txt new file mode 100644 index 0000000000..22553e4488 --- /dev/null +++ b/elections/arch-committee-2023-10/FupanLi.txt @@ -0,0 +1,19 @@ +Name: Fupan Li + +Email: lifupan@gmail.com + +Background: + +I’m one of the Kata Containers communities maintainer and active contributor since 2018, +during the past few years, I developed the Kata Containers shimv2, which promoted Kata +Containers from multi process model into only two process(shimv2 and vmm) model, at the +same time, it made Kata Containers much more populated and adoptable in the k8s community. +In addition, I’m the author of the rust version of the kata-agent, which bring Kata Containers +from 1.0 to 2.0. Last but not lease, I’m the architecture and key developer of the rust version’s +kata runtime, which had been opened and contributed to runtime-rs. + +In addition to that, I worked in Ant Group , which maintained the largest Kata Containers cluster, +as an senior engineer, I’m responsible for the implementation and development of the kata container +inside Ant, and I am confident that based on my development and land experience on the Ant Group, +as well as the maintenance work of the community, I’d try my best to contribute much more to the +Kata community. diff --git a/elections/arch-committee-2023-10/GerryLiu.txt b/elections/arch-committee-2023-10/GerryLiu.txt new file mode 100644 index 0000000000..392e1d5201 --- /dev/null +++ b/elections/arch-committee-2023-10/GerryLiu.txt @@ -0,0 +1,23 @@ +Name: Gerry Liu +Email: gerry at linux dot alibaba dot com + +Background +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. + +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. + +Last year, I contributed to the community in the following ways: +1) Refactor the storage object management subsystem in Kata runtime/agent. +2) Help integrating Nydus Image Service into Dragonball vmm. +3) Reconstruct Coco’s image management system to help merging Coco into the Kata main branch. +4) Enhance Nydus image service to better support Coco. +5) Put Kata related technologies into production and have a huge deployment base + +In the coming year, I plan to work with the community and focus on the following tasks: +1) Get runtime-rs ready for production +2) Get Dragonball ready for production +3) Better cooperation between Coco and Kata, mainly integrating Coco into the Kata main branch +4) Enhance Nydus Image Service to better support Kata +5) Enhance Dragonball to better support GPU, other accelerators and DPU. + +Gerry diff --git a/elections/arch-committee-2023-10/GregKurz.txt b/elections/arch-committee-2023-10/GregKurz.txt new file mode 100644 index 0000000000..a0bbbfb96b --- /dev/null +++ b/elections/arch-committee-2023-10/GregKurz.txt @@ -0,0 +1,42 @@ +Name: Greg Kurz + +Email: groug@kaod.org + +Background: + +I am a Senior Software Engineer at Red Hat. I work for the Openshift +Sandboxed Containers project, which provides Kata Containers to the +Openshift Container Platform. I initially joined the effort to share my +expertise on system components involved in virtualization, most notably +QEMU, but my interest now spans the full stack, in order to provide a +well integrated and production grade software to end users. + +Being an open source enthousiast since the late 90s, with a strong focus +on system programing, I have been involved in early implementations of +containers in Linux (LXC). After a brief detour through a proprietary +operating system, I came back even more convinced of the virtues of open +source regarding software quality and personal development. I then spent +nearly 10 years working in underlying virtualization technologies used by +Kata Containers, especially QEMU where I actively contributed to IBM's POWER +architecture support and acted as maintainer for the 9Pfs subsystem until +today. + +I have developped over the years a strong appetite for "learning from" +and "sharing with" people in open communities, with a peculiar interest +in promoting good practices. The main piece I'd keep from my experience +with QEMU and Linux, is the importance of accompanying and improving +contributions so that new comers can fully benefit from the priceless +expertise that was accumulated over the years. This is a key part for the +success and sustainability of any community. + +I joined Kata Containers 2 years ago, as a developper first, but then +quickly endorsed the roles of reviewer, maintainer and I got directly +involved in several official releases. I am now ready to go one step +further and join the Architecture Commitee in order to accompany the +community even more on consolidating good practices and improving +processes. This is crucial for the success of Kata Containers, now that +it has become the de-facto vehicle to bring more and more virtualization +features to the containers ecosystem, with its share of integration +challenges. + +Greg diff --git a/elections/arch-committee-2023-10/JeremiPiotrowski.txt b/elections/arch-committee-2023-10/JeremiPiotrowski.txt new file mode 100644 index 0000000000..8373c67e74 --- /dev/null +++ b/elections/arch-committee-2023-10/JeremiPiotrowski.txt @@ -0,0 +1,38 @@ +Name: Jeremi Piotrowski + +Email: jpiotrowski@microsoft.com + +Background: + +I'm a software engineer at Microsoft, where I work within Azure. My primary +focus is contributing to open source projects within the Cloud Native space, +but I do not draw the line there and try to improve any and every part of the +stack involved in running containers. + +For more than a year now I have been active in both the Kata Containers and +Confidential Containers communities. I have been working in numerous areas most +recently CI stability, and reviewing contributions (especially Cloud-Hypervisor +related) to ensure the project can incorporate them in a timely manner. Other +areas I've helped with are CoCo releases, CoCo development related to +attestation (TDX and SNP) and bugfixes in Kata (cgroups and others). You may +also have seen me answering questions on slack and helping others understand +the Kata design or debugging issues. + +Microsoft relies on Kata Containers in some of our service offerings, with more +to come. We sponsor both the Kata as well CoCo CI infrastructures. We are also +active in adjacent projects like Cloud Hypervisor. Our goal within the Kata +project is simple: contribute to the security and reliability of the project +and help make it suitable for an even wider range of use cases. Part of this is +taking our learnings from years of running hardware isolated containers and +confidential computing workloads in production and contributing them to the +project, in a way that benefits all users. + +Joining the Kata Architecure Committee will give me a chance to better serve +the community. Kata is a very dynamic and friendly project, and I'd like to +contribute directly to that. I care about making the project more robust as the +codebase grows, improving our test and release processes and making it is +easier for new contributors to join the project. I also want to work within the +AC to see if we can reconcile some of the extensions that the community has +built up around Kata. + +Jeremi diff --git a/elections/arch-committee-2023-10/README.md b/elections/arch-committee-2023-10/README.md new file mode 100644 index 0000000000..9184576652 --- /dev/null +++ b/elections/arch-committee-2023-10/README.md @@ -0,0 +1,15 @@ +# Architecture Committee Elections: Oct 2023 + +There are four Architecture Committee seats up for election. The seats up for +election are currently filled by `Eric Ernst`, `Fabiano Fidêncio`, `Gerry Liu` and `Feng Wang` who stepped down early. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* October 03, 2023: Election officials confirmed @stevenhorsman +* October 09, 15:00 UTC - October 16, 2023 14:59 UTC: Candidate nominations open +* October 17, 15:00 UTC - October 24, 2023 14:59 UTC: Q&A/Debate period +* October 26, 20:00 UTC - November 02, 2023 18:59 UTC: Voting open +* November 03, 2023, results announced diff --git a/elections/arch-committee-2023-10/Results.md b/elections/arch-committee-2023-10/Results.md new file mode 100644 index 0000000000..2fded08c29 --- /dev/null +++ b/elections/arch-committee-2023-10/Results.md @@ -0,0 +1,23 @@ +# Architecture Committee Election Results: October 2023 + +Six nominations were received for the October 2023 elections: + + +- [`Fabiano Fidêncio`](https://github.com/fidencio) +- [`Fupan Li`](https://github.com/lifupan) +- [`Gerry Liu`](https://github.com/jiangliu) +- [`Greg Kurz`](https://github.com/gkurz) +- [`Jeremi Piotrowski`](https://github.com/jepio) +- [`Zvonko Kaiser`](https://github.com/zvonkok) + +Four seats were available, so elections were held. + +The nominees elected to the positions were: + +- [`Fabiano Fidêncio`](https://github.com/fidencio) +- [`Fupan Li`](https://github.com/lifupan) +- [`Gerry Liu`](https://github.com/jiangliu) +- [`Greg Kurz`](https://github.com/gkurz) + +Congratulations to our new architecture committee members `Fupan` and `Greg`, +and to our continuing members `Fabiano` and `Gerry`! diff --git a/elections/arch-committee-2024-04/AnastassiosNanos.txt b/elections/arch-committee-2024-04/AnastassiosNanos.txt new file mode 100644 index 0000000000..b773a005c2 --- /dev/null +++ b/elections/arch-committee-2024-04/AnastassiosNanos.txt @@ -0,0 +1,24 @@ +Name: Anastassios Nanos + +Email: ananos@nubificus.co.uk + +Background: + +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. + +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. + +If elected to the Kata Architecture Committee, my primary focus will be hypervisor support, particularly in the context of the runtime-rs port. + +A few thoughts: + +- 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. + +- 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. + +- 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. + +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. + +cheers, +Tassos diff --git a/elections/arch-committee-2024-04/README.md b/elections/arch-committee-2024-04/README.md new file mode 100644 index 0000000000..52b839f6f2 --- /dev/null +++ b/elections/arch-committee-2024-04/README.md @@ -0,0 +1,16 @@ +# Architecture Committee Elections: Apr 2024 + +There are four Architecture Committee seats up for election. The seats up for +election are currently filled by `Fabiano Fidêncio`, `Peng Tao`, `Samuel Ortiz` +and `Steve Horsman`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* April 01, 2024: Election officials are confirmed: @sprt, @Apokleos +* April 08, 15:00 UTC - April 15, 2024 14:59 UTC: Candidate nominations open +* April 15, 15:00 UTC - April 22, 2024 14:59 UTC: Q&A/Debate period +* April 22, 15:00 UTC - April 29, 2024 14:59 UTC: Voting open +* April 30, 2024, results announced diff --git a/elections/arch-committee-2024-04/Results.md b/elections/arch-committee-2024-04/Results.md new file mode 100644 index 0000000000..de1f41c6cc --- /dev/null +++ b/elections/arch-committee-2024-04/Results.md @@ -0,0 +1,16 @@ +# Architecture Committee Election Results: Apr 2024 + +Four nominations were received for the April 2024 elections: + +- [`Anastassios Nanos`](https://github.com/ananos) +- [`Steve Horsman`](https://github.com/stevenhorsman) +- [`Tao Peng`](https://github.com/bergwolf) +- [`Zvonko Kaiser`](https://github.com/zvonkok) + +Four seats were available, and the architecture committee resulting from +the above nominations would not contain more than two members of the +same affiliation, so the voting phase was skipped and all the nominated +individuals were appointed to the architecture committee. + +Congratulations to our new architecture committee members `Anastassios` +and `Zvonko`, and to our continuing members `Steve` and `Tao`! diff --git a/elections/arch-committee-2024-04/SteveHorsman.txt b/elections/arch-committee-2024-04/SteveHorsman.txt new file mode 100644 index 0000000000..c13648ac30 --- /dev/null +++ b/elections/arch-committee-2024-04/SteveHorsman.txt @@ -0,0 +1,24 @@ +Name: Steve Horsman + +Email: steven@uk.ibm.com + +Background: + +I am a software engineer at IBM, where I work on Confidential Computing +based on Z mainframe technology. + +I've been involved in the Kata Containers project since July 2021, when the +development in the Confidential Containers started. My main focus has been +working on the the CCv0 branch of kata-containers and tests, where I've helped +add new features, test code, jobs, done many code reviews, helped with the CoCo +release process and then helped to co-ordinate the migration of the CoCo +function into the main branch in a proper way. In the last year I've served on +the Architecture Committee. + +I've also been involved in helping with the CI and updated release process +and I see my role going forwards to continue to be focused on the CoCo uses +of kata and try and help bring between the community and help with CI +stability and releases. I also look forward to some large changes in the near +future like moving to containerd 2.0 and the transition to runtime-rs. + +Steve diff --git a/elections/arch-committee-2024-04/TaoPeng.txt b/elections/arch-committee-2024-04/TaoPeng.txt new file mode 100644 index 0000000000..6a5a0329aa --- /dev/null +++ b/elections/arch-committee-2024-04/TaoPeng.txt @@ -0,0 +1,42 @@ +Name: Tao Peng + +Email: bergwolf@hyper.sh, bergwolf@antgroup.com + +Background: + +I am a staff engineer at Ant Group, where my primary focus is cloud-native +infrastructure-related technologies, including both container runtimes and +images. + +I have been an active contributor since the foundation of Kata Containers +project back in 2017. I used to work on many areas of the project including +architectural design, development, releasing management, security auditing, +event organizing, and community promoting. I have served as a member of the +architecture committee since 2021 and would like to renew my seat to continue +my contribution to the community. + +In the coming year, there are still quite a lot of interesting things going on +in the community, out of which my main focus would mostly be around: + +1. Engaging more users. While Kata is getting more and more end users, it is +also obvious that we are not getting enough feedback from them. The latest end-user +survey is a good start. I would like to help engage more end users so +that we can use their feedback to prioritize features of the project. + +2. Collaboration with the confidential container project. Coco is certainly one +of the most important downstream of Kata. While Coco has been doing great so far, +it has been living in the shadow for too long. We should merge it into the main +branch soonish and ensure the roadmap-wise longterm alignment of Coco and Kata. + +3. PVM (Pagetable-based Virtual Machine) is a cutting-edge isolation technology +developed by Ant Group and expands Kata's usage in nested VM environments. It +is still in the process of being upstreamed in the Linux kernel community and I +would devote part of my time to help integrate and promote it in the Kata +community, especially to the SaaS/PaaS provider users of Kata who operate mostly +in public cloud. + +Meanwhile, there is certainly more to do for the community and I look forward to +continuing to serve the community and help it thrive. + +Cheers, +Bergwolf diff --git a/elections/arch-committee-2024-04/ZvonkoKaiser.txt b/elections/arch-committee-2024-04/ZvonkoKaiser.txt new file mode 100644 index 0000000000..4c9dd5b82f --- /dev/null +++ b/elections/arch-committee-2024-04/ZvonkoKaiser.txt @@ -0,0 +1,64 @@ +Name: Zvonko Kaiser + +Email: zkaiser@nvidia.com + +Background: + +I am a software engineer at NVIDIA, where I work on all things cloud-native. +At NVIDIA I am leading the Kata and Confidential Containers efforts and enabling +Kata and Confidential Containers on all of our architectures, platforms and +projects, ranging from embedded, edge devices to data centers and cloud. + +Over the last two years, I have been actively involved in Kata, contributing +my expertise and dedication towards its success. As a passionate and experienced +professional in the field, I strongly believe that my skills and insights can +greatly benefit the AC's decision-making process. + +Here are a few reasons why I believe I am well-suited for this role: + +Extensive Technical Knowledge: With over ten years of experience in system +software development/performance engineering and a strong background in +virtualization from embedded to cloud, I possess a deep understanding of the +technical aspects involved in our project. This knowledge allows me to provide +valuable input and contribute to informed discussions within the committee. + +Additionally I have an broad experience and insight from various industry fields, +ranging from robotics at the Fraunhofer Institute, automotive doing autonomous +parking at Mercedes Research to mainframe and blade servers at IBM to cloud and +Kubernetes at RedHat and NVIDIA. + +Especially in Kata I have added the virtualization reference architecture to +support advanced use-cases like GPUDirect RDMA and GPUDirect GDS which is a must +have for allmost all of the NVIDIA customers and internal projects leveraging +Kata. Last year I added proper support for GPU, vGPU time-sliced, +vGPU MIG-backed and this year my focus was on the confidential GPU support. + +Last but not least my insights through my work at NVIDIA on Confidential +Computing and AI/ML use-cases will help me as a member of the AC to help guide +the project to support important use-cases and requirements. + +Strong Leadership Abilities: Throughout my career, I have demonstrated effective +leadership skills by successfully leading cross-functional teams and delivering +complex projects on time and within budget. My ability to collaborate with +diverse stakeholders ensures that decisions made by the committee align with +both technical requirements and overall project goals. + +Commitment to Continuous Improvement: As a member of the AC, I will strive to +drive innovation and promote best practices within our project. By staying +up-to-date with emerging technologies and industry trends, I can help guide our +software towards greater efficiency, scalability, and user satisfaction. + +Excellent Communication Skills: Effective communication is crucial for any +committee's success. With my strong verbal and written communication abilities, +I can facilitate productive discussions among committee members, ensuring that +ideas are shared openly and transparently. + +I am excited about the opportunity to contribute further to this project's +growth as a member of the AC. If given the chance, I will dedicate myself +wholeheartedly to fulfilling my responsibilities with utmost professionalism. + +Thank you for considering my nomination. +Mr. Z + + + diff --git a/elections/arch-committee-2024-10/AurelienBombo.txt b/elections/arch-committee-2024-10/AurelienBombo.txt new file mode 100644 index 0000000000..44d3c8bb31 --- /dev/null +++ b/elections/arch-committee-2024-10/AurelienBombo.txt @@ -0,0 +1,40 @@ +Name: Aurelien Bombo + +Email: abombo@microsoft.com + +Background: + +I'm a software engineer at Microsoft, where I work on developing the +Azure Linux OS for different offerings, including the Azure Kubernetes +Service (AKS), and where my primary focus is to grow Kata Containers +both outside and inside Microsoft. + +I joined the project at the beginning of last year, when I initially +helped with the move from Jenkins to Github Actions in order to +modernize the CI. Since then, I've been involved in both the Kata and +CoCo communities, maintaining and strengthening our CI, reviewing +contributions, and helping out cutting releases. + +Notably, as Microsoft sponsors the CI infrastructure for Kata and CoCo +(as well as adjacent projects like Cloud Hypervisor), I've worked with +Microsoft leadership to unlock $54,000 of funding for Azure resources +for testing. Separately, I've worked with Github to upgrade our +concurrent free runner limit from 20 to 100, significantly speeding up +our CI at no extra cost. In everyday operations, I make it a point to +ensure our CI usage continuously gives us a safe operating margin in +terms of costs, and I bring my expertise in helping the community +maintain the health of the test infrastructure relying on AKS. + +More recently, I've been leading a mentorship program with Boston +University, in which a team of five students is working on turning our +CI dashboard prototype into a production solution, as well as adding +more automation to our CI. I've also been working more closely with +the CoCo community to enable confidential storage features. + +In the next year, I plan to keep executing on these priorities and to +further stabilize and strengthen Kata. As the project matures, a logical +next step that I'd like to explore is advertising it around different +online communities and increasing the reach and growth of the project +this way. + +Aurelien diff --git a/elections/arch-committee-2024-10/FupanLi.txt b/elections/arch-committee-2024-10/FupanLi.txt new file mode 100644 index 0000000000..13493e2a73 --- /dev/null +++ b/elections/arch-committee-2024-10/FupanLi.txt @@ -0,0 +1,23 @@ +Name: Fupan Li + +Email: lifupan@gmail.com + +Background: + +I’m one of the Kata Containers communities maintainer and active contributor since 2018, +during the past few years, I developed the Kata Containers shimv2, which promoted Kata +Containers from multi process model into only two process(shimv2 and vmm) model, at the +same time, it made Kata Containers much more populated and adoptable in the k8s community. +In addition, I’m the author of the rust version of the kata-agent, which bring Kata Containers +from 1.0 to 2.0. Last but not lease, I’m the architecture and key developer of the rust version’s +kata runtime, which had been opened and contributed to runtime-rs. + +I was elected as a Kata AC member last year and have served the Kata community for a year. During +this year, I actively promoted the maturity of Kata rust runtime and it has reached the requirements +of product-level stability. + +In addition to that, I worked in Ant Group, which maintained the largest Kata Containers cluster, +as an senior engineer, I’m responsible for the implementation and development of the kata container +inside Ant, and I am confident that based on my development and land experience on the Ant Group, +as well as the maintenance work of the community, I’d try my best to contribute much more to the +Kata community. diff --git a/elections/arch-committee-2024-10/GregKurz.txt b/elections/arch-committee-2024-10/GregKurz.txt new file mode 100644 index 0000000000..e38fb7d749 --- /dev/null +++ b/elections/arch-committee-2024-10/GregKurz.txt @@ -0,0 +1,21 @@ +Name: Greg Kurz + +Email: groug@kaod.org + +Background: + +I am a Senior Software Engineer at Red Hat. I work for the Openshift +Sandboxed Containers project, which provides Kata Containers to the +Openshift Container Platform. I initially joined the effort to share my +expertise on system components involved in virtualization, most notably +QEMU, but my interest now spans the full stack, in order to provide a +well integrated and production grade software to end users. + +I joined Kata Containers 3 years ago, as a developper first, but then +quickly endorsed the roles of reviewer, maintainer and I got directly +involved in several official releases. I've served on the Architecture +Committee for a year, helping with CI, releases and providing guidance +on good coding practices during reviews. I want to continue the effort, +with a focus on the upcomfing transition to runtime-rs and CI improvements. + +Greg diff --git a/elections/arch-committee-2024-10/README.md b/elections/arch-committee-2024-10/README.md new file mode 100644 index 0000000000..2e466c1444 --- /dev/null +++ b/elections/arch-committee-2024-10/README.md @@ -0,0 +1,15 @@ +# Architecture Committee Elections: Oct 2024 + +There are three Architecture Committee seats up for election. The seats up for +election are currently filled by `Fupan Li`, `Gerry Liu` and `Greg Kurz`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* September 23, 2024: Election officials are confirmed: @Apokleos, @stevenhorsman +* October 01, 15:00 UTC - October 15, 2024 14:59 UTC: Candidate nominations open +* October 15, 15:00 UTC - October 22, 2024 14:59 UTC: Q&A/Debate period +* October 22, 15:00 UTC - October 29, 2024 14:59 UTC: Voting open +* October 29, 2024, results announced diff --git a/elections/arch-committee-2024-10/Results.md b/elections/arch-committee-2024-10/Results.md new file mode 100644 index 0000000000..27be210dd3 --- /dev/null +++ b/elections/arch-committee-2024-10/Results.md @@ -0,0 +1,18 @@ +# Architecture Committee Election Results: Oct 2024 + +Four nominations were received for the October 2024 elections, however +one of the candidates withdrew before the voting period. The final +candidate list is: + +- [`Aurelien Bombo`](https://github.com/sprt) +- [`Fupan Li`](https://github.com/lifupan) +- [`Greg Kurz`](https://github.com/gkurz) + +Three seats were available, and the architecture committee resulting from +the above nominations would not contain more than two members of the +same affiliation, so the voting phase was skipped and all the nominated +individuals were appointed to the architecture committee. + +Congratulations to our new architecture committee member `Aurélien` +and to our continuing members `Fupan` and `Greg`! + diff --git a/elections/arch-committee-2025-04/AnastassiosNanos.txt b/elections/arch-committee-2025-04/AnastassiosNanos.txt new file mode 100644 index 0000000000..693283665e --- /dev/null +++ b/elections/arch-committee-2025-04/AnastassiosNanos.txt @@ -0,0 +1,22 @@ +Name: Anastassios Nanos + +Email: ananos@nubificus.co.uk + +Background: + +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. + +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. + +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. + +A few thoughts: + +- 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. + +- 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. + +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. + +cheers, +Tassos diff --git a/elections/arch-committee-2025-04/README.md b/elections/arch-committee-2025-04/README.md new file mode 100644 index 0000000000..178faaa3b4 --- /dev/null +++ b/elections/arch-committee-2025-04/README.md @@ -0,0 +1,16 @@ +# Architecture Committee Elections: Apr 2025 + +There are four Architecture Committee seats up for election. The seats up for +election are currently filled by `Anastassios Nanos`, `Peng Tao`, `Steve Horsman` +and `Zvonko Kaiser`. + +Refer to the [elections folder README](https://github.com/kata-containers/community/tree/main/elections) +for election process, declaring candidacy, and eligible voters. + +Election Dates: + +* March 31, 2025: Election officials are confirmed: @sprt, @Apokleos +* April 07, 15:00 UTC - April 14, 2025 14:59 UTC: Candidate nominations open +* April 14, 15:00 UTC - April 21, 2025 14:59 UTC: Q&A/Debate period +* April 21, 15:00 UTC - April 28, 2025 14:59 UTC: Voting open +* April 28, 2025, results announced diff --git a/elections/arch-committee-2025-04/Results.md b/elections/arch-committee-2025-04/Results.md new file mode 100644 index 0000000000..98938e9a3b --- /dev/null +++ b/elections/arch-committee-2025-04/Results.md @@ -0,0 +1,21 @@ +# Architecture Committee Election Results: Apr 2025 + +There were 5 nominations received for the April 2025 elections: + +- [`Anastassios Nanos`](https://github.com/ananos) +- [`Peng Tao`](https://github.com/bergwolf) +- [`Steve Horsman`](https://github.com/stevenhorsman) +- [`Ruoqing He`](https://github.com/RuoqingHe) +- [`Zvonko Kaiser`](https://github.com/zvonkok) + +Four seats were available, so elections were held. + +The nominees elected to the positions were: + +- [`Anastassios Nanos`](https://github.com/ananos) +- [`Steve Horsman`](https://github.com/stevenhorsman) +- [`Ruoqing He`](https://github.com/RuoqingHe) +- [`Zvonko Kaiser`](https://github.com/zvonkok) + +Congratulations to our new architecture committee member `Ruoqing`, +and to our continuing members `Anastassios`, `Steve` and `Zvonk`! \ No newline at end of file diff --git a/elections/arch-committee-2025-04/RuoqingHe.txt b/elections/arch-committee-2025-04/RuoqingHe.txt new file mode 100644 index 0000000000..266bb128fb --- /dev/null +++ b/elections/arch-committee-2025-04/RuoqingHe.txt @@ -0,0 +1,59 @@ +Name: Ruoqing He + +Email: heruoqing@iscas.ac.cn + +Background: + +I'm a software engineer at Institute of Software, Chinese Academy of Sciences, +and my focus is virtualization and cloud-native on RISC-V architecture. More +specifically, the software stack related/connected to and includes Kata +Containers. + +I walked all the way up from rust-vmm -> cloud-hypervisor -> Kata Contaienrs, +laid down the RISC-V CI infrastructures and introduced RISC-V architecture +support, while actively maintaining them. Besides, we have been working on +dragonball too since last year, those works will be put up and receive reviews +in a few months after we figured out how to deal with and upgrade the rust-vmm +dependencies correctly and elegantly. + +As for the RISC-V infrastructure, we are closely working with RISC-V hardware +vendors, testing our works on their FPGA, QEMU and prototypes even before those +products are manufactured. So for sure, we will get a hold on them when they +(RISC-V hardware capable of running Kata Containers software stack) are made +available to the market. As of now, we are maintaining the RISC-V runners we +have in Kata community. With that being said, I would be actively playing with +and maintaining our CI as of those connected/going to be connected machines, to +establish solid ground for RISC-V work to stably progress. + +In the year ahead we are going to have real hardware that is capable of +building, testing, and running full Kata Containers software stack, which would +be an important milestone for both Kata and RISC-V. I will be pushing the +following forward: + +- Extend/Upgrade the runner matrix in Kata self-hosted RISC-V runners: + Currently, we are using machines without hypervisor extension solely for + building, and my goal is always align with other architectures to build, test, + and run on self-hosted machines. + +- Expand RISC-V support for Kata components: This is my primary focus in our + community, I will continue to work out, stabilize and maintain RISC-V + architecture support all over the place. + +- Explore RISC-V Confidential Containers: Looking for works could/should be + done in both coco community and integrating them to Kata, and catching up the + developments of CoVE here. + +- Advocate Kata Containers: I have been talking about Kata Containers more than + ten times in the past year, to developers, end users, and the public. I + talked about Kata on RISC-V in FOSDEM 2025 [1] in Feb 2025, and I will bring + this topic to RISC-V Summit Europe 2025 in May 2025. + +apart from those, I will be committed to helping maintaining our CI +infrastructure, reviewing/unblocking PRs and contributing like predecessors and +current ACs/maintainers/contributors in our community did. + +Cheers, +Ruoqing + +[1] https://fosdem.org/2025/schedule/event/fosdem-2025-4156-from-rust-vmm-to-katacontainers-the-development-of-h-ext-based-software-ecosystem/ + diff --git a/elections/arch-committee-2025-04/SteveHorsman.txt b/elections/arch-committee-2025-04/SteveHorsman.txt new file mode 100644 index 0000000000..8c4f60a107 --- /dev/null +++ b/elections/arch-committee-2025-04/SteveHorsman.txt @@ -0,0 +1,25 @@ +Name: Steve Horsman + +Email: steven@uk.ibm.com + +Background: + +I am a software engineer at IBM, where I work on Confidential Computing +based on Z mainframe technology. + +I've been involved in the Kata Containers project since July 2021, when the +development in the Confidential Containers started. My main focus has been +working on CoCo features, CI and helping with the Kata Containers releases. +In the last two years I've served on the Architecture Committee. + +Some of the activities that I'm keen to help drive in the next year are: +- Helping onboard new members and platforms to the community +- Trying to help drive more "professional" standards in kata-containers, +like regularly running security scans, ensuring our crates and modules are +kept up-to-date and driving our CVE backlog down +- Helping to improve our CI process and get faster and more targeted testing + +I'm also looking forward to seeing what happens with the move to containerd 2.0 +and with runtime-rs enhancements. + +Steve diff --git a/elections/arch-committee-2025-04/TaoPeng.txt b/elections/arch-committee-2025-04/TaoPeng.txt new file mode 100644 index 0000000000..002fdecf7e --- /dev/null +++ b/elections/arch-committee-2025-04/TaoPeng.txt @@ -0,0 +1,38 @@ +Name: Tao Peng + +Email: bergwolf@hyper.sh, bergwolf@antgroup.com + +Background: + +I am a staff engineer at Ant Group, where my primary focus is cloud-native +infrastructure-related technologies, including both container runtimes and +images. + +I have been an active member of the Kata Containers community since 2017. +I worked on many areas of the project, including architectural design, +development, releasing management, security auditing, event organizing, and +community promoting. I've been part of the architecture Committee since 2021, +and I'd be honored to continue serving the community. + +In the past years, the community has done tremendous work to bring a fast, +secure and production-ready container runtime to the world. In the coming year, +my main focus will mostly be around: + +1. runtime-rs maturity and adoption. We've been developing runtime-rs for +quite some time. It is faster, more stable, and more memory efficient. It is +now time to look at a realistic timeline to make it default and share it with +a wider range of Kata Containers users. + +2. PVM (Pagetable-based Virtual Machine) is a cutting-edge isolation technology +developed by Ant Group and expands Kata's usage in nested VM environments by +removing the nested VT hardware requirement. While it is still in the process +of being upstreamed in the Linux kernel community, we've been deploying it on +a large scale internally, and there are community users around as well. I'd like +to help integrate and promote it both in the Kata community and in the wider +kernel community. + +I sincerely look forward to continuing to serve the Kata community and helping +it thrives. + +Cheers, +Bergwolf diff --git a/elections/arch-committee-2025-04/ZvonkoKaiser.txt b/elections/arch-committee-2025-04/ZvonkoKaiser.txt new file mode 100644 index 0000000000..e7424ecea7 --- /dev/null +++ b/elections/arch-committee-2025-04/ZvonkoKaiser.txt @@ -0,0 +1,42 @@ +Name: Zvonko Kaiser + +Email: zkaiser@nvidia.com + +Background: + +I would be honored to continue serving on the Architecture Committee and further +contribute to our shared goals. I am a principal engineer at NVIDIA, focusing on +cloud-native development and leading Kata and Confidential Containers efforts +across various architectures—from embedded and edge devices to data centers and +cloud platforms. Over the last four years, I’ve been deeply involved in Kata, +bringing my expertise and dedication to help it flourish. + +Throughout my career, I’ve gained extensive technical knowledge in system +software development, performance engineering, and virtualization—experience +that spans robotics at the Fraunhofer Institute, automotive research at +Mercedes, mainframe and blade servers at IBM, and cloud/Kubernetes roles at +RedHat and NVIDIA. In Kata, I helped introduce the virtualization reference +architecture to support advanced GPU use cases like GPUDirect RDMA and GPUDirect +GDS. I also added GPU, vGPU (time-sliced and MIG-backed) support, and recently +focused on confidential GPU capabilities. All of these efforts have aimed to +expand Kata’s features and better serve the wider community. + +Collaboration and teamwork are at the heart of my approach. I have led +cross-functional teams and worked with diverse stakeholders to ensure open +communication and consensus-driven decisions. I stay up-to-date with emerging +technologies and industry trends, continually seeking ways to enhance +efficiency, scalability, and user satisfaction in our projects. + +Looking ahead, I am excited to help guide our work into the secure AI era. By +strengthening confidential computing, advancing GPU virtualization technologies, +and aligning with robust security standards, I believe we can ensure that our +project remains at the forefront of modern AI use cases—empowering developers +and users alike with trusted, scalable solutions. + +If given the opportunity, I will continue promoting innovation, community +engagement, and transparency within the Architecture Committee. Thank you for +considering my nomination, and I look forward to helping guide our work to even +greater success. + +Sincerely, +Mr. Z \ No newline at end of file diff --git a/elections/process/README.md b/elections/process/README.md new file mode 100644 index 0000000000..5c67bb5c2a --- /dev/null +++ b/elections/process/README.md @@ -0,0 +1,130 @@ +# Election Process + +The election process is administered and guided by +the Election Officials. + +This group is responsible for working with the +Architecture Committee (AC) on the election timeline, +performing the preparation steps and carrying out all +required communications. + +## Pick election officials +Election officials should not run in the election themselves. +Ideally they should also have no interest in the election +outcome (to preserve neutrality) but that is generally +harder to achieve. + +Election officials should be identified by no later than a +week prior to the start of the election. + +# Selecting Election Dates +Things to keep in mind when selecting election dates: + +- Try to avoid overlapping with big in-person events + in the interest for the community or major public holidays +- Allow enough time for the contributors to decide if they + are planning to run, and fulfill all the requirements to be + able to participate +- Allow at least a week for nomination and campaign periods +- The current AC needs to approve the timeline once there + is a proposal + +# Preparation +As early as possible but at least a month before election +starts: + +- Edit elections details (timeline, elected positions, deadlines) + in the [community repo](https://github.com/kata-containers/community/tree/main/elections) +- Create the PR to update the information on GitHub + +A couple of weeks before election starts: + +- Post information about the upcoming election on the + kata-dev mailing list and on Slack +- Generate an initial electorate list and share it with the + AC and community to ensure that the list contains all active + contributors + +# During the election +## AC Nomination Round +When AC nomination period starts: + +- Send Kata AC Nomination period started email to kata-dev +- Announce the start of the nomination period on Slack +- Generate the final electorate list + +Email and Slack announcement tips: +- Introduce yourself as election official +- Announce start of process +- List seats up for reelection +- Provide timeline overview +- Describe candidacy process +- Describe voting eligibility +- Link to references from kata-containers/community +- Example email from an earlier cycle: [draft Etherpad](https://etherpad.opendev.org/p/r.256a531373da9595cf4c3af45bd58782) + +During the AC Candidacy round: +- Election officials review the nominations on GitHub +- A couple of days before the candidacy submission ends send + reminders to the mailing list and Slack + - Mention this is the last call for candidate nomination + - Mention specifically the nomination deadline, and the + full timeline + - Example email from an earlier cycle: + [September 2020 Kata Containers Architecture Committee elections candidate nomination reminder](https://lists.katacontainers.io/pipermail/kata-dev/2020-September/001512.html) + +When AC Candidacy submission ends: + +- Send Kata AC election - Nomination period ended email + +Once the email deadline is reached: + +- Check if there are enough candidate to run the election + - If yes, generate the electorate rolls and move forward with + the next steps of the process + - If not, reach out to the AC and have the active members + (whose seats are not up for re-election) officiate the results + before the last steps of administration + +# AC Campaigning +The AC election includes a period after the candidates are defined +but before the election, for candidates to answer questions from +the community. + +The questions will be hosted in the Community repo's +[discussions board](https://github.com/kata-containers/community/discussions) +and tagged with the election date/name for ease of searching. + +Open this with Kata AC election - Campaign period started email, and +also announce it on Slack. + +# AC Election Round +Before AC Election begins: + +- Create CIVS page + - Title the poll:

Kata Architecture Committee Election Poll + - Enable detailed ballot reporting + - Send to other officials to verify + - Check number of seats + - Check closing date + + +When AC Election begins: + +- Upload rolls +- CIVS has a maximum number of electorate emails you can upload at a time without + crashing, limit to 500 at a time +- Send Kata AC election - Voting period started email, and announce the start + of the voting period on Slack + +A couple of days before the AC Election ends: + +- Send Kata AC election - Voting period started reminder email and Slack + note + +Ending the Kata AC Election: + +- Close the election and send Kata AC election - Voting period ended email, and + announcement on Slack +- Update the list of AC members and their terms on GitHub and create a PR +- Send Kata AC Election Results email and Slack update diff --git a/elections/tools/README.md b/elections/tools/README.md new file mode 100644 index 0000000000..dfce4dbbe2 --- /dev/null +++ b/elections/tools/README.md @@ -0,0 +1,64 @@ + +# Election Tools + +This directory contains tools that can help generate the Kata Containers eligible +electorate details. + +## `generate_electorate.py` + +The `generate_electorate.py` tool gathers data from GitHub and generates a `YAML` +dataset containing the details of the eligible electorate for a defined date range. + +This tool needs the following python libraries: + +* `pytz` +* `github3.py` +* `pyyaml` + +To install them in a virtual environment do something like: + +```bash +$ python3 -m venv .venv +$ .venv/bin/pip install pytz github3.py pyyaml +``` + +Before running the tool you will need to create a +[GitHub API token](https://github.blog/2013-05-16-personal-api-tokens/) + +replace `__API_TOKEN__` in the script with your personal token. + +Also update the election start and end times to cover the period being +examined for this election period. The lines to edit look like: + +```python +start_time = datetime.datetime(2018, 1, 1, 0, 0, 0, tzinfo=pytz.UTC) +end_time = datetime.datetime(2018, 8, 1, 0, 0, 0, tzinfo=pytz.UTC) +``` + +Then run the tool with: + +```bash +$ .venv/bin/python ./generate_electorate.py +``` + +The code looks at all commits in all Kata Containers repos *except* +`kata-containers/linux` and `kata-containers/qemu`. As both of these are forks +(in the GitHub sense) they'll have lots of contributors that may not be Kata +contributors. + +For contributors that have more than one email address it picks one as default +but supplies all the others so we can be smarter about where to send the +emails. + +The sources for email addresses are: +* GitHub account +* Git commit data +* Look for a `Signed-Off-By` line in the commit message + +The GitHub login is always stored so that is the primary identifier. + +## Output results + +As the script runs it prints a summary on `stdout`. When the script has completed it places the +generated data into a file called `electorate.yaml`. Use this file to send the bulk email notification +to the eligible electorate. diff --git a/elections/tools/generate_electorate.py b/elections/tools/generate_electorate.py new file mode 100755 index 0000000000..b6e5418079 --- /dev/null +++ b/elections/tools/generate_electorate.py @@ -0,0 +1,178 @@ +#!/usr/bin/env python3 + +# +# Copyright (c) 2023 Kata Contributors +# +# SPDX-License-Identifier: Apache-2.0 +# +# Description: Generate a list of kata contributors by extracting contact +# information from GitHub + +import datetime +import pytz +import re +import yaml + +from collections import OrderedDict +from github3 import login + + +class AuthorSet(set): + pass + + +def _authorset_representer(dumper, data): + return dumper.represent_list(sorted(list(data))) + + +class Author(object): + def __init__(self, id, name=None, email=None): + self.id = id + self.name = name + self._emails = set() + if email: + self._emails.add(email) + self.commit_count = 0 + + @property + def email(self): + emails = list(self._emails or []) + if emails: + # This is horrible simplistic and probably wont work long term. + return sorted(emails)[0] + return None + + @email.setter + def email(self, email): + self._emails.add(email) + + def __eq__(self, other): + return self.id == other.id + + def __lt__(self, other): + return self.id < other.id + + def __hash__(self): + return hash(self.id) + + +def _author_representer(dumper, data): + o_dict = OrderedDict(github_id=data.id, + name=data.name, + email=data.email, + # _emails is a private member and we probably + # shouldn't do this but it might be needed for + # post-processing + emails=list(data._emails), + commit_count=data.commit_count) + return dumper.represent_dict(o_dict.items()) + + +dco_re = re.compile('signed.off.by[: ]*(?P[^<]*)<(?P.*)>$', + re.IGNORECASE | re.MULTILINE) +# Get a token GitHub Personal API token see: +# https://blog.github.com/2013-05-16-personal-api-tokens/ +# for more information. +gh = login(token='__API_TOKEN__') +org = gh.organization('kata-containers') +# Example dates for testing. +start_time = datetime.datetime(2018, 1, 1, 0, 0, 0, tzinfo=pytz.UTC) +end_time = datetime.datetime(2018, 8, 1, 0, 0, 0, tzinfo=pytz.UTC) +# ... Or run just include all commits +# start_time = end_time = None +# All commits +number = -1 +projects = [] +ignored_repos = [ + 'cgroups-rs', + 'dbs-snapshot', + 'edk2', + 'qemu', + 'linux', + 'project-infra', + 'govmm', + 'resolve-pr-refs', + 'is-organization-member', + 'osbuilder', + 'proxy', + 'runtime', + 'shim', + 'packaging', + 'ksm-throttler', + 'documentation', + 'agent', + 'slash-command-action', + 'tests-1', + 'kata-containers-github-actions-tests', + 'kata-containers-cache-kernel', + 'kata-containers-2', + 'kata-containers-1', + ] + +author_cache = {} +for repo in org.repositories(): + # Skip these repos as they are not a core part of the project, and are + # forked/imported so contain many contributors from outside the project. + if str(repo).split("/")[1] in ignored_repos: + print('Skipping repo %s' % (repo)) + continue + print('Looking for changes in %s between %s and %s' % + (repo, start_time, end_time)) + + authors = AuthorSet() + for branch in repo.branches(): + for commit in repo.commits(sha=branch.name, since=start_time, until=end_time, + number=number): + if commit.author is None: + if commit.commit.author is None: + print('Skipping %s in %s as it has no author. Did this merge via GitHub?' % + (commit, repo)) + continue + + author_id = commit.commit.author.get('email') + print('%s in %s as has no author. Using email (%s) as the author id' % + (commit, repo, author_id)) + else: + author_id = commit.author.login + + if author_id not in author_cache: + if commit.author is None: + author = Author(author_id, email=author_id, + name=commit.commit.author.get('name')) + else: + _author = gh.user(commit.author.login) + author = Author(_author.login, email=_author.email, + name=_author.name) + + author_cache[author_id] = author + + author = author_cache[author_id] + author.commit_count += 1 + + # If the GitHub account doesn't have a name or email address + # the author *may* have included it in their git config. + if author.email is None and commit.commit.author.get('email'): + author.email = commit.commit.author.get('email') + if author.name is None and commit.commit.author.get('name'): + author.name = commit.commit.author.get('name') + + # last ditch effort did the author use a valid email address in the + # DCO line? + match = dco_re.search(commit.message) + if match: + if ((author.email is None or + 'users.noreply.github.com' in author.email) and + match.group('email')): + author.email = match.group('email') + if author.name is None and match.group('name'): + author.name = match.group('name') + authors.add(author) + projects.append({str(repo): authors}) + +# Dark YAML voodoo +yaml.Dumper.ignore_aliases = lambda *args: True +yaml.Dumper.add_representer(AuthorSet, _authorset_representer) +yaml.Dumper.add_representer(Author, _author_representer) +with open('electorate.yaml', 'w') as f: + yaml.dump(projects, f, default_flow_style=False, default_style='', + explicit_start=True) diff --git a/fig1-ci-cd-failure.png b/fig1-ci-cd-failure.png new file mode 100644 index 0000000000..9656aec381 Binary files /dev/null and b/fig1-ci-cd-failure.png differ diff --git a/fig2-ci-cd-log.png b/fig2-ci-cd-log.png new file mode 100644 index 0000000000..0f5714c111 Binary files /dev/null and b/fig2-ci-cd-log.png differ diff --git a/src/runtime/pkg/containerd-shim-v2/container.go b/src/runtime/pkg/containerd-shim-v2/container.go index d23a05e300..ae3562a27e 100644 --- a/src/runtime/pkg/containerd-shim-v2/container.go +++ b/src/runtime/pkg/containerd-shim-v2/container.go @@ -26,6 +26,7 @@ type container struct { exitIOch chan struct{} stdinPipe io.WriteCloser stdinCloser chan struct{} + stdioCloser chan struct{} exitCh chan uint32 id string stdin string @@ -64,6 +65,7 @@ func newContainer(s *service, r *taskAPI.CreateTaskRequest, containerType vc.Con exitIOch: make(chan struct{}), exitCh: make(chan uint32, 1), stdinCloser: make(chan struct{}), + stdioCloser: make(chan struct{}), mounted: mounted, } return c, nil diff --git a/src/runtime/pkg/containerd-shim-v2/exec.go b/src/runtime/pkg/containerd-shim-v2/exec.go index 5ebdbfa434..aedeca0dda 100644 --- a/src/runtime/pkg/containerd-shim-v2/exec.go +++ b/src/runtime/pkg/containerd-shim-v2/exec.go @@ -31,6 +31,7 @@ type exec struct { exitIOch chan struct{} stdinCloser chan struct{} + stdioCloser chan struct{} exitCh chan uint32 @@ -125,6 +126,7 @@ func newExec(c *container, stdin, stdout, stderr string, terminal bool, jspec *a exitCode: exitCode255, exitIOch: make(chan struct{}), stdinCloser: make(chan struct{}), + stdioCloser: make(chan struct{}), exitCh: make(chan uint32, 1), status: task.Status_CREATED, } diff --git a/src/runtime/pkg/containerd-shim-v2/service.go b/src/runtime/pkg/containerd-shim-v2/service.go index ec82063e41..9f92a764f2 100644 --- a/src/runtime/pkg/containerd-shim-v2/service.go +++ b/src/runtime/pkg/containerd-shim-v2/service.go @@ -889,15 +889,21 @@ func (s *service) CloseIO(ctx context.Context, r *taskAPI.CloseIORequest) (_ *em }() s.mu.Lock() - defer s.mu.Unlock() + isServiceMutexLocked := true + defer func() { + if isServiceMutexLocked { + s.mu.Unlock() + } + }() c, err := s.getContainer(r.ID) if err != nil { return nil, err } - stdin := c.stdinPipe - stdinCloser := c.stdinCloser + var stdin io.WriteCloser + var stdinCloser <-chan struct{} + var stdioCloser <-chan struct{} if r.ExecID != "" { execs, err := c.getExec(r.ExecID) @@ -906,8 +912,18 @@ func (s *service) CloseIO(ctx context.Context, r *taskAPI.CloseIORequest) (_ *em } stdin = execs.stdinPipe stdinCloser = execs.stdinCloser + stdioCloser = execs.stdioCloser + } else { + stdin = c.stdinPipe + stdinCloser = c.stdinCloser + stdioCloser = c.stdioCloser } + // Unlocking before the end as this is preventing + // the service to run other execs until it has answer the current call + s.mu.Unlock() + isServiceMutexLocked = false + // wait until the stdin io copy terminated, otherwise // some contents would not be forwarded to the process. <-stdinCloser @@ -915,6 +931,10 @@ func (s *service) CloseIO(ctx context.Context, r *taskAPI.CloseIORequest) (_ *em return nil, errors.Wrap(err, "close stdin") } + // wait until the whole iocopy process to be over + // to return the response + <-stdioCloser + return empty, nil } diff --git a/src/runtime/pkg/containerd-shim-v2/start.go b/src/runtime/pkg/containerd-shim-v2/start.go index b4f023ab29..c2e1e149fb 100644 --- a/src/runtime/pkg/containerd-shim-v2/start.go +++ b/src/runtime/pkg/containerd-shim-v2/start.go @@ -82,7 +82,7 @@ func startContainer(ctx context.Context, s *service, c *container) (retErr error } c.ttyio = tty - go ioCopy(shimLog.WithField("container", c.id), c.exitIOch, c.stdinCloser, tty, stdin, stdout, stderr) + go ioCopy(shimLog.WithField("container", c.id), c.exitIOch, c.stdinCloser, c.stdioCloser, tty, stdin, stdout, stderr) } else { // close the io exit channel, since there is no io for this container, // otherwise the following wait goroutine will hang on this channel. @@ -151,7 +151,7 @@ func startExec(ctx context.Context, s *service, containerID, execID string) (e * go ioCopy(shimLog.WithFields(logrus.Fields{ "container": c.id, "exec": execID, - }), execs.exitIOch, execs.stdinCloser, tty, stdin, stdout, stderr) + }), execs.exitIOch, execs.stdinCloser, execs.stdioCloser, tty, stdin, stdout, stderr) go wait(ctx, s, c, execID) diff --git a/src/runtime/pkg/containerd-shim-v2/stream.go b/src/runtime/pkg/containerd-shim-v2/stream.go index 123c1c1148..142db1874b 100644 --- a/src/runtime/pkg/containerd-shim-v2/stream.go +++ b/src/runtime/pkg/containerd-shim-v2/stream.go @@ -101,7 +101,7 @@ func newTtyIO(ctx context.Context, ns, id, stdin, stdout, stderr string, console }, nil } -func ioCopy(shimLog *logrus.Entry, exitch, stdinCloser chan struct{}, tty *ttyIO, stdinPipe io.WriteCloser, stdoutPipe, stderrPipe io.Reader) { +func ioCopy(shimLog *logrus.Entry, exitch, stdinCloser, stdioCloser chan struct{}, tty *ttyIO, stdinPipe io.WriteCloser, stdoutPipe, stderrPipe io.Reader) { var wg sync.WaitGroup if tty.io.Stdin() != nil { @@ -149,6 +149,7 @@ func ioCopy(shimLog *logrus.Entry, exitch, stdinCloser chan struct{}, tty *ttyIO wg.Wait() tty.close() + close(stdioCloser) close(exitch) shimLog.Debug("all io stream copy goroutines exited") } diff --git a/src/runtime/pkg/containerd-shim-v2/stream_test.go b/src/runtime/pkg/containerd-shim-v2/stream_test.go index c85633c884..4bde484231 100644 --- a/src/runtime/pkg/containerd-shim-v2/stream_test.go +++ b/src/runtime/pkg/containerd-shim-v2/stream_test.go @@ -130,6 +130,7 @@ func TestIoCopy(t *testing.T) { exitioch := make(chan struct{}) stdinCloser := make(chan struct{}) + stdioCloser := make(chan struct{}) createFifo := func(f string) (io.ReadCloser, io.WriteCloser) { reader, err := fifo.OpenFifo(ctx, f, syscall.O_RDONLY|syscall.O_CREAT|syscall.O_NONBLOCK, 0700) @@ -182,7 +183,7 @@ func TestIoCopy(t *testing.T) { defer tty.close() // start the ioCopy threads : copy from src to dst - go ioCopy(logrus.WithContext(context.Background()), exitioch, stdinCloser, tty, dstInW, srcOutR, srcErrR) + go ioCopy(logrus.WithContext(context.Background()), exitioch, stdinCloser, stdioCloser, tty, dstInW, srcOutR, srcErrR) var firstW, secondW, thirdW io.WriteCloser var firstR, secondR, thirdR io.Reader diff --git a/src/runtime/pkg/containerd-shim-v2/wait.go b/src/runtime/pkg/containerd-shim-v2/wait.go index 272fbb22aa..7ebcdb7543 100644 --- a/src/runtime/pkg/containerd-shim-v2/wait.go +++ b/src/runtime/pkg/containerd-shim-v2/wait.go @@ -62,13 +62,13 @@ func wait(ctx context.Context, s *service, c *container, execID string) (int32, timeStamp := time.Now() - s.mu.Lock() if execID == "" { + s.mu.Lock() + // Take care of the use case where it is a sandbox. // Right after the container representing the sandbox has // been deleted, let's make sure we stop and delete the // sandbox. - if c.cType.IsSandbox() { // cancel watcher if s.monitor != nil { @@ -93,6 +93,7 @@ func wait(ctx context.Context, s *service, c *container, execID string) (int32, c.exitCh <- uint32(ret) shimLog.WithField("container", c.id).Debug("The container status is StatusStopped") + s.mu.Unlock() } else { execs.status = task.Status_STOPPED execs.exitCode = ret @@ -104,7 +105,6 @@ func wait(ctx context.Context, s *service, c *container, execID string) (int32, "exec": execID, }).Debug("The container exec status is StatusStopped") } - s.mu.Unlock() go cReap(s, int(ret), c.id, execID, timeStamp) diff --git a/statusreports/REPORT_TEMPLATE.md b/statusreports/REPORT_TEMPLATE.md new file mode 100644 index 0000000000..fc9576f60a --- /dev/null +++ b/statusreports/REPORT_TEMPLATE.md @@ -0,0 +1,16 @@ +# [YYYY-MM-DD] Week in Review + +### Notable Pull Requests/Issues + +- Was something significant merged in the last week? [Resolves #115](https://example.com/resolved/pull/request) +- Was a PR submitted for a significant change? [In Progress #120](https://example.com/pull/request) +- Is there new/dynamic conversation happening about a PR/issue that readers should look at? [Issue #100](https://example.com/open/issue) + +### Mailing List Discussions + +- Discussions happening that readers should look at (summarize and point to ML archives) + +### Community Updates + +- Is someone presenting a talk? +- Noteworthy Kata news? (i.e. "Became an OCI member this week")