How to manage central, persistent data as superadmin

[ninsbl]

Maybe I just overlooked it, but I could not figure out how to best manage data in persistent mapsets for all users as superadmin...

Is that somewhere documented already?

In a try-out, where I do have superadmin rights, I would like to add data that all users can access to test actinia workflows with own, real life data... But I feel a bit lost here. I do have a fair understanding of GRASS GIS and could probably work on the server directly in GRASS, but it would be nice if I could do things through actinia...

May have some overlap with #264

[ninsbl]

Looking at: https://mmacata.github.io/actinia-introduction/img/actinia_PDB_UDB.png I wonder if it would be an option to create a UDB for superadmin and then create a symlink for either the whole DB or selected locations to the PDB, or would that have problematic side effects?

[mmacata]

Hi @ninsbl in general it is not recommended to create the shared data pool via API. There are different options.

• If it is a basic docker on a server deployment, the data storage might be mounted and data edited directly with GRASS GIS, as you suggested
• if it is a kubernetes deployment or similar, it is possible to create the data pool with a so-called init container, example can be seen here

If you really want to use the API here and keep the option to maintain the data pool via API, the approach with symlinks could work. If all users are in the same group, a symlink wouldn't even be necessary, as mapsets are shared amongst groups. But as I already wrote in #264, by design the persistent DB is not editable via API and often mounted read-only, so that no data loss can occur.

[ninsbl]

Thanks, @mmacata. Very helpful. This answers my question and we will then likely go for a non-REST-API (or SSH / GRASS GIS) way to maintain persistent data...

Maybe worth adding this to FAQ?...

[mmacata]

Definitely, I added it here