[sonic-telemetry]: Enable docker cmd inside sonic-telemetry #1976
Conversation
| # enable docker cmd inside the telemetry container | ||
| $(DOCKER_TELEMETRY)_RUN_OPT += -v /var/run/docker.sock:/var/run/docker.sock:rw | ||
| $(DOCKER_TELEMETRY)_RUN_OPT += -v /usr/bin/docker:/usr/bin/docker | ||
| $(DOCKER_TELEMETRY)_RUN_OPT += -v /usr/lib/x86_64-linux-gnu/libapparmor.so.1:/usr/lib/x86_64-linux-gnu/libapparmor.so.1 |
There was a problem hiding this comment.
why do we need this? can we install them in the docker instead of mapping them from the base image? also, what is docker cmd?
There was a problem hiding this comment.
We need to use docker command like "docker ps" to get docker container list, or "docker exec -i vtysh -c 'show ip bgp summary'" to get bgp neighbor status.
If we want to get the docker information or access the other docker container in the host, we should mapping them from host.
There was a problem hiding this comment.
letting an application in one docker to directly access cmd in another docker poses security concern. It is better to community this thought the database, in this case, we can ask bgp docker to put information into database and then telemetry can read from database.
There was a problem hiding this comment.
If you really need vtysh in a non-quaggy container, please let me know. We have some solution with socket.
| # enable docker cmd inside the telemetry container | ||
| $(DOCKER_TELEMETRY)_RUN_OPT += -v /var/run/docker.sock:/var/run/docker.sock:rw | ||
| $(DOCKER_TELEMETRY)_RUN_OPT += -v /usr/bin/docker:/usr/bin/docker | ||
| $(DOCKER_TELEMETRY)_RUN_OPT += -v /usr/lib/x86_64-linux-gnu/libapparmor.so.1:/usr/lib/x86_64-linux-gnu/libapparmor.so.1 |
There was a problem hiding this comment.
libapparmor [](start = 60, length = 11)
The libapparmor.so and libltdl.so files are docker dependency, so it is implementation details. We'd better not to handle it for better future.
…read/maintain (sonic-net#1977) #### What I did Moved PatchSorter unit-test to json file to make it easier to read/maintain In the future this test json file can be used for adding nightly tests. While testing I had to set `skip_exact_change_list_match=True` because different runs of the same input produce correct but different changes. It is better to always generate the same steps for easier debugging. Created issue: sonic-net#1976 #### How I did it Copied to Json file the following: - current_config i.e. current running config - patch - expected change list #### How to verify it unit-tests
…nic-net#1988) #### What I did Fixes sonic-net#1976 Different runs of `apply-patch` would produce different sorted steps. It is better to be consistent while producing the sorted steps to make it easier to debug issues in the future. The issue is with using `set(list)` to remove duplicates from the list. Looping over the set elements does not guarantee same order every time we iterate. To reproduce this do the following: 1. Create a file named `test.py` with the content ```python x = ["XYZ", "ABC", "DEF"] y = set(x) print(y) ``` 2. Run `python3 test.py` 3. Again `python3 test.py` 4. Again `python3 test.py` The output of these runs will be different each time. #### How I did it Instead of returning a `set`, return a list of `ref_paths` which does not have duplicated elements inserted to begin with. #### How to verify it unit-tests #### Previous command output (if the output of a command-line utility has changed) #### New command output (if the output of a command-line utility has changed)
- What I did
- How I did it
- How to verify it
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)