Feature #1871
closedConsolidate project file directories
Description
For the containerization of OpenAtlas, it would be beneficial if the folders where files are written are in one. Right now we have openatlas/uploads, openatlas/export/sql and openatlas/processed_images/. Can we move these folders in one folder named maybe files, e.g. openatlas/ files /uploads, openatlas/ files /export and openatlas/ files /images?
Updated by Bernhard Koschiček-Krombholz about 2 years ago
- Tracker changed from Question to Feature
- Subject changed from Move files folder together to Consolidate project file directories
- Status changed from Assigned to Acknowledged
- Assignee deleted (
Alexander Watzinger) - Target version set to 7.9.0
Updated by Alexander Watzinger almost 2 years ago
We talked about it a few times but you are absolutely right, it really is time to consolidate them because it would have a lot of advantages. It of course would mean that extra steps will be needed when updating the instances but better to do it now than later.
I would even suggest putting the new directory into the project root (already thinking about maybe having one OpenAtlas software installed to run many instances). So the new structure would look like:
- files
- export (former openatlas/export/sql)
- processed_images (former openatlas/processed_images, I would keep the processed_ prefix for clarity)
- uploads (former openatlas/uploads)
- Move folder (locally)
- Adapt .gitignore and taking care of that the empty folders are still tracked in git but not their content
- Adapt paths in config/default.py. Ideally needed only there, if more is needed we should change this
- Adapt install notes in install.md
- Note it in install/upgrade/upgrade.md, also mention that backup scripts might have to be adapted
- When releasing
- Mention in release news
- Adapt wiki page Application and database structure
- I was thinking about a script to automate the folder moves but decided against it, it's better to do it manually because e.g. backup scripts might have to be adapted too
- It should be done in an extra branch and only be merged to develop shortly before a release to avoid complications when switching branches while developing
- Would the frontends need adaption too? I would hope not but we should check and change it for future versions, if this is the case.
What do you think? And is this something you would like to do or should I do it (both is fine with me).
Updated by Bernhard Koschiček-Krombholz almost 2 years ago
- Status changed from Acknowledged to Assigned
- Assignee set to Bernhard Koschiček-Krombholz
Thank you, Alex, for your thoughts! I will take this issue.
Updated by Bernhard Koschiček-Krombholz almost 2 years ago
So far, I'm done. My last issue is how we want to handle the upgrade of instances. But let's talk in person about this.
Updated by Alexander Watzinger almost 2 years ago
- Status changed from Assigned to Closed
I took a look at it, fixed some stuff and adapted the install and upgrade notes a bit, see: https://github.com/craws/OpenAtlas/commit/93ba3c5c1d5aa7b8cc8ccec86c73dcd67f5790a8.
About how to proceed: I guess I will merge it in the new release_candidate when freezing for next release to avoid complications while developing.
Thank you for your work, just as a reminder for me when releasing:
- Merge to branch release_candidate
- Mention in news
- Adapt wiki page Application and database structure
- Adapt in manual (new export path)
- Test frontends and backup scripts