Environment Variables: Inconsistency between docs & code

[anhldbk]

Describe the issue

This is an accompanied issue with the unmerged PR dapr/cli#770.

I spotted the inconsistency in following sources:

• Our document
• Env passed by CLI to child apps
• Our Python SDK: global settings

URL of the docs

• Environment variable reference
• Dapr CLI: run command
• Python SDK: global settings. The expected settings are identical with dapr/dapr env_variables.go

Screenshots

To summarize, here are the inconsistencies

Variable	Fact	Note
APP_ID	Expected from Python SDK, not defined by docs
APP_PORT	Expected from Python SDK, not defined by docs	port of apps, http/grpc depending on mode.
APP_TOKEN_API	Expected by Doc. dapr/cli does not pass to child apps
DAPR_METRICS_PORT	Not defined by docs. Used by dapr/cli, Python SDK
DAPR_PROFILE_PORT	Expected from Python SDK, not defined by docs
DAPR_PLACEMENT_HOST	Expected by docs. dapr/cli does not pass to child apps
DAPR_TOKEN_API	Expected by docs. dapr/cli does not pass to child apps
HOST_ADDRESS	Expected from Python SDK, not defined by docs

Questions

I want to correct our docs. So please answer following questions

1. For expected-but-not-defined variables, what should we do? Define them in docs?

• APP_ID
• APP_PORT
• APP_TOKEN_API
• DAPR_METRICS_PORT
• DAPR_PROFILE_PORT
• HOST_ADDRESS

2. For defined-but-not-passed variables, do we need to change dapr/cli or just remove them?

• DAPR_PLACEMENT_HOST
• DAPR_TOKEN_API

3. If we pass APP_PORT, do we need to pass the associated mode? Actually I can't find things related to mode in our documentation. The most resemble to that variable is app-protocol

[anhldbk]

@yaron2 @mukundansundar @artursouza PTAL

[msfussell]

Thanks @anhldbk for writing up this detailed issue. Greatly appreciated
IMO

1. These are all needed in the docs
2. The DAPR_TOKEN_API certainly needs to be passed to the app
3. Not sure @yaron2. I do not see why the application would need to know the mode. Do you have a scenario?

[anhldbk]

@yaron2 How do you think?

[artursouza]

DAPR_PLACEMENT_HOST is not in any source code, only docs. This is safe to be deleted from docs. Same for DAPR_TOKEN_API.

APP_PORT is used only by the sidecar and it handles mode correctly.

HOST_ADDRESS is set by CLI but not used anywhere. It should be safe to be removed.
DAPR_PROFILE_PORT is set by CLI but not used anywhere. It should be safe to be removed.
DAPR_METRICS_PORT is set by CLI but not used anywhere. It should be safe to be removed.

APP_TOKEN_API is document and not used, should be removed.

The environment variables you are referring to are used in Dapr sidecar

Also, see this documentation about K8s annotations and CLI flags: https://docs.dapr.io/reference/arguments-annotations-overview/

[yaron2]

LGTM on @artursouza's comment. I'd really like to see a PR for this @anhldbk

[anhldbk]

@artursouza I propose we should provide definitions for APP_ID, APP_PORT also

To sum up, here are our actions. Is that ok?

[anhldbk]

@artursouza another question: should we dedicate Environment variables for variables passed to child applications only? There are so many environment variables automatically scoped by Viper.

If yes, we'll remove definition for DAPR_NETWORK, NAMESPACE

[msfussell]

DAPR_API_TOKEN and APP_API_TOKEN are validate env variables, they are just spelt wrong in the table here https://docs.dapr.io/reference/environment/
Also APP_ID and APP_PORT should be in the docs

For DAPR_PLACEMENT_HOST, are you sure that the Placement service does not use this on startup if I run the exe myself?

[anhldbk]

For DAPR_PLACEMENT_HOST, are you sure that the Placement service does not use this on startup if I run the exe myself?

@msfussell @artursouza WDYT?