Update documentation for v0.2

Auto-generated from v0.2.2-7-g6f66b4e by 'update-gh-pages.sh'

v0.2/.buildinfo

@@ -1,4 +1,4 @@
 # Sphinx build info version 1
 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: 756386a0f19b997858d5bd911f4389a1
+config: 7fe59d849c67e5dabd1a995a3a779af2
 tags: 645f666f9bcd5a90fca523b33c5a78b7

v0.2/_sources/docs/deployment/balloons.md.txt

@@ -0,0 +1,2 @@
+```{include} ../../deployment/helm/balloons/README.md
+```

v0.2/_sources/docs/deployment/index.md.txt

@@ -0,0 +1,15 @@
+# Deployment
+
+The only supported installation method of the NRI plugins at the moment is
+through Helm.
+
+```{toctree}
+---
+maxdepth: 2
+caption: Contents
+---
+balloons.md
+topology-aware.md
+memory-qos.md
+memtierd.md
+```

v0.2/_sources/docs/deployment/memory-qos.md.txt

@@ -0,0 +1,2 @@
+```{include} ../../deployment/helm/memory-qos/README.md
+```

v0.2/_sources/docs/deployment/memtierd.md.txt

@@ -0,0 +1,2 @@
+```{include} ../../deployment/helm/memtierd/README.md
+```

v0.2/_sources/docs/deployment/topology-aware.md.txt

@@ -0,0 +1,2 @@
+```{include} ../../deployment/helm/topology-aware/README.md
+```

v0.2/_sources/docs/index.md.txt

@@ -8,6 +8,7 @@ caption: Contents
 introduction.md
 resource-policy/index.rst
 memory/index.md
+deployment/index.md
 contributing.md
 Project GitHub repository <https://github.com/containers/nri-plugins>
 ```

v0.2/_sources/docs/introduction.md.txt

@@ -1,6 +1,7 @@
 # Introduction
 
 The NRI plugins is a collection of NRI (Node Resource Interface) based plugins
-to manage various aspects of pod and container life cycle.
-For example the [resource policy plugins](resource-policy/policy/index.md) can be used to modify
-the container resource allocation depending on available system resources.
+to manage various aspects of pod and container life cycle. For example the
+[resource policy plugins](resource-policy/policy/index.md) can be used to
+modify the container resource allocation depending on available system
+resources.

v0.2/_sources/docs/memory/memory-qos.md.txt

@@ -6,6 +6,7 @@ parameters: memory QoS classes and direct memory annotations.
 ## Workload configuration
 
 There are two configuration methods:
+
 1. Memory QoS classes: memory parameters are calculated in the same
    way for all workloads that belong to the same class.
 2. Direct workload-specific memory parameters.
@@ -48,6 +49,7 @@ Plugin configuration lists memory QoS classes and their parameters
 that affect calculating actual memory parameters.
 
 `classes:` is followed by list of maps with following keys and values:
+
 - `name` (string): name of the memory QoS class, matches
   `class.memory-qos.nri.io` annotation values.
 - `swaplimitratio` (from 0.0 to 1.0): minimum ratio of container's
@@ -94,7 +96,8 @@ This configuration defines the following.
 
 - Containerd v1.7+
 - Enable NRI in /etc/containerd/config.toml:
-  ```
+
+  ```toml
   [plugins."io.containerd.nri.v1.nri"]
     disable = false
     disable_connections = false

v0.2/_sources/docs/memory/memtierd.md.txt

@@ -31,6 +31,7 @@ The class of a pod or a container is defined using pod annotations:
 Plugin configuration lists workload classes and their attributes.
 
 `classes:` is followed by list of maps with following keys and values:
+
 - `name` (string): name of the class, matches
   `class.memtierd.nri.io` annotations.
 - `allowswap` (`true` or `false`): if `true`, allow OS to swap the
@@ -91,7 +92,8 @@ for more configuration options.
 
 - Containerd v1.7+
 - Enable NRI in /etc/containerd/config.toml:
-  ```
+
+  ```toml
   [plugins."io.containerd.nri.v1.nri"]
     disable = false
     disable_connections = false
@@ -101,7 +103,9 @@ for more configuration options.
     plugin_request_timeout = "2s"
     socket_path = "/var/run/nri/nri.sock"
   ```
