Skip to content

Latest commit

 

History

History
178 lines (113 loc) · 5.48 KB

03-07_platform-settings.md

File metadata and controls

178 lines (113 loc) · 5.48 KB
Raw

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.
  1. 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.
  1. Are there any other workarounds, and if so, what are the drawbacks?
  • n/a
  1. 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 and PostHog.

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
  1. What's the estimated time to completion?
  • 2-3 weeks

Please provide all tasks (gists, issues, pull requests, etc.) completed to implement the design: