This repo contains example models for the Inmanta Service Orchestrator
Self contained examples for managing various types of network equipment:
| Vendor | Folder | License required? | Containerlab File |
|---|---|---|---|
| SR Linux | Networking/SR Linux | No | Yes |
| Vyos | Networking/Vyos | No | Yes |
| Nokia SR | Networking/Nokia | Yes | Yes |
| Juniper JunOS MX | Networking/Juniper | Yes | Yes |
| Cisco IOS-XR | Networking/Cisco | Yes | Yes |
The training lab is a sandbox to learn the Inmanta modeling language.
In this repo, we provide a lab environment based on SRLinux in which you can easily deploy config manually and with the orchestrator.
For more information continue here.
LSM means Lifecycle and Service Management, which is not part of the opensource orchestrator.
To learn LSM, the first thing to look at is the documentation: here. For LSM with allocation: here
This repo has the following additional examples.
- Network configuration examples: Collection of examples on how to configure different services on vendor devices
- lsm-external-allocation: example on how to allocate and de-allocate attributes from an external inventory
- lsm-from-inventory-a: example on how to load all attributes of a service from an external inventory
- lsm-from-inventory-b: another example on how to load all attributes of a service from an external inventory
- lsm-partial-allocation: shows a use case of the AllocatorWrapper from the lsm module. This example is relevant for services which need multiple allocations that might fail, and the service needs to know the succeeded allocated values for the de-allocation. Without the AllocatorWrapper, the successfully allocated values would be lost if a failure in an upcoming allocation on the same service is raised.
If you want to fetch the entire service definition from the inventory take a look at external-allocation.
If proper de-allocation is important and you use an external inventory, there are some additional things to keep in mind:
- de-allocation when the service is decommissioned
- de-allocation after a failed allocation (we already allocated some attributes, but not all of them)
- resume allocation after a hard failure (e.g. the machine with the orchestrator on it died while allocation was ongoing)
How to handle these depends on the inventory
| de-allocation on decommissioning | de-allocation on failed allocation | hard failure | example | |
|---|---|---|---|---|
| the inventory is transactional (i.e. we either allocate everything or nothing) | not required | not required | ||
| the inventory allows us to put an ID or tag on what we allocate (so we can find 'our' stuff back) | on service ID | on service ID | on service ID | example |
| we can de-allocate based on the value we allocated | on allocated value | on allocated value | (can leak in case of hard failure) | example |
| we can only de-allocate using an ID generated by the inventory during allocation | on inventory ID | on inventory ID | (can leak in case of hard failure) | example |