Multi-Tenant support

[0xAda]

Core is currently a single tenant app, this has historically been inconvenient. Running multiple instances on one box requires us to juggle resource allocations, a multi tenant approach would allow us to run these all on one instance which has all the resources. We'd also gain a lot of freedom in terms of test isolation, each test can run in its own tenant and we don't have to worry about clashing config changes and can test much more thoroughly (e.g. things that rely on specific database states).

In terms of implementation, I believe the best way would be to determine the tenant based on the host header. This would allow us to make the change entirely transparent to the frontend and any other API clients. The database changes would mostly be a matter of creating an event table and tagging top level objects (users, teams, categories, etc) with the event id. I'm not sure how we'd implement this on the views level, possibly some middleware magic could handle it, I'd be interested in thoughts from people more experienced with Django.

I have no thoughts yet on how we'd migrate our existing set of instances to one multi tenant instance, I'm fairly sure we have different versions running, that would be the first thing we need to rectify.

[jchristgit]

One more thing I think we need to take care of is the config app. Currently, as far as I'm aware, it's a bunch of globals set for the whole instance. That would need to be migrated to per tenant level. Maybe we should make separate issues for each distinct refactor here, starting with finding the tenant based on the host header?

[jchristgit]

https://pypi.org/project/django-tenants/ might be a relatively easy solution if we have all the data in models.

[jchristgit]

Rethinking back to this, I remember there were some issues with django-tenants where it would start each query with `SET search_path` leading to a lot of latency adding up in our environment. The reason why it didn't just prefix all the queries with the schema name was,

[0xAda]

Yeah, the config app would need changes, I think this would actually offer a bit of clarity over the config app as historically it's been unclear what goes in config and what goes in settings.py. I'd still like to reconsider the config app, it feels gross but that's a separate issue.

…

On Thu, Aug 1, 2024, 16:54 jchristgit ***@***.***> wrote: One more thing I think we need to take care of is the config app. Currently, as far as I'm aware, it's a bunch of globals set for the whole instance. That would need to be migrated to per tenant level. Maybe we should make separate issues for each distinct refactor here, starting with finding the tenant based on the host header? — Reply to this email directly, view it on GitHub <#350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBCZQ4RBVVG3MV3PKIYHEDZPJK4HAVCNFSM6AAAAABL2HJVA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRTGQYTCMZZGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>