From a4d5bc4b2b4b3d9ab34ae2cdf7f6a3f5c5f6158f Mon Sep 17 00:00:00 2001 From: mesutoezdil Date: Thu, 7 May 2026 21:06:05 +0200 Subject: [PATCH] docs: remove filler words and first-person from versioned doc snapshots Apply consistent style cleanup across all versioned_docs (v1.3.0-v2.8.0): - Remove filler phrases: 'Note that', 'Please note', 'In summary' - Replace first-person 'we/our' with third-person or passive voice - Remove emoji from adopters.md template text - 107 files across 7 versions Signed-off-by: mesutoezdil --- .../contributor/contributing.md | 10 ++++----- .../version-v1.3.0/contributor/governance.md | 4 ++-- .../version-v1.3.0/contributor/ladder.md | 4 ++-- .../version-v1.3.0/developers/dynamic-mig.md | 6 ++--- .../version-v1.3.0/developers/scheduling.md | 8 +++---- .../get-started/nginx-example.md | 4 ++-- .../installation/prerequisites.md | 2 +- .../enable-cambricon-mlu-sharing.md | 2 +- .../version-v1.3.0/userguide/configure.md | 2 +- .../userguide/monitoring/device-allocation.md | 2 +- .../examples/specify-card-type-to-use.md | 4 ++-- .../contributor/cherry-picks.md | 2 +- .../contributor/contribute-docs.md | 22 +++++++++---------- .../contributor/contributing.md | 10 ++++----- .../version-v2.4.1/contributor/governance.md | 4 ++-- .../version-v2.4.1/contributor/ladder.md | 4 ++-- .../version-v2.4.1/developers/dynamic-mig.md | 6 ++--- .../version-v2.4.1/developers/scheduling.md | 8 +++---- .../get-started/nginx-example.md | 4 ++-- .../installation/prerequisites.md | 2 +- .../enable-cambricon-mlu-sharing.md | 2 +- .../version-v2.4.1/userguide/configure.md | 2 +- .../userguide/monitoring/device-allocation.md | 2 +- .../examples/specify-card-type-to-use.md | 4 ++-- .../version-v2.5.0/contributor/adopters.md | 6 ++--- .../contributor/cherry-picks.md | 2 +- .../contributor/contribute-docs.md | 22 +++++++++---------- .../contributor/contributing.md | 10 ++++----- .../version-v2.5.0/contributor/governance.md | 4 ++-- .../version-v2.5.0/contributor/ladder.md | 4 ++-- .../version-v2.5.0/developers/dynamic-mig.md | 6 ++--- .../version-v2.5.0/developers/scheduling.md | 8 +++---- .../get-started/nginx-example.md | 4 ++-- .../installation/prerequisites.md | 2 +- .../enable-cambricon-mlu-sharing.md | 2 +- .../version-v2.5.0/userguide/configure.md | 2 +- .../enable-enflame-gpu-sharing.md | 6 ++--- .../enable-iluvatar-gpu-sharing.md | 2 +- .../userguide/monitoring/device-allocation.md | 2 +- .../examples/specify-card-type-to-use.md | 4 ++-- .../version-v2.5.1/contributor/adopters.md | 6 ++--- .../contributor/cherry-picks.md | 2 +- .../contributor/contribute-docs.md | 22 +++++++++---------- .../contributor/contributing.md | 10 ++++----- .../version-v2.5.1/contributor/governance.md | 4 ++-- .../version-v2.5.1/contributor/ladder.md | 4 ++-- .../version-v2.5.1/developers/dynamic-mig.md | 6 ++--- .../version-v2.5.1/developers/scheduling.md | 8 +++---- .../get-started/nginx-example.md | 4 ++-- .../installation/prerequisites.md | 2 +- .../enable-cambricon-mlu-sharing.md | 2 +- .../userguide/monitoring/device-allocation.md | 2 +- .../nvidia-device/dynamic-mig-support.md | 2 +- .../examples/specify-card-type-to-use.md | 4 ++-- .../version-v2.6.0/contributor/adopters.md | 6 ++--- .../contributor/cherry-picks.md | 2 +- .../contributor/contribute-docs.md | 22 +++++++++---------- .../contributor/contributing.md | 10 ++++----- .../version-v2.6.0/contributor/governance.md | 4 ++-- .../version-v2.6.0/contributor/ladder.md | 4 ++-- .../version-v2.6.0/developers/dynamic-mig.md | 6 ++--- .../version-v2.6.0/developers/protocol.md | 2 +- .../version-v2.6.0/developers/scheduling.md | 12 +++++----- versioned_docs/version-v2.6.0/faq/faq.md | 4 ++-- .../get-started/nginx-example.md | 4 ++-- .../installation/prerequisites.md | 2 +- .../enable-enflame-gcu-sharing.md | 6 ++--- .../enable-illuvatar-gpu-sharing.md | 2 +- .../metax-gpu/enable-metax-gpu-schedule.md | 2 +- .../metax-sgpu/enable-metax-gpu-sharing.md | 2 +- .../userguide/monitoring/device-allocation.md | 2 +- .../nvidia-device/dynamic-mig-support.md | 2 +- .../examples/specify-card-type-to-use.md | 4 ++-- .../version-v2.7.0/contributor/adopters.md | 6 ++--- .../contributor/cherry-picks.md | 2 +- .../contributor/contribute-docs.md | 22 +++++++++---------- .../contributor/contributing.md | 10 ++++----- .../version-v2.7.0/contributor/governance.md | 4 ++-- .../version-v2.7.0/contributor/ladder.md | 4 ++-- .../version-v2.7.0/developers/dynamic-mig.md | 6 ++--- .../version-v2.7.0/developers/protocol.md | 2 +- .../version-v2.7.0/developers/scheduling.md | 8 +++---- versioned_docs/version-v2.7.0/faq/faq.md | 4 ++-- .../get-started/deploy-with-helm.md | 4 ++-- .../installation/prerequisites.md | 2 +- .../enable-enflame-gcu-sharing.md | 6 ++--- .../enable-illuvatar-gpu-sharing.md | 2 +- .../userguide/monitoring/device-allocation.md | 2 +- .../nvidia-device/dynamic-mig-support.md | 2 +- .../examples/specify-card-type-to-use.md | 4 ++-- .../version-v2.8.0/contributor/adopters.md | 6 ++--- .../contributor/cherry-picks.md | 2 +- .../contributor/contribute-docs.md | 22 +++++++++---------- .../contributor/contributing.md | 10 ++++----- .../version-v2.8.0/contributor/governance.md | 4 ++-- .../version-v2.8.0/contributor/ladder.md | 4 ++-- .../version-v2.8.0/developers/dynamic-mig.md | 6 ++--- .../version-v2.8.0/developers/protocol.md | 2 +- .../version-v2.8.0/developers/scheduling.md | 8 +++---- versioned_docs/version-v2.8.0/faq/faq.md | 4 ++-- .../get-started/deploy-with-helm.md | 4 ++-- .../installation/prerequisites.md | 2 +- .../enable-enflame-gcu-sharing.md | 6 ++--- .../enable-illuvatar-gpu-sharing.md | 2 +- .../userguide/monitoring/device-allocation.md | 2 +- .../nvidia-device/dynamic-mig-support.md | 2 +- .../examples/specify-card-type-to-use.md | 4 ++-- 107 files changed, 281 insertions(+), 281 deletions(-) diff --git a/versioned_docs/version-v1.3.0/contributor/contributing.md b/versioned_docs/version-v1.3.0/contributor/contributing.md index fab6d31c..796c8e36 100644 --- a/versioned_docs/version-v1.3.0/contributor/contributing.md +++ b/versioned_docs/version-v1.3.0/contributor/contributing.md @@ -6,7 +6,7 @@ Welcome to HAMi! ## Code of Conduct -Please make sure to read and observe our [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) +Please make sure to read and observe the [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) ## Community Expectations @@ -20,7 +20,7 @@ HAMi is a community project driven by its community which strives to promote a h ## Your First Contribution -We will help you to contribute in different areas like filing issues, developing features, fixing critical bugs and +Help is available for contributing in areas like filing issues, developing features, fixing critical bugs and getting your work reviewed and merged. If you have questions about the development process, @@ -28,7 +28,7 @@ feel free to [file an issue](https://github.com/Project-HAMi/HAMi/issues/new/cho ## Find something to work on -We are always in need of help, be it fixing documentation, reporting bugs or writing some code. +Contributions are always welcome - fixing documentation, reporting bugs or writing some code. Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing. Here is how you get started. @@ -40,7 +40,7 @@ For example, [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi) has [help wanted](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) and [good first issue](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) labels for issues that should not need deep knowledge of the system. -We can help new contributors who wish to work on such issues. +Maintainers can help new contributors who wish to work on such issues. Another good way to contribute is to find a documentation improvement, such as a missing/broken link. Please see [Contributor Workflow](#contributor-workflow) below for the workflow. @@ -51,7 +51,7 @@ When you are willing to take on an issue, just reply on the issue. The maintaine ### File an Issue -While we encourage everyone to contribute code, it is also appreciated when someone reports an issue. +Code contributions are welcome, and bug reports are equally appreciated. Issues should be filed under the appropriate HAMi sub-repository. *Example:* a HAMi issue should be opened to [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi/issues). diff --git a/versioned_docs/version-v1.3.0/contributor/governance.md b/versioned_docs/version-v1.3.0/contributor/governance.md index f49b23b7..94c265e7 100644 --- a/versioned_docs/version-v1.3.0/contributor/governance.md +++ b/versioned_docs/version-v1.3.0/contributor/governance.md @@ -15,11 +15,11 @@ The HAMi and its leadership embrace the following values: * Fairness: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits. -* Community over Product or Company: Sustaining and growing our community takes +* Community over Product or Company: Sustaining and growing the community takes priority over shipping code or sponsors' organizational goals. Each contributor participates in the project as an individual. -* Inclusivity: We innovate through different perspectives and skill sets, which +* Inclusivity: Innovation happens through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment. * Participation: Responsibilities within the project are earned through diff --git a/versioned_docs/version-v1.3.0/contributor/ladder.md b/versioned_docs/version-v1.3.0/contributor/ladder.md index 68ee4d27..2994f5e9 100644 --- a/versioned_docs/version-v1.3.0/contributor/ladder.md +++ b/versioned_docs/version-v1.3.0/contributor/ladder.md @@ -4,7 +4,7 @@ title: Contributor Ladder This docs different ways to get involved and level up within the project. You can see different roles within the project in the contributor roles. -Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. +This contributor ladder outlines the different contributor roles within the project. Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. @@ -126,7 +126,7 @@ The current list of maintainers can be found in the [MAINTAINERS](https://github ## An active maintainer should -* Actively participate in reviewing pull requests and incoming issues. Note that there are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. +* Actively participate in reviewing pull requests and incoming issues. There are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. * Actively participate in discussions about design and the future of the project. diff --git a/versioned_docs/version-v1.3.0/developers/dynamic-mig.md b/versioned_docs/version-v1.3.0/developers/dynamic-mig.md index ccdde8a9..813259f8 100644 --- a/versioned_docs/version-v1.3.0/developers/dynamic-mig.md +++ b/versioned_docs/version-v1.3.0/developers/dynamic-mig.md @@ -10,8 +10,8 @@ This feature will not be implemented without the help of @sailorvii. ## Introduction -The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, so we chose the MPS and MIG. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. We want to develop an automatic slice plugin and create the slice when the user require it. -For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, we consider the CPU, Mem, GPU memory and other user-defined resource. +The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, MPS and MIG were chosen. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. An automatic slice plugin is planned to create slices on demand. +For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, CPU, Mem, GPU memory, and other user-defined resources are considered. HAMi is done by using [hami-core](https://github.com/Project-HAMi/HAMi-core), which is a cuda-hacking library. But mig is also widely used across the world. A unified API for dynamic-mig and hami-core is needed. ## Targets @@ -150,7 +150,7 @@ The Procedure of a vGPU task which uses dynamic-mig is shown below: HAMi dynamic MIG procedure flowchart showing task scheduling process -Note that after submitted a task, deviceshare plugin will iterate over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. +After submitting a task, the deviceshare plugin iterates over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. If you submit the example on an empty A100-PCIE-40GB node, then it will select a GPU and choose MIG template below: diff --git a/versioned_docs/version-v1.3.0/developers/scheduling.md b/versioned_docs/version-v1.3.0/developers/scheduling.md index 02270146..9f44e903 100644 --- a/versioned_docs/version-v1.3.0/developers/scheduling.md +++ b/versioned_docs/version-v1.3.0/developers/scheduling.md @@ -104,7 +104,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Binpack` policy we can select `Node1`. +So, in `Binpack` policy the scheduler selects `Node1`. #### Spread @@ -124,7 +124,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Spread` policy we can select `Node2`. +So, in `Spread` policy the scheduler selects `Node2`. ### GPU-scheduler-policy @@ -147,7 +147,7 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Binpack` policy we can select `GPU2`. +So, in `Binpack` policy the scheduler selects `GPU2`. #### Spread @@ -166,4 +166,4 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Spread` policy we can select `GPU1`. +So, in `Spread` policy the scheduler selects `GPU1`. diff --git a/versioned_docs/version-v1.3.0/get-started/nginx-example.md b/versioned_docs/version-v1.3.0/get-started/nginx-example.md index 8bf574bc..b82231ce 100644 --- a/versioned_docs/version-v1.3.0/get-started/nginx-example.md +++ b/versioned_docs/version-v1.3.0/get-started/nginx-example.md @@ -92,7 +92,7 @@ sudo systemctl daemon-reload && systemctl restart containerd #### 2. Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ``` kubectl label nodes {nodeid} gpu=on @@ -106,7 +106,7 @@ First, you need to check your Kubernetes version by using the following command: kubectl version ``` -Then, add our repo in helm +Then, add the HAMi repo in helm ``` helm repo add hami-charts https://project-hami.github.io/HAMi/ diff --git a/versioned_docs/version-v1.3.0/installation/prerequisites.md b/versioned_docs/version-v1.3.0/installation/prerequisites.md index 13666bb8..4e52d10e 100644 --- a/versioned_docs/version-v1.3.0/installation/prerequisites.md +++ b/versioned_docs/version-v1.3.0/installation/prerequisites.md @@ -82,7 +82,7 @@ sudo systemctl daemon-reload && systemctl restart containerd ### Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ``` kubectl label nodes {nodeid} gpu=on diff --git a/versioned_docs/version-v1.3.0/userguide/cambricon-device/enable-cambricon-mlu-sharing.md b/versioned_docs/version-v1.3.0/userguide/cambricon-device/enable-cambricon-mlu-sharing.md index ae498abe..d446a30c 100644 --- a/versioned_docs/version-v1.3.0/userguide/cambricon-device/enable-cambricon-mlu-sharing.md +++ b/versioned_docs/version-v1.3.0/userguide/cambricon-device/enable-cambricon-mlu-sharing.md @@ -12,7 +12,7 @@ title: Enable cambricon MLU sharing ***MLU Type Specification***: You can specify which type of MLU to use or to avoid for a certain task, by setting "cambricon.com/use-mlutype" or "cambricon.com/nouse-mlutype" annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your MLU jobs will be automatically supported after installation. The only thing you need to do is tag the MLU node. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your MLU jobs will be automatically supported after installation. The only thing you need to do is tag the MLU node. ## Prerequisites diff --git a/versioned_docs/version-v1.3.0/userguide/configure.md b/versioned_docs/version-v1.3.0/userguide/configure.md index 8e3a34f3..23abea99 100644 --- a/versioned_docs/version-v1.3.0/userguide/configure.md +++ b/versioned_docs/version-v1.3.0/userguide/configure.md @@ -18,7 +18,7 @@ You can update these configurations using one of the following methods: 2. Modify Helm Chart: Update the corresponding values in the [ConfigMap](https://raw.githubusercontent.com/archlitchi/HAMi/refs/heads/master/charts/hami/templates/scheduler/device-configmap.yaml), then reapply the Helm Chart to regenerate the ConfigMap. * `nvidia.deviceMemoryScaling:` - Float type, by default: 1. The ratio for NVIDIA device memory scaling, can be greater than 1 (enable virtual device memory, experimental feature). For NVIDIA GPU with *M* memory, if we set `nvidia.deviceMemoryScaling` argument to *S*, vGPUs split by this GPU will totally get `S * M` memory in Kubernetes with our device plugin. + Float type, by default: 1. The ratio for NVIDIA device memory scaling, can be greater than 1 (enable virtual device memory, experimental feature). For NVIDIA GPU with *M* memory, if `nvidia.deviceMemoryScaling` is set to *S*, vGPUs split by this GPU will totally get `S * M` memory in Kubernetes with the HAMi device plugin. * `nvidia.deviceSplitCount:` Integer type, by default: equals 10. Maximum tasks assigned to a simple GPU device. * `nvidia.migstrategy:` diff --git a/versioned_docs/version-v1.3.0/userguide/monitoring/device-allocation.md b/versioned_docs/version-v1.3.0/userguide/monitoring/device-allocation.md index 94bbf0a5..c86b1a3e 100644 --- a/versioned_docs/version-v1.3.0/userguide/monitoring/device-allocation.md +++ b/versioned_docs/version-v1.3.0/userguide/monitoring/device-allocation.md @@ -21,4 +21,4 @@ It contains the following metrics: | GPUDeviceSharedNum | Number of containers sharing this GPU | `{deviceidx="0",deviceuuid="GPU-00552014-5c87-89ac-b1a6-7b53aa24b0ec",nodeid="aio-node67",zone="vGPU"}` 1 | | vGPUPodsDeviceAllocated | vGPU Allocated from pods | `{containeridx="Ascend310P",deviceusedcore="0",deviceuuid="aio-node74-arm-Ascend310P-0",nodename="aio-node74-arm",podname="ascend310p-pod",podnamespace="default",zone="vGPU"}` 3.221225472e+09 | -> **Note** Please note that, this is the overview about device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file +> **Note** This is an overview of device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file diff --git a/versioned_docs/version-v1.3.0/userguide/nvidia-device/examples/specify-card-type-to-use.md b/versioned_docs/version-v1.3.0/userguide/nvidia-device/examples/specify-card-type-to-use.md index 397e984f..ebab2615 100644 --- a/versioned_docs/version-v1.3.0/userguide/nvidia-device/examples/specify-card-type-to-use.md +++ b/versioned_docs/version-v1.3.0/userguide/nvidia-device/examples/specify-card-type-to-use.md @@ -13,7 +13,7 @@ metadata: name: gpu-pod annotations: nvidia.com/use-gputype: "A100,V100" - #In this example, we want to run this job on A100 or V100 + #In this example, the job should run on A100 or V100 spec: containers: - name: ubuntu-container @@ -24,4 +24,4 @@ spec: nvidia.com/gpu: 2 # requesting 2 vGPUs ``` -> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, we want to run this job on A100 or V100* +> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, the job should run on A100 or V100* diff --git a/versioned_docs/version-v2.4.1/contributor/cherry-picks.md b/versioned_docs/version-v2.4.1/contributor/cherry-picks.md index 80a58e56..c3edd9eb 100644 --- a/versioned_docs/version-v2.4.1/contributor/cherry-picks.md +++ b/versioned_docs/version-v2.4.1/contributor/cherry-picks.md @@ -62,7 +62,7 @@ your case by supplementing your PR with e.g., - Key stakeholder reviewers/approvers attesting to their confidence in the change being a required backport -It is critical that our full community is actively engaged on enhancements in +It is critical that the full community is actively engaged on enhancements in the project. If a released feature was not enabled on a particular provider's platform, this is a community miss that needs to be resolved in the `master` branch for subsequent releases. Such enabling will not be backported to the diff --git a/versioned_docs/version-v2.4.1/contributor/contribute-docs.md b/versioned_docs/version-v2.4.1/contributor/contribute-docs.md index 5fe0302e..47d4f6ce 100644 --- a/versioned_docs/version-v2.4.1/contributor/contribute-docs.md +++ b/versioned_docs/version-v2.4.1/contributor/contribute-docs.md @@ -9,23 +9,23 @@ the `Project-HAMi/website` repository. ## Prerequisites - Docs, like codes, are also categorized and stored by version. - 1.3 is the first version we have archived. + 1.3 is the first archived version. - Docs need to be translated into multiple languages for readers from different regions. The community now supports both Chinese and English. English is the official language of documentation. -- For our docs we use markdown. If you are unfamiliar with Markdown, please see [https://guides.github.com/features/mastering-markdown/](https://guides.github.com/features/mastering-markdown/) or [https://www.markdownguide.org/](https://www.markdownguide.org/) if you are looking for something more substantial. -- We get some additions through [Docusaurus 2](https://docusaurus.io/), a model static website generator. +- The docs use markdown. If you are unfamiliar with Markdown, please see [https://guides.github.com/features/mastering-markdown/](https://guides.github.com/features/mastering-markdown/) or [https://www.markdownguide.org/](https://www.markdownguide.org/) if you are looking for something more substantial. +- The site uses [Docusaurus 2](https://docusaurus.io/), a model static website generator. ## Setup -You can set up your local environment by cloning our website repository. +Clone the website repository to set up a local environment. ```shell git clone https://github.com/Project-HAMi/website.git cd website ``` -Our website is organized like below: +The website is organized as follows: ```text website @@ -85,7 +85,7 @@ title: A doc with tags ## secondary title ``` -The top section between two lines of --- is the Front Matter section. Here we define a couple of entries which tell Docusaurus how to handle the article: +The top section between two lines of --- is the Front Matter section. The entries tell Docusaurus how to handle the article: - Title is the equivalent of the `

