Handle Docker Compose configuration entirely with environment variables #282
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nsor into all-config-with-env
Updated from old "docker-compose"
…-config-with-env
jhazentia
requested changes
Dec 13, 2024
env.template
Outdated
| @@ -89,12 +88,22 @@ SSL_CA_PATH=scos_test_ca.crt | |||
| SSL_CERT_PATH=sensor01.pem | |||
| SSL_KEY_PATH=sensor01.pem | |||
|
|
|||
| # Device made available to SCOS Plugins, e.g. for getting SMART data | |||
| SSD_DEVICE="$(lsblk -I 8 -npdo KNAME)" | |||
There was a problem hiding this comment.
This command isn't returning anything on the sensors or my laptop
There was a problem hiding this comment.
Replaced with a plaintext default value which can be changed when configuring a sensor.
Note also that I made changes in scos-actions (NTIA/scos-actions#126) which will result in a default value of /dev/nvme0n1 being used by the SEA action if the environment variable is not provided.
| @@ -95,7 +94,7 @@ services: | |||
| - SYS_ADMIN # required for ^ with NVMe drives | |||
| devices: | |||
| - /dev/bus/usb:/dev/bus/usb:rw | |||
| - /dev/nvme0n1:/dev/nvme0n1:ro | |||
| - ${SSD_DEVICE}:/dev/nvme0n1:ro | |||
There was a problem hiding this comment.
I wonder if this would work if the SSD_DEVICE is a SATA device which is then mapped to an nvme device in the container? Perhaps it would be better to use ${SSD_DEVICE} for both then pass the SSD_DEVICE environment variable to scos-actions to get the path?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #279 by adding new environment variables
SSD_DEVICEandAPI_SHM_SIZE.Now,
SSD_DEVICEis used to map the/dev/nvme0n1device in the API container, which is used by the SEA edge compute action to get diagnostic SSD SMART data. The default value is dynamically retrieved using the commandlsblk -I 8 -npdo KNAMEwhich should work in most cases, and resolves to/dev/nvme0n1for SEA sensors. This default could cause missing metadata when using the SEA action if theSSD_DEVICEis not an SSD. The default setting will also cause SCOS Sensor to fail to start if multiple devices are returned bylsblk -I 8 -npdo KNAME.API_SHM_SIZEis used to set the shared memory in the API container, and a default is provided keeping it at 16 GB. This is used to provide sufficient shared memory to the Ray package for parallel processing of large IQ captures.If merged after #289, the following need to be added to the environment variables documentation in the wiki:
/dev/shm) in the API container. Thisis currently used to allocate shared memory for parallel processing of IQ data with Ray.
/dev/sda/) which is mapped to/dev/nvme0n1withinthe API container. This is currently only used to retrieve SSD SMART diagnostics (in
SCOS Actions).