Feat/310 default agent conf

[CasperGN]

Description

This PR allows default configuration and default secrets to be passed to the agent through agent-secretstore and agent-runtime. This PR also covers automatically setting up OTel tracing if the appropriate configuration parameters are passed through agent-runtime statestore.
This allows operators to automate configuration setup as well as externalize the lifecycle of these configurations.

NB: This carries a breaking change with dropping support for Python 3.10.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR closes: #310

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Created/updated tests
• Tested this change against all the quickstarts
• Extended the documentation
  • Created the dapr/docs PR:

Note: We expect contributors to open a corresponding documentation PR in the dapr/docs repository. As the implementer, you are the best person to document your work! Implementation PRs will not be merged until the documentation PR is opened and ready for review.

[CasperGN]

@sicoyle before I get too far it would be good to align on the assumptions I take on naming:

Secrets:

• OTEL_TOKEN -> Bearer token for OTLP auth

Conf:

• OTEL_ENDPOINT -> Str: endpoint to otel collectors
• OTEL_ENABLED -> Bool: whether to init otel
• OTEL_TRACING_ENABLED -> Bool: Whether to init tracing
• OTEL_LOGGING_ENABLED -> Bool: Whether to init logging
• OTEL_TRACING_EXPORTER -> Enum: Type of exporter (otlp_grpc, otlp_http, zipkin, console, defaults to latter)
• OTEL_LOGGING_EXPORTER -> Enum: Type of exporter (otlp_grpc, otlp_http, console, defaults to latter)

I was thinking we could also allow users to specify this via env variables on equal terms.

[sicoyle]

@sicoyle before I get too far it would be good to align on the assumptions I take on naming:

Looks great so far!

Instead of an env var equivalent what are your thoughts on if we add an otelConfig dataclass instead as an optional secondary setup to reduce the amt of env vars we support.

[sicoyle]

few comments so far for ya :)

[sicoyle]

what if someone has set agent-pubsub and we're picking it up, but they set a diff broadcast_topic? Same for the state components... then, we would be overriding their value.

[CasperGN]

Uf, this is a good point. Let me try to handle this scenario better!

[CasperGN]

Actually, shouldn't that be covered by the conditional:

if (
    "pubsub" in component.type
    and component.name == "agent-pubsub"
    and pubsub is None
):
  ...

If they've added:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: agent-pubsub
spec:
  type: pubsub.redis
  version: v1
  metadata:
    - name: redisHost
      value: localhost:6379

But they have not added it in the agent instantiation then this does exactly what we want it to, no?
"pubsub" in component.type -> We found the component
and component.name == "agent-pubsub" -> It has the right default naming
and pubsub is None -> And they didn't pass any during instantiation

Then the agent would pick it up as the default pubsub

[CasperGN]

@sicoyle before I get too far it would be good to align on the assumptions I take on naming:

Looks great so far!

Instead of an env var equivalent what are your thoughts on if we add an otelConfig dataclass instead as an optional secondary setup to reduce the amt of env vars we support.

@sicoyle I think this is a better approach. We'd still have to support the "usual suspects" (i.e., endpoint & token) but it would substantially lower the amount!

[sicoyle]

few comments so far and will complete my review in my morning. Thank you!!

[sicoyle]

one final comment and then g2g - thank you!

[sicoyle]

LGTM, pls fix the linter issue (flake8 I believe) and then this is g2g 🚀