Closed philliphoff closed 1 year ago
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.
Describe the proposal
Tooling may need to correlate applications to the configuration files with which the components were loaded. For example, to display or otherwise use component-specific configuration properties. Currently there is no easy means for tooling to identify the configuration file with which a component was loaded, in particular, if resource paths are relative. (One could get the
daprd
process command, find the--resources-path
arguments, then find the process's working directory, and put them together. However, the process for doing so differs widely across platforms as well as restrictions on the availability of that data.)If the Dapr CLI (or runtime?) stored the absolute paths used to locate/load component configuration files, to be reported with a
dapr list
(potentially only when in the JSON output format), it would greatly simplify tooling that needs to perform more in-depth introspection of application components.Open question(s):
daprd
vs.dapr
(and reported via metadata APIs), as it's the runtime itself that actually loads the components from the files? This would then allow capturing components whendaprd
is used directly rather than via the CLI.Release Note
RELEASE NOTE: