Bind mounting MFEs fails on dev #711
Labels
bug
Bugs will be investigated and fixed as quickly as possible.
Comments
|
I'm currently working on a fix to this issue. In the meantime, it seems to me that Compose v2 is not affected by this issue. On my machine, I use Of course this would only be a temporary fix. Cc @dagg who might be interested in this. |
regisb
added a commit
that referenced
this issue
Jul 25, 2022
The -m/--mount option makes it possible to bind-mount volumes at runtime. The volumes are declared in a local/docker-compose.tmp.yml file. The problem with this approach is when we want to bind-mount a volume to a service which is specific to the dev context. For instance: the "learning" service when the MFE plugin is enabled. In such a case, starting the service triggers a call to `docker-compose stop` in the local context. This call fails because the "learning" service does not exist in the local context. Note that this issue only seems to occur with docker-compose v1. To resolve this issue, we create two additional filters for the dev context, which emulate the behaviour of the local context. With this approach, we convert the -m/--mount arguments right after they are parsed. Because they are parsed just once, we can get rid of the de-duplication logic initially introduced with the COMPOSE_CLI_MOUNTS context. Close #711. Close also overhangio/tutor-mfe#57.
regisb
added a commit
that referenced
this issue
Jul 25, 2022
The -m/--mount option makes it possible to bind-mount volumes at runtime. The volumes are declared in a local/docker-compose.tmp.yml file. The problem with this approach is when we want to bind-mount a volume to a service which is specific to the dev context. For instance: the "learning" service when the MFE plugin is enabled. In such a case, starting the service triggers a call to `docker-compose stop` in the local context. This call fails because the "learning" service does not exist in the local context. Note that this issue only seems to occur with docker-compose v1. To resolve this issue, we create two additional filters for the dev context, which emulate the behaviour of the local context. With this approach, we convert the -m/--mount arguments right after they are parsed. Because they are parsed just once, we can get rid of the de-duplication logic initially introduced with the COMPOSE_CLI_MOUNTS context. Close #711. Close also overhangio/tutor-mfe#57.
regisb
added a commit
that referenced
this issue
Jul 25, 2022
The -m/--mount option makes it possible to bind-mount volumes at runtime. The volumes are declared in a local/docker-compose.tmp.yml file. The problem with this approach is when we want to bind-mount a volume to a service which is specific to the dev context. For instance: the "learning" service when the MFE plugin is enabled. In such a case, starting the service triggers a call to `docker-compose stop` in the local context. This call fails because the "learning" service does not exist in the local context. Note that this issue only seems to occur with docker-compose v1. To resolve this issue, we create two additional filters for the dev context, which emulate the behaviour of the local context. With this approach, we convert the -m/--mount arguments right after they are parsed. Because they are parsed just once, we can get rid of the de-duplication logic initially introduced with the COMPOSE_CLI_MOUNTS context. Close #711. Close also overhangio/tutor-mfe#57.
regisb
added a commit
that referenced
this issue
Jul 29, 2022
The -m/--mount option makes it possible to bind-mount volumes at runtime. The volumes are declared in a local/docker-compose.tmp.yml file. The problem with this approach is when we want to bind-mount a volume to a service which is specific to the dev context. For instance: the "learning" service when the MFE plugin is enabled. In such a case, starting the service triggers a call to `docker-compose stop` in the local context. This call fails because the "learning" service does not exist in the local context. Note that this issue only seems to occur with docker-compose v1. To resolve this issue, we create two additional filters for the dev context, which emulate the behaviour of the local context. With this approach, we convert the -m/--mount arguments right after they are parsed. Because they are parsed just once, we can get rid of the de-duplication logic initially introduced with the COMPOSE_CLI_MOUNTS context. Close #711. Close also overhangio/tutor-mfe#57.
regisb
added a commit
that referenced
this issue
Jul 29, 2022
The -m/--mount option makes it possible to bind-mount volumes at runtime. The volumes are declared in a local/docker-compose.tmp.yml file. The problem with this approach is when we want to bind-mount a volume to a service which is specific to the dev context. For instance: the "learning" service when the MFE plugin is enabled. In such a case, starting the service triggers a call to `docker-compose stop` in the local context. This call fails because the "learning" service does not exist in the local context. Note that this issue only seems to occur with docker-compose v1. To resolve this issue, we create two additional filters for the dev context, which emulate the behaviour of the local context. With this approach, we convert the -m/--mount arguments right after they are parsed. Because they are parsed just once, we can get rid of the de-duplication logic initially introduced with the COMPOSE_CLI_MOUNTS context. Close #711. Close also overhangio/tutor-mfe#57.
regisb
added a commit
that referenced
this issue
Jul 29, 2022
The -m/--mount option makes it possible to bind-mount volumes at runtime. The volumes are declared in a local/docker-compose.tmp.yml file. The problem with this approach is when we want to bind-mount a volume to a service which is specific to the dev context. For instance: the "learning" service when the MFE plugin is enabled. In such a case, starting the service triggers a call to `docker-compose stop` in the local context. This call fails because the "learning" service does not exist in the local context. Note that this issue only seems to occur with docker-compose v1. To resolve this issue, we create two additional filters for the dev context, which emulate the behaviour of the local context. With this approach, we convert the -m/--mount arguments right after they are parsed. Because they are parsed just once, we can get rid of the de-duplication logic initially introduced with the COMPOSE_CLI_MOUNTS context. Close #711. Close also overhangio/tutor-mfe#57.
regisb
added a commit
that referenced
this issue
Jul 29, 2022
The -m/--mount option makes it possible to bind-mount volumes at runtime. The volumes are declared in a local/docker-compose.tmp.yml file. The problem with this approach is when we want to bind-mount a volume to a service which is specific to the dev context. For instance: the "learning" service when the MFE plugin is enabled. In such a case, starting the service triggers a call to `docker-compose stop` in the local context. This call fails because the "learning" service does not exist in the local context. Note that this issue only seems to occur with docker-compose v1. To resolve this issue, we create two additional filters for the dev context, which emulate the behaviour of the local context. With this approach, we convert the -m/--mount arguments right after they are parsed. Because they are parsed just once, we can get rid of the de-duplication logic initially introduced with the COMPOSE_CLI_MOUNTS context. Close #711. Close also overhangio/tutor-mfe#57.
moonesque
pushed a commit
to edSPIRIT/tutor
that referenced
this issue
Jul 31, 2022
The -m/--mount option makes it possible to bind-mount volumes at runtime. The volumes are declared in a local/docker-compose.tmp.yml file. The problem with this approach is when we want to bind-mount a volume to a service which is specific to the dev context. For instance: the "learning" service when the MFE plugin is enabled. In such a case, starting the service triggers a call to `docker-compose stop` in the local context. This call fails because the "learning" service does not exist in the local context. Note that this issue only seems to occur with docker-compose v1. To resolve this issue, we create two additional filters for the dev context, which emulate the behaviour of the local context. With this approach, we convert the -m/--mount arguments right after they are parsed. Because they are parsed just once, we can get rid of the de-duplication logic initially introduced with the COMPOSE_CLI_MOUNTS context. Close overhangio#711. Close also overhangio/tutor-mfe#57.
moonesque
pushed a commit
to edSPIRIT/tutor
that referenced
this issue
Jul 31, 2022
The -m/--mount option makes it possible to bind-mount volumes at runtime. The volumes are declared in a local/docker-compose.tmp.yml file. The problem with this approach is when we want to bind-mount a volume to a service which is specific to the dev context. For instance: the "learning" service when the MFE plugin is enabled. In such a case, starting the service triggers a call to `docker-compose stop` in the local context. This call fails because the "learning" service does not exist in the local context. Note that this issue only seems to occur with docker-compose v1. To resolve this issue, we create two additional filters for the dev context, which emulate the behaviour of the local context. With this approach, we convert the -m/--mount arguments right after they are parsed. Because they are parsed just once, we can get rid of the de-duplication logic initially introduced with the COMPOSE_CLI_MOUNTS context. Close overhangio#711. Close also overhangio/tutor-mfe#57.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This bug has been reported on tutor-mfe but I believe it concerns tutor not tutor-mfe.
Bug description
Running
tutor dev start --mount=<MFE_PATH> <MFE_NAME>results in docker-compose error. Please find the output for the command regarding theprofileMFE from the tutor-mfe readme in the How to reproduce section below.I've tried the command using both syntaxes of
--mount, running the commands in thefrontend-app-profiledirectory:tutor dev start --mount=profile:.:/openedx/appand
tutor dev start --mount=. profileHow to reproduce
command:
tutor dev start --mount=. profileoutput:
mfe plugin is installed and enabled.
Environment
Ubuntu 20.04
Tutor version: 13.3.1
tutor-mfe version: 13.0.6
Additional context
The problem seems to be that running
tutor dev starttriggers_stop_on_dev_start(code) which in turns callsself.__update_docker_compose_tmp()(code) on the runner which populates/env/local/docker-compose.tmp.ymlwith the volume configuration:But since the profile mfe service is not defined in the
/env/local/docker-compose.prod.ymldocker-compose sees the service definition as insufficient.I've gone through this PR by @kdmccormick which seems closely related.
I'm thinking a solution would be that services must only be added to
docker-compose.tmp.ymlfiles if such service exists in non temp files.The text was updated successfully, but these errors were encountered: