Skip to content

BaseHarbor v0.4.7

Choose a tag to compare

View all tags
@github-actions github-actions released this 19 Sep 12:23
· 500 commits to main since this release
v0.4.7
e44e335
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

BaseHarbor v0.4.7

BaseHarbor v0.4.7 adds a provider-neutral OpenTelemetry Protocol (OTLP) transport foundation before the individual metrics, logs and traces platforms planned for the next releases.

Why this matters

Applications should be able to emit telemetry without depending on which observability products an environment uses.

v0.4.7 makes that boundary explicit:

application instrumentation
        |
        | telemetry.otlp/v1
        v
OTLP transport/binding
        |
        +-- shared OpenTelemetry Collector today
        +-- external OTLP destination
        +-- other conforming providers later

OpenTelemetry is the ecosystem and instrumentation model. OTLP is the portable protocol. The OpenTelemetry Collector is one provider implementation, not part of application identity.

Added

  • Versioned telemetry.otlp/v1 Capability Specification.
  • Manifest v1 OTLP signal declarations for traces, metrics and logs.
  • OTLP HTTP/protobuf export as the initial v1 transport.
  • OpenTelemetry Collector 0.161.0 as a lazy shared Compose reference provider.
  • External OTLP destination support without BaseHarbor taking lifecycle ownership.
  • Standard OpenTelemetry workload bindings:
    • OTEL_EXPORTER_OTLP_ENDPOINT
    • OTEL_EXPORTER_OTLP_PROTOCOL
    • OTEL_SERVICE_NAME
    • OTEL_RESOURCE_ATTRIBUTES
  • Common application/environment/workload/resource/provider identity.
  • Secret-safe provider lifecycle instrumentation hooks for preflight/apply/bind/verify.
  • Real OTLP export verification using a protobuf trace accepted by the selected endpoint.
  • Capability, manifest, binding, negative and real Collector acceptance coverage.

Changed

OTLP now follows the same shared BaseHarbor lifecycle as other provider-backed capabilities:

resolve
  -> preflight
  -> provision
  -> bind
  -> verify

The managed Collector is created only when an application explicitly requests OTLP transport. Multiple applications may reuse that shared provider while their logical telemetry resources remain application-owned.

Repository workloads using the managed Collector attach to a dedicated BaseHarbor telemetry network. External OTLP destinations do not create or own a BaseHarbor Collector.

Application contract

An instrumented application can declare the signals it exports without naming an observability product:

workload:
  compose: compose.yaml
  services:
    - api
    - worker

telemetry:
  otlp:
    signals:
      - traces
      - metrics

BaseHarbor injects the resolved endpoint and standard OpenTelemetry resource identity into the selected workloads.

External OTLP destinations

A deployment can bind an existing endpoint without changing portable application intent:

export BASEHARBOR_OTLP_ENDPOINT=https://otel.example.com

Optional authorization headers use BASEHARBOR_OTLP_HEADERS. These are deployment/runtime inputs and are never written into the portable application manifest.

Verification

Readiness does not mean that a Collector container exists.

BaseHarbor sends a real OTLP HTTP/protobuf trace to the resolved endpoint and requires the endpoint to accept it. This proves the transport/binding path that later Prometheus, Loki and Tempo integrations will build on.

Security

  • OTLP credential/header material is not part of baseharbor.yaml.
  • Provider-registry and portable capability metadata contain no plaintext telemetry credentials.
  • External provider lifecycle ownership remains external.
  • Invalid or missing OTLP binding semantics fail before provider mutation.
  • Global destroy removes only the BaseHarbor-owned shared Collector.

No implicit observability stack

Requesting telemetry.otlp/v1 does not provision:

  • Prometheus;
  • Loki;
  • Tempo or Jaeger;
  • Grafana;
  • dashboards or alerting.

Those remain separate platform/provider concerns and are intentionally handled by later capability releases.

Deprecated

Nothing.

Removed

Nothing.

Compatibility & upgrade notes

  • Manifest version remains 1.
  • Existing manifests require no migration.
  • OTLP is additive and opt-in.
  • Existing PostgreSQL, Valkey, OpenBao, secure bindings, managed exposure and S3 behavior remains compatible.
  • Compose remains the complete current runtime implementation.
  • Applications continue using standard ecosystem protocols and configuration; no BaseHarbor SDK is required.

Intentionally deferred

  • OTLP/gRPC application binding.
  • Receive-mode/application-hosted OTLP endpoints.
  • Prometheus metrics platform integration.
  • Loki log platform integration.
  • Tempo/Jaeger trace platform integration.
  • Grafana dashboards.
  • Advanced sampling/routing policy.
  • OpAMP/control-plane management.
  • Kubernetes/OpenShift collector deployment.
Assets 5
Loading