You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The latter we can skip if we only want to support http, which I'm ok with.
💡 Why is this needed? What if we don't build it?
Right now, we can select otel via TELEMETRY_SINKS=otel and control its service name via OTEL_SERVICE_NAME. However, you can't change the OTLP endpoint used without writing your own configuration file, as it is hard-coded to not read a variable.
This implies that first timers will have to edit configuration when using the easiest way to start (docker) because in a container localhost isn't going to the host's localhost.
By supporting ENV defaults, they can change config like this:
A workaround is to use --add-host=localhost:host-gateway which can help folks use ollama and otel when both are running on the host docker process like so:
🚀 Describe the new functionality needed
Let's support the following two variables for the OTLP endpoint when generating configuration, instead of generating a constant.
The latter we can skip if we only want to support http, which I'm ok with.
💡 Why is this needed? What if we don't build it?
Right now, we can select otel via
TELEMETRY_SINKS=otel
and control its service name viaOTEL_SERVICE_NAME
. However, you can't change the OTLP endpoint used without writing your own configuration file, as it is hard-coded to not read a variable.This implies that first timers will have to edit configuration when using the easiest way to start (docker) because in a container localhost isn't going to the host's localhost.
By supporting ENV defaults, they can change config like this:
Other thoughts
A workaround is to use
--add-host=localhost:host-gateway
which can help folks use ollama and otel when both are running on the host docker process like so:The text was updated successfully, but these errors were encountered: