Skip to content

Refactor CTL to Support Multiple BeeGFS Instances #261

@iamjoemccormick

Description

@iamjoemccormick

We need to update the CTL library to properly support managing multiple BeeGFS instances simultaneously (e.g., for the CSI driver and future use cases like web frontends).

Currently when used as a library CTL relies on global state initialized using InitViperFromExternal(), which works for a single BeeGFS instance but doesn’t scale. Two main approaches have emerged:

  • Option 1: Instance via Context
  • Option 2: Explicit Client with Sub-Services

Option 2 (explicit client) is the more idiomatic and future-proof choice. It’s widely used in the Go ecosystem, encourages clean architecture, and makes testing and multi-instance support straightforward.

Option 1 could work as a transitional step if we want to minimize churn, but it introduces implicit behavior that may be problematic long-term.

Next Steps:

  • Discuss the proposed options with the team and decide on the option 1 or 2.
  • Come up with a design proposal and plan for how we can roll this out.
    • Notably, should we make it possible to continue using the CTL library as it exists today (at least for some period of time). For example by making InitViperFromExternal() initialize a global client instance, then the current free standing functions are just a thin wrapper over the global client.

Metadata

Metadata

Labels

ctlIssues primarily affecting the BeeGFS control tool.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions