API v2 #9
Description
Rationale
After shipping several Aspire releases we have learned enough, and accumulated enough outstanding, breaking-change work items, to develop a new version of DCP API.
Must-have work items and issues
- Create v2 version of all current DCP resources and make all object kinds namespaced. This will allow us to use DCP as a long-running application orchestrator, supporting multiple application runs simultaneously.
- Make sure all current integration tests have their v2 equivalent and are passing
- Account for, and report, all relevant network addresses for Services, Executables, and Containers (eliminate single "effective address" fiction) Service status contains only one effective address #10
- Introduce a "physical" container resource/controller differentiated from the current "logical" container type Introduce a "physical" container resource/controller differentiated from the current "logical" container type #11 An immediate benefit of doing this is logic reuse between Container and ContainerNetworkTunnelProxy controllers.
- Introduce a "process" resource differentiated from the current, logical
Executableto be able to model Executables that are suspended under debugger/restarted after code change (watch mode). Relevant Aspire issue: Add Suspended state for projects/Executables dotnet/aspire#9321 - Support for multiple networks Support for multiple networks #18
- Resource change tracking Track Executable and Container state changes #34
- Add "container image" resource Introduce a dedicated resource for container image management (API v2) #8
- Allow more than one ExecutionType to be specified for an Executable (to solve [DCP] Executables that are not able to be run via IDE should fall back to process execution dotnet/aspire#12522)
Should-consider work items and issues
These are issues that should be considered when designing details of v2 API and may benefit from being implemented on top of the new v2 API (not supported by v1 API), but are not blocking with regards to shipping v2 API