+
 - To run the nri-memtierd plugin on a host, install memtierd on the host.
+
   ```bash
   GOBIN=/usr/local/bin go install github.com/intel/memtierd/cmd/memtierd@latest
   ```

v0.2/_sources/docs/resource-policy/developers-guide/architecture.md.txt

@@ -41,11 +41,12 @@ by NRI-RP with the Kubernetes Control Plane go through the node agent with
 the node agent performing any direct interactions on behalf of NRI-RP.
 
 The agent interface implements the following functionality:
-  - push updated external configuration data to NRI-RP
-  - updating resource capacity of the node
-  - getting, setting, or removing labels on the node
-  - getting, setting, or removing annotations on the node
-  - getting, setting, or removing taints on the node
+
+- push updated external configuration data to NRI-RP
+- updating resource capacity of the node
+- getting, setting, or removing labels on the node
+- getting, setting, or removing annotations on the node
+- getting, setting, or removing taints on the node
 
 The config interface is defined and has its gRPC server running in
 NRI-RP. The agent acts as a gRPC client for this interface. The low-level
@@ -55,9 +56,9 @@ NRI-RP acts as a gRPC client for the low-level plumbing interface.
 
 Additionally, the stock node agent that comes with NRI-RP implements schemes
 for:
-   - configuration management for all NRI-RP instances
-   - management of dynamic adjustments to container resource assignments
 
+- configuration management for all NRI-RP instances
+- management of dynamic adjustments to container resource assignments
 
 ### [Resource Manager](tree:/pkg/resmgr/)
 
@@ -81,35 +82,37 @@ pipeline; hand it off for logging, then relay it to the server and the
 corresponding response back to the client.
 
 B. If the request needs to be intercepted for policying, do the following:
- 1. Lock the processing pipeline serialization lock.
- 2. Look up/create cache objects (pod/container) for the request.
- 3. If the request has no resource allocation consequences, do proxying
-    (step 6).
- 4. Otherwise, invoke the policy layer for resource allocation:
-    - Pass it on to the configured active policy, which will
-    - Allocate resources for the container.
-    - Update the assignments for the container in the cache.
-    - Update any other containers affected by the allocation in the cache.
- 5. Invoke the controller layer for post-policy processing, which will:
-    - Collect controllers with pending changes in their domain of control
-    - for each invoke the post-policy processing function corresponding to
-      the request.
-    - Clear pending markers for the controllers.
- 6. Proxy the request:
-    - Relay the request to the server.
-    - Send update requests for any additional affected containers.
-    - Update the cache if/as necessary based on the response.
-    - Relay the response back to the client.
- 7. Release the processing pipeline serialization lock.
+
+1. Lock the processing pipeline serialization lock.
+2. Look up/create cache objects (pod/container) for the request.
+3. If the request has no resource allocation consequences, do proxying
+   (step 6).
+4. Otherwise, invoke the policy layer for resource allocation:
+  - Pass it on to the configured active policy, which will
+  - Allocate resources for the container.
+  - Update the assignments for the container in the cache.
+  - Update any other containers affected by the allocation in the cache.
+5. Invoke the controller layer for post-policy processing, which will:
+  - Collect controllers with pending changes in their domain of control
+  - for each invoke the post-policy processing function corresponding to
+    the request.
+  - Clear pending markers for the controllers.
+6. Proxy the request:
+  - Relay the request to the server.
+  - Send update requests for any additional affected containers.
+  - Update the cache if/as necessary based on the response.
+  - Relay the response back to the client.
+7. Release the processing pipeline serialization lock.
 
 The high-level control flow of the event processing pipeline is one of the
 following, based on the event type:
 
