chore: multi-tenant cleanup #754

New issue

Closed

opened 2026-03-28 04:28:11 +00:00 by mfreeman451 · 1 comment

mfreeman451 commented

2026-03-28 04:28:11 +00:00

Owner

Imported from GitHub.

Original GitHub issue: #2313
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2313
Original created: 2026-01-15T05:17:03Z

I think instead of trying to make the core-elx and web-ng be responsible for tenant provisioning and a lot of stuff that sort of crosses isolation boundaries at least with the platform tenant, we need to make a clean break from all of this and simplify the multi-tenancy architecture by:

create new repo for serviceradar-saas
removing tenant-workload-operator and putting in new repo
helm deployment cleanup around tenant-workload-operator
reconsider concept of super_admin, most likely not really needed
analysis of codebase around multi-tenant schema changes between public/tenant schemas
figure out how spiffe/spire work, should probably be owned by control plane

Our stack doesn't really need to be "multi-tenant" aware, we will build a new SaaS control plane outside of the OSS serviceradar repo that separates out the creation and management of tenants, using our tenant-workload-operator and so on. In the SaaS version of SR, a NATS cluster and cnpg cluster will live in separate/outside namespaces and will be the only shared resources in the SaaS. Every tenant going forward will get their own pods/services for everything except NATS and CNPG.

We need a clean deployment for OSS users that are just going to be installing this as a single-tenant variant on k8s or docker, and a new helm only deployment system for the SaaS that is in the new repo.

We are isolating all of the multi-tenant provisioning and management into this separate control plane now, so there should be lots of opportunity to find places to cleanup stuff in the codebase.

Imported from GitHub. Original GitHub issue: #2313 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2313 Original created: 2026-01-15T05:17:03Z --- I think instead of trying to make the core-elx and web-ng be responsible for tenant provisioning and a lot of stuff that sort of crosses isolation boundaries at least with the platform tenant, we need to make a clean break from all of this and simplify the multi-tenancy architecture by: - [x] create new repo for serviceradar-saas - [x] removing tenant-workload-operator and putting in new repo - [x] helm deployment cleanup around tenant-workload-operator - [x] reconsider concept of super_admin, most likely not really needed - [x] analysis of codebase around multi-tenant schema changes between public/tenant schemas - [x] figure out how spiffe/spire work, should probably be owned by control plane Our stack doesn't really need to be "multi-tenant" aware, we will build a new SaaS control plane outside of the OSS serviceradar repo that separates out the creation and management of tenants, using our tenant-workload-operator and so on. In the SaaS version of SR, a NATS cluster and cnpg cluster will live in separate/outside namespaces and will be the only shared resources in the SaaS. Every tenant going forward will get their own pods/services for everything except NATS and CNPG. We need a clean deployment for OSS users that are just going to be installing this as a single-tenant variant on k8s or docker, and a new helm only deployment system for the SaaS that is in the new repo. We are isolating all of the multi-tenant provisioning and management into this separate control plane now, so there should be lots of opportunity to find places to cleanup stuff in the codebase.

mfreeman451 commented

2026-03-28 04:28:12 +00:00

Author

Owner

Imported GitHub comment.

Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2313#issuecomment-3765088859
Original created: 2026-01-18T09:14:40Z

closing as completed

Imported GitHub comment. Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2313#issuecomment-3765088859 Original created: 2026-01-18T09:14:40Z --- closing as completed