Merge pull request #596 from srl-labs/rn-0.17

Rn 0.17

docs/install.md

@@ -135,13 +135,13 @@ When the container is started, you will have a bash shell opened with the direct
     Then I will create a directory under the `$HOME` path on my mac:
 
     ```
-    mkdir -p ~/clab-mac-demo
+    mkdir -p ~/clab
     ```
 
     Then I will create a clab file defining my lab in the newly created directory:
 
     ```bash
-    cat <<EOF > ~/clab-mac-demo/2srl.clab.yml
+    cat <<EOF > ~/clab/2srl.clab.yml
     name: 2srl
 
     topology:
@@ -161,7 +161,7 @@ When the container is started, you will have a bash shell opened with the direct
     Now when the clab file is there, launch the container and don't forget to use path to the directory you created:
 
     ```bash
-    CLAB_WORKDIR=~/clab-mac-demo
+    CLAB_WORKDIR=~/clab
 
     docker run --rm -it --privileged \
         --network host \
@@ -176,15 +176,15 @@ When the container is started, you will have a bash shell opened with the direct
     Immediately you will get into the directory inside the container with your lab file available:
 
     ```
-    root@docker-desktop:/Users/romandodin/clab-mac-demo# ls
+    root@docker-desktop:/Users/romandodin/clab# ls
     2srl.clab.yml
     ```
 
     Now you can launch the lab, as containerlab is already part of the image:
     ```
-    root@docker-desktop:/Users/romandodin/clab-mac-demo# clab dep -t 2srl.clab.yml
+    root@docker-desktop:/Users/romandodin/clab# clab dep -t 2srl.clab.yml
     INFO[0000] Parsing & checking topology file: 2srl.clab.yml 
-    INFO[0000] Creating lab directory: /Users/romandodin/clab-mac-demo/clab-2srl 
+    INFO[0000] Creating lab directory: /Users/romandodin/clab/clab-2srl 
     INFO[0000] Creating root CA                             
     INFO[0000] Creating docker network: Name='clab', IPv4Subnet='172.20.20.0/24', IPv6Subnet='2001:172:20:20::/64', MTU='1500' 
     INFO[0000] Creating container: srl1                     

docs/rn/0.17.md

@@ -0,0 +1,44 @@
+# Release 0.17
+:material-calendar: 2021-08-24
+
+## Environment variables expansion
+A new feature contributed by [@GrigoriyMikhalkin](https://github.com/GrigoriyMikhalkin) allows you to perform [environment variables expansion](../manual/nodes.md#env) throughout the whole clab topology file.
+
+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:
+
+1. config file found in lab directory
+2. startup config set with `startup-config` setting
+3. 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`](../cmd/deploy.md#reconfigure) flag or a new parameter can be used in the topo file - [enforce-startup-config](../manual/nodes.md#enforce-startup-config).
+
+## Arista cEOS persistency improvements
+A big improvement in the way management interface is configured for [ceos](../manual/kinds/ceos.md) kinds.
+
+With a new [scrapligo](https://github.com/scrapli/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`](../manual/nodes.md#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.
+
+## Fixes
+- fixed `containerlab save` command for vmx nodes
+
+## New contributors
+Welcome [@GrigoriyMikhalkin](https://github.com/GrigoriyMikhalkin) and thank you for your contributions to containerlab!

mkdocs.yml

@@ -78,6 +78,7 @@ nav:
       - BGP VPLS between Nokia and Juniper: lab-examples/bgp-vpls-nok-jun.md
       - Multi-node labs: lab-examples/multinode.md
   - Release notes:
+      - 0.17: rn/0.17.md
       - 0.16: rn/0.16.md
       - 0.15: rn/0.15.md
       - 0.14.4: rn/0.14.4.md