- - For policy-specific events:
-   1. Engage the processing pipeline lock.
-   2. Call policy event handler.
-   3. Invoke the controller layer for post-policy processing (same as step 5 for requests).
-   4. Release the pipeline lock.
+- For policy-specific events:
+  1. Engage the processing pipeline lock.
+  2. Call policy event handler.
+  3. Invoke the controller layer for post-policy processing (same as step 5 for
+     requests).
+  4. Release the pipeline lock.
 
 ### [Cache](tree:/pkg/resmgr/cache/)
 
@@ -144,22 +147,19 @@ managers event loop. This causes a callback from the resource manager to
 the policy's event handler with the injected event as an argument and with
 the cache properly locked.
 
-
 ### [Generic Policy Layer](blob:/pkg/resmgr/policy/policy.go)
 
 The generic policy layer defines the abstract interface the rest of NRI-RP
 uses to interact with policy implementations and takes care of the details
 of activating and dispatching calls through to the configured active policy.
 
-
 ### [Generic Resource Controller Layer](blob:/pkg/resmgr/control/control.go)
 
 The generic resource controller layer defines the abstract interface the rest
 of NRI-RP uses to interact with resource controller implementations and takes
 care of the details of dispatching calls to the controller implementations
 for post-policy enforcment of decisions.
 
-
 ### [Metrics Collector](tree:/pkg/metrics/)
 
 The metrics collector gathers a set of runtime metrics about the containers
@@ -168,7 +168,6 @@ collected data to determine how optimal the current assignment of container
 resources is and to attempt a rebalancing/reallocation if it is deemed
 both possible and necessary.
 
-
 ### [Policy Implementations](tree:/cmd/plugins)
 
 #### [Topology Aware](tree:/cmd/plugins/topology-aware/)

v0.2/_sources/docs/resource-policy/developers-guide/e2e-test.md.txt

@@ -3,21 +3,22 @@
 ## Prerequisites
 
 Install:
+
 - `docker`
 - `vagrant`
 
 ## Usage
 
 Run policy tests:
 
-```
+```bash
 cd test/e2e
 [VAR=VALUE...] ./run_tests.sh policies.test-suite
 ```
 
 Run tests only on certain policy, topology, or only selected test:
 
-```
+```bash
 cd test/e2e
 [VAR=VALUE...] ./run_tests.sh policies.test-suite[/POLICY[/TOPOLOGY[/testNN-*]]]
 ```
@@ -65,7 +66,8 @@ configuration.
 
 The `topology` variable is a JSON array of objects. Each object
 defines one or more NUMA nodes. Keys in objects:
-```
+
+```text
 "mem"                 mem (RAM) size on each NUMA node in this group.
                       The default is "0G".
 "nvmem"               nvmem (non-volatile RAM) size on each NUMA node
@@ -82,12 +84,12 @@ defines one or more NUMA nodes. Keys in objects:
                       The default is 1.
 ```
 
-
 Example:
 
 Run the test in a VM with two NUMA nodes. There are 4 CPUs (two cores, two
 threads per core by default) and 4G RAM in each node
-```
+
+```bash
 e2e$ vm_name=my2x4 topology='[{"mem":"4G","cores":2,"nodes":2}]' ./run.sh
 ```
 
@@ -97,7 +99,7 @@ two NUMA nodes, each node containing 2 CPU cores, each core containing
 two threads. And with a NUMA node with 16G of non-volatile memory
 (NVRAM) but no CPUs.
 
-```
+```bash
 e2e$ vm_name=mynvram topology='[{"mem":"4G","cores":2,"nodes":2,"dies":2,"packages":2},{"nvmem":"16G"}]' ./run.sh
 ```
 

v0.2/_sources/docs/resource-policy/developers-guide/unit-test.md.txt

@@ -1,7 +1,8 @@
 # Unit tests
 
 Run unit tests with
-```
+
+```bash
 make test
 ```
 

v0.2/_sources/docs/resource-policy/index.md.txt

@@ -6,7 +6,6 @@ maxdepth: 2
 caption: Contents
 ---
 introduction.md
-installation.md
 setup.md
 configuration.md
 policy/index.md