feat: add tracing interface lib#588
Conversation
dwilding
force-pushed
the
add-tracing-lib
branch
from
4e59efd to
707dc17
Compare
dwilding
force-pushed
the
add-tracing-lib
branch
from
707dc17 to
e98ca0c
Compare
| """Raised when one wrongly assumes that there can only be one relation on an endpoint.""" | ||
|
|
||
|
|
||
| if int(pydantic.version.VERSION.split(".")[0]) < 2: |
There was a problem hiding this comment.
We now depend on pydantic>=2 (see pyproject.toml). So this is dead code. There's an identical if statement further down the file. Shall we remove the code?
|
|
||
| Usage:: | ||
|
|
||
| >>> from lib.charms.tempo_coordinator_k8s.v0.charm_tracing import trace_charm |
There was a problem hiding this comment.
lib.charms.tempo_coordinator_k8s.v0.charm_tracing is a separate lib. How should we adjust this usage example?
In #439, Dima thought that the whole charm_tracing_config function ought to be deprecated.
| @@ -0,0 +1,247 @@ | |||
| # Copyright 2026 Canonical Ltd. | |||
There was a problem hiding this comment.
I've only migrated the requirer tests. The Charmhub-hosted lib also has provider, legacy, and ingressed tests, which depend on TempoCoordinatorCharm. How should we handle those?
In #439, Dima migrated the provider tests by writing a minimal MyCharm(ops.CharmBase) wrapper for TracingEndpointProvider, to replace the TempoCoordinatorCharm dependency.
| AmbiguousRelationUsageError, | ||
| BrokenEvent, | ||
| DataAccessPermissionError, | ||
| DatabagModel, |
There was a problem hiding this comment.
Do we expect people to subclass this? Should it even be exported?
| description: Deprecated in favor of ``charmlibs.interfaces.tracing``. | ||
| tags: | ||
| - observability | ||
| - name: charms.tempo_coordinator_k8s.tracing |
There was a problem hiding this comment.
Should we also update the lib field in interfaces/tracing/interface/v2/interface.yaml? Or wait until this PR has merged?
1 participant
Resolves #581 and replaces #439.
This PR migrates
charms.tempo_coordinator_k8s.v0.tracingto become thetracinginterface lib in Charmlibs.This is a bug-for-bug migration, following How to migrate to the charmlibs monorepo. The package version is set to 1.0.0. I had to make formatting and type-checking changes to comply with Charmlibs requirements.
The first 11 commits correspond to the migration plan in #581. I strongly recommend reviewing the commits in sequence, cross-checking with that plan.
Preview of the new reference docs