External data store for Radius

[zachcasper]

Overview of feature request

Today, Radius stores its configuration and resource data in etc within the host Kubernetes cluster. This presents challenges for users backing up their Radius resource data and coordinating with Kubernetes cluster updates. This feature is to implement options for advanced Radius deployments which use an external data store provided by the user. The first supported external data store should be PostgreSQL.

Acceptance criteria

• Getting started users can install Radius without needing an external database
• Advanced users can install Radius and provide an existing PostgreSQL database

Additional context

No response

Would you like to support us?

• Yes, I would like to support you

AB#13755

[radius-triage-bot]

👋 @zachcasper Thanks for filing this feature request.

A project maintainer will review this feature request and get back to you soon.

We also welcome community contributions! If you would like to pick this item up sooner and submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.

For more information on our triage process please visit our triage overview

[radius-triage-bot]

👍 We've reviewed this issue and have agreed to add it to our backlog. Please subscribe to this issue for notifications, we'll provide updates when we pick it up.

We also welcome community contributions! If you would like to pick this item up sooner and submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.

For more information on our triage process please visit our triage overview

[superbeeny]

Adding some more context based on conversations in the last design meeting:

Some of the why we need to change the current implementation of the radius datastore?

1. It is hard to debug.
2. It is hard to migrate.
3. Over time performance degrades to a point the cluster becomes unusable.

Some features to maintain

1. No more steps required from the user during rad init
2. Maintain the simplicity of the "Getting Started" and other tutorials.
3. We don't want to maintain a lot of stuff or be responsible for items outside our expertise. This includes operations on how to maintain and configure Postgres.
4. Production should support "bring your own database", BYOD.

Some features to add

1. Start performance profiling of the radius installation, as we add more components to radius it will become necessary to maintain a performance profile.

Workback Plan:

Goal: Radius uses the database as a datastore.

1. Complete implementation of the helm chart install.
2. Generate username and password and store in secrets.
3. Implement seeding script to initialize the schema.
4. Implement performance profiling for the radius deployment within the cluster.
5. Update the developer documentation.
6. Update the User documentation.
7. Update the production deployment documentation with instructions to bring your own.
8. Switch Radius over to using the db as the datastore.
9. Profit!

@rynowak and @zachcasper thoughts?

[superbeeny]

@kachawla and @zachcasper is there a preference on how to initialize the db? can do either through adding to the docker image or possibly shelling out from rad init. Thoughts?

[kachawla]

@kachawla and @zachcasper is there a preference on how to initialize the db? can do either through adding to the docker image or possibly shelling out from rad init. Thoughts?

Sorry missed this earlier. Synced up offline on this.