I've been using NSO running in Docker on my laptop to develop and test NSO.
After getting the NEDs installed and a few things set up, I can run NSO using the startup script: ./run-nso.sh in the root folder.
If I exit the container, I can re-start and attach to it and NSO still runs using the run-nso.sh script in the root folder.
The problem happens after I run "docker commit <container id> new-image"
Then, after starting new-image and running ./run-nso.sh, I get the following error:
"Bad configuration: /etc/ncs/ncs.conf:0: \"/nso/run/state/packages-in-use.cur: Failed to rename to /nso/run/state/packages-in-use.old: cross-domain link\"\n"
Seems like the file system is still intact, I haven't been able to figure out what the issue may be.
The error string "cross-domain link" is Erlang's way of formatting the POSIX error code "EXDEV" (see https://erlang.org/doc/man/file.html#posix-error-codes)
And EXDEV is a possible error when renaming a file fails. From https://man7.org/linux/man-pages/man2/rename.2.html
EXDEV oldpath and newpath are not on the same mounted filesystem. (Linux permits a filesystem to be mounted at multiple points, but rename() does not work across different mount points, even if the same filesystem is mounted on both.)
So, perhaps something to do with the way you mount your volumes/filesystems?
Thank you for your reply,
I think you are close to the answer as it looks like the docker commit command does not include any volumes mounted in the container.
My guess would be NSO is looking for something that was on a volume in the original container.
It will take me some time of testing to prove that as I don't exectly know how to yet but I will get reply if I am able to test.
Thanks again -
I remember we ran into this error as well, but the guy who fixed it is no longer at the company.
From viewing our yml file that takes in the NSO base container and builds our new one, we have some of the following (hopefully it helps):
# Symlink /nso/run/packages to /var/opt/ncs/packages because that's where NSO will look for packages - docker exec -i nso_one /bin/bash -c 'rm -rf /nso/run/packages && ln -s /var/opt/ncs/packages /nso/run/packages' # Link /nso/run/logs to log, this fixes a bug where packages reload fails without it - docker exec -i nso_one /bin/bash -c 'ln -s /log /nso/run/logs' # Reload packages - docker exec -i nso_one /bin/bash -c 'source /opt/ncs/current/ncsrc && echo "packages reload" | ncs_cli -C -u admin -g admin' # Tag production image - export DATE_TIME=$(date '+%Y.%m.%d'); - docker commit nso_one $REGISTRY_HOSTNAME/nso-prod-188.8.131.52:$DATE_TIME.$CI_COMMIT_SHORT_SHA
Another thing we've noticed, is that if we're trying to develop in a docker container (making changes to a service/action), when we perform the packages reload command, sometimes it won't actually load the new change. We've found that we have to go into /nso/run/state/ and copy the file from packages-in-use.new/1/... to packages-in-use.cur/1/... and reload the package again. Then it loads the new package.
I think you are using https://gitlab.com/nso-developer/nso-docker/ to build your Docker images, is that right?
Can you tell me a little more about what you are trying to achieve? In particular, what are you trying to accomplish with `docker commit`. The philosophy of NSO in Docker is that you insert packages into the container image at build time while run time data, like CDB, is stored on a volume. There is no need to use `docker commit`. What do you expect will happen through `docker commit`?
I am using a dev image that we have developed in house.
I was using docker commit so I could make things like CDB and templates a part of my local image.
As a workaround I've just been restarting the previous container when I want to restart NSO where I left off. Main drawback for me is it makes things difficult to keep track of which container has the changes I want to keep.