` in a HTML document or `# ` in a Markdown article. - Each document has a unique ID. By default, a document ID is the name of the document (without the extension) related to the root docs directory. @@ -101,7 +101,7 @@ You can easily route to other places by adding any of the following links: You can use relative paths to index the corresponding files. - Link to pictures or other resources. If your article contains images, prefer storing them in `/static/img/docs/` and linking - with absolute paths. We use language-aware folders: + with absolute paths. Language-aware folders are used: - `/static/img/docs/common/` for shared images - `/static/img/docs/en/` for English-only images - `/static/img/docs/zh/` for Chinese-only images @@ -120,7 +120,7 @@ Creating a sidebar is useful to: - Display a sidebar on each of those documents - Provide paginated navigation, with next/previous button -For our docs, you can know how our documents are organized from [https://github.com/Project-HAMi/website/blob/main/sidebars.js](https://github.com/Project-HAMi/website/blob/main/sidebars.js). +The document organization is defined in [https://github.com/Project-HAMi/website/blob/main/sidebars.js](https://github.com/Project-HAMi/website/blob/main/sidebars.js). ```js module.exports = { @@ -168,7 +168,7 @@ If you add a document, you must add it to `sidebars.js` to make it display prope There are two situations about the Chinese version of the document: -- You want to translate our existing English docs to Chinese. In this case, you need to modify the corresponding file content from [https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current](https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current). +- To translate existing English docs to Chinese: you need to modify the corresponding file content from [https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current](https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current). The organization of this directory is exactly the same as the outer layer. `current.json` holds translations for the documentation directory. You can edit it if you want to translate the name of directory. - You want to contribute Chinese docs without English version. Any articles of any kind are welcomed. In this case, you can add articles and titles to the main directory first. Article content can be TBD first, like this. Then add the corresponding Chinese content to the Chinese directory. @@ -187,5 +187,5 @@ If the previewed page is not what you expected, please check your docs again. ### Versioning -For the newly supplemented documents of each version, we will synchronize to the latest version on the release date of each version, and the documents of the old version will not be modified. -For errata found in the documentation, we will fix it with every release. +For the newly supplemented documents of each version, they are synchronized to the latest version on the release date of each version, and the documents of the old version will not be modified. +For errata found in the documentation, fixes are applied with every release. diff --git a/versioned_docs/version-v2.4.1/contributor/contributing.md b/versioned_docs/version-v2.4.1/contributor/contributing.md index fab6d31c..796c8e36 100644 --- a/versioned_docs/version-v2.4.1/contributor/contributing.md +++ b/versioned_docs/version-v2.4.1/contributor/contributing.md @@ -6,7 +6,7 @@ Welcome to HAMi! ## Code of Conduct -Please make sure to read and observe our [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) +Please make sure to read and observe the [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) ## Community Expectations @@ -20,7 +20,7 @@ HAMi is a community project driven by its community which strives to promote a h ## Your First Contribution -We will help you to contribute in different areas like filing issues, developing features, fixing critical bugs and +Help is available for contributing in areas like filing issues, developing features, fixing critical bugs and getting your work reviewed and merged. If you have questions about the development process, @@ -28,7 +28,7 @@ feel free to [file an issue](https://github.com/Project-HAMi/HAMi/issues/new/cho ## Find something to work on -We are always in need of help, be it fixing documentation, reporting bugs or writing some code. +Contributions are always welcome - fixing documentation, reporting bugs or writing some code. Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing. Here is how you get started. @@ -40,7 +40,7 @@ For example, [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi) has [help wanted](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) and [good first issue](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) labels for issues that should not need deep knowledge of the system. -We can help new contributors who wish to work on such issues. +Maintainers can help new contributors who wish to work on such issues. Another good way to contribute is to find a documentation improvement, such as a missing/broken link. Please see [Contributor Workflow](#contributor-workflow) below for the workflow. @@ -51,7 +51,7 @@ When you are willing to take on an issue, just reply on the issue. The maintaine ### File an Issue -While we encourage everyone to contribute code, it is also appreciated when someone reports an issue. +Code contributions are welcome, and bug reports are equally appreciated. Issues should be filed under the appropriate HAMi sub-repository. *Example:* a HAMi issue should be opened to [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi/issues). diff --git a/versioned_docs/version-v2.4.1/contributor/governance.md b/versioned_docs/version-v2.4.1/contributor/governance.md index f49b23b7..94c265e7 100644 --- a/versioned_docs/version-v2.4.1/contributor/governance.md +++ b/versioned_docs/version-v2.4.1/contributor/governance.md @@ -15,11 +15,11 @@ The HAMi and its leadership embrace the following values: * Fairness: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits. -* Community over Product or Company: Sustaining and growing our community takes +* Community over Product or Company: Sustaining and growing the community takes priority over shipping code or sponsors' organizational goals. Each contributor participates in the project as an individual. -* Inclusivity: We innovate through different perspectives and skill sets, which +* Inclusivity: Innovation happens through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment. * Participation: Responsibilities within the project are earned through diff --git a/versioned_docs/version-v2.4.1/contributor/ladder.md b/versioned_docs/version-v2.4.1/contributor/ladder.md index 26ea756f..26ecea39 100644 --- a/versioned_docs/version-v2.4.1/contributor/ladder.md +++ b/versioned_docs/version-v2.4.1/contributor/ladder.md @@ -4,7 +4,7 @@ title: Contributor Ladder This docs different ways to get involved and level up within the project. You can see different roles within the project in the contributor roles. -Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. +This contributor ladder outlines the different contributor roles within the project. Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. @@ -126,7 +126,7 @@ The current list of maintainers can be found in the [MAINTAINERS](https://github ## An active maintainer should -* Actively participate in reviewing pull requests and incoming issues. Note that there are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. +* Actively participate in reviewing pull requests and incoming issues. There are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. * Actively participate in discussions about design and the future of the project. diff --git a/versioned_docs/version-v2.4.1/developers/dynamic-mig.md b/versioned_docs/version-v2.4.1/developers/dynamic-mig.md index fd22875b..c1a56970 100644 --- a/versioned_docs/version-v2.4.1/developers/dynamic-mig.md +++ b/versioned_docs/version-v2.4.1/developers/dynamic-mig.md @@ -10,8 +10,8 @@ This feature will not be implemented without the help of @sailorvii. ## Introduction -The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, so we chose the MPS and MIG. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. We want to develop an automatic slice plugin and create the slice when the user require it. -For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, we consider the CPU, Mem, GPU memory and other user-defined resource. +The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, MPS and MIG were chosen. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. An automatic slice plugin is planned to create slices on demand. +For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, CPU, Mem, GPU memory, and other user-defined resources are considered. HAMi is done by using [hami-core](https://github.com/Project-HAMi/HAMi-core), which is a cuda-hacking library. But mig is also widely used across the world. A unified API for dynamic-mig and hami-core is needed. ## Targets @@ -149,7 +149,7 @@ The Procedure of a vGPU task which uses dynamic-mig is shown below: <img src="https://github.com/Project-HAMi/HAMi/blob/master/docs/develop/imgs/hami-dynamic-mig-procedure.png?raw=true" width="800" alt="HAMi dynamic MIG procedure flowchart showing task scheduling process" /> -Note that after submitted a task, deviceshare plugin will iterate over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. +After submitting a task, the deviceshare plugin iterates over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. If you submit the example on an empty A100-PCIE-40GB node, then it will select a GPU and choose MIG template below: diff --git a/versioned_docs/version-v2.4.1/developers/scheduling.md b/versioned_docs/version-v2.4.1/developers/scheduling.md index 02270146..9f44e903 100644 --- a/versioned_docs/version-v2.4.1/developers/scheduling.md +++ b/versioned_docs/version-v2.4.1/developers/scheduling.md @@ -104,7 +104,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Binpack` policy we can select `Node1`. +So, in `Binpack` policy the scheduler selects `Node1`. #### Spread @@ -124,7 +124,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Spread` policy we can select `Node2`. +So, in `Spread` policy the scheduler selects `Node2`. ### GPU-scheduler-policy @@ -147,7 +147,7 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Binpack` policy we can select `GPU2`. +So, in `Binpack` policy the scheduler selects `GPU2`. #### Spread @@ -166,4 +166,4 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Spread` policy we can select `GPU1`. +So, in `Spread` policy the scheduler selects `GPU1`. diff --git a/versioned_docs/version-v2.4.1/get-started/nginx-example.md b/versioned_docs/version-v2.4.1/get-started/nginx-example.md index 3e5aa4cd..b1d16917 100644 --- a/versioned_docs/version-v2.4.1/get-started/nginx-example.md +++ b/versioned_docs/version-v2.4.1/get-started/nginx-example.md @@ -92,7 +92,7 @@ sudo systemctl daemon-reload && systemctl restart containerd #### 2. Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ```bash kubectl label nodes {nodeid} gpu=on @@ -106,7 +106,7 @@ First, you need to check your Kubernetes version by using the following command: kubectl version ``` -Then, add our repo in helm +Then, add the HAMi repo in helm ```bash helm repo add hami-charts https://project-hami.github.io/HAMi/ diff --git a/versioned_docs/version-v2.4.1/installation/prerequisites.md b/versioned_docs/version-v2.4.1/installation/prerequisites.md index 13666bb8..4e52d10e 100644 --- a/versioned_docs/version-v2.4.1/installation/prerequisites.md +++ b/versioned_docs/version-v2.4.1/installation/prerequisites.md @@ -82,7 +82,7 @@ sudo systemctl daemon-reload && systemctl restart containerd ### Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ``` kubectl label nodes {nodeid} gpu=on diff --git a/versioned_docs/version-v2.4.1/userguide/cambricon-device/enable-cambricon-mlu-sharing.md b/versioned_docs/version-v2.4.1/userguide/cambricon-device/enable-cambricon-mlu-sharing.md index ae498abe..d446a30c 100644 --- a/versioned_docs/version-v2.4.1/userguide/cambricon-device/enable-cambricon-mlu-sharing.md +++ b/versioned_docs/version-v2.4.1/userguide/cambricon-device/enable-cambricon-mlu-sharing.md @@ -12,7 +12,7 @@ title: Enable cambricon MLU sharing ***MLU Type Specification***: You can specify which type of MLU to use or to avoid for a certain task, by setting "cambricon.com/use-mlutype" or "cambricon.com/nouse-mlutype" annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your MLU jobs will be automatically supported after installation. The only thing you need to do is tag the MLU node. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your MLU jobs will be automatically supported after installation. The only thing you need to do is tag the MLU node. ## Prerequisites diff --git a/versioned_docs/version-v2.4.1/userguide/configure.md b/versioned_docs/version-v2.4.1/userguide/configure.md index 8e3a34f3..23abea99 100644 --- a/versioned_docs/version-v2.4.1/userguide/configure.md +++ b/versioned_docs/version-v2.4.1/userguide/configure.md @@ -18,7 +18,7 @@ You can update these configurations using one of the following methods: 2. Modify Helm Chart: Update the corresponding values in the [ConfigMap](https://raw.githubusercontent.com/archlitchi/HAMi/refs/heads/master/charts/hami/templates/scheduler/device-configmap.yaml), then reapply the Helm Chart to regenerate the ConfigMap. * `nvidia.deviceMemoryScaling:` - Float type, by default: 1. The ratio for NVIDIA device memory scaling, can be greater than 1 (enable virtual device memory, experimental feature). For NVIDIA GPU with *M* memory, if we set `nvidia.deviceMemoryScaling` argument to *S*, vGPUs split by this GPU will totally get `S * M` memory in Kubernetes with our device plugin. + Float type, by default: 1. The ratio for NVIDIA device memory scaling, can be greater than 1 (enable virtual device memory, experimental feature). For NVIDIA GPU with *M* memory, if `nvidia.deviceMemoryScaling` is set to *S*, vGPUs split by this GPU will totally get `S * M` memory in Kubernetes with the HAMi device plugin. * `nvidia.deviceSplitCount:` Integer type, by default: equals 10. Maximum tasks assigned to a simple GPU device. * `nvidia.migstrategy:` diff --git a/versioned_docs/version-v2.4.1/userguide/monitoring/device-allocation.md b/versioned_docs/version-v2.4.1/userguide/monitoring/device-allocation.md index 94bbf0a5..c86b1a3e 100644 --- a/versioned_docs/version-v2.4.1/userguide/monitoring/device-allocation.md +++ b/versioned_docs/version-v2.4.1/userguide/monitoring/device-allocation.md @@ -21,4 +21,4 @@ It contains the following metrics: | GPUDeviceSharedNum | Number of containers sharing this GPU | `{deviceidx="0",deviceuuid="GPU-00552014-5c87-89ac-b1a6-7b53aa24b0ec",nodeid="aio-node67",zone="vGPU"}` 1 | | vGPUPodsDeviceAllocated | vGPU Allocated from pods | `{containeridx="Ascend310P",deviceusedcore="0",deviceuuid="aio-node74-arm-Ascend310P-0",nodename="aio-node74-arm",podname="ascend310p-pod",podnamespace="default",zone="vGPU"}` 3.221225472e+09 | -> **Note** Please note that, this is the overview about device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file +> **Note** This is an overview of device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file diff --git a/versioned_docs/version-v2.4.1/userguide/nvidia-device/examples/specify-card-type-to-use.md b/versioned_docs/version-v2.4.1/userguide/nvidia-device/examples/specify-card-type-to-use.md index 397e984f..ebab2615 100644 --- a/versioned_docs/version-v2.4.1/userguide/nvidia-device/examples/specify-card-type-to-use.md +++ b/versioned_docs/version-v2.4.1/userguide/nvidia-device/examples/specify-card-type-to-use.md @@ -13,7 +13,7 @@ metadata: name: gpu-pod annotations: nvidia.com/use-gputype: "A100,V100" - #In this example, we want to run this job on A100 or V100 + #In this example, the job should run on A100 or V100 spec: containers: - name: ubuntu-container @@ -24,4 +24,4 @@ spec: nvidia.com/gpu: 2 # requesting 2 vGPUs ``` -> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, we want to run this job on A100 or V100* +> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, the job should run on A100 or V100* diff --git a/versioned_docs/version-v2.5.0/contributor/adopters.md b/versioned_docs/version-v2.5.0/contributor/adopters.md index 8c521c76..40bd5058 100644 --- a/versioned_docs/version-v2.5.0/contributor/adopters.md +++ b/versioned_docs/version-v2.5.0/contributor/adopters.md @@ -1,12 +1,12 @@ # HAMi Adopters -So you and your organisation are using HAMi? That's great. We would love to hear from you! 💖 +So you and your organisation are using HAMi? That's great. ## Adding yourself [Here](https://github.com/Project-HAMi/website/blob/master/src/pages/adopters.mdx) lists the organisations who adopted the HAMi project in production. -You just need to add an entry for your company and upon merging it will automatically be added to our website. +You just need to add an entry for your company and upon merging it will automatically be added to the website. To add your organisation follow these steps: @@ -25,4 +25,4 @@ To add your organisation follow these steps: 6. Push the commit with `git push origin main`. 7. Open a Pull Request to [HAMi-io/website](https://github.com/Project-HAMi/website) and a preview build will turn up. -Thanks a lot for being part of our community - we very much appreciate it! +Thanks for being part of the community! diff --git a/versioned_docs/version-v2.5.0/contributor/cherry-picks.md b/versioned_docs/version-v2.5.0/contributor/cherry-picks.md index ca4c976b..a7a96275 100644 --- a/versioned_docs/version-v2.5.0/contributor/cherry-picks.md +++ b/versioned_docs/version-v2.5.0/contributor/cherry-picks.md @@ -62,7 +62,7 @@ your case by supplementing your PR with e.g., - Key stakeholder reviewers/approvers attesting to their confidence in the change being a required backport -It is critical that our full community is actively engaged on enhancements in +It is critical that the full community is actively engaged on enhancements in the project. If a released feature was not enabled on a particular provider's platform, this is a community miss that needs to be resolved in the `master` branch for subsequent releases. Such enabling will not be backported to the diff --git a/versioned_docs/version-v2.5.0/contributor/contribute-docs.md b/versioned_docs/version-v2.5.0/contributor/contribute-docs.md index f095e61a..31015974 100644 --- a/versioned_docs/version-v2.5.0/contributor/contribute-docs.md +++ b/versioned_docs/version-v2.5.0/contributor/contribute-docs.md @@ -9,25 +9,25 @@ the `Project-HAMi/website` repository. ## Prerequisites - Docs, like codes, are also categorized and stored by version. - 1.3 is the first version we have archived. + 1.3 is the first archived version. - Docs need to be translated into multiple languages for readers from different regions. The community now supports both Chinese and English. English is the official language of documentation. -- For our docs we use markdown. If you are unfamiliar with Markdown, +- The docs use markdown. If you are unfamiliar with Markdown, please see [https://guides.github.com/features/mastering-markdown/](https://guides.github.com/features/mastering-markdown/) or [https://www.markdownguide.org/](https://www.markdownguide.org/) if you are looking for something more substantial. -- We get some additions through [Docusaurus 2](https://docusaurus.io/), a model static website generator. +- The site uses [Docusaurus 2](https://docusaurus.io/), a model static website generator. ## Setup -You can set up your local environment by cloning our website repository. +Clone the website repository to set up a local environment. ```shell git clone https://github.com/Project-HAMi/website.git cd website ``` -Our website is organized like below: +The website is organized as follows: ```text website @@ -88,7 +88,7 @@ title: A doc with tags ``` The top section between two lines of --- is the Front Matter section. -Here we define a couple of entries which tell Docusaurus how to handle the article: +The entries tell Docusaurus how to handle the article: - Title is the equivalent of the `<h1>` in a HTML document or `# <title>` in a Markdown article. - Each document has a unique ID. By default, a document ID is the name of the document @@ -106,7 +106,7 @@ You can easily route to other places by adding any of the following links: You can use relative paths to index the corresponding files. - Link to pictures or other resources. If your article contains images, prefer storing them in `/static/img/docs/` and linking - with absolute paths. We use language-aware folders: + with absolute paths. Language-aware folders are used: - `/static/img/docs/common/` for shared images - `/static/img/docs/en/` for English-only images - `/static/img/docs/zh/` for Chinese-only images @@ -125,7 +125,7 @@ Creating a sidebar is useful to: - Display a sidebar on each of those documents - Provide paginated navigation, with next/previous button -For our docs, you can know how our documents are organized from +The document organization is defined in [https://github.com/Project-HAMi/website/blob/main/sidebars.js](https://github.com/Project-HAMi/website/blob/main/sidebars.js). ```js @@ -175,7 +175,7 @@ If you're not sure where your docs are located, you can ask community members in There are two situations about the Chinese version of the document: -- You want to translate our existing English docs to Chinese. In this case, +- To translate existing English docs to Chinese: you need to modify the corresponding file content from [https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current](https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current). The organization of this directory is exactly the same as the outer layer. @@ -202,6 +202,6 @@ If the previewed page is not what you expected, please check your docs again. ### Versioning -For the newly supplemented documents of each version, we will synchronize to the latest version +For the newly supplemented documents of each version, they are synchronized to the latest version on the release date of each version, and the documents of the old version will not be modified. -For errata found in the documentation, we will fix it with every release. +For errata found in the documentation, fixes are applied with every release. diff --git a/versioned_docs/version-v2.5.0/contributor/contributing.md b/versioned_docs/version-v2.5.0/contributor/contributing.md index fab6d31c..796c8e36 100644 --- a/versioned_docs/version-v2.5.0/contributor/contributing.md +++ b/versioned_docs/version-v2.5.0/contributor/contributing.md @@ -6,7 +6,7 @@ Welcome to HAMi! ## Code of Conduct -Please make sure to read and observe our [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) +Please make sure to read and observe the [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) ## Community Expectations @@ -20,7 +20,7 @@ HAMi is a community project driven by its community which strives to promote a h ## Your First Contribution -We will help you to contribute in different areas like filing issues, developing features, fixing critical bugs and +Help is available for contributing in areas like filing issues, developing features, fixing critical bugs and getting your work reviewed and merged. If you have questions about the development process, @@ -28,7 +28,7 @@ feel free to [file an issue](https://github.com/Project-HAMi/HAMi/issues/new/cho ## Find something to work on -We are always in need of help, be it fixing documentation, reporting bugs or writing some code. +Contributions are always welcome - fixing documentation, reporting bugs or writing some code. Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing. Here is how you get started. @@ -40,7 +40,7 @@ For example, [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi) has [help wanted](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) and [good first issue](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) labels for issues that should not need deep knowledge of the system. -We can help new contributors who wish to work on such issues. +Maintainers can help new contributors who wish to work on such issues. Another good way to contribute is to find a documentation improvement, such as a missing/broken link. Please see [Contributor Workflow](#contributor-workflow) below for the workflow. @@ -51,7 +51,7 @@ When you are willing to take on an issue, just reply on the issue. The maintaine ### File an Issue -While we encourage everyone to contribute code, it is also appreciated when someone reports an issue. +Code contributions are welcome, and bug reports are equally appreciated. Issues should be filed under the appropriate HAMi sub-repository. *Example:* a HAMi issue should be opened to [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi/issues). diff --git a/versioned_docs/version-v2.5.0/contributor/governance.md b/versioned_docs/version-v2.5.0/contributor/governance.md index f49b23b7..94c265e7 100644 --- a/versioned_docs/version-v2.5.0/contributor/governance.md +++ b/versioned_docs/version-v2.5.0/contributor/governance.md @@ -15,11 +15,11 @@ The HAMi and its leadership embrace the following values: * Fairness: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits. -* Community over Product or Company: Sustaining and growing our community takes +* Community over Product or Company: Sustaining and growing the community takes priority over shipping code or sponsors' organizational goals. Each contributor participates in the project as an individual. -* Inclusivity: We innovate through different perspectives and skill sets, which +* Inclusivity: Innovation happens through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment. * Participation: Responsibilities within the project are earned through diff --git a/versioned_docs/version-v2.5.0/contributor/ladder.md b/versioned_docs/version-v2.5.0/contributor/ladder.md index 26ea756f..26ecea39 100644 --- a/versioned_docs/version-v2.5.0/contributor/ladder.md +++ b/versioned_docs/version-v2.5.0/contributor/ladder.md @@ -4,7 +4,7 @@ title: Contributor Ladder This docs different ways to get involved and level up within the project. You can see different roles within the project in the contributor roles. -Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. +This contributor ladder outlines the different contributor roles within the project. Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. @@ -126,7 +126,7 @@ The current list of maintainers can be found in the [MAINTAINERS](https://github ## An active maintainer should -* Actively participate in reviewing pull requests and incoming issues. Note that there are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. +* Actively participate in reviewing pull requests and incoming issues. There are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. * Actively participate in discussions about design and the future of the project. diff --git a/versioned_docs/version-v2.5.0/developers/dynamic-mig.md b/versioned_docs/version-v2.5.0/developers/dynamic-mig.md index fd22875b..c1a56970 100644 --- a/versioned_docs/version-v2.5.0/developers/dynamic-mig.md +++ b/versioned_docs/version-v2.5.0/developers/dynamic-mig.md @@ -10,8 +10,8 @@ This feature will not be implemented without the help of @sailorvii. ## Introduction -The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, so we chose the MPS and MIG. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. We want to develop an automatic slice plugin and create the slice when the user require it. -For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, we consider the CPU, Mem, GPU memory and other user-defined resource. +The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, MPS and MIG were chosen. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. An automatic slice plugin is planned to create slices on demand. +For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, CPU, Mem, GPU memory, and other user-defined resources are considered. HAMi is done by using [hami-core](https://github.com/Project-HAMi/HAMi-core), which is a cuda-hacking library. But mig is also widely used across the world. A unified API for dynamic-mig and hami-core is needed. ## Targets @@ -149,7 +149,7 @@ The Procedure of a vGPU task which uses dynamic-mig is shown below: <img src="https://github.com/Project-HAMi/HAMi/blob/master/docs/develop/imgs/hami-dynamic-mig-procedure.png?raw=true" width="800" alt="HAMi dynamic MIG procedure flowchart showing task scheduling process" /> -Note that after submitted a task, deviceshare plugin will iterate over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. +After submitting a task, the deviceshare plugin iterates over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. If you submit the example on an empty A100-PCIE-40GB node, then it will select a GPU and choose MIG template below: diff --git a/versioned_docs/version-v2.5.0/developers/scheduling.md b/versioned_docs/version-v2.5.0/developers/scheduling.md index 02270146..9f44e903 100644 --- a/versioned_docs/version-v2.5.0/developers/scheduling.md +++ b/versioned_docs/version-v2.5.0/developers/scheduling.md @@ -104,7 +104,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Binpack` policy we can select `Node1`. +So, in `Binpack` policy the scheduler selects `Node1`. #### Spread @@ -124,7 +124,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Spread` policy we can select `Node2`. +So, in `Spread` policy the scheduler selects `Node2`. ### GPU-scheduler-policy @@ -147,7 +147,7 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Binpack` policy we can select `GPU2`. +So, in `Binpack` policy the scheduler selects `GPU2`. #### Spread @@ -166,4 +166,4 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Spread` policy we can select `GPU1`. +So, in `Spread` policy the scheduler selects `GPU1`. diff --git a/versioned_docs/version-v2.5.0/get-started/nginx-example.md b/versioned_docs/version-v2.5.0/get-started/nginx-example.md index 3e5aa4cd..b1d16917 100644 --- a/versioned_docs/version-v2.5.0/get-started/nginx-example.md +++ b/versioned_docs/version-v2.5.0/get-started/nginx-example.md @@ -92,7 +92,7 @@ sudo systemctl daemon-reload && systemctl restart containerd #### 2. Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ```bash kubectl label nodes {nodeid} gpu=on @@ -106,7 +106,7 @@ First, you need to check your Kubernetes version by using the following command: kubectl version ``` -Then, add our repo in helm +Then, add the HAMi repo in helm ```bash helm repo add hami-charts https://project-hami.github.io/HAMi/ diff --git a/versioned_docs/version-v2.5.0/installation/prerequisites.md b/versioned_docs/version-v2.5.0/installation/prerequisites.md index 13666bb8..4e52d10e 100644 --- a/versioned_docs/version-v2.5.0/installation/prerequisites.md +++ b/versioned_docs/version-v2.5.0/installation/prerequisites.md @@ -82,7 +82,7 @@ sudo systemctl daemon-reload && systemctl restart containerd ### Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ``` kubectl label nodes {nodeid} gpu=on diff --git a/versioned_docs/version-v2.5.0/userguide/cambricon-device/enable-cambricon-mlu-sharing.md b/versioned_docs/version-v2.5.0/userguide/cambricon-device/enable-cambricon-mlu-sharing.md index ae498abe..d446a30c 100644 --- a/versioned_docs/version-v2.5.0/userguide/cambricon-device/enable-cambricon-mlu-sharing.md +++ b/versioned_docs/version-v2.5.0/userguide/cambricon-device/enable-cambricon-mlu-sharing.md @@ -12,7 +12,7 @@ title: Enable cambricon MLU sharing ***MLU Type Specification***: You can specify which type of MLU to use or to avoid for a certain task, by setting "cambricon.com/use-mlutype" or "cambricon.com/nouse-mlutype" annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your MLU jobs will be automatically supported after installation. The only thing you need to do is tag the MLU node. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your MLU jobs will be automatically supported after installation. The only thing you need to do is tag the MLU node. ## Prerequisites diff --git a/versioned_docs/version-v2.5.0/userguide/configure.md b/versioned_docs/version-v2.5.0/userguide/configure.md index 8e3a34f3..23abea99 100644 --- a/versioned_docs/version-v2.5.0/userguide/configure.md +++ b/versioned_docs/version-v2.5.0/userguide/configure.md @@ -18,7 +18,7 @@ You can update these configurations using one of the following methods: 2. Modify Helm Chart: Update the corresponding values in the [ConfigMap](https://raw.githubusercontent.com/archlitchi/HAMi/refs/heads/master/charts/hami/templates/scheduler/device-configmap.yaml), then reapply the Helm Chart to regenerate the ConfigMap. * `nvidia.deviceMemoryScaling:` - Float type, by default: 1. The ratio for NVIDIA device memory scaling, can be greater than 1 (enable virtual device memory, experimental feature). For NVIDIA GPU with *M* memory, if we set `nvidia.deviceMemoryScaling` argument to *S*, vGPUs split by this GPU will totally get `S * M` memory in Kubernetes with our device plugin. + Float type, by default: 1. The ratio for NVIDIA device memory scaling, can be greater than 1 (enable virtual device memory, experimental feature). For NVIDIA GPU with *M* memory, if `nvidia.deviceMemoryScaling` is set to *S*, vGPUs split by this GPU will totally get `S * M` memory in Kubernetes with the HAMi device plugin. * `nvidia.deviceSplitCount:` Integer type, by default: equals 10. Maximum tasks assigned to a simple GPU device. * `nvidia.migstrategy:` diff --git a/versioned_docs/version-v2.5.0/userguide/enflame-device/enable-enflame-gpu-sharing.md b/versioned_docs/version-v2.5.0/userguide/enflame-device/enable-enflame-gpu-sharing.md index 4761c98c..35265e73 100644 --- a/versioned_docs/version-v2.5.0/userguide/enflame-device/enable-enflame-gpu-sharing.md +++ b/versioned_docs/version-v2.5.0/userguide/enflame-device/enable-enflame-gpu-sharing.md @@ -8,15 +8,15 @@ title: Enable Enflame GCU sharing ***GCU sharing***: Each task can allocate a portion of GCU instead of a whole GCU card, thus GCU can be shared among multiple tasks. -***Device Memory and Core Control***: GCUs can be allocated with certain percentage of device memory and core, we make sure that it does not exceed the boundary. +***Device Memory and Core Control***: GCUs can be allocated with certain percentage of device memory and core, the limit is enforced and the boundary is not exceeded. ***Device UUID Selection***: You can specify which GCU devices to use or exclude using annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your GPU jobs will be automatically supported after installation. ## Prerequisites -* Enflame gcushare-device-plugin >= 2.1.6 (please consult your device provider, gcushare has two components: gcushare-scheduler-plugin and gcushare-device-plugin, we only need gcushare-device-plugin here ) +* Enflame gcushare-device-plugin >= 2.1.6 (please consult your device provider, gcushare has two components: gcushare-scheduler-plugin and gcushare-device-plugin, only the gcushare-device-plugin is needed here ) * driver version >= 1.2.3.14 * kubernetes >= 1.24 * enflame-container-toolkit >=2.0.50 diff --git a/versioned_docs/version-v2.5.0/userguide/iluvatar-device/enable-iluvatar-gpu-sharing.md b/versioned_docs/version-v2.5.0/userguide/iluvatar-device/enable-iluvatar-gpu-sharing.md index 615adcce..3af55701 100644 --- a/versioned_docs/version-v2.5.0/userguide/iluvatar-device/enable-iluvatar-gpu-sharing.md +++ b/versioned_docs/version-v2.5.0/userguide/iluvatar-device/enable-iluvatar-gpu-sharing.md @@ -14,7 +14,7 @@ title: Enable Iluvatar GCU sharing ***Device UUID Selection***: You can specify which GPU devices to use or exclude using annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your GPU jobs will be automatically supported after installation. ## Prerequisites diff --git a/versioned_docs/version-v2.5.0/userguide/monitoring/device-allocation.md b/versioned_docs/version-v2.5.0/userguide/monitoring/device-allocation.md index 94bbf0a5..c86b1a3e 100644 --- a/versioned_docs/version-v2.5.0/userguide/monitoring/device-allocation.md +++ b/versioned_docs/version-v2.5.0/userguide/monitoring/device-allocation.md @@ -21,4 +21,4 @@ It contains the following metrics: | GPUDeviceSharedNum | Number of containers sharing this GPU | `{deviceidx="0",deviceuuid="GPU-00552014-5c87-89ac-b1a6-7b53aa24b0ec",nodeid="aio-node67",zone="vGPU"}` 1 | | vGPUPodsDeviceAllocated | vGPU Allocated from pods | `{containeridx="Ascend310P",deviceusedcore="0",deviceuuid="aio-node74-arm-Ascend310P-0",nodename="aio-node74-arm",podname="ascend310p-pod",podnamespace="default",zone="vGPU"}` 3.221225472e+09 | -> **Note** Please note that, this is the overview about device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file +> **Note** This is an overview of device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file diff --git a/versioned_docs/version-v2.5.0/userguide/nvidia-device/examples/specify-card-type-to-use.md b/versioned_docs/version-v2.5.0/userguide/nvidia-device/examples/specify-card-type-to-use.md index 397e984f..ebab2615 100644 --- a/versioned_docs/version-v2.5.0/userguide/nvidia-device/examples/specify-card-type-to-use.md +++ b/versioned_docs/version-v2.5.0/userguide/nvidia-device/examples/specify-card-type-to-use.md @@ -13,7 +13,7 @@ metadata: name: gpu-pod annotations: nvidia.com/use-gputype: "A100,V100" - #In this example, we want to run this job on A100 or V100 + #In this example, the job should run on A100 or V100 spec: containers: - name: ubuntu-container @@ -24,4 +24,4 @@ spec: nvidia.com/gpu: 2 # requesting 2 vGPUs ``` -> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, we want to run this job on A100 or V100* +> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, the job should run on A100 or V100* diff --git a/versioned_docs/version-v2.5.1/contributor/adopters.md b/versioned_docs/version-v2.5.1/contributor/adopters.md index 8c521c76..40bd5058 100644 --- a/versioned_docs/version-v2.5.1/contributor/adopters.md +++ b/versioned_docs/version-v2.5.1/contributor/adopters.md @@ -1,12 +1,12 @@ # HAMi Adopters -So you and your organisation are using HAMi? That's great. We would love to hear from you! 💖 +So you and your organisation are using HAMi? That's great. ## Adding yourself [Here](https://github.com/Project-HAMi/website/blob/master/src/pages/adopters.mdx) lists the organisations who adopted the HAMi project in production. -You just need to add an entry for your company and upon merging it will automatically be added to our website. +You just need to add an entry for your company and upon merging it will automatically be added to the website. To add your organisation follow these steps: @@ -25,4 +25,4 @@ To add your organisation follow these steps: 6. Push the commit with `git push origin main`. 7. Open a Pull Request to [HAMi-io/website](https://github.com/Project-HAMi/website) and a preview build will turn up. -Thanks a lot for being part of our community - we very much appreciate it! +Thanks for being part of the community! diff --git a/versioned_docs/version-v2.5.1/contributor/cherry-picks.md b/versioned_docs/version-v2.5.1/contributor/cherry-picks.md index ca4c976b..a7a96275 100644 --- a/versioned_docs/version-v2.5.1/contributor/cherry-picks.md +++ b/versioned_docs/version-v2.5.1/contributor/cherry-picks.md @@ -62,7 +62,7 @@ your case by supplementing your PR with e.g., - Key stakeholder reviewers/approvers attesting to their confidence in the change being a required backport -It is critical that our full community is actively engaged on enhancements in +It is critical that the full community is actively engaged on enhancements in the project. If a released feature was not enabled on a particular provider's platform, this is a community miss that needs to be resolved in the `master` branch for subsequent releases. Such enabling will not be backported to the diff --git a/versioned_docs/version-v2.5.1/contributor/contribute-docs.md b/versioned_docs/version-v2.5.1/contributor/contribute-docs.md index f095e61a..31015974 100644 --- a/versioned_docs/version-v2.5.1/contributor/contribute-docs.md +++ b/versioned_docs/version-v2.5.1/contributor/contribute-docs.md @@ -9,25 +9,25 @@ the `Project-HAMi/website` repository. ## Prerequisites - Docs, like codes, are also categorized and stored by version. - 1.3 is the first version we have archived. + 1.3 is the first archived version. - Docs need to be translated into multiple languages for readers from different regions. The community now supports both Chinese and English. English is the official language of documentation. -- For our docs we use markdown. If you are unfamiliar with Markdown, +- The docs use markdown. If you are unfamiliar with Markdown, please see [https://guides.github.com/features/mastering-markdown/](https://guides.github.com/features/mastering-markdown/) or [https://www.markdownguide.org/](https://www.markdownguide.org/) if you are looking for something more substantial. -- We get some additions through [Docusaurus 2](https://docusaurus.io/), a model static website generator. +- The site uses [Docusaurus 2](https://docusaurus.io/), a model static website generator. ## Setup -You can set up your local environment by cloning our website repository. +Clone the website repository to set up a local environment. ```shell git clone https://github.com/Project-HAMi/website.git cd website ``` -Our website is organized like below: +The website is organized as follows: ```text website @@ -88,7 +88,7 @@ title: A doc with tags ``` The top section between two lines of --- is the Front Matter section. -Here we define a couple of entries which tell Docusaurus how to handle the article: +The entries tell Docusaurus how to handle the article: - Title is the equivalent of the `<h1>` in a HTML document or `# <title>` in a Markdown article. - Each document has a unique ID. By default, a document ID is the name of the document @@ -106,7 +106,7 @@ You can easily route to other places by adding any of the following links: You can use relative paths to index the corresponding files. - Link to pictures or other resources. If your article contains images, prefer storing them in `/static/img/docs/` and linking - with absolute paths. We use language-aware folders: + with absolute paths. Language-aware folders are used: - `/static/img/docs/common/` for shared images - `/static/img/docs/en/` for English-only images - `/static/img/docs/zh/` for Chinese-only images @@ -125,7 +125,7 @@ Creating a sidebar is useful to: - Display a sidebar on each of those documents - Provide paginated navigation, with next/previous button -For our docs, you can know how our documents are organized from +The document organization is defined in [https://github.com/Project-HAMi/website/blob/main/sidebars.js](https://github.com/Project-HAMi/website/blob/main/sidebars.js). ```js @@ -175,7 +175,7 @@ If you're not sure where your docs are located, you can ask community members in There are two situations about the Chinese version of the document: -- You want to translate our existing English docs to Chinese. In this case, +- To translate existing English docs to Chinese: you need to modify the corresponding file content from [https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current](https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current). The organization of this directory is exactly the same as the outer layer. @@ -202,6 +202,6 @@ If the previewed page is not what you expected, please check your docs again. ### Versioning -For the newly supplemented documents of each version, we will synchronize to the latest version +For the newly supplemented documents of each version, they are synchronized to the latest version on the release date of each version, and the documents of the old version will not be modified. -For errata found in the documentation, we will fix it with every release. +For errata found in the documentation, fixes are applied with every release. diff --git a/versioned_docs/version-v2.5.1/contributor/contributing.md b/versioned_docs/version-v2.5.1/contributor/contributing.md index fab6d31c..796c8e36 100644 --- a/versioned_docs/version-v2.5.1/contributor/contributing.md +++ b/versioned_docs/version-v2.5.1/contributor/contributing.md @@ -6,7 +6,7 @@ Welcome to HAMi! ## Code of Conduct -Please make sure to read and observe our [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) +Please make sure to read and observe the [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) ## Community Expectations @@ -20,7 +20,7 @@ HAMi is a community project driven by its community which strives to promote a h ## Your First Contribution -We will help you to contribute in different areas like filing issues, developing features, fixing critical bugs and +Help is available for contributing in areas like filing issues, developing features, fixing critical bugs and getting your work reviewed and merged. If you have questions about the development process, @@ -28,7 +28,7 @@ feel free to [file an issue](https://github.com/Project-HAMi/HAMi/issues/new/cho ## Find something to work on -We are always in need of help, be it fixing documentation, reporting bugs or writing some code. +Contributions are always welcome - fixing documentation, reporting bugs or writing some code. Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing. Here is how you get started. @@ -40,7 +40,7 @@ For example, [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi) has [help wanted](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) and [good first issue](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) labels for issues that should not need deep knowledge of the system. -We can help new contributors who wish to work on such issues. +Maintainers can help new contributors who wish to work on such issues. Another good way to contribute is to find a documentation improvement, such as a missing/broken link. Please see [Contributor Workflow](#contributor-workflow) below for the workflow. @@ -51,7 +51,7 @@ When you are willing to take on an issue, just reply on the issue. The maintaine ### File an Issue -While we encourage everyone to contribute code, it is also appreciated when someone reports an issue. +Code contributions are welcome, and bug reports are equally appreciated. Issues should be filed under the appropriate HAMi sub-repository. *Example:* a HAMi issue should be opened to [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi/issues). diff --git a/versioned_docs/version-v2.5.1/contributor/governance.md b/versioned_docs/version-v2.5.1/contributor/governance.md index f49b23b7..94c265e7 100644 --- a/versioned_docs/version-v2.5.1/contributor/governance.md +++ b/versioned_docs/version-v2.5.1/contributor/governance.md @@ -15,11 +15,11 @@ The HAMi and its leadership embrace the following values: * Fairness: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits. -* Community over Product or Company: Sustaining and growing our community takes +* Community over Product or Company: Sustaining and growing the community takes priority over shipping code or sponsors' organizational goals. Each contributor participates in the project as an individual. -* Inclusivity: We innovate through different perspectives and skill sets, which +* Inclusivity: Innovation happens through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment. * Participation: Responsibilities within the project are earned through diff --git a/versioned_docs/version-v2.5.1/contributor/ladder.md b/versioned_docs/version-v2.5.1/contributor/ladder.md index 26ea756f..26ecea39 100644 --- a/versioned_docs/version-v2.5.1/contributor/ladder.md +++ b/versioned_docs/version-v2.5.1/contributor/ladder.md @@ -4,7 +4,7 @@ title: Contributor Ladder This docs different ways to get involved and level up within the project. You can see different roles within the project in the contributor roles. -Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. +This contributor ladder outlines the different contributor roles within the project. Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. @@ -126,7 +126,7 @@ The current list of maintainers can be found in the [MAINTAINERS](https://github ## An active maintainer should -* Actively participate in reviewing pull requests and incoming issues. Note that there are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. +* Actively participate in reviewing pull requests and incoming issues. There are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. * Actively participate in discussions about design and the future of the project. diff --git a/versioned_docs/version-v2.5.1/developers/dynamic-mig.md b/versioned_docs/version-v2.5.1/developers/dynamic-mig.md index fd22875b..c1a56970 100644 --- a/versioned_docs/version-v2.5.1/developers/dynamic-mig.md +++ b/versioned_docs/version-v2.5.1/developers/dynamic-mig.md @@ -10,8 +10,8 @@ This feature will not be implemented without the help of @sailorvii. ## Introduction -The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, so we chose the MPS and MIG. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. We want to develop an automatic slice plugin and create the slice when the user require it. -For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, we consider the CPU, Mem, GPU memory and other user-defined resource. +The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, MPS and MIG were chosen. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. An automatic slice plugin is planned to create slices on demand. +For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, CPU, Mem, GPU memory, and other user-defined resources are considered. HAMi is done by using [hami-core](https://github.com/Project-HAMi/HAMi-core), which is a cuda-hacking library. But mig is also widely used across the world. A unified API for dynamic-mig and hami-core is needed. ## Targets @@ -149,7 +149,7 @@ The Procedure of a vGPU task which uses dynamic-mig is shown below: <img src="https://github.com/Project-HAMi/HAMi/blob/master/docs/develop/imgs/hami-dynamic-mig-procedure.png?raw=true" width="800" alt="HAMi dynamic MIG procedure flowchart showing task scheduling process" /> -Note that after submitted a task, deviceshare plugin will iterate over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. +After submitting a task, the deviceshare plugin iterates over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. If you submit the example on an empty A100-PCIE-40GB node, then it will select a GPU and choose MIG template below: diff --git a/versioned_docs/version-v2.5.1/developers/scheduling.md b/versioned_docs/version-v2.5.1/developers/scheduling.md index 02270146..9f44e903 100644 --- a/versioned_docs/version-v2.5.1/developers/scheduling.md +++ b/versioned_docs/version-v2.5.1/developers/scheduling.md @@ -104,7 +104,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Binpack` policy we can select `Node1`. +So, in `Binpack` policy the scheduler selects `Node1`. #### Spread @@ -124,7 +124,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Spread` policy we can select `Node2`. +So, in `Spread` policy the scheduler selects `Node2`. ### GPU-scheduler-policy @@ -147,7 +147,7 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Binpack` policy we can select `GPU2`. +So, in `Binpack` policy the scheduler selects `GPU2`. #### Spread @@ -166,4 +166,4 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Spread` policy we can select `GPU1`. +So, in `Spread` policy the scheduler selects `GPU1`. diff --git a/versioned_docs/version-v2.5.1/get-started/nginx-example.md b/versioned_docs/version-v2.5.1/get-started/nginx-example.md index 3e5aa4cd..b1d16917 100644 --- a/versioned_docs/version-v2.5.1/get-started/nginx-example.md +++ b/versioned_docs/version-v2.5.1/get-started/nginx-example.md @@ -92,7 +92,7 @@ sudo systemctl daemon-reload && systemctl restart containerd #### 2. Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ```bash kubectl label nodes {nodeid} gpu=on @@ -106,7 +106,7 @@ First, you need to check your Kubernetes version by using the following command: kubectl version ``` -Then, add our repo in helm +Then, add the HAMi repo in helm ```bash helm repo add hami-charts https://project-hami.github.io/HAMi/ diff --git a/versioned_docs/version-v2.5.1/installation/prerequisites.md b/versioned_docs/version-v2.5.1/installation/prerequisites.md index 13666bb8..4e52d10e 100644 --- a/versioned_docs/version-v2.5.1/installation/prerequisites.md +++ b/versioned_docs/version-v2.5.1/installation/prerequisites.md @@ -82,7 +82,7 @@ sudo systemctl daemon-reload && systemctl restart containerd ### Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ``` kubectl label nodes {nodeid} gpu=on diff --git a/versioned_docs/version-v2.5.1/userguide/cambricon-device/enable-cambricon-mlu-sharing.md b/versioned_docs/version-v2.5.1/userguide/cambricon-device/enable-cambricon-mlu-sharing.md index ae498abe..d446a30c 100644 --- a/versioned_docs/version-v2.5.1/userguide/cambricon-device/enable-cambricon-mlu-sharing.md +++ b/versioned_docs/version-v2.5.1/userguide/cambricon-device/enable-cambricon-mlu-sharing.md @@ -12,7 +12,7 @@ title: Enable cambricon MLU sharing ***MLU Type Specification***: You can specify which type of MLU to use or to avoid for a certain task, by setting "cambricon.com/use-mlutype" or "cambricon.com/nouse-mlutype" annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your MLU jobs will be automatically supported after installation. The only thing you need to do is tag the MLU node. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your MLU jobs will be automatically supported after installation. The only thing you need to do is tag the MLU node. ## Prerequisites diff --git a/versioned_docs/version-v2.5.1/userguide/monitoring/device-allocation.md b/versioned_docs/version-v2.5.1/userguide/monitoring/device-allocation.md index 94bbf0a5..c86b1a3e 100644 --- a/versioned_docs/version-v2.5.1/userguide/monitoring/device-allocation.md +++ b/versioned_docs/version-v2.5.1/userguide/monitoring/device-allocation.md @@ -21,4 +21,4 @@ It contains the following metrics: | GPUDeviceSharedNum | Number of containers sharing this GPU | `{deviceidx="0",deviceuuid="GPU-00552014-5c87-89ac-b1a6-7b53aa24b0ec",nodeid="aio-node67",zone="vGPU"}` 1 | | vGPUPodsDeviceAllocated | vGPU Allocated from pods | `{containeridx="Ascend310P",deviceusedcore="0",deviceuuid="aio-node74-arm-Ascend310P-0",nodename="aio-node74-arm",podname="ascend310p-pod",podnamespace="default",zone="vGPU"}` 3.221225472e+09 | -> **Note** Please note that, this is the overview about device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file +> **Note** This is an overview of device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file diff --git a/versioned_docs/version-v2.5.1/userguide/nvidia-device/dynamic-mig-support.md b/versioned_docs/version-v2.5.1/userguide/nvidia-device/dynamic-mig-support.md index bea5435b..2c926be5 100644 --- a/versioned_docs/version-v2.5.1/userguide/nvidia-device/dynamic-mig-support.md +++ b/versioned_docs/version-v2.5.1/userguide/nvidia-device/dynamic-mig-support.md @@ -130,7 +130,7 @@ nvidia: :::note Helm installations and updates will follow the configuration specified in this file, overriding the default Helm settings. -Please note that HAMi will identify and use the first MIG template that matches the job, in the order defined in this configMap. +HAMi will identify and use the first MIG template that matches the job, in the order defined in this configMap. ::: ## Running MIG jobs diff --git a/versioned_docs/version-v2.5.1/userguide/nvidia-device/examples/specify-card-type-to-use.md b/versioned_docs/version-v2.5.1/userguide/nvidia-device/examples/specify-card-type-to-use.md index 397e984f..ebab2615 100644 --- a/versioned_docs/version-v2.5.1/userguide/nvidia-device/examples/specify-card-type-to-use.md +++ b/versioned_docs/version-v2.5.1/userguide/nvidia-device/examples/specify-card-type-to-use.md @@ -13,7 +13,7 @@ metadata: name: gpu-pod annotations: nvidia.com/use-gputype: "A100,V100" - #In this example, we want to run this job on A100 or V100 + #In this example, the job should run on A100 or V100 spec: containers: - name: ubuntu-container @@ -24,4 +24,4 @@ spec: nvidia.com/gpu: 2 # requesting 2 vGPUs ``` -> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, we want to run this job on A100 or V100* +> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, the job should run on A100 or V100* diff --git a/versioned_docs/version-v2.6.0/contributor/adopters.md b/versioned_docs/version-v2.6.0/contributor/adopters.md index 8c521c76..40bd5058 100644 --- a/versioned_docs/version-v2.6.0/contributor/adopters.md +++ b/versioned_docs/version-v2.6.0/contributor/adopters.md @@ -1,12 +1,12 @@ # HAMi Adopters -So you and your organisation are using HAMi? That's great. We would love to hear from you! 💖 +So you and your organisation are using HAMi? That's great. ## Adding yourself [Here](https://github.com/Project-HAMi/website/blob/master/src/pages/adopters.mdx) lists the organisations who adopted the HAMi project in production. -You just need to add an entry for your company and upon merging it will automatically be added to our website. +You just need to add an entry for your company and upon merging it will automatically be added to the website. To add your organisation follow these steps: @@ -25,4 +25,4 @@ To add your organisation follow these steps: 6. Push the commit with `git push origin main`. 7. Open a Pull Request to [HAMi-io/website](https://github.com/Project-HAMi/website) and a preview build will turn up. -Thanks a lot for being part of our community - we very much appreciate it! +Thanks for being part of the community! diff --git a/versioned_docs/version-v2.6.0/contributor/cherry-picks.md b/versioned_docs/version-v2.6.0/contributor/cherry-picks.md index ca4c976b..a7a96275 100644 --- a/versioned_docs/version-v2.6.0/contributor/cherry-picks.md +++ b/versioned_docs/version-v2.6.0/contributor/cherry-picks.md @@ -62,7 +62,7 @@ your case by supplementing your PR with e.g., - Key stakeholder reviewers/approvers attesting to their confidence in the change being a required backport -It is critical that our full community is actively engaged on enhancements in +It is critical that the full community is actively engaged on enhancements in the project. If a released feature was not enabled on a particular provider's platform, this is a community miss that needs to be resolved in the `master` branch for subsequent releases. Such enabling will not be backported to the diff --git a/versioned_docs/version-v2.6.0/contributor/contribute-docs.md b/versioned_docs/version-v2.6.0/contributor/contribute-docs.md index f095e61a..31015974 100644 --- a/versioned_docs/version-v2.6.0/contributor/contribute-docs.md +++ b/versioned_docs/version-v2.6.0/contributor/contribute-docs.md @@ -9,25 +9,25 @@ the `Project-HAMi/website` repository. ## Prerequisites - Docs, like codes, are also categorized and stored by version. - 1.3 is the first version we have archived. + 1.3 is the first archived version. - Docs need to be translated into multiple languages for readers from different regions. The community now supports both Chinese and English. English is the official language of documentation. -- For our docs we use markdown. If you are unfamiliar with Markdown, +- The docs use markdown. If you are unfamiliar with Markdown, please see [https://guides.github.com/features/mastering-markdown/](https://guides.github.com/features/mastering-markdown/) or [https://www.markdownguide.org/](https://www.markdownguide.org/) if you are looking for something more substantial. -- We get some additions through [Docusaurus 2](https://docusaurus.io/), a model static website generator. +- The site uses [Docusaurus 2](https://docusaurus.io/), a model static website generator. ## Setup -You can set up your local environment by cloning our website repository. +Clone the website repository to set up a local environment. ```shell git clone https://github.com/Project-HAMi/website.git cd website ``` -Our website is organized like below: +The website is organized as follows: ```text website @@ -88,7 +88,7 @@ title: A doc with tags ``` The top section between two lines of --- is the Front Matter section. -Here we define a couple of entries which tell Docusaurus how to handle the article: +The entries tell Docusaurus how to handle the article: - Title is the equivalent of the `<h1>` in a HTML document or `# <title>` in a Markdown article. - Each document has a unique ID. By default, a document ID is the name of the document @@ -106,7 +106,7 @@ You can easily route to other places by adding any of the following links: You can use relative paths to index the corresponding files. - Link to pictures or other resources. If your article contains images, prefer storing them in `/static/img/docs/` and linking - with absolute paths. We use language-aware folders: + with absolute paths. Language-aware folders are used: - `/static/img/docs/common/` for shared images - `/static/img/docs/en/` for English-only images - `/static/img/docs/zh/` for Chinese-only images @@ -125,7 +125,7 @@ Creating a sidebar is useful to: - Display a sidebar on each of those documents - Provide paginated navigation, with next/previous button -For our docs, you can know how our documents are organized from +The document organization is defined in [https://github.com/Project-HAMi/website/blob/main/sidebars.js](https://github.com/Project-HAMi/website/blob/main/sidebars.js). ```js @@ -175,7 +175,7 @@ If you're not sure where your docs are located, you can ask community members in There are two situations about the Chinese version of the document: -- You want to translate our existing English docs to Chinese. In this case, +- To translate existing English docs to Chinese: you need to modify the corresponding file content from [https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current](https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current). The organization of this directory is exactly the same as the outer layer. @@ -202,6 +202,6 @@ If the previewed page is not what you expected, please check your docs again. ### Versioning -For the newly supplemented documents of each version, we will synchronize to the latest version +For the newly supplemented documents of each version, they are synchronized to the latest version on the release date of each version, and the documents of the old version will not be modified. -For errata found in the documentation, we will fix it with every release. +For errata found in the documentation, fixes are applied with every release. diff --git a/versioned_docs/version-v2.6.0/contributor/contributing.md b/versioned_docs/version-v2.6.0/contributor/contributing.md index 32af0a21..579a6083 100644 --- a/versioned_docs/version-v2.6.0/contributor/contributing.md +++ b/versioned_docs/version-v2.6.0/contributor/contributing.md @@ -6,7 +6,7 @@ Welcome to HAMi! ## Code of Conduct -Please make sure to read and observe our [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) +Please make sure to read and observe the [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) ## Community Expectations @@ -20,7 +20,7 @@ HAMi is a community project driven by its community which strives to promote a h ## Your First Contribution -We will help you to contribute in different areas like filing issues, developing features, fixing critical bugs and +Help is available for contributing in areas like filing issues, developing features, fixing critical bugs and getting your work reviewed and merged. If you have questions about the development process, @@ -28,7 +28,7 @@ feel free to [file an issue](https://github.com/Project-HAMi/HAMi/issues/new/cho ## Find something to work on -We are always in need of help, be it fixing documentation, reporting bugs or writing some code. +Contributions are always welcome - fixing documentation, reporting bugs or writing some code. Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing. Here is how you get started. @@ -40,7 +40,7 @@ For example, [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi) has [help wanted](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) and [good first issue](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) labels for issues that should not need deep knowledge of the system. -We can help new contributors who wish to work on such issues. +Maintainers can help new contributors who wish to work on such issues. Another good way to contribute is to find a documentation improvement, such as a missing/broken link. Please see [Contributor Workflow](#contributor-workflow) below for the workflow. @@ -51,7 +51,7 @@ When you are willing to take on an issue, just reply on the issue. The maintaine ## File an Issue -While we encourage everyone to contribute code, it is also appreciated when someone reports an issue. +Code contributions are welcome, and bug reports are equally appreciated. Issues should be filed under the appropriate HAMi sub-repository. *Example:* a HAMi issue should be opened to [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi/issues). diff --git a/versioned_docs/version-v2.6.0/contributor/governance.md b/versioned_docs/version-v2.6.0/contributor/governance.md index f49b23b7..94c265e7 100644 --- a/versioned_docs/version-v2.6.0/contributor/governance.md +++ b/versioned_docs/version-v2.6.0/contributor/governance.md @@ -15,11 +15,11 @@ The HAMi and its leadership embrace the following values: * Fairness: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits. -* Community over Product or Company: Sustaining and growing our community takes +* Community over Product or Company: Sustaining and growing the community takes priority over shipping code or sponsors' organizational goals. Each contributor participates in the project as an individual. -* Inclusivity: We innovate through different perspectives and skill sets, which +* Inclusivity: Innovation happens through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment. * Participation: Responsibilities within the project are earned through diff --git a/versioned_docs/version-v2.6.0/contributor/ladder.md b/versioned_docs/version-v2.6.0/contributor/ladder.md index 26ea756f..26ecea39 100644 --- a/versioned_docs/version-v2.6.0/contributor/ladder.md +++ b/versioned_docs/version-v2.6.0/contributor/ladder.md @@ -4,7 +4,7 @@ title: Contributor Ladder This docs different ways to get involved and level up within the project. You can see different roles within the project in the contributor roles. -Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. +This contributor ladder outlines the different contributor roles within the project. Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. @@ -126,7 +126,7 @@ The current list of maintainers can be found in the [MAINTAINERS](https://github ## An active maintainer should -* Actively participate in reviewing pull requests and incoming issues. Note that there are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. +* Actively participate in reviewing pull requests and incoming issues. There are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. * Actively participate in discussions about design and the future of the project. diff --git a/versioned_docs/version-v2.6.0/developers/dynamic-mig.md b/versioned_docs/version-v2.6.0/developers/dynamic-mig.md index fd22875b..c1a56970 100644 --- a/versioned_docs/version-v2.6.0/developers/dynamic-mig.md +++ b/versioned_docs/version-v2.6.0/developers/dynamic-mig.md @@ -10,8 +10,8 @@ This feature will not be implemented without the help of @sailorvii. ## Introduction -The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, so we chose the MPS and MIG. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. We want to develop an automatic slice plugin and create the slice when the user require it. -For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, we consider the CPU, Mem, GPU memory and other user-defined resource. +The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, MPS and MIG were chosen. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. An automatic slice plugin is planned to create slices on demand. +For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, CPU, Mem, GPU memory, and other user-defined resources are considered. HAMi is done by using [hami-core](https://github.com/Project-HAMi/HAMi-core), which is a cuda-hacking library. But mig is also widely used across the world. A unified API for dynamic-mig and hami-core is needed. ## Targets @@ -149,7 +149,7 @@ The Procedure of a vGPU task which uses dynamic-mig is shown below: <img src="https://github.com/Project-HAMi/HAMi/blob/master/docs/develop/imgs/hami-dynamic-mig-procedure.png?raw=true" width="800" alt="HAMi dynamic MIG procedure flowchart showing task scheduling process" /> -Note that after submitted a task, deviceshare plugin will iterate over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. +After submitting a task, the deviceshare plugin iterates over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. If you submit the example on an empty A100-PCIE-40GB node, then it will select a GPU and choose MIG template below: diff --git a/versioned_docs/version-v2.6.0/developers/protocol.md b/versioned_docs/version-v2.6.0/developers/protocol.md index 54d04056..ba994abb 100644 --- a/versioned_docs/version-v2.6.0/developers/protocol.md +++ b/versioned_docs/version-v2.6.0/developers/protocol.md @@ -31,7 +31,7 @@ hami.io/node-nvidia-register: GPU-00552014-5c87-89ac-b1a6-7b53aa24b0ec,10,32768, In this example, this node has two different AI devices, 2 Nvidia-V100 GPUs, and 2 Cambircon 370-X4 MLUs -Note that a device node may become unavailable due to hardware or network failure, if a node hasn't registered in last 5 minutes, scheduler will mark that node as 'unavailable'. +A device node may become unavailable due to hardware or network failure, if a node hasn't registered in last 5 minutes, scheduler will mark that node as 'unavailable'. Since system clock on scheduler node and 'device' node may not align properly, scheduler node will patch the following device node annotations every 30s diff --git a/versioned_docs/version-v2.6.0/developers/scheduling.md b/versioned_docs/version-v2.6.0/developers/scheduling.md index d80d3957..c50dc18d 100644 --- a/versioned_docs/version-v2.6.0/developers/scheduling.md +++ b/versioned_docs/version-v2.6.0/developers/scheduling.md @@ -105,7 +105,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Binpack` policy we can select `Node1`. +So, in `Binpack` policy the scheduler selects `Node1`. #### Spread @@ -125,7 +125,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Spread` policy we can select `Node2`. +So, in `Spread` policy the scheduler selects `Node2`. ### GPU-scheduler-policy @@ -148,7 +148,7 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Binpack` policy we can select `GPU2`. +So, in `Binpack` policy the scheduler selects `GPU2`. #### Spread @@ -167,7 +167,7 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Spread` policy we can select `GPU1`. +So, in `Spread` policy the scheduler selects `GPU1`. #### Topology-aware @@ -231,7 +231,7 @@ gpu2 score: 100 + 200 + 200 = 500 gpu3 score: 200 + 100 + 200 = 500 ``` -Therefore, when a **Pod requests only one GPU**, we randomly select either **gpu0** or **gpu1**. +Therefore, when a **Pod requests only one GPU**, the scheduler randomly selects either **gpu0** or **gpu1**. ###### More than one GPU @@ -253,4 +253,4 @@ For example: If a Pod requests 3 GPUs, take **gpu0, gpu1, gpu2** as an example. (gpu1, gpu2, gpu3) totalScore: 200 + 100 + 200 = 500 ``` -Therefore, when a **Pod requests 3 GPUs**, we allocate **gpu1, gpu2, gpu3**. +Therefore, when a **Pod requests 3 GPUs**, the scheduler allocates **gpu1, gpu2, gpu3**. diff --git a/versioned_docs/version-v2.6.0/faq/faq.md b/versioned_docs/version-v2.6.0/faq/faq.md index 6a9b72f4..f41a45ff 100644 --- a/versioned_docs/version-v2.6.0/faq/faq.md +++ b/versioned_docs/version-v2.6.0/faq/faq.md @@ -42,7 +42,7 @@ A vGPU is a logical instance of a physical GPU created using virtualization, all 4. **Design Intent** The design of vGPU aims to **allow one GPU to be shared by multiple tasks**, rather than letting one task occupy multiple vGPUs on the same GPU. The purpose of vGPU overcommitment is to improve GPU utilization, not to increase resource allocation for individual tasks. -## HAMi's `nvidia.com/priority` field only supports two levels. How can we implement multi-level, user-defined priority-based scheduling for a queue of jobs, especially when cluster resources are limited? +## HAMi's `nvidia.com/priority` field only supports two levels. How to implement multi-level, user-defined priority-based scheduling for a queue of jobs, especially when cluster resources are limited? **TL;DR** @@ -63,7 +63,7 @@ However, achieving multi-level priority scheduling **is feasible**. The recommen 1. HAMi integrates with Volcano via the [volcano-vgpu-device-plugin](https://github.com/Project-HAMi/volcano-vgpu-device-plugin). 2. It continues to manage the vGPU sharing and its own two-level runtime priority for tasks contending on the *same physical GPU*, as described earlier. -In summary, while HAMi's own priority serves a different, device-specific purpose (runtime preemption on a single card), implementing multi-level job scheduling priority is achievable by using **Volcano in conjunction with HAMi**. Volcano would handle which job from the queue is prioritized for resource allocation based on multiple priority levels, and HAMi would manage the GPU sharing and its specific on-device preemption. +While HAMi's own priority serves a different, device-specific purpose (runtime preemption on a single card), implementing multi-level job scheduling priority is achievable by using **Volcano in conjunction with HAMi**. Volcano would handle which job from the queue is prioritized for resource allocation based on multiple priority levels, and HAMi would manage the GPU sharing and its specific on-device preemption. ## Integration with Other Open-Source Tools diff --git a/versioned_docs/version-v2.6.0/get-started/nginx-example.md b/versioned_docs/version-v2.6.0/get-started/nginx-example.md index 3e5aa4cd..b1d16917 100644 --- a/versioned_docs/version-v2.6.0/get-started/nginx-example.md +++ b/versioned_docs/version-v2.6.0/get-started/nginx-example.md @@ -92,7 +92,7 @@ sudo systemctl daemon-reload && systemctl restart containerd #### 2. Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ```bash kubectl label nodes {nodeid} gpu=on @@ -106,7 +106,7 @@ First, you need to check your Kubernetes version by using the following command: kubectl version ``` -Then, add our repo in helm +Then, add the HAMi repo in helm ```bash helm repo add hami-charts https://project-hami.github.io/HAMi/ diff --git a/versioned_docs/version-v2.6.0/installation/prerequisites.md b/versioned_docs/version-v2.6.0/installation/prerequisites.md index f08ec526..acced9ec 100644 --- a/versioned_docs/version-v2.6.0/installation/prerequisites.md +++ b/versioned_docs/version-v2.6.0/installation/prerequisites.md @@ -60,7 +60,7 @@ sudo systemctl daemon-reload && systemctl restart containerd ### Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ``` kubectl label nodes {nodeid} gpu=on diff --git a/versioned_docs/version-v2.6.0/userguide/enflame-device/enable-enflame-gcu-sharing.md b/versioned_docs/version-v2.6.0/userguide/enflame-device/enable-enflame-gcu-sharing.md index 3f3eecbf..df871823 100644 --- a/versioned_docs/version-v2.6.0/userguide/enflame-device/enable-enflame-gcu-sharing.md +++ b/versioned_docs/version-v2.6.0/userguide/enflame-device/enable-enflame-gcu-sharing.md @@ -9,15 +9,15 @@ title: Enable Enflame GPU Sharing ***GCU sharing***: Each task can allocate a portion of GCU instead of a whole GCU card, thus GCU can be shared among multiple tasks. -***Device Memory and Core Control***: GCUs can be allocated with certain percentage of device memory and core, we make sure that it does not exceed the boundary. +***Device Memory and Core Control***: GCUs can be allocated with certain percentage of device memory and core, the limit is enforced and the boundary is not exceeded. ***Device UUID Selection***: You can specify which GCU devices to use or exclude using annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your GPU jobs will be automatically supported after installation. ## Prerequisites -* Enflame gcushare-device-plugin >= 2.1.6 (please consult your device provider, gcushare has two components: gcushare-scheduler-plugin and gcushare-device-plugin, we only need gcushare-device-plugin here ) +* Enflame gcushare-device-plugin >= 2.1.6 (please consult your device provider, gcushare has two components: gcushare-scheduler-plugin and gcushare-device-plugin, only the gcushare-device-plugin is needed here ) * driver version >= 1.2.3.14 * kubernetes >= 1.24 * enflame-container-toolkit >=2.0.50 diff --git a/versioned_docs/version-v2.6.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md b/versioned_docs/version-v2.6.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md index 1de8daac..6f386cbf 100644 --- a/versioned_docs/version-v2.6.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md +++ b/versioned_docs/version-v2.6.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md @@ -15,7 +15,7 @@ title: Enable Illuvatar GPU Sharing ***Device UUID Selection***: You can specify which GPU devices to use or exclude using annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your GPU jobs will be automatically supported after installation. ## Prerequisites diff --git a/versioned_docs/version-v2.6.0/userguide/metax-device/metax-gpu/enable-metax-gpu-schedule.md b/versioned_docs/version-v2.6.0/userguide/metax-device/metax-gpu/enable-metax-gpu-schedule.md index da0b5726..55549e2b 100644 --- a/versioned_docs/version-v2.6.0/userguide/metax-device/metax-gpu/enable-metax-gpu-schedule.md +++ b/versioned_docs/version-v2.6.0/userguide/metax-device/metax-gpu/enable-metax-gpu-schedule.md @@ -4,7 +4,7 @@ title: Enable Metax GPU topology-aware scheduling ## Introduction -**we now support metax.com/gpu by implementing topo-awareness among metax GPUs** +HAMi now supports metax.com/gpu with topo-awareness among metax GPUs When multiple GPUs are configured on a single server, the GPU cards are connected to the same PCIe Switch or MetaXLink depending on whether they are connected , there is a near-far relationship. This forms a topology among all the cards on the server, as shown in the following figure: diff --git a/versioned_docs/version-v2.6.0/userguide/metax-device/metax-sgpu/enable-metax-gpu-sharing.md b/versioned_docs/version-v2.6.0/userguide/metax-device/metax-sgpu/enable-metax-gpu-sharing.md index 0b8d9132..f1b2e093 100644 --- a/versioned_docs/version-v2.6.0/userguide/metax-device/metax-sgpu/enable-metax-gpu-sharing.md +++ b/versioned_docs/version-v2.6.0/userguide/metax-device/metax-sgpu/enable-metax-gpu-sharing.md @@ -5,7 +5,7 @@ translated: true ## Introduction -**we now support metax.com/gpu by implementing most device-sharing features as nvidia-GPU**, device-sharing features include the following: +HAMi now supports metax.com/gpu with most device-sharing features available for nvidia-GPU. Supported features: ***GPU sharing***: Each task can allocate a portion of GPU instead of a whole GPU card, thus GPU can be shared among multiple tasks. diff --git a/versioned_docs/version-v2.6.0/userguide/monitoring/device-allocation.md b/versioned_docs/version-v2.6.0/userguide/monitoring/device-allocation.md index 94bbf0a5..c86b1a3e 100644 --- a/versioned_docs/version-v2.6.0/userguide/monitoring/device-allocation.md +++ b/versioned_docs/version-v2.6.0/userguide/monitoring/device-allocation.md @@ -21,4 +21,4 @@ It contains the following metrics: | GPUDeviceSharedNum | Number of containers sharing this GPU | `{deviceidx="0",deviceuuid="GPU-00552014-5c87-89ac-b1a6-7b53aa24b0ec",nodeid="aio-node67",zone="vGPU"}` 1 | | vGPUPodsDeviceAllocated | vGPU Allocated from pods | `{containeridx="Ascend310P",deviceusedcore="0",deviceuuid="aio-node74-arm-Ascend310P-0",nodename="aio-node74-arm",podname="ascend310p-pod",podnamespace="default",zone="vGPU"}` 3.221225472e+09 | -> **Note** Please note that, this is the overview about device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file +> **Note** This is an overview of device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file diff --git a/versioned_docs/version-v2.6.0/userguide/nvidia-device/dynamic-mig-support.md b/versioned_docs/version-v2.6.0/userguide/nvidia-device/dynamic-mig-support.md index bea5435b..2c926be5 100644 --- a/versioned_docs/version-v2.6.0/userguide/nvidia-device/dynamic-mig-support.md +++ b/versioned_docs/version-v2.6.0/userguide/nvidia-device/dynamic-mig-support.md @@ -130,7 +130,7 @@ nvidia: :::note Helm installations and updates will follow the configuration specified in this file, overriding the default Helm settings. -Please note that HAMi will identify and use the first MIG template that matches the job, in the order defined in this configMap. +HAMi will identify and use the first MIG template that matches the job, in the order defined in this configMap. ::: ## Running MIG jobs diff --git a/versioned_docs/version-v2.6.0/userguide/nvidia-device/examples/specify-card-type-to-use.md b/versioned_docs/version-v2.6.0/userguide/nvidia-device/examples/specify-card-type-to-use.md index dd7239fd..d6fe7379 100644 --- a/versioned_docs/version-v2.6.0/userguide/nvidia-device/examples/specify-card-type-to-use.md +++ b/versioned_docs/version-v2.6.0/userguide/nvidia-device/examples/specify-card-type-to-use.md @@ -13,7 +13,7 @@ metadata: name: gpu-pod annotations: nvidia.com/use-gputype: "A100,V100" - #In this example, we want to run this job on A100 or V100 + #In this example, the job should run on A100 or V100 spec: containers: - name: ubuntu-container @@ -24,4 +24,4 @@ spec: nvidia.com/gpu: 2 # requesting 2 vGPUs ``` -> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, we want to run this job on A100 or V100* \ No newline at end of file +> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, the job should run on A100 or V100* \ No newline at end of file diff --git a/versioned_docs/version-v2.7.0/contributor/adopters.md b/versioned_docs/version-v2.7.0/contributor/adopters.md index 8c521c76..40bd5058 100644 --- a/versioned_docs/version-v2.7.0/contributor/adopters.md +++ b/versioned_docs/version-v2.7.0/contributor/adopters.md @@ -1,12 +1,12 @@ # HAMi Adopters -So you and your organisation are using HAMi? That's great. We would love to hear from you! 💖 +So you and your organisation are using HAMi? That's great. ## Adding yourself [Here](https://github.com/Project-HAMi/website/blob/master/src/pages/adopters.mdx) lists the organisations who adopted the HAMi project in production. -You just need to add an entry for your company and upon merging it will automatically be added to our website. +You just need to add an entry for your company and upon merging it will automatically be added to the website. To add your organisation follow these steps: @@ -25,4 +25,4 @@ To add your organisation follow these steps: 6. Push the commit with `git push origin main`. 7. Open a Pull Request to [HAMi-io/website](https://github.com/Project-HAMi/website) and a preview build will turn up. -Thanks a lot for being part of our community - we very much appreciate it! +Thanks for being part of the community! diff --git a/versioned_docs/version-v2.7.0/contributor/cherry-picks.md b/versioned_docs/version-v2.7.0/contributor/cherry-picks.md index ca4c976b..a7a96275 100644 --- a/versioned_docs/version-v2.7.0/contributor/cherry-picks.md +++ b/versioned_docs/version-v2.7.0/contributor/cherry-picks.md @@ -62,7 +62,7 @@ your case by supplementing your PR with e.g., - Key stakeholder reviewers/approvers attesting to their confidence in the change being a required backport -It is critical that our full community is actively engaged on enhancements in +It is critical that the full community is actively engaged on enhancements in the project. If a released feature was not enabled on a particular provider's platform, this is a community miss that needs to be resolved in the `master` branch for subsequent releases. Such enabling will not be backported to the diff --git a/versioned_docs/version-v2.7.0/contributor/contribute-docs.md b/versioned_docs/version-v2.7.0/contributor/contribute-docs.md index 58f4b0d4..16e2423c 100644 --- a/versioned_docs/version-v2.7.0/contributor/contribute-docs.md +++ b/versioned_docs/version-v2.7.0/contributor/contribute-docs.md @@ -9,25 +9,25 @@ the `Project-HAMi/website` repository. ## Prerequisites - Docs, like codes, are also categorized and stored by version. - 1.3 is the first version we have archived. + 1.3 is the first archived version. - Docs need to be translated into multiple languages for readers from different regions. The community now supports both Chinese and English. English is the official language of documentation. -- For our docs we use markdown. If you are unfamiliar with Markdown, +- The docs use markdown. If you are unfamiliar with Markdown, please see [https://guides.github.com/features/mastering-markdown/](https://guides.github.com/features/mastering-markdown/) or [https://www.markdownguide.org/](https://www.markdownguide.org/) if you are looking for something more substantial. -- We get some additions through [Docusaurus 2](https://docusaurus.io/), a model static website generator. +- The site uses [Docusaurus 2](https://docusaurus.io/), a model static website generator. ## Setup -You can set up your local environment by cloning our website repository. +Clone the website repository to set up a local environment. ```shell git clone https://github.com/Project-HAMi/website.git cd website ``` -Our website is organized like below: +The website is organized as follows: ```text website @@ -88,7 +88,7 @@ title: A doc with tags ``` The top section between two lines of --- is the Front Matter section. -Here we define a couple of entries which tell Docusaurus how to handle the article: +The entries tell Docusaurus how to handle the article: - Title is the equivalent of the `<h1>` in a HTML document or `# <title>` in a Markdown article. - Each document has a unique ID. By default, a document ID is the name of the document @@ -106,7 +106,7 @@ You can easily route to other places by adding any of the following links: You can use relative paths to index the corresponding files. - Link to pictures or other resources. If your article contains images, prefer storing them in `/static/img/docs/` and linking - with absolute paths. We use language-aware folders: + with absolute paths. Language-aware folders are used: - `/static/img/docs/common/` for shared images - `/static/img/docs/en/` for English-only images - `/static/img/docs/zh/` for Chinese-only images @@ -125,7 +125,7 @@ Creating a sidebar is useful to: - Display a sidebar on each of those documents - Provide paginated navigation, with next/previous button -For our docs, you can know how our documents are organized from +The document organization is defined in [https://github.com/Project-HAMi/website/blob/main/sidebars.js](https://github.com/Project-HAMi/website/blob/main/sidebars.js). ```js @@ -175,7 +175,7 @@ If you're not sure where your docs are located, you can ask community members in There are two situations about the Chinese version of the document: -- You want to translate our existing English docs to Chinese. In this case, +- To translate existing English docs to Chinese: you need to modify the corresponding file content from [https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current](https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current). The organization of this directory is exactly the same as the outer layer. @@ -202,6 +202,6 @@ If the previewed page is not what you expected, please check your docs again. ### Versioning -For the newly supplemented documents of each version, we will synchronize to the latest version +For the newly supplemented documents of each version, they are synchronized to the latest version on the release date of each version, and the documents of the old version will not be modified. -For errata found in the documentation, we will fix it with every release. +For errata found in the documentation, fixes are applied with every release. diff --git a/versioned_docs/version-v2.7.0/contributor/contributing.md b/versioned_docs/version-v2.7.0/contributor/contributing.md index fab6d31c..796c8e36 100644 --- a/versioned_docs/version-v2.7.0/contributor/contributing.md +++ b/versioned_docs/version-v2.7.0/contributor/contributing.md @@ -6,7 +6,7 @@ Welcome to HAMi! ## Code of Conduct -Please make sure to read and observe our [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) +Please make sure to read and observe the [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) ## Community Expectations @@ -20,7 +20,7 @@ HAMi is a community project driven by its community which strives to promote a h ## Your First Contribution -We will help you to contribute in different areas like filing issues, developing features, fixing critical bugs and +Help is available for contributing in areas like filing issues, developing features, fixing critical bugs and getting your work reviewed and merged. If you have questions about the development process, @@ -28,7 +28,7 @@ feel free to [file an issue](https://github.com/Project-HAMi/HAMi/issues/new/cho ## Find something to work on -We are always in need of help, be it fixing documentation, reporting bugs or writing some code. +Contributions are always welcome - fixing documentation, reporting bugs or writing some code. Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing. Here is how you get started. @@ -40,7 +40,7 @@ For example, [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi) has [help wanted](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) and [good first issue](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) labels for issues that should not need deep knowledge of the system. -We can help new contributors who wish to work on such issues. +Maintainers can help new contributors who wish to work on such issues. Another good way to contribute is to find a documentation improvement, such as a missing/broken link. Please see [Contributor Workflow](#contributor-workflow) below for the workflow. @@ -51,7 +51,7 @@ When you are willing to take on an issue, just reply on the issue. The maintaine ### File an Issue -While we encourage everyone to contribute code, it is also appreciated when someone reports an issue. +Code contributions are welcome, and bug reports are equally appreciated. Issues should be filed under the appropriate HAMi sub-repository. *Example:* a HAMi issue should be opened to [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi/issues). diff --git a/versioned_docs/version-v2.7.0/contributor/governance.md b/versioned_docs/version-v2.7.0/contributor/governance.md index f49b23b7..94c265e7 100644 --- a/versioned_docs/version-v2.7.0/contributor/governance.md +++ b/versioned_docs/version-v2.7.0/contributor/governance.md @@ -15,11 +15,11 @@ The HAMi and its leadership embrace the following values: * Fairness: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits. -* Community over Product or Company: Sustaining and growing our community takes +* Community over Product or Company: Sustaining and growing the community takes priority over shipping code or sponsors' organizational goals. Each contributor participates in the project as an individual. -* Inclusivity: We innovate through different perspectives and skill sets, which +* Inclusivity: Innovation happens through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment. * Participation: Responsibilities within the project are earned through diff --git a/versioned_docs/version-v2.7.0/contributor/ladder.md b/versioned_docs/version-v2.7.0/contributor/ladder.md index 50a277f9..b9ed3712 100644 --- a/versioned_docs/version-v2.7.0/contributor/ladder.md +++ b/versioned_docs/version-v2.7.0/contributor/ladder.md @@ -6,7 +6,7 @@ This docs different ways to get involved and level up within the project. You ca ## Contributor Ladder -Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. +This contributor ladder outlines the different contributor roles within the project. Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. @@ -128,7 +128,7 @@ The current list of maintainers can be found in the [MAINTAINERS](https://github ## An active maintainer should -* Actively participate in reviewing pull requests and incoming issues. Note that there are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. +* Actively participate in reviewing pull requests and incoming issues. There are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. * Actively participate in discussions about design and the future of the project. diff --git a/versioned_docs/version-v2.7.0/developers/dynamic-mig.md b/versioned_docs/version-v2.7.0/developers/dynamic-mig.md index fd22875b..c1a56970 100644 --- a/versioned_docs/version-v2.7.0/developers/dynamic-mig.md +++ b/versioned_docs/version-v2.7.0/developers/dynamic-mig.md @@ -10,8 +10,8 @@ This feature will not be implemented without the help of @sailorvii. ## Introduction -The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, so we chose the MPS and MIG. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. We want to develop an automatic slice plugin and create the slice when the user require it. -For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, we consider the CPU, Mem, GPU memory and other user-defined resource. +The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, MPS and MIG were chosen. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. An automatic slice plugin is planned to create slices on demand. +For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, CPU, Mem, GPU memory, and other user-defined resources are considered. HAMi is done by using [hami-core](https://github.com/Project-HAMi/HAMi-core), which is a cuda-hacking library. But mig is also widely used across the world. A unified API for dynamic-mig and hami-core is needed. ## Targets @@ -149,7 +149,7 @@ The Procedure of a vGPU task which uses dynamic-mig is shown below: <img src="https://github.com/Project-HAMi/HAMi/blob/master/docs/develop/imgs/hami-dynamic-mig-procedure.png?raw=true" width="800" alt="HAMi dynamic MIG procedure flowchart showing task scheduling process" /> -Note that after submitted a task, deviceshare plugin will iterate over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. +After submitting a task, the deviceshare plugin iterates over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. If you submit the example on an empty A100-PCIE-40GB node, then it will select a GPU and choose MIG template below: diff --git a/versioned_docs/version-v2.7.0/developers/protocol.md b/versioned_docs/version-v2.7.0/developers/protocol.md index 2d3bbd03..fdd826f6 100644 --- a/versioned_docs/version-v2.7.0/developers/protocol.md +++ b/versioned_docs/version-v2.7.0/developers/protocol.md @@ -31,7 +31,7 @@ hami.io/node-nvidia-register: GPU-00552014-5c87-89ac-b1a6-7b53aa24b0ec,10,32768, In this example, this node has two different AI devices, 2 Nvidia-V100 GPUs, and 2 Cambircon 370-X4 MLUs -Note that a device node may become unavailable due to hardware or network failure, if a node hasn't registered in last 5 minutes, scheduler will mark that node as 'unavailable'. +A device node may become unavailable due to hardware or network failure, if a node hasn't registered in last 5 minutes, scheduler will mark that node as 'unavailable'. Since system clock on scheduler node and 'device' node may not align properly, scheduler node will patch the following device node annotations every 30s diff --git a/versioned_docs/version-v2.7.0/developers/scheduling.md b/versioned_docs/version-v2.7.0/developers/scheduling.md index 02270146..9f44e903 100644 --- a/versioned_docs/version-v2.7.0/developers/scheduling.md +++ b/versioned_docs/version-v2.7.0/developers/scheduling.md @@ -104,7 +104,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Binpack` policy we can select `Node1`. +So, in `Binpack` policy the scheduler selects `Node1`. #### Spread @@ -124,7 +124,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Spread` policy we can select `Node2`. +So, in `Spread` policy the scheduler selects `Node2`. ### GPU-scheduler-policy @@ -147,7 +147,7 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Binpack` policy we can select `GPU2`. +So, in `Binpack` policy the scheduler selects `GPU2`. #### Spread @@ -166,4 +166,4 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Spread` policy we can select `GPU1`. +So, in `Spread` policy the scheduler selects `GPU1`. diff --git a/versioned_docs/version-v2.7.0/faq/faq.md b/versioned_docs/version-v2.7.0/faq/faq.md index 067ca2b8..91d95689 100644 --- a/versioned_docs/version-v2.7.0/faq/faq.md +++ b/versioned_docs/version-v2.7.0/faq/faq.md @@ -42,7 +42,7 @@ A vGPU is a logical instance of a physical GPU created using virtualization, all 4. **Design Intent** The design of vGPU aims to **allow one GPU to be shared by multiple tasks**, rather than letting one task occupy multiple vGPUs on the same GPU. The purpose of vGPU overcommitment is to improve GPU utilization, not to increase resource allocation for individual tasks. -## HAMi's `nvidia.com/priority` field only supports two levels. How can we implement multi-level, user-defined priority-based scheduling for a queue of jobs, especially when cluster resources are limited? +## HAMi's `nvidia.com/priority` field only supports two levels. How to implement multi-level, user-defined priority-based scheduling for a queue of jobs, especially when cluster resources are limited? **TL;DR** @@ -63,7 +63,7 @@ However, achieving multi-level priority scheduling **is feasible**. The recommen 1. HAMi integrates with Volcano via the [volcano-vgpu-device-plugin](https://github.com/Project-HAMi/volcano-vgpu-device-plugin). 2. It continues to manage the vGPU sharing and its own two-level runtime priority for tasks contending on the *same physical GPU*, as described earlier. -In summary, while HAMi's own priority serves a different, device-specific purpose (runtime preemption on a single card), implementing multi-level job scheduling priority is achievable by using **Volcano in conjunction with HAMi**. Volcano would handle which job from the queue is prioritized for resource allocation based on multiple priority levels, and HAMi would manage the GPU sharing and its specific on-device preemption. +While HAMi's own priority serves a different, device-specific purpose (runtime preemption on a single card), implementing multi-level job scheduling priority is achievable by using **Volcano in conjunction with HAMi**. Volcano would handle which job from the queue is prioritized for resource allocation based on multiple priority levels, and HAMi would manage the GPU sharing and its specific on-device preemption. ## Integration with Other Open-Source Tools diff --git a/versioned_docs/version-v2.7.0/get-started/deploy-with-helm.md b/versioned_docs/version-v2.7.0/get-started/deploy-with-helm.md index 80781bbd..16d2b3e7 100644 --- a/versioned_docs/version-v2.7.0/get-started/deploy-with-helm.md +++ b/versioned_docs/version-v2.7.0/get-started/deploy-with-helm.md @@ -99,7 +99,7 @@ sudo systemctl daemon-reload && systemctl restart containerd #### 2. Label your nodes {#label-your-nodes} Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". -Without this label, the nodes cannot be managed by our scheduler. +Without this label, the nodes cannot be managed by the HAMi scheduler. ```bash kubectl label nodes {nodeid} gpu=on @@ -113,7 +113,7 @@ First, you need to check your Kubernetes version by using the following command: kubectl version ``` -Then, add our repo in helm +Then, add the HAMi repo in helm ```bash helm repo add hami-charts https://project-hami.github.io/HAMi/ diff --git a/versioned_docs/version-v2.7.0/installation/prerequisites.md b/versioned_docs/version-v2.7.0/installation/prerequisites.md index 41bfa6d4..c283d5bd 100644 --- a/versioned_docs/version-v2.7.0/installation/prerequisites.md +++ b/versioned_docs/version-v2.7.0/installation/prerequisites.md @@ -59,7 +59,7 @@ sudo systemctl daemon-reload && systemctl restart containerd ### Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ```bash kubectl label nodes {nodeid} gpu=on diff --git a/versioned_docs/version-v2.7.0/userguide/enflame-device/enable-enflame-gcu-sharing.md b/versioned_docs/version-v2.7.0/userguide/enflame-device/enable-enflame-gcu-sharing.md index a8a3026f..caa96fbe 100644 --- a/versioned_docs/version-v2.7.0/userguide/enflame-device/enable-enflame-gcu-sharing.md +++ b/versioned_docs/version-v2.7.0/userguide/enflame-device/enable-enflame-gcu-sharing.md @@ -9,15 +9,15 @@ title: Enable Enflame GPU Sharing ***GCU sharing***: Each task can allocate a portion of GCU instead of a whole GCU card, thus GCU can be shared among multiple tasks. -***Device Memory and Core Control***: GCUs can be allocated with certain percentage of device memory and core, we make sure that it does not exceed the boundary. +***Device Memory and Core Control***: GCUs can be allocated with certain percentage of device memory and core, the limit is enforced and the boundary is not exceeded. ***Device UUID Selection***: You can specify which GCU devices to use or exclude using annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your GPU jobs will be automatically supported after installation. ## Prerequisites -* Enflame gcushare-device-plugin >= 2.1.6 (please consult your device provider, gcushare has two components: gcushare-scheduler-plugin and gcushare-device-plugin, we only need gcushare-device-plugin here ) +* Enflame gcushare-device-plugin >= 2.1.6 (please consult your device provider, gcushare has two components: gcushare-scheduler-plugin and gcushare-device-plugin, only the gcushare-device-plugin is needed here ) * driver version >= 1.2.3.14 * kubernetes >= 1.24 * enflame-container-toolkit >=2.0.50 diff --git a/versioned_docs/version-v2.7.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md b/versioned_docs/version-v2.7.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md index 9771b6bf..48cdb0f3 100644 --- a/versioned_docs/version-v2.7.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md +++ b/versioned_docs/version-v2.7.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md @@ -15,7 +15,7 @@ title: Enable Illuvatar GPU Sharing ***Device UUID Selection***: You can specify which GPU devices to use or exclude using annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your GPU jobs will be automatically supported after installation. ## Prerequisites diff --git a/versioned_docs/version-v2.7.0/userguide/monitoring/device-allocation.md b/versioned_docs/version-v2.7.0/userguide/monitoring/device-allocation.md index 03388648..e061e9c4 100644 --- a/versioned_docs/version-v2.7.0/userguide/monitoring/device-allocation.md +++ b/versioned_docs/version-v2.7.0/userguide/monitoring/device-allocation.md @@ -24,4 +24,4 @@ It contains the following metrics: | QuotaUsed | resourcequota usage for a certain device | `{quotaName="nvidia.com/gpucores", quotanamespace="default",limit="200",zone="vGPU"}` 100 | | vGPUPodsDeviceAllocated | vGPU Allocated from pods (This metric will be deprecated in v2.8.0, use vGPUMemoryAllocated and vGPUCoreAllocated instead.)| `{containeridx="Ascend310P",deviceusedcore="0",deviceuuid="aio-node74-arm-Ascend310P-0",nodename="aio-node74-arm",podname="ascend310p-pod",podnamespace="default",zone="vGPU"}` 3.221225472e+09 | -> **Note** Please note that, this is the overview about device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file +> **Note** This is an overview of device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. \ No newline at end of file diff --git a/versioned_docs/version-v2.7.0/userguide/nvidia-device/dynamic-mig-support.md b/versioned_docs/version-v2.7.0/userguide/nvidia-device/dynamic-mig-support.md index bea5435b..2c926be5 100644 --- a/versioned_docs/version-v2.7.0/userguide/nvidia-device/dynamic-mig-support.md +++ b/versioned_docs/version-v2.7.0/userguide/nvidia-device/dynamic-mig-support.md @@ -130,7 +130,7 @@ nvidia: :::note Helm installations and updates will follow the configuration specified in this file, overriding the default Helm settings. -Please note that HAMi will identify and use the first MIG template that matches the job, in the order defined in this configMap. +HAMi will identify and use the first MIG template that matches the job, in the order defined in this configMap. ::: ## Running MIG jobs diff --git a/versioned_docs/version-v2.7.0/userguide/nvidia-device/examples/specify-card-type-to-use.md b/versioned_docs/version-v2.7.0/userguide/nvidia-device/examples/specify-card-type-to-use.md index 397e984f..ebab2615 100644 --- a/versioned_docs/version-v2.7.0/userguide/nvidia-device/examples/specify-card-type-to-use.md +++ b/versioned_docs/version-v2.7.0/userguide/nvidia-device/examples/specify-card-type-to-use.md @@ -13,7 +13,7 @@ metadata: name: gpu-pod annotations: nvidia.com/use-gputype: "A100,V100" - #In this example, we want to run this job on A100 or V100 + #In this example, the job should run on A100 or V100 spec: containers: - name: ubuntu-container @@ -24,4 +24,4 @@ spec: nvidia.com/gpu: 2 # requesting 2 vGPUs ``` -> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, we want to run this job on A100 or V100* +> **NOTICE:** * You can assign this task to multiple GPU types, use comma to separate,In this example, the job should run on A100 or V100* diff --git a/versioned_docs/version-v2.8.0/contributor/adopters.md b/versioned_docs/version-v2.8.0/contributor/adopters.md index 8c521c76..40bd5058 100644 --- a/versioned_docs/version-v2.8.0/contributor/adopters.md +++ b/versioned_docs/version-v2.8.0/contributor/adopters.md @@ -1,12 +1,12 @@ # HAMi Adopters -So you and your organisation are using HAMi? That's great. We would love to hear from you! 💖 +So you and your organisation are using HAMi? That's great. ## Adding yourself [Here](https://github.com/Project-HAMi/website/blob/master/src/pages/adopters.mdx) lists the organisations who adopted the HAMi project in production. -You just need to add an entry for your company and upon merging it will automatically be added to our website. +You just need to add an entry for your company and upon merging it will automatically be added to the website. To add your organisation follow these steps: @@ -25,4 +25,4 @@ To add your organisation follow these steps: 6. Push the commit with `git push origin main`. 7. Open a Pull Request to [HAMi-io/website](https://github.com/Project-HAMi/website) and a preview build will turn up. -Thanks a lot for being part of our community - we very much appreciate it! +Thanks for being part of the community! diff --git a/versioned_docs/version-v2.8.0/contributor/cherry-picks.md b/versioned_docs/version-v2.8.0/contributor/cherry-picks.md index ca4c976b..a7a96275 100644 --- a/versioned_docs/version-v2.8.0/contributor/cherry-picks.md +++ b/versioned_docs/version-v2.8.0/contributor/cherry-picks.md @@ -62,7 +62,7 @@ your case by supplementing your PR with e.g., - Key stakeholder reviewers/approvers attesting to their confidence in the change being a required backport -It is critical that our full community is actively engaged on enhancements in +It is critical that the full community is actively engaged on enhancements in the project. If a released feature was not enabled on a particular provider's platform, this is a community miss that needs to be resolved in the `master` branch for subsequent releases. Such enabling will not be backported to the diff --git a/versioned_docs/version-v2.8.0/contributor/contribute-docs.md b/versioned_docs/version-v2.8.0/contributor/contribute-docs.md index 179e55a8..16d5fcc9 100644 --- a/versioned_docs/version-v2.8.0/contributor/contribute-docs.md +++ b/versioned_docs/version-v2.8.0/contributor/contribute-docs.md @@ -9,25 +9,25 @@ the `Project-HAMi/website` repository. ## Prerequisites - Docs, like codes, are also categorized and stored by version. - 1.3 is the first version we have archived. + 1.3 is the first archived version. - Docs need to be translated into multiple languages for readers from different regions. The community now supports both Chinese and English. English is the official language of documentation. -- For our docs we use markdown. If you are unfamiliar with Markdown, +- The docs use markdown. If you are unfamiliar with Markdown, please see [https://guides.github.com/features/mastering-markdown/](https://guides.github.com/features/mastering-markdown/) or [https://www.markdownguide.org/](https://www.markdownguide.org/) if you are looking for something more substantial. -- We get some additions through [Docusaurus 2](https://docusaurus.io/), a model static website generator. +- The site uses [Docusaurus 2](https://docusaurus.io/), a model static website generator. ## Setup -You can set up your local environment by cloning our website repository. +Clone the website repository to set up a local environment. ```shell git clone https://github.com/Project-HAMi/website.git cd website ``` -Our website is organized like below: +The website is organized as follows: ```text website @@ -88,7 +88,7 @@ title: A doc with tags ``` The top section between two lines of --- is the Front Matter section. -Here we define a couple of entries which tell Docusaurus how to handle the article: +The entries tell Docusaurus how to handle the article: - Title is the equivalent of the `<h1>` in a HTML document or `# <title>` in a Markdown article. - Each document has a unique ID. By default, a document ID is the name of the document @@ -106,7 +106,7 @@ You can easily route to other places by adding any of the following links: You can use relative paths to index the corresponding files. - Link to pictures or other resources. If your article contains images, prefer storing them in `/static/img/docs/` and linking - with absolute paths. We use language-aware folders: + with absolute paths. Language-aware folders are used: - `/static/img/docs/common/` for shared images - `/static/img/docs/en/` for English-only images - `/static/img/docs/zh/` for Chinese-only images @@ -125,7 +125,7 @@ Creating a sidebar is useful to: - Display a sidebar on each of those documents - Provide paginated navigation, with next/previous button -For our docs, you can know how our documents are organized from +The document organization is defined in [https://github.com/Project-HAMi/website/blob/main/sidebars.js](https://github.com/Project-HAMi/website/blob/main/sidebars.js). ```js @@ -175,7 +175,7 @@ If you're not sure where your docs are located, you can ask community members in There are two situations about the Chinese version of the document: -- You want to translate our existing English docs to Chinese. In this case, +- To translate existing English docs to Chinese: you need to modify the corresponding file content from [https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current](https://github.com/Project-HAMi/website/tree/main/i18n/zh/docusaurus-plugin-content-docs/current). The organization of this directory is exactly the same as the outer layer. @@ -202,6 +202,6 @@ If the previewed page is not what you expected, please check your docs again. ### Versioning -For the newly supplemented documents of each version, we will synchronize to the latest version +For the newly supplemented documents of each version, they are synchronized to the latest version on the release date of each version, and the documents of the old version will not be modified. -For errata found in the documentation, we will fix it with every release. +For errata found in the documentation, fixes are applied with every release. diff --git a/versioned_docs/version-v2.8.0/contributor/contributing.md b/versioned_docs/version-v2.8.0/contributor/contributing.md index fab6d31c..796c8e36 100644 --- a/versioned_docs/version-v2.8.0/contributor/contributing.md +++ b/versioned_docs/version-v2.8.0/contributor/contributing.md @@ -6,7 +6,7 @@ Welcome to HAMi! ## Code of Conduct -Please make sure to read and observe our [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) +Please make sure to read and observe the [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) ## Community Expectations @@ -20,7 +20,7 @@ HAMi is a community project driven by its community which strives to promote a h ## Your First Contribution -We will help you to contribute in different areas like filing issues, developing features, fixing critical bugs and +Help is available for contributing in areas like filing issues, developing features, fixing critical bugs and getting your work reviewed and merged. If you have questions about the development process, @@ -28,7 +28,7 @@ feel free to [file an issue](https://github.com/Project-HAMi/HAMi/issues/new/cho ## Find something to work on -We are always in need of help, be it fixing documentation, reporting bugs or writing some code. +Contributions are always welcome - fixing documentation, reporting bugs or writing some code. Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing. Here is how you get started. @@ -40,7 +40,7 @@ For example, [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi) has [help wanted](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) and [good first issue](https://github.com/Project-HAMi/HAMi/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) labels for issues that should not need deep knowledge of the system. -We can help new contributors who wish to work on such issues. +Maintainers can help new contributors who wish to work on such issues. Another good way to contribute is to find a documentation improvement, such as a missing/broken link. Please see [Contributor Workflow](#contributor-workflow) below for the workflow. @@ -51,7 +51,7 @@ When you are willing to take on an issue, just reply on the issue. The maintaine ### File an Issue -While we encourage everyone to contribute code, it is also appreciated when someone reports an issue. +Code contributions are welcome, and bug reports are equally appreciated. Issues should be filed under the appropriate HAMi sub-repository. *Example:* a HAMi issue should be opened to [Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi/issues). diff --git a/versioned_docs/version-v2.8.0/contributor/governance.md b/versioned_docs/version-v2.8.0/contributor/governance.md index f49b23b7..94c265e7 100644 --- a/versioned_docs/version-v2.8.0/contributor/governance.md +++ b/versioned_docs/version-v2.8.0/contributor/governance.md @@ -15,11 +15,11 @@ The HAMi and its leadership embrace the following values: * Fairness: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits. -* Community over Product or Company: Sustaining and growing our community takes +* Community over Product or Company: Sustaining and growing the community takes priority over shipping code or sponsors' organizational goals. Each contributor participates in the project as an individual. -* Inclusivity: We innovate through different perspectives and skill sets, which +* Inclusivity: Innovation happens through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment. * Participation: Responsibilities within the project are earned through diff --git a/versioned_docs/version-v2.8.0/contributor/ladder.md b/versioned_docs/version-v2.8.0/contributor/ladder.md index b9f51fbc..8cb50808 100644 --- a/versioned_docs/version-v2.8.0/contributor/ladder.md +++ b/versioned_docs/version-v2.8.0/contributor/ladder.md @@ -4,7 +4,7 @@ title: Contributor Ladder This docs different ways to get involved and level up within the project. You can see different roles within the project in the contributor roles. -Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. +This contributor ladder outlines the different contributor roles within the project. Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. @@ -126,7 +126,7 @@ The current list of maintainers can be found in the [MAINTAINERS](https://github ### An active maintainer should -* Actively participate in reviewing pull requests and incoming issues. Note that there are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. +* Actively participate in reviewing pull requests and incoming issues. There are no hard rules on what is “active enough” and this is left up to the judgement of the current group of maintainers. * Actively participate in discussions about design and the future of the project. diff --git a/versioned_docs/version-v2.8.0/developers/dynamic-mig.md b/versioned_docs/version-v2.8.0/developers/dynamic-mig.md index ebe587f2..ee3b9ed8 100644 --- a/versioned_docs/version-v2.8.0/developers/dynamic-mig.md +++ b/versioned_docs/version-v2.8.0/developers/dynamic-mig.md @@ -9,8 +9,8 @@ This feature will not be implemented without the help of @sailorvii. ## Introduction -The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, so we chose the MPS and MIG. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. We want to develop an automatic slice plugin and create the slice when the user require it. -For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, we consider the CPU, Mem, GPU memory and other user-defined resource. +The NVIDIA GPU build-in sharing method includes: time-slice, MPS and MIG. The context switch for time slice sharing would waste some time, MPS and MIG were chosen. The GPU MIG profile is variable, the user could acquire the MIG device in the profile definition, but current implementation only defines the dedicated profile before the user requirement. That limits the usage of MIG. An automatic slice plugin is planned to create slices on demand. +For the scheduling method, node-level binpack and spread will be supported. Referring to the binpack plugin, CPU, Mem, GPU memory, and other user-defined resources are considered. HAMi is done by using [hami-core](https://github.com/Project-HAMi/HAMi-core), which is a cuda-hacking library. But mig is also widely used across the world. A unified API for dynamic-mig and hami-core is needed. ## Targets @@ -149,7 +149,7 @@ The Procedure of a vGPU task which uses dynamic-mig is shown below: <img src="https://github.com/Project-HAMi/HAMi/blob/master/docs/develop/imgs/hami-dynamic-mig-procedure.png?raw=true" width="800" alt="HAMi dynamic MIG procedure flowchart showing task scheduling process" /> -Note that after submitted a task, deviceshare plugin will iterate over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. +After submitting a task, the deviceshare plugin iterates over templates defined in configMap `hami-scheduler-device`, and find the first available template to fit. You can always change the content of that configMap, and restart vc-scheduler to customize. If you submit the example on an empty A100-PCIE-40GB node, then it will select a GPU and choose MIG template below: diff --git a/versioned_docs/version-v2.8.0/developers/protocol.md b/versioned_docs/version-v2.8.0/developers/protocol.md index d6aead03..af093054 100644 --- a/versioned_docs/version-v2.8.0/developers/protocol.md +++ b/versioned_docs/version-v2.8.0/developers/protocol.md @@ -31,7 +31,7 @@ hami.io/node-nvidia-register: GPU-00552014-5c87-89ac-b1a6-7b53aa24b0ec,10,32768, In this example, this node has two different AI devices, 2 Nvidia-V100 GPUs, and 2 Cambircon 370-X4 MLUs -Note that a device node may become unavailable due to hardware or network failure, if a node hasn't registered in last 5 minutes, scheduler will mark that node as 'unavailable'. +A device node may become unavailable due to hardware or network failure, if a node hasn't registered in last 5 minutes, scheduler will mark that node as 'unavailable'. Since system clock on scheduler node and 'device' node may not align properly, scheduler node will patch the following device node annotations every 30s diff --git a/versioned_docs/version-v2.8.0/developers/scheduling.md b/versioned_docs/version-v2.8.0/developers/scheduling.md index 02f1cc9c..5cde63db 100644 --- a/versioned_docs/version-v2.8.0/developers/scheduling.md +++ b/versioned_docs/version-v2.8.0/developers/scheduling.md @@ -105,7 +105,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Binpack` policy we can select `Node1`. +So, in `Binpack` policy the scheduler selects `Node1`. #### Spread @@ -127,7 +127,7 @@ Node1 score: ((1+3)/4) * 10= 10 Node2 score: ((1+2)/4) * 10= 7.5 ``` -So, in `Spread` policy we can select `Node2`. +So, in `Spread` policy the scheduler selects `Node2`. ### GPU-scheduler-policy @@ -153,7 +153,7 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Binpack` policy we can select `GPU2`. +So, in `Binpack` policy the scheduler selects `GPU2`. #### Spread @@ -175,4 +175,4 @@ GPU1 Score: ((20+10)/100 + (1000+2000)/8000)) * 10 = 6.75 GPU2 Score: ((20+70)/100 + (1000+6000)/8000)) * 10 = 17.75 ``` -So, in `Spread` policy we can select `GPU1`. +So, in `Spread` policy the scheduler selects `GPU1`. diff --git a/versioned_docs/version-v2.8.0/faq/faq.md b/versioned_docs/version-v2.8.0/faq/faq.md index f5ee5c04..f661e687 100644 --- a/versioned_docs/version-v2.8.0/faq/faq.md +++ b/versioned_docs/version-v2.8.0/faq/faq.md @@ -41,7 +41,7 @@ A vGPU is a logical instance of a physical GPU created using virtualization, all 4. **Design Intent** The design of vGPU aims to **allow one GPU to be shared by multiple tasks**, rather than letting one task occupy multiple vGPUs on the same GPU. The purpose of vGPU overcommitment is to improve GPU utilization, not to increase resource allocation for individual tasks. -## HAMi's `nvidia.com/priority` field only supports two levels. How can we implement multi-level, user-defined priority-based scheduling for a queue of jobs, especially when cluster resources are limited? +## HAMi's `nvidia.com/priority` field only supports two levels. How to implement multi-level, user-defined priority-based scheduling for a queue of jobs, especially when cluster resources are limited? **TL;DR** @@ -62,7 +62,7 @@ However, achieving multi-level priority scheduling **is feasible**. The recommen 1. HAMi integrates with Volcano via the [volcano-vgpu-device-plugin](https://github.com/Project-HAMi/volcano-vgpu-device-plugin). 2. It continues to manage the vGPU sharing and its own two-level runtime priority for tasks contending on the *same physical GPU*, as described earlier. -In summary, while HAMi's own priority serves a different, device-specific purpose (runtime preemption on a single card), implementing multi-level job scheduling priority is achievable by using **Volcano in conjunction with HAMi**. Volcano would handle which job from the queue is prioritized for resource allocation based on multiple priority levels, and HAMi would manage the GPU sharing and its specific on-device preemption. +While HAMi's own priority serves a different, device-specific purpose (runtime preemption on a single card), implementing multi-level job scheduling priority is achievable by using **Volcano in conjunction with HAMi**. Volcano would handle which job from the queue is prioritized for resource allocation based on multiple priority levels, and HAMi would manage the GPU sharing and its specific on-device preemption. ## Integration with Other Open-Source Tools diff --git a/versioned_docs/version-v2.8.0/get-started/deploy-with-helm.md b/versioned_docs/version-v2.8.0/get-started/deploy-with-helm.md index 80781bbd..16d2b3e7 100644 --- a/versioned_docs/version-v2.8.0/get-started/deploy-with-helm.md +++ b/versioned_docs/version-v2.8.0/get-started/deploy-with-helm.md @@ -99,7 +99,7 @@ sudo systemctl daemon-reload && systemctl restart containerd #### 2. Label your nodes {#label-your-nodes} Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". -Without this label, the nodes cannot be managed by our scheduler. +Without this label, the nodes cannot be managed by the HAMi scheduler. ```bash kubectl label nodes {nodeid} gpu=on @@ -113,7 +113,7 @@ First, you need to check your Kubernetes version by using the following command: kubectl version ``` -Then, add our repo in helm +Then, add the HAMi repo in helm ```bash helm repo add hami-charts https://project-hami.github.io/HAMi/ diff --git a/versioned_docs/version-v2.8.0/installation/prerequisites.md b/versioned_docs/version-v2.8.0/installation/prerequisites.md index 8a90cbd0..c4670ca9 100644 --- a/versioned_docs/version-v2.8.0/installation/prerequisites.md +++ b/versioned_docs/version-v2.8.0/installation/prerequisites.md @@ -62,7 +62,7 @@ sudo systemctl daemon-reload && systemctl restart containerd ### Label your nodes -Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by our scheduler. +Label your GPU nodes for scheduling with HAMi by adding the label "gpu=on". Without this label, the nodes cannot be managed by the HAMi scheduler. ```bash kubectl label nodes {nodeid} gpu=on diff --git a/versioned_docs/version-v2.8.0/userguide/enflame-device/enable-enflame-gcu-sharing.md b/versioned_docs/version-v2.8.0/userguide/enflame-device/enable-enflame-gcu-sharing.md index c95ca130..55d106e8 100644 --- a/versioned_docs/version-v2.8.0/userguide/enflame-device/enable-enflame-gcu-sharing.md +++ b/versioned_docs/version-v2.8.0/userguide/enflame-device/enable-enflame-gcu-sharing.md @@ -9,15 +9,15 @@ title: Enable Enflame GPU Sharing ***GCU sharing***: Each task can allocate a portion of GCU instead of a whole GCU card, thus GCU can be shared among multiple tasks. -***Device Memory and Core Control***: GCUs can be allocated with certain percentage of device memory and core, we make sure that it does not exceed the boundary. +***Device Memory and Core Control***: GCUs can be allocated with certain percentage of device memory and core, the limit is enforced and the boundary is not exceeded. ***Device UUID Selection***: You can specify which GCU devices to use or exclude using annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your GPU jobs will be automatically supported after installation. ## Prerequisites -* Enflame gcushare-device-plugin >= 2.1.6 (please consult your device provider, gcushare has two components: gcushare-scheduler-plugin and gcushare-device-plugin, we only need gcushare-device-plugin here ) +* Enflame gcushare-device-plugin >= 2.1.6 (please consult your device provider, gcushare has two components: gcushare-scheduler-plugin and gcushare-device-plugin, only the gcushare-device-plugin is needed here ) * driver version >= 1.2.3.14 * kubernetes >= 1.24 * enflame-container-toolkit >=2.0.50 diff --git a/versioned_docs/version-v2.8.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md b/versioned_docs/version-v2.8.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md index 3462da64..12592dab 100644 --- a/versioned_docs/version-v2.8.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md +++ b/versioned_docs/version-v2.8.0/userguide/iluvatar-device/enable-illuvatar-gpu-sharing.md @@ -14,7 +14,7 @@ title: Enable Illuvatar GPU Sharing ***Device UUID Selection***: You can specify which GPU devices to use or exclude using annotations. -***Very Easy to use***: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. +***Very Easy to use***: You don't need to modify your task yaml to use the HAMi scheduler. All your GPU jobs will be automatically supported after installation. ## Prerequisites diff --git a/versioned_docs/version-v2.8.0/userguide/monitoring/device-allocation.md b/versioned_docs/version-v2.8.0/userguide/monitoring/device-allocation.md index 8fb12d60..f81c21b6 100644 --- a/versioned_docs/version-v2.8.0/userguide/monitoring/device-allocation.md +++ b/versioned_docs/version-v2.8.0/userguide/monitoring/device-allocation.md @@ -23,4 +23,4 @@ It contains the following metrics: | QuotaUsed | resourcequota usage for a certain device | `{quotaName="nvidia.com/gpucores", quotanamespace="default",limit="200",zone="vGPU"}` 100 | | vGPUPodsDeviceAllocated | vGPU Allocated from pods (This metric will be deprecated in v2.8.0, use vGPUMemoryAllocated and vGPUCoreAllocated instead.)| `{containeridx="Ascend310P",deviceusedcore="0",deviceuuid="aio-node74-arm-Ascend310P-0",nodename="aio-node74-arm",podname="ascend310p-pod",podnamespace="default",zone="vGPU"}` 3.221225472e+09 | -> **Note** Please note that, this is the overview about device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. +> **Note** This is an overview of device allocation, it is NOT device real-time usage metrics. For that part, see real-time device usage. diff --git a/versioned_docs/version-v2.8.0/userguide/nvidia-device/dynamic-mig-support.md b/versioned_docs/version-v2.8.0/userguide/nvidia-device/dynamic-mig-support.md index bea5435b..2c926be5 100644 --- a/versioned_docs/version-v2.8.0/userguide/nvidia-device/dynamic-mig-support.md +++ b/versioned_docs/version-v2.8.0/userguide/nvidia-device/dynamic-mig-support.md @@ -130,7 +130,7 @@ nvidia: :::note Helm installations and updates will follow the configuration specified in this file, overriding the default Helm settings. -Please note that HAMi will identify and use the first MIG template that matches the job, in the order defined in this configMap. +HAMi will identify and use the first MIG template that matches the job, in the order defined in this configMap. ::: ## Running MIG jobs diff --git a/versioned_docs/version-v2.8.0/userguide/nvidia-device/examples/specify-card-type-to-use.md b/versioned_docs/version-v2.8.0/userguide/nvidia-device/examples/specify-card-type-to-use.md index a2f0072a..f3b8f413 100644 --- a/versioned_docs/version-v2.8.0/userguide/nvidia-device/examples/specify-card-type-to-use.md +++ b/versioned_docs/version-v2.8.0/userguide/nvidia-device/examples/specify-card-type-to-use.md @@ -11,7 +11,7 @@ metadata: name: gpu-pod annotations: nvidia.com/use-gputype: "A100,V100" - #In this example, we want to run this job on A100 or V100 + #In this example, the job should run on A100 or V100 spec: containers: - name: ubuntu-container @@ -22,4 +22,4 @@ spec: nvidia.com/gpu: 2 # requesting 2 vGPUs ``` -> **NOTICE:** *You can assign this task to multiple GPU types, use comma to separate,In this example, we want to run this job on A100 or V100* +> **NOTICE:** *You can assign this task to multiple GPU types, use comma to separate,In this example, the job should run on A100 or V100*