|
| 1 | +# Grout Ansible Role |
| 2 | + |
| 3 | +This Ansible role (`grout`) is designed to deploy and manage the Grout application in a Kubernetes/OpenShift environment. It automates the creation of necessary Kubernetes resources, parses network definitions, and configures the Grout deployment according to user-specified parameters. |
| 4 | + |
| 5 | +## Default Variables |
| 6 | + |
| 7 | +The following variables are defined in [`defaults/main.yml`](defaults/main.yml): |
| 8 | + |
| 9 | +| Variable | Default Value | Description | |
| 10 | +|-----------------------|------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------| |
| 11 | +| `image_grout` | quay.io/rh-nfv-int/grout-container-app-cnfapp@sha256:112bed772707280de16a64eb4fb3c3c0ec027fa030372dff05927d105bc822fd | Container image for the Grout application. | |
| 12 | +| `size` | 1 | Number of replicas for the Grout deployment. | |
| 13 | +| `skip_annot` | false | Whether to skip annotation steps. | |
| 14 | +| `networks` | [] | List of network definitions (see below for structure). | |
| 15 | +| `image_pull_policy` | IfNotPresent | Image pull policy for the Grout container (`Always`, `IfNotPresent`, or `Never`). | |
| 16 | +| `privileged` | false | Whether to run the container in privileged mode. | |
| 17 | +| `hugepage_1gb_count` | 4Gi | Amount of 1Gi hugepages to allocate. | |
| 18 | +| `memory` | 1000Mi | Memory request for the Grout container. | |
| 19 | +| `cpu` | 4 | CPU request for the Grout container. | |
| 20 | +| `network_resources` | {} | Internal variable for tracking network resource usage. | |
| 21 | +| `resources` | [] | List of additional resources to be used. | |
| 22 | +| `environments` | {} | Environment variables to set in the container. | |
| 23 | +| `rx_queues` | 2 | Number of RX queues. | |
| 24 | + |
| 25 | +### Example `networks` Variable Structure |
| 26 | + |
| 27 | +The `networks` variable is a list of dictionaries, each describing a network attachment. Example: |
| 28 | + |
| 29 | +``` |
| 30 | +"networks": [ |
| 31 | + { |
| 32 | + "count": 1, |
| 33 | + "ip": [ |
| 34 | + "192.168.36.60/26" |
| 35 | + ], |
| 36 | + "mac": [ |
| 37 | + "80:03:0f:f1:89:01" |
| 38 | + ], |
| 39 | + "name": "example-cnf-net1" |
| 40 | + }, |
| 41 | + { |
| 42 | + "count": 1, |
| 43 | + "ip": [ |
| 44 | + "192.168.36.100/26" |
| 45 | + ], |
| 46 | + "mac": [ |
| 47 | + "80:03:0f:f1:89:02" |
| 48 | + ], |
| 49 | + "name": "example-cnf-net2" |
| 50 | + } |
| 51 | +] |
| 52 | +``` |
| 53 | + |
| 54 | +## How the Ansible Tasks Work |
| 55 | + |
| 56 | +The Grout role uses a series of Ansible tasks (see [`tasks/main.yml`](tasks/main.yml)) to automate the deployment and configuration of the Grout application. Here is an overview of the main steps: |
| 57 | + |
| 58 | +1. **Initialization**: |
| 59 | + The role initializes internal variables such as `network_resources` (to track network resource usage) and `network_name_list` (to keep a list of network names). |
| 60 | + |
| 61 | +2. **Input Validation**: |
| 62 | + The role checks that at least one of the `networks` or `resources` variables is provided. If both are empty, the playbook fails with an error. |
| 63 | + |
| 64 | +3. **Network Parsing**: |
| 65 | + If the `networks` variable is defined and not empty, the role loops through each network entry and includes the `network-parse.yaml` task file. This subtask: |
| 66 | + - Extracts the network name and details. |
| 67 | + - Looks up the corresponding `NetworkAttachmentDefinition` in the cluster. |
| 68 | + - Gathers resource names, counts, and updates the `network_resources` dictionary accordingly. |
| 69 | + - Handles duplicate resources by incrementing their counts. |
| 70 | + - Collects a list of all network names used. |
| 71 | + |
| 72 | +4. **Resource Parsing**: |
| 73 | + If `resources` are defined and `networks` is empty, the role populates `network_resources` directly from the `resources` list. |
| 74 | + |
| 75 | +5. **Debugging and Output**: |
| 76 | + Throughout the process, the role prints debug information for variables like `networks`, `resources`, `network_resources`, and `network_name_list` to aid troubleshooting. |
| 77 | + |
| 78 | +6. **Kubernetes Resource Creation**: |
| 79 | + The role then creates the necessary Kubernetes resources for the Grout application: |
| 80 | + - **ServiceAccount**: For the Grout pod to interact with the cluster. |
| 81 | + - **Role and RoleBinding**: To grant the required permissions. |
| 82 | + - **Deployment**: To launch the Grout application pods using the specified configuration. |
| 83 | + - **PodDisruptionBudget**: To ensure high availability during node maintenance or upgrades. |
| 84 | + |
| 85 | +These tasks ensure that the Grout application is deployed with the correct network attachments, resource allocations, and permissions, based on the variables you provide to the role. |
| 86 | + |
| 87 | +## Deployment Details |
| 88 | + |
| 89 | +The Grout role creates a Kubernetes `Deployment` resource to manage the lifecycle of the Grout application pods. This deployment is defined using a Jinja2 template (`deployment.yml`) and is rendered with the variables you provide to the role. The deployment includes the following key features: |
| 90 | + |
| 91 | +- **Replica Count**: The number of pod replicas is controlled by the `size` variable. |
| 92 | +- **Container Image**: The Grout container image is specified by the `image_grout` variable, with the pull policy set by `image_pull_policy`. |
| 93 | +- **Network Attachments**: The deployment attaches the specified networks to the pods using the `networks` variable, enabling SR-IOV or other CNI-based networking as required. |
| 94 | +- **Resource Requests and Limits**: CPU, memory, and hugepage resources are set according to the role defaults or your overrides. |
| 95 | +- **Security Context**: The pod can be run in privileged mode if `privileged` is set to `true`. |
| 96 | +- **RuntimeClass**: If a high-performance runtime is specified (via `runtime_class_name`), it is set on the pod for advanced scheduling or isolation. |
| 97 | +- **Environment Variables**: Any custom environment variables can be injected using the `environments` variable. |
| 98 | +- **Service Account**: The deployment uses a dedicated ServiceAccount created by the role to ensure proper permissions. |
| 99 | +- **PodDisruptionBudget**: A PodDisruptionBudget is also created to help maintain pod availability during node drains or upgrades. |
| 100 | + |
| 101 | +This deployment ensures that the Grout application is robustly managed by Kubernetes, with flexible configuration for networking, resources, and security to suit a variety of CNF (Cloud-Native Network Function) scenarios. |
0 commit comments