Descripton
Authors of application components (such as Aspire integrations) might wish to take advantage of DCP networking services (port allocation, injection of connectivity information via environment variables and startup parameters etc) without being confined to basing their component on existing DCP Executable and Container types. A NetworkResource that combines networking functionality and health tracking, but does not prescribe any specific form of execution, would support these component authors much better.
Related issues
Addtitional notes
As part of this work we should consider adding a way for application components to advertise Services and Endpoints they expose without having to speak Kubernetes protocol and create DCP API objects. This would be effectively a mirror capability to what we have for clients, where they can learn about service endpoints via environment variables and startup parameters. The tricky part is that environment variables and startup parameters are well-established, universally-supported way of pushing information INTO execution units such as processes and containers; there is no equivalent way of "advertising one's capabilities" that is nearly equally well supported. So we might end up relying on Kubernetes API after all, especially if NetworkResource has a standard way of learning how to call back into DCP.
Descripton
Authors of application components (such as Aspire integrations) might wish to take advantage of DCP networking services (port allocation, injection of connectivity information via environment variables and startup parameters etc) without being confined to basing their component on existing DCP
ExecutableandContainertypes. ANetworkResourcethat combines networking functionality and health tracking, but does not prescribe any specific form of execution, would support these component authors much better.Related issues
Addtitional notes
As part of this work we should consider adding a way for application components to advertise
ServicesandEndpointsthey expose without having to speak Kubernetes protocol and create DCP API objects. This would be effectively a mirror capability to what we have for clients, where they can learn about service endpoints via environment variables and startup parameters. The tricky part is that environment variables and startup parameters are well-established, universally-supported way of pushing information INTO execution units such as processes and containers; there is no equivalent way of "advertising one's capabilities" that is nearly equally well supported. So we might end up relying on Kubernetes API after all, especially ifNetworkResourcehas a standard way of learning how to call back into DCP.