20 topologies, 7 of them notation examples
drop the flag and the field that did nothing
split writing a block from assembling the blocks
wiki: point the shared-parameter example at one that reads the value back
wiki: point at the topologies, and let the tutorial change one
wiki: finish the terminology change, and give every page a way out The substitution left the word in a few places and left Basic-Concepts arguing with its own definition: the callout said a topology is both files, and the page below kept saying "change topology" for editing the DOT file. A reader ends a page believing whatever it said last. - the graph is called the graph where the graph is meant - "topology file" only where a platform is named; the cross-platform places name topo.yaml and spec.yaml instead - Upgrading names netroub, which the CHANGELOG already warns about, as the downstream tool that reads generated files by path - Basic-Concepts and Command-Reference had no outgoing links at all; both now end somewhere, and the class table and param_rule reach the pages that explain them - two links pointed at nothing (a Graphviz-style path, an anchor with a slash in it) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
wiki: say topology where a topology is meant, and stop saying scenario scenario is netroub's word - a configuration together with the events that happen in it, defined in its papers and in its own schema, where a scenario is a topology plus events. This documentation had taken it for what a reader writes, which would have left two projects by the same author using one word for two things. What you write - the DOT file and the YAML that configures it - is a topology, which is how this field already speaks: containerlab calls its own file a topology definition and puts the nodes' images and configuration in it. Basic-Concepts and Home say so before the word is used. Where only the graph is meant the pages now say the DOT file, and topology file is left to mean what a platform reads.
wiki: say what each module is for, and run labs through the entry script The module list mixed a platform with a configuration helper without saying so. Modules are now introduced by what they do for you: platform modules write the file their platform reads, which is where the automation is; software modules help write what runs inside the nodes; assert checks the scenario against itself. Writing a module is a different subject from using one, so the interfaces and their timing moved to a page of their own, along with what a module may and may not say to a scenario. Each platform page now runs its lab through the generated script first and by hand second. That is not a preference: destroy through the script runs the teardown commands, collects the files, and cleans up what the lab left on the machine, and none of it happens when the platform's own command is called directly.
home: drop the pages that were never written Thirteen entries were commented-out placeholders - Troubleshooting, Data Flow, Template Engine, Conflict Detection, Contributing and the rest. Each names something a page that exists already covers, so the comments were a list of work nobody was going to do, in front of the list of what is actually there. The remaining entries say what they cover instead, and the sections that held only comments are gone.
explain what the fields decide, not just that they exist A table row saying provide is 'mount or copy' tells a reader nothing about which to pick. The file definition fields now say what each one decides and links to the section that explains the choice, and the same was done for the param_rule sources and the class combination rules - where the config row was also wrong: two classes defining a config entry of the same name is an error whatever their strength, not a conflict resolved by tier. Module-FRR says where the log actually ends up: inside the container while the lab runs, under collected/<node>/ once it is destroyed, owned by whoever ran the script. That is the question a reader of the FRR page has, and answering it there is worth the repetition. Best-Practices had two sections about building incrementally and no table of contents; it now has one of each, in an order that follows how a scenario is written, plus what multi-host asks of a design. Also: the upgrade page belongs in Getting Started, not under Modules; node_class: is not a key and 0.8.0 rejects it; TiNET's complete example still had sysctls, switches: [] and ./ mounts; a digraph cannot hold --; and virtual on an interface no longer taking its link with it is a breaking change nobody was told about.
add an upgrade page for 0.8.0 A scenario written for 0.7.x meets several changes at once - where its files are written, what its interfaces are called, whether containerlab gives it a management network - and each was described only in its own place.
0.8.0: multi-host, the ConfigTemplate field reference, and the assert module YAML-Configuration: the worker group class and what follows from naming it - a topology file per machine, the check against a node in two of them, the bridge replacement for a segment that reaches across - and boundary_crossing_connection_class. Template-System: a reference for the fields of a config entry, which the wiki never had. raw, delimiters, required_link and required_params are in it. Module-System: the assert module. Home: the Kathara page.
fix TiNet -> TiNET, update broken links to File-Output and Module-System
reorganize wiki: split File-Output and Module-System, restructure Home categories
add Parameter-Generation link to Home
update wiki for v0.7.0: add module docs, required_params, Value class
add Architecture Overview and NetworkModel Design pages
add Development Guide page
update readme
restructure wiki: simplify Home and add Tutorial page
update Wiki for v0.6.0 FormatStyle changes
add Template-System
add some contents
Initial Home page