intel · klihub · Mar 12, 2021 · Mar 3, 2021
@@ -1,8 +1,7 @@
-# CRI Resource Manager for Kubernetes
+# CRI Resource Manager for Kubernetes\*
 
 Welcome!
 
 ### See our [Documentation][documentation] site for detailed documentation.
 
 [documentation]: https://intel.github.io/cri-resource-manager
-
@@ -1,9 +1,10 @@
 # Contributing
 
-Please use the GitHub infrastructure for contributing to
+Please use the GitHub\* infrastructure for contributing to
 CRI Resource Manager.
 Use [pull requests](https://github.com/intel/cri-resource-manager/pulls)
-to contribute code, bug fixes, or if you want to discuss your ideas in terms of code.
-Open [issues](https://github.com/intel/cri-resource-manager/issues) to report bugs,
-request new features, or if you want to discuss any other topics related to CRI Resource
-Manager or orchestration resource management in general.
+to contribute code, bug fixes, or if you want to discuss your ideas in terms of
+code. Open [issues](https://github.com/intel/cri-resource-manager/issues) to
+report bugs, request new features, or if you want to discuss any other topics
+related to CRI Resource Manager or orchestration resource management in
+general.
@@ -1,16 +1,17 @@
 # Installation
 
-## Installing From Packages
+## Installing from packages
 
 You can install CRI Resource Manager from `deb` or `rpm` packages
 for supported distros.
 
-  - [download](https://github.com/intel/cri-resource-manager/releases/latest) packages
+  - [download](https://github.com/intel/cri-resource-manager/releases/latest)
+  packages
   - install them:
     - for rpm packages: `sudo rpm -Uvh <packages>`
     - for deb packages: `sudo dpkg -i <packages>`
 
-## Installing From Sources
+## Installing from sources
 
 Although not recommended, you can install CRI Resource Manager from sources:
 
@@ -21,7 +22,7 @@ You will need at least `git`, `golang 1.14` or newer, `GNU make`, `bash`,
 `find`, `sed`, `head`, `date`, and `install` to be able to build and install
 from sources.
 
-## Building Packages for the Distro of Your Host
+## Building packages for the distro of your host
 
 You can build packages for the `$distro` of your host by executing the
 following command:
@@ -33,7 +34,7 @@ make packages
 If the `$version` of your `$distro` is supported, this will leave the
 resulting packages in `packages/$distro-$version`. Building packages
 this way requires `docker`, but it does not require you to install
-the full set of build dependecies of CRI Resource Manager to your host.
+the full set of build dependencies of CRI Resource Manager to your host.
 
 If you want to build packages without docker, you can use either
 `make rpm` or `make deb`, depending on which supported distro you are
@@ -49,34 +50,34 @@ ls dockerfiles/cross-build
 If you see a `Dockerfile.$distro-$version` matching your host then your
 distro is supported.
 
-## Building Packages for Another Distro
+## Building packages for another distro
 
 You can cross-build packages of the native `$type` for a particular
-`$version` of a `$distro` by running the follwing command:
+`$version` of a `$distro` by running the following command:
 
 ```
 make cross-$type.$distro-$version
 ```
 
-Similarly to `make packages` this will build packages using a `docker`
+Similarly to `make packages`, this will build packages using a `Docker\*`
 container. However, instead of building for your host, it will build them
 for the specified distro. For instance `make cross-deb.ubuntu-18.04` will
-build `deb` packages for `Ubuntu 18.04`, and `make cross-rpm.centos-8` will
-build `rpm` packages for `CentOS 8`
+build `deb` packages for `Ubuntu\* 18.04` and `make cross-rpm.centos-8` will
+build `rpm` packages for `CentOS\* 8`
 
-## Post-Install Configuration
+## Post-install configuration
 
-The provided packages install `systemd` service files and sample configuration.
-The easiest way to get up and running is to rename the sample configuration and
-start CRI Resource Manager using systemd. You can do this using the following
-commands:
+The provided packages install `systemd` service files and a sample
+configuration. The easiest way to get up and running is to rename the sample
+configuration and start CRI Resource Manager using systemd. You can do this
+using the following commands:
 
 ```
 mv /etc/cri-resmgr/fallback.cfg.sample /etc/cri-resmgr/fallback.cfg
 systemctl start cri-resource-manager
 ```
 
-If you want, you can set up automatic starting of CRI Resource Manager
+If you want, you can set CRI Resource Manager to automatically start
 when your system boots with this command:
 
 ```
@@ -88,7 +89,7 @@ passed to CRI Resource Manager upon startup. You can change these by editing
 this file and then restarting CRI Resource Manager, like this:
 
 ```
-# On debian-based systems edit the defaults like this:
+# On Debian\*-based systems edit the defaults like this:
 ${EDITOR:-vi} /etc/default/cri-resource-manager
 # On rpm-based systems edit the defaults like this:
 ${EDITOR:-vi} /etc/sysconfig/cri-resource-manager

@@ -6,15 +6,15 @@ dockershim+docker), relaying requests and responses back and forth. The main
 purpose of the proxy is to apply hardware-aware resource allocation policies
 to the containers running in the system.
 
-Policies are applied by either modifying a request before forwarding it, or
+Policies are applied by either modifying a request before forwarding it or
 by performing extra actions related to the request during its processing and
 proxying. There are several policies available, each with a different set of
 goals in mind and implementing different hardware allocation strategies. The
 details of whether and how a CRI request is altered or if extra actions are
-performed depend on which policy is active in CRI Resource Manager, and how
+performed depend on which policy is active in CRI Resource Manager and how
 that policy is configured.
 
 The current goal for the CRI Resource Manager is to prototype and experiment
-with new Kubernetes container placement policies. The existing policies are
+with new Kubernetes\* container placement policies. The existing policies are
 written with this in mind and the intended setup is for the Resource Manager
 to only act as a proxy for the Kubernetes Node Agent, kubelet.
@@ -1,34 +1,36 @@
 # Node Agent
 
 CRI Resource Manager can be configured dynamically using the CRI Resource
-Manager Node Agent and Kubernetes ConfigMaps. The agent can be build using
-the [provided Dockerfile](/cmd/cri-resmgr-agent/Dockerfile). It can be deployed
-as a `DaemonSet` in the cluster using the [provided deployment file](/cmd/cri-resmgr-agent/agent-deployment.yaml).
+Manager Node Agent and Kubernetes\* ConfigMaps. The agent can be build using
+the [provided Dockerfile](/cmd/cri-resmgr-agent/Dockerfile). It can be
+deployed as a `DaemonSet` in the cluster using the
+[provided deployment file](/cmd/cri-resmgr-agent/agent-deployment.yaml).
 
-To run the agent manually or as a `systemd` service, set the environment variable
-`NODE_NAME` to the name of the cluster node the agent is running on. If necessary
-pass it the credentials for accessing the cluster using the the `-kubeconfig <file>`
-command line option.
+To run the agent manually or as a `systemd` service, set the environment
+variable `NODE_NAME` to the name of the cluster node the agent is running
+on. If necessary pass it the credentials for accessing the cluster using
+ the `-kubeconfig <file>` command line option.
 
-The agent monitors two ConfigMaps for the node, a primary node-specific one, and
-a secondary group-specific or default one, depending on whether the node belongs
-to a configuration group. The node-specific ConfigMap always takes precedence over
-the others.
+The agent monitors two ConfigMaps for the node, a primary node-specific one
+and a secondary group-specific or default one, depending on whether the node
+belongs to a configuration group. The node-specific ConfigMap always takes
+precedence over the others.
 
 The names of these ConfigMaps are
 
 1. `cri-resmgr-config.node.$NODE_NAME`: primary, node-specific configuration
-2. `cri-resmgr-config.group.$GROUP_NAME`: secondary group-specific node configuration
-3. `cri-resmgr-config.default`: secondary: secondary default node configuration
+2. `cri-resmgr-config.group.$GROUP_NAME`: secondary group-specific node
+    configuration
+3. `cri-resmgr-config.default`: secondary: secondary default node
+    configuration
 
 You can assign a node to a configuration group by setting the
 `cri-resource-manager.intel.com/group` label on the node to the name of
-the configuration group. You can remove a node from its group by deleting the node
-group label.
-
-There is a [sample ConfigMap spec](/sample-configs/cri-resmgr-configmap.example.yaml)
-that contains anode-specific, a group-specific, and a default ConfigMap examples.
-See [any available policy-specific documentation](policy/index.rst) for more information on the
-policy configurations.
-
-
+the configuration group. You can remove a node from its group by deleting
+the node group label.
+
+There is a
+[sample ConfigMap spec](/sample-configs/cri-resmgr-configmap.example.yaml)
+that contains a node-specific, a group-specific, and a default ConfigMap
+example. See [any available policy-specific documentation](policy/index.rst)
+for more information on the policy configurations.
@@ -1,7 +1,7 @@
 # Quick-start
 
-The following describes the Minimal steps to get started with CRI Resource
-Manager.
+The following describes the minimum number of steps to get started with CRI
+Resource Manager.
 
 ## Pre-requisites
 
@@ -12,9 +12,9 @@ Manager.
 
 First, install and setup cri-resource-manager.
 
-### Install Package
+### Install package
 
-#### CentOS, Fedora and SUSE
+#### CentOS\*, Fedora\*, and SUSE\*
 
 ```
 CRIRM_VERSION=`curl -s "https://api.github.com/repos/intel/cri-resource-manager/releases/latest" | \
@@ -23,7 +23,7 @@ source /etc/os-release
 sudo rpm -Uvh https://github.com/intel/cri-resource-manager/releases/download/v${CRIRM_VERSION}/cri-resource-manager-${CRIRM_VERSION}-0.x86_64.${ID}-${VERSION_ID}.rpm
 ```
 
-#### Ubuntu and Debian
+#### Ubuntu\* and Debian\*
 ```
 CRIRM_VERSION=`curl -s "https://api.github.com/repos/intel/cri-resource-manager/releases/latest" | \
                jq .tag_name | tr -d '"v'`
@@ -32,7 +32,7 @@ pkg=cri-resource-manager_${CRIRM_VERSION}_amd64.${ID}-${VERSION_ID}.deb; curl -L
 ```
 
 
-### Setup and Verify
+### Setup and verify
 
 Create configuration and start cri-resource-manager
 ```
@@ -50,13 +50,13 @@ systemctl status cri-resource-manager
 Next, you need to configure kubelet to user cri-resource-manager as it's
 container runtime endpoint.
 
-### Existing Cluster
+### Existing cluster
 
 When integrating into an existing cluster you need to change kubelet to use
 cri-resmgr instead of the existing container runtime (expecting containerd
 here).
 
-#### CentOS, Fedora and SUSE
+#### CentOS, Fedora, and SUSE
 ```
 sudo sed '/KUBELET_EXTRA_ARGS/ s!$! --container-runtime-endpoint=/var/run/cri-resmgr/cri-resmgr.sock!' -i /etc/sysconfig/kubelet
 sudo systemctl restart kubelet
@@ -70,8 +70,9 @@ sudo systemctl restart kubelet
 
 ### New Cluster
 
-When in the process of setting up a new cluster you simply point kubelet to use
-the cri-resmgr cri sockets on cluster node setup time. E.g. with kubeadm:
+When in the process of setting up a new cluster you simply point the kubelet
+to use the cri-resmgr cri sockets on cluster node setup time. Here's an
+example with kubeadm:
 ```
 kubeadm join --cri-socket /var/run/cri-resmgr/cri-resmgr.sock \
 ...
@@ -82,8 +83,11 @@ kubeadm join --cri-socket /var/run/cri-resmgr/cri-resmgr.sock \
 
 Congratulations, you now have cri-resource-manager running on your system and
 policying container resource allocations. Next, you could see:
-- [Installation](installation.md) for more installation options and detailed installation instructions
+- [Installation](installation.md) for more installation options and
+  detailed installation instructions
 - [Setup](setup.md) for details on setup and usage
-- [Node Agent](node-agent.md) for seting up cri-resmgr-agent for dynamic configuration and more
+- [Node Agent](node-agent.md) for setting up cri-resmgr-agent for dynamic
+  configuration and more
 - [Webhook](webhook.md) for setting up our resource-annotating webhook
-- [Kata support](setup.md#kata-containers) for setting up CRI-RM with Kata containers
+- [Support for Kata Containers\*](setup.md#kata-containers) for setting up
+  CRI-RM with Kata Containers
@@ -1,3 +1,4 @@
 # Reporting a Potential Security Vulnerability
 
-Please visit [intel.com/security](https://intel.com/security) for reporting security issues.
+Please visit [intel.com/security](https://intel.com/security) to report
+security issues.