Environment variables expansion#
This allows you to modify topology definition at runtime using the env vars you have defined in your environment. Awesome addition to make clab play nice in CI/CD systems!
Local config takes precedence over startup config#
A major change has been made to the config load order. With this release the following order of configuration load is in place:
- config file found in lab directory
- startup config set with
- generated config from a template that comes within containerlab
The change is with the local config to be preferred over a startup-config. The idea here is simple: when a user deploys a lab from with a
startup-config pointing to a certain file the lab boots with this config.
Later, users typically build on top of that startup config some additional use cases. And in the case they save their changes to the startup config the changes will be persisted in a lab directory of this node. Now, if a users destroys a lab and deploys it again, if the file in the lab dir is found, it will be used, and startup-config will be ignored.
If it is needed to make a config file referenced in
startup-config to be used, the deploy command should be augmented with
reconfigure flag or a new parameter can be used in the topo file - enforce-startup-config.
Arista cEOS persistency improvements#
A big improvement in the way management interface is configured for ceos kinds.
With a new scrapligo feature we were able to configure ceos nodes over
docker exec command after the node finishes booting. That allowed us to always ensure that ceos nodes will have management interface addressed with the IP that docker assigned to it, regardless of which IP was already set in startup-config file.
That made it possible to remove a lot of workarounds and restrictions that were in place before.
Mixed mode labs with Static and Dynamic IP addresses#
Containerlab allows users to set static IP address for the node management interface. This is done with
mgmt_ipv4/6 setting of a node.
It was possible to set static address for part of the nodes of a lab, in that case some nodes will get a static address, the rest would receive an address as assigned by Docker daemon. The issue that users might see with such labs is that docker assigns dynamically an IP that was set as a static IP for another node.
To overcome this race condition the nodes with Static IP address will now be scheduled first, and the dynamic IP allocated nodes will follow.
Startup delay for nodes#
Nodes can be artificially delayed if they have
startup-delay field set to a value greater than zero. This indicates amount in seconds that this node will wait till it will be scheduled for creation by containerlab.
Welcome @GrigoriyMikhalkin and thank you for your contributions to containerlab!