This is meta "knowledge base" issue about "peculiarity" of the current docker-compose setup (as inherited from upstream https://git.lavasoftware.org/lava/pkg/docker-compose), where it consists of "breadcrumb" style services/containers. For example, what in a normal install would be "lava server", consists of a number of containers: lava-server, lava-master, apache2 then possibly lava-logs, lava-publisher.
However, some of these services actually expect to share filesystem with other. https://github.com/Linaro/lite-lava-docker-compose/pull/103 documents a case where "lavacli device-type template set" pushed a file to "lava-server" container, while "lava-master" also expects to have access to it, leading to hard to diagnose bugs. This particular issue re: custom device type templates access is tracked upstream https://git.lavasoftware.org/lava/pkg/docker-compose/-/issues/4, but there're likely more issues like that of different severity are lurking around.
This is meta "knowledge base" issue about "peculiarity" of the current docker-compose setup (as inherited from upstream https://git.lavasoftware.org/lava/pkg/docker-compose), where it consists of "breadcrumb" style services/containers. For example, what in a normal install would be "lava server", consists of a number of containers: lava-server, lava-master, apache2 then possibly lava-logs, lava-publisher.
However, some of these services actually expect to share filesystem with other. https://github.com/Linaro/lite-lava-docker-compose/pull/103 documents a case where "lavacli device-type template set" pushed a file to "lava-server" container, while "lava-master" also expects to have access to it, leading to hard to diagnose bugs. This particular issue re: custom device type templates access is tracked upstream https://git.lavasoftware.org/lava/pkg/docker-compose/-/issues/4, but there're likely more issues like that of different severity are lurking around.