Persistance, for 'manual' testing

[danpoltawski]

For doing manual testing, we don't want our docker environments to be completely torn down and recreated each time.

Need to investigate this:

1. I think docker-compose does some sort of volume persistance itself, especially if you use stop rather than down. But I have not looked into this at all
2. We might want explict mounted data directories

So far i've been focused initially on quick manual tests and automated testing and haven't examined this case at all, but manual testing is very much part of the usecase for this project.

[abias]

Hi Dan,

For doing manual testing, we don't want our docker environments to be completely torn down and recreated each time.

I completely agree with this need for our use cases.

I think docker-compose does some sort of volume persistance itself, especially if you use stop rather than down. But I have not looked into this at all

I'm not a Docker expert yet, but I have seen than with
bin/moodle-docker-compose stop
and
bin/moodle-docker-compose start
you can stop and start the docker containers and the containers will still have their data, even if the whole docker environment is shut down and restarted in the meantime.

So, do you think there is anything left to do or unsure?
If not, I would create a PR to add this information to the README.md.

We might want explict mounted data directories

Could you please elaborate what you mean with this sentence so that I can understand the problem you are seing?

Thanks,
Alex

[scara]

Hi @abias,
trying to anticipate Dan's reply, that means assigning real folders (i.e. somewhere out of the container, e.g. in the host) where to safely store what required to persist the tests setup (or some hacking done while investigating a failure) i.e. the database and the fixtures as deployed into Moodle i.e. the so called moodle data.
Read more at https://docs.docker.com/compose/compose-file/compose-file-v2/#volumes-volume_driver.

Since this setup is for dev/test purposes I'm keen to second your idea of PR w/o the need to expore more optional params to give persistance to the environment: anyone playing with down will be warned about the lacking of persistance by design.
Indeed, the only drawback I found w/ this lacking is when switching among different DBs which requires a down=>export MOODLE_DOCKER_DB=<other_db_type>=>up -d sequence but I'm fine with missing the status while switching.

HTH,
Matteo

[abias]

Hi Matteo,

thank you for your feedback.

trying to anticipate Dan's reply, that means assigning real folders (i.e. somewhere out of the container, e.g. in the host) where to safely store what required to persist the tests setup (or some hacking done while investigating a failure) i.e. the database and the fixtures as deployed into Moodle i.e. the so called moodle data.
Read more at https://docs.docker.com/compose/compose-file/compose-file-v2/#volumes-volume_driver.

Allright, I understood this now. I think this is really some "extended usage" which Dan or anyone else can think about if this should be officially supported.

Since this setup is for dev/test purposes I'm keen to second your idea of PR w/o the need to expore more optional params to give persistance to the environment: anyone playing with down will be warned about the lacking of persistance by design.

I added a note to README in PR #54. Please feel free to comment on the PR if you have improvement proposals.

Indeed, the only drawback I found w/ this lacking is when switching among different DBs which requires a down=>export MOODLE_DOCKER_DB=<other_db_type>=>up -d sequence but I'm fine with missing the status while switching.

So you mean that to switch the underlying DBMS, you have to destroy the containers and rebuild the containers completely and it would be nice to be able to switch the DBMS while keeping the data inside the DB? From my point of view, this is an edge case and you would have to deal with all the same obstacles like you have it in production when moving from one DBMS to another while keeping production data. Do you think Docker can help here in any way?

[scara]

Do you think Docker can help here in any way?

I think that what written in #55 describes what docker could and couldn't do w/o any further code.

For the record, I'm not talking here about moving data between different DB types but the ability to use them concurrently, even more versions of the same DB type.

HTH,
Matteo

[danpoltawski]

A very common use case here which i don't think is handled with just the 'stop and start', is for example using the same data for both a php56 install and php71 install - being able to quickly test on both versions of php without completely duplicating an install.

[danpoltawski]

I think the new bits of readme and other pull request are probably enough to keep open for now with work to be done, so i'll close this.