From 076817abd55f9aadcf7eca46c92dbba18a97166b Mon Sep 17 00:00:00 2001 From: dave vader <48764154+plyr4@users.noreply.github.com> Date: Sun, 19 May 2024 23:35:05 -0500 Subject: [PATCH] feat(proposal): dynamic platform settings (#921) * feat: add platform settings proposal * wip: platform settings table --- proposals/2024/03-07_platform-settings.md | 178 ++++++++++++++++++++++ proposals/2024/README.md | 7 + proposals/README.md | 4 + 3 files changed, 189 insertions(+) create mode 100644 proposals/2024/03-07_platform-settings.md create mode 100644 proposals/2024/README.md diff --git a/proposals/2024/03-07_platform-settings.md b/proposals/2024/03-07_platform-settings.md new file mode 100644 index 00000000..55095d91 --- /dev/null +++ b/proposals/2024/03-07_platform-settings.md @@ -0,0 +1,178 @@ +# Platform Settings + + + +| Key | Value | +| :-----------: | :-: | +| **Author(s)** | David.Vader | +| **Reviewers** | | +| **Date** | March 7th, 2024 | +| **Status** | In Progress | + + + +## Background + + + +**Please provide a summary of the new feature, redesign or refactor:** + + + +* Build a system that gives platform admins the ability to update platform settings on the fly, without requiring a platform redeploy. +* Potentially support multiple configs and an ability to switch the "active" configuration. + +**Please briefly answer the following questions:** + +1. Why is this required? + +* This allows admins to respond quicker to configuration change requirements and configuration rollbacks. +* It may set the groundwork for feature flags, meaning faster feature rollout and easier feature rollback. + +2. If this is a redesign or refactor, what issues exist in the current implementation? + +* Platform settings are currently configured using environment variables and are basically treated as insensitive secrets. This is fine and should still be supported moving forward (at least for the next release) but it would be ideal to set these in a provider that can be updated. + +3. Are there any other workarounds, and if so, what are the drawbacks? + +* n/a + +4. Are there any related issues? Please provide them below if any exist. + +* n/a + +## Design + + + +**Please describe your solution to the proposal. This includes, but is not limited to:** + +* new/updated configuration variables (environment, flags, files, etc.) +* performance and user experience tradeoffs +* security concerns or assumptions +* examples or (pseudo) code snippets + +## Solution 1: Use A New Database Table + +### Database + +* A new table called `settings` with fields such as: + * `clone-image` + * `log.level` + * `log.formatter` + * `queue.routes` + * `repo-allowlist` + * `schedule-allowlist` + * etc, anything non-sensitive. + +### Server + +* Logic for creating the initial platform settings on startup (using environment variables?). +* A new API handler `GET /admin/settings` that returns a JSON for platform settings. +* A new API handler `PUT /admin/settings` that receives a JSON payload for updating platform settings. +* Alerting/logging specifically for tracking changes made. +* A source of truth definition for all configurable platform settings. +* A system for mapping platform settings database type to urfave flags. + +### CLI + +* Commands for managing platform settings. + +### Pros + +* It is a simple and straight-forward solution that solves the problem. +* It doesn't require any additional libraries or fancy tooling. +* It would allow admins to configure the platform directly in the UI. + +### Cons + +* It does not scale well without some boiler plate code. It might get annoying to modify database tables every time you add a server configuration. +* It would require full-stack development every time a new field is added that we should be able to update. +* It leans heavily on the `admin` user flag which does not have the best control experience. +* More code (hidden pro?). + +## Solution 2: Use a Feature Flag Provider + +### Database + +* n/a + +### Server + +* An authentication process for fetching flags from the provider. +* A pattern for defining feature flags that can be fetched. +* A pattern for actually fetching a feature flag and executing custom code. + +### Pros + +* It would scale well. +* It would allow us to implement actual feature flags. +* Feature flag providers are getting pretty slick, see [Unleash](https://github.com/Unleash/unleash) and [PostHog](https://posthog.com/). + +### Cons + +* It would potentially require us to self-host another solution. +* It would make our codebase slightly harder to test. +* It would require another layer of communication. +* It would require admins to visit a different source of truth to apply and set configurations. + +## Implementation + + + +**Please briefly answer the following questions:** + +1. Is this something you plan to implement yourself? + + +* Yes + +2. What's the estimated time to completion? + + +* 2-3 weeks + +**Please provide all tasks (gists, issues, pull requests, etc.) completed to implement the design:** + + + diff --git a/proposals/2024/README.md b/proposals/2024/README.md new file mode 100644 index 00000000..27ff9b38 --- /dev/null +++ b/proposals/2024/README.md @@ -0,0 +1,7 @@ +# Proposals + +This directory is meant to house a historical record of the more substantial potential features and modifications to be made to Vela in 2024. + +## Index + +- [03/07 Platform Settings](2024/03-07_platform-settings.md): contains proposal information for `platform settings` and dynamic configurations. diff --git a/proposals/README.md b/proposals/README.md index 1ccce107..aaf171f9 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -36,3 +36,7 @@ To create a new proposal, make a PR into master using the [template](https://git - [03/16 Scheduled Builds](2023/03-16_scheduled-builds.md): contains proposal information for scheduling builds for a repo. - [05/11 Queue Sensitivity](2023/05-11_queue-sensitivity.md): contains proposal information for enhancing queue security. - [05/16 Worker Visibility](2023/05_16_worker_visibility.md): contains proposal information for extending the worker table with additional fields, and their uses. + +### 2024 + +- [03/07 Platform Settings](2024/03-07_platform-settings.md): contains proposal information for `platform settings` and dynamic configurations.