You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Activity
crawlchat commentedon Sep 21, 2026
COSMOS Product Expert response
Thanks for the detailed proposal! I checked the current plugin/interface configuration docs and code, and confirmed that no
SHARED_RESOURCEkeyword currently exists forINTERFACEorMICROSERVICEdefinitions .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/MICROSERVICEcover things likeCMD,CONTAINER,PORT,ROUTE_PREFIX,SHARD,STOPPED, andSECRET, 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:
SHARED_RESOURCEplugin keywordI 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.