Bind mount is not working for the mfe apps in tutor dev mode. #57
Labels
bug
Something isn't working
Comments
regisb
added a commit
to overhangio/tutor
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
to overhangio/tutor
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
to overhangio/tutor
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
to overhangio/tutor
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
to overhangio/tutor
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
to overhangio/tutor
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
to overhangio/tutor
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.
|
Thanks for reporting this @dagg . It should be fixed in the latest Tutor release (v14.0.4). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have experienced the following problem while trying to bind-mount (using the --mount option) some of the mfe apps in tutor dev mode.
After I copy the learning mfe to a local directory:
I try to mount the learning mfe app (according to tutor's documentation) while starting the learning app as shown below:
and I get the following error:
The exact same happens also with the profile app (learning and profile are the mfe apps I have tried so far).
I have to note that after I run the "copyfrom" command I have to recursively chown the directory "frontend-app-learning" because it's contents are owned by the "root" user.
Also the following command (without the "--mount" option) works perfectly:
When I try to mount (using the --mount option) the lms or other non-mfe apps it seems to be working correctly though...
The only workaround that worked for me so far was to override the "docker-compose.yml" file by creating a "docker-compose.override.yml" file in the directory "../env/dev" ("$(tutor config printroot)/env/dev") which is a clone of the original "docker-compose.yml" that already exists in there, and put in the learning/volumes part the volume I want to be mounted when starting the learning app, like it's shown below:
But I guess that's not the most proper way of doing it.
I think there is a fix in a similar problem in v13.2.2 of Tutor: Here
Maybe it's something similar but specific for bind mounting the mfe apps...
I use the latest (at this time) tutor version (14.0.3).
The text was updated successfully, but these errors were encountered: