search

canonical / charm-relation-interfaces

https://canonical.github.io/charm-relation-interfaces/
Apache License 2.0
16 stars 48 forks source link

Add Tracing v2 schema and spec #136

Closed PietroPasotti closed 8 months ago

PietroPasotti commented 9 months ago

This PR adds a tracing v1 interface specification, as implemented in the tempo.v2.tracing charm library.

Reference implementation at: https://github.com/canonical/tempo-k8s-operator/

PietroPasotti commented 8 months ago

tandem PR: https://github.com/canonical/tempo-k8s-operator/pull/71 as soon as that closes, we can un-WIP this one, remove the tempo branches from charms.yaml and proceed.

gruyaume commented 8 months ago

tandem PR: canonical/tempo-k8s-operator#71 as soon as that closes, we can un-WIP this one, remove the tempo branches from charms.yaml and proceed.

This was merged, can we rebase? It is hard to review as is

gruyaume commented 8 months ago

tandem PR: canonical/tempo-k8s-operator#71 as soon as that closes, we can un-WIP this one, remove the tempo branches from charms.yaml and proceed.

This was merged, can we rebase? It is hard to review as is

@PietroPasotti This PR still seem to contain 70+ file changes, can we only have the tracing content here?

PietroPasotti commented 8 months ago

changes, can we only have the tracing

The large diff is not due to a missing rebase, but to the fact that I bumped pydantic to v2 and had to make a number of adjustments to the models due to model now being a protected field. I needed to bump to v2 because tempo uses v2 and it would have been impossible to test otherwise.

You can ignore the json models changes as they're derived. The changes in all schema.py files that are not in tracing are usually a single line changing that model field I mentioned above. The exception is cos-agent where the grafana dashboard field needed to be refactored to use pydantic v2's custom data fields.