Expose stdin/stdout/stderr streams for Containers and Executables
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 189
- Forks
- 24
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 18
Description
## Feature description
Users may desire to interact directly with resources. E.g. Aspire dashboard might want to have a terminal emulator that one could attach to a container-based-, or process-based resource and interact directly with it. Or an MCP server with stdio interface might be part of Aspire workload and one would need to access its stdio streams to use it.
## Design outline and constraints
1. Both Executable and Container resource get a flag that enables "attaching to stdio" (stdin + stdout + stderr). When this flag is present, we capture and memorize standard file descriptors for a given resource as it is started.
> Consider if we could enable attaching to `stdio` for all Executables and Containers
1. Executable and Container API objects get a `stdio` subresource. When that subresource is queried, we create and return paths to 3 Unix domain sockets that are attached to relevant resource file descriptors. We also start a proxy that will push data between these sockets and resource file descriptors.
> These paths could also be simply status properties of Executable and Container objects.
1. Standard output and standard error streams are captured and stored in (raw) temporary files from the moment a resource (with `AttachToStdio == true`) is started. They are also forwarded to the log writer so the existing log streams continue to work for `AttachToStdio == true` resources.
1. When a new client connects to stdout or stderr socket, the existing content is replayed to it.
1. If more than one client connects to stdin socket, bad things might happen :smile:
## Additional notes
Related to https://github.com/microsoft/usvc/issues/241
@sebastienros has created a proof-of-concept https://github.com/microsoft/usvc-apiserver/tree/sebros/stdin The details are different from the design outline above, but it illustrates the potential.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the feature description and the linked usvc-apiserver stdin proof of concept. Compare its approach with the stated design outline for Executable and Container resources, including stdio subresources or status properties, Unix domain sockets, proxying, and temporary-file replay. Done should cover the agreed API and stdio behavior for attached resources.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100