Skip to content

Shared Resource Across Scopes #3909

Open

Description

@ryanmelt

What is the use case or problem this feature would solve?

When using a shared expensive asset, it would be nice to be able to define it in multiple scopes, but only have it actually in one scope at a time. This prevents two different scopes from trying to use it at the same time.

Describe the solution you'd like

Add a new SHARED_RESOURCE keyword to at least Interfaces to mark them as shared between scopes. First plugin installed claims the resource. Additional plugins run the installation, but don't spawn the microservice. New apis to switch the resource between scopes and ensure only active ever in one scope at a time.

Additional context

No response

Screenshots

No response

Activity

  1. added theissue type on Sep 21, 2026
  2. added and removed
    triageMore information is needed
    on Sep 21, 2026
  3. crawlchat commented on Sep 21, 2026

    @crawlchat
    COSMOS Product Expert response

    Thanks for the detailed proposal! I checked the current plugin/interface configuration docs and code, and confirmed that no SHARED_RESOURCE keyword currently exists for INTERFACE or MICROSERVICE definitions .

    Today, each plugin installation independently spawns its own interfaces/microservices — there's no built-in concept of a resource being "claimed" by one scope and left dormant (installed but not running) in others. The existing keywords for INTERFACE/MICROSERVICE cover things like CMD, CONTAINER, PORT, ROUTE_PREFIX, SHARD, STOPPED, and SECRET , but none address cross-scope resource ownership/arbitration.

    This looks like a legitimate new feature request rather than a bug or existing capability, since it would require:

    • A new SHARED_RESOURCE plugin keyword
    • Coordination logic so only the first installing scope actually starts the microservice, while subsequent scopes register but stay inactive
    • New APIs to transfer "active" ownership between scopes with a guarantee of exclusivity

    I don't see this tracked elsewhere in the docs/codebase I have access to, so I'd recommend keeping this open for the OpenC3 engineering team to scope out the design (e.g., how ownership transfer should be triggered — manual API call vs. automatic failover, and how state is persisted across scope changes).

    If you have a specific use case (e.g., a particular hardware interface or licensed resource) that's driving this, adding that context would help prioritize/design the feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions