[Proposal] Add ability to override application commands in Dapr Compose configuration files

[philliphoff]

Describe the proposal

This proposal is related to the Dapr Compose feature work currently underway.

Tooling that integrates the Dapr Compose feature will likely use Dapr to manage startup of most services and applications, by directly invoking the Dapr Compose command. In certain situations, however, tooling may need to alter or eliminate the commands for certain applications. For example, when debugging a .NET application, the application must be started via the .NET debugger, outside of a traditional dapr run. Such tooling needs a way to inform the Dapr Compose feature of which applications to start normally, which applications have an altered command, which applications have no command (but still need the sidecar), and which applications should not be started at all.

There are several ways this could be done:

1. Tooling simply points Dapr Compose to a different (likely generated file): this is the simplest approach but suffers from a significant drawback in that troubleshooting startup issues becomes difficult, as such generated files tend to be ephemeral, randomly names, located apart from the applications themselves, and mixed with other such generated files.
2. Dapr Compose allows configuration "layering" and tooling points to the original configuration file and an "override" file: this approach is similar to Docker Compose, where configuration files are successively layered to create a final configuration model. Advantages are that it's a familiar approach and the overrides are easier to identify by users (because each file only contains the changes from the original). Disadvantages are similar to the item above; locating the override files can be more difficult.
3. Dapr Compose allows the command properties of each application section to be overridden via command line arguments: this model is likely the simplest for tooling to implement and the user to understand as the overrides become part of the logged command line with no risk of losing an ephemeral override file. Downsides are the override applies only to the command (and not any other portion of the configuration); each additional property desired to change in the future must be exposed as a command line argument, which adds complexity (especially given the 1:many relationship of applications to configuration files).

There may also be other options that I haven't considered.

Of these, I believe (2) or (3) to be the better options. Option (2) feels like the best compromise between flexibility for tooling, familiarity and observability by users, and ease implementation within the Dapr Compose feature.

Release Note

RELEASE NOTE:

[dapr-bot]

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.

[dapr-bot]

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.