You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
uv run ansible-playbook -i inv -e intent_dir=${PWD}/intent --diff playbooks/cf_fabric.yml
325
325
```
326
326
327
327
The schema files for these level-1 intents exist in the `playbooks/roles/infra/criteria` directory. There is a JSON-schema file per top-level level-1 resource.
@@ -391,7 +391,7 @@ Copy over above 2 files from `intent_examples/services` into `intent/` and run t
This will make the playbook run interactive and it will ask for explicit confirmation to leave the latest commit intact. If no confirmation is given, the commits are rolled back after the specified timeout.
Copy file name to clipboardExpand all lines: docs/tutorials/programmability/ansible/intent-based-management/env.md
+14-9Lines changed: 14 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,13 +15,18 @@ The following sections assume you are in the `intent-based-ansible-lab` director
15
15
16
16
## Install Ansible and dependencies
17
17
18
-
- To run the playbooks in the above repo, Ansible and related dependencies must be installed. The recommended way is to create a Python virtual environment and install the packages in that environment. Next to the Python packages, the `nokia.srlinux` Ansible collection is required that provides the connection plugin to interact with SR Linux using JSON-RPC.
18
+
- To run the playbooks in the above repo, Ansible and related dependencies must be installed. The recommended way is to use uv. Next to the Python packages, the `nokia.srlinux` Ansible collection is required that provides the connection plugin to interact with SR Linux using JSON-RPC.
19
19
20
-
```bash title="Creating a venv and installing dependencies"
uv run ansible-galaxy collection install nokia.srlinux
25
30
```
26
31
27
32
- Ensure you have the [Containerlab](https://containerlab.dev/install)[^2] installed and are meeting its installation requirements.
@@ -30,15 +35,15 @@ The following sections assume you are in the `intent-based-ansible-lab` director
30
35
`fcli` is not required to run the project, but it's useful to verify the state of the fabric after running the playbook and is used throughout this tutorial to illustrate the effects of the Ansible playbooks. It is packaged in a container and run via a shell alias via the following command:
You need an SR Linux test topology to run the Ansible playbook and roles against. We will use [Containerlab](https://containerlab.dev/) to create a lab environment with 6 SR Linux nodes: 4 leaves and 2 spines:
This will create a lab environment with 6 SR Linux nodes and a set of Linux containers to act as hosts:
@@ -51,7 +56,7 @@ This will create a lab environment with 6 SR Linux nodes and a set of Linux cont
51
56
Containerlab populates the `/etc/hosts` file on the host machine with the IP addresses of the deployed nodes. This allows Ansible to connect to the nodes that has a matching inventory file inside the `inv` directory.
52
57
53
58
```bash title="Verifying that all lab nodes are up and running"
54
-
sudo containerlab inspect -t topo.yml
59
+
containerlab inspect -t topo.clab.yml
55
60
```
56
61
57
62
With the lab deployed, we can now explore the project's structure and understand the role's layout that powers the intent-based configuration management.
Copy file name to clipboardExpand all lines: docs/tutorials/programmability/ansible/intent-based-management/summary.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ The reasons for this approach are:
17
17
This is a 'low-code' approach to network automation using only Jinja templating and the Ansible domain-specific language. It does require some basic development and troubleshooting skills as playbook errors will happen and debugging will be required. For example, when adding new capabilities to roles/templates, invalid data in intent variables, when SR Linux model changes happen across software releases, etc. These events may break template rendering inside the roles. Most of the logic is embedded in the Jinja templates but runtime errors are not always easy to pinpoint as Ansible does not provide a stack trace or position of failure within the template. A general troubleshooting process is as follows:
18
18
19
19
1. Reduce the output by limiting the playbook run to a single host that exhibits the problem (`hosts` variable in `cf_fabric.yml`)
20
-
2. run `ansible-playbook` with the `-vvv` option to get verbose output during the playbook run
20
+
2. run `uv run ansible-playbook` with the `-vvv` option to get verbose output during the playbook run
21
21
3. insert `debug` tasks at strategic places in the playbook to narrow down the problem. Debugging variables `my_intent`, which is local to the role, `intent`, which is built up incrementally as the playbook progresses and `replace`, `update` and `delete` in the `configure` role usually point you to the root cause of the problem. Running a playbook with the debug statements in place will show the values of these variables during a regular playbook run
22
22
23
23
_Network-wide transactions_ could be implemented with _Git_. You `git commit` your changes (intents/roles) to a Git repository after any change to intents or roles. If some issues occur during the playbook run, e.g. some nodes fail in the playbook resulting in a partial fabric-wide deployment or changes appear to be permanently service-affecting, you can revert back to a previous commit with e.g. `git revert` and run the playbook again from a known good state (intent/roles).
0 commit comments