2023-07-11 installation meeting¶
- User database - Database containing user data (shows up in UI)
- Internal database - Database containing metadata used internally by the software (doesn’t show up in UI)
1st Persona: Someone Trying out Mathesar quickly, with Docker¶
- They have docker
- Want to try things out locally
- Won’t keep this installation long-term
- Single Docker image
- Postgres inside
- Secret key generated with no interaction
- Side benefit: support older Docker versions (since our compatibility issues are with docker compose)
- Should we have a second Docker image without Postgres?
- For connecting to remote DBs
- This seems for a different persona
- Also, connecting to local DBs (vs. remote DBs) from a Docker container is much harder for Linux
- Config files vs. environment variables
- Research into similar products indicates users wants config files that can be overridden by environment variables
- Config files can be put into protected locations (e.g. not readable by other users on the system)
- Config file will live in the container, not the host system
- Environment variables doesn’t make sense for this persona
- We can pass environment variables when running the image if needed, and they would persist in the config file in the Docker filesystem
- What do we need environment variables for?
- Binding volumes?
- Not needed for this persona
- If they want to transition installation to long term solution, that would be different, but we’re not recommending that anyway
- We could have docs for “you lost your container, how to get your data”
- Using different ports?
- Binding volumes?
- For this persona, it’s about speed to get Mathesar running
- What about users who want to try it out quickly by connecting to an existing DB?
- Pass config via environment variables
- Write config file via UI, persist to disk.
Installing Mathesar on PaaS (one-click, frictionless)¶
- Need a lean image without a DB for this
- We want to wire Mathesar up to managed DB services
- We need to decide what PaaS to target
- Should be frictionless
- Managed Postgres would be helpful
- Additional work we might need to do, on a per-platform basis:
- Add Mathesar to their installer system
- Add platform-specific details to our documentation
- Which platforms should we target?
- Mukesh has not yet done research into this
- Pavish: We should consider the possibilty that users might want multiple instances of Mathsar running on the same PaaS. How will we acheive this if we use a config file?
- Kriti: “I’m sure this is a solved problem”
- Pavish: Mathesar might be unique in that we are planning to allow the application to modify the config file
- Pavish: What are we storing in the config file?
- Mukesh: it would be the same as all the ENV vars
- Pavish: Do we even need the config file?
- Mukesh: it’s important for persistance. It’s important in the case when you have Mathesar running behind a load balancer. Config file is meant only for running one instance of Mathesar
- Brent: I’m not convinced that horizontal scaling is a huge priority right now. In that case, the stuff that you’s want to persist would be in the database anyway.
- Kriti: PaaS platforms often have their own systems for persisting private data like “secret key” and similar.
- Where do we store the database connection credentials?
- PaaS service doesn’t necessarily have access to modify files on disk, so we would need to store the user DB credentials in the internal DB.
- How do we secure the credentials that we’re storing in the Django DB?
- We either:
- Need to store connection credentials in the internal DB
- OR: we need to give up support for editing DB connections through the UI.
- We need to do more research on how to store connection credentials
- Brent: If we can solve the problem of securely storing the connection credentials in the internal DB, then we solve a huge class of problems that apply to many different personas
- What does Mukesh need in order to write up a project?
- Sean: concerned that we’re not looking at the high level of “reducing total number of personas”
- Kriti: we’ve reduced the number of personas through prioritization
- Solving PaaS well could help solve other personas too
- Kriti reccomends:
- Work towards implementing the “Single Docker Image” approach
- Continue research on other approaches
- Fine to focus on other research and implementation that would seem to improve other personas too, e.g. Zipapps, etc.
- By the end of the cycle, we should have a plan for what personas we’re doing and the implementation plan for them
- Mukesh will write up project
- Kriti & Mukesh will discuss next steps and schedule another call