Closed hellt closed 3 years ago
why would you not simply copy the file after ceos node is started? so intead of start -> stop -> start
do start -> copy
?
will ceos immediately apply the changes as I do them in startup-config
file? Or do I also need to trigger the config reload?
I think instead of a copy I can also do docker exec ... Cli <config ipv4/6>
I think you overestimate how fast ceos boots 😄 , if you place this file during the postDeploy action, ceos won't have time to get to the config parsing stage.
If you don't want to rely on timers, you can place a bash script in /mnt/flash/rc.eos and make it wait for startup-config (or any other "sentinel" file) to be found before continuing to boot. The rc.eos
is a special file that's guaranteed to run before the startup-config is processed. I used it previously to mount the startup config inside veos
this has been solved in #593 The new approach eliminates the troubles with ceos not being able to use the docker assigned IP in the following way:
docker exec
connection in the postdeploy stage.docker exec
PTY and once ceos is ready it configures the management address with the IPs we know docker assigned to it
arista ceos is a challenging platform when it comes to the management network addressing
the issue arises with the fact that ceos management interface can't be set to ipv4/6 address that is set by docker daemon on a linux interface. This forces clab to do extra work for ceos, such as:
Now the next problem comes when we redeploy a lab with
deploy -> destroy
sequence. In that case the current logic of config persistency dictates that the ceos node will boot with a config that is already present in theclab-$labName
folder for ceos node. But since docker assigns new addresses for a newly deployed lab, it might be that ceos node will get new management IP addresses allocated by the docker, and they will mismatch with the configuration that is saved in the config file.It looks like have to implement additional logic here. If ceos nodes boot up and there is a config file in the lab directory present, we need to take this config file and replace the management interface configuration with the values that docker has assigned for this lab run, rather than blindly using the values that are there.
Considerations
Of course it is possible to do
deploy --reconfigure
and the nodes will not have any previous state, but that means that whatever the config was from the last lab deployment will be lost.If the startup-config file is used, it has the most significant value and will be used always.