RFC: allow the creation of stopped Spans that can be started later manually.

[t-8ch]

This allows the span to be injected into a carrier before starting it.

The usecase is a buildsystem where the build environment is defined before the build is executed. (Background info: https://groups.google.com/forum/#!topic/jenkinsci-dev/VBYvIv3S_r4)

[objectiser]

Why not create a span representing the "build environment is defined" and inject its context for use when the build is executed, and have another span created around the build execution defining a "follows from" reference back to the first span?

[t-8ch]

@objectiser This is certainly possible, thanks for the hint.

To be honest though I think it would be much clearer if the trace would not contain this step. The build definitions are written in groovy and it would be great if the traces match the source code for easier analysis.

[carlosalberto]

Hey @t-8ch

I think having Spans that can be created and started later is something that, even if evidence shows they are needed, would take some time to adopt and implement.

And as @objectiser mentioned, Tracer.inject() exists precisely for this case (with the proper follows_from reference).

Thoughts on this? @yurishkuro @tedsuo

[yurishkuro]

I agree. I don't see anything special in this use case that cannot be done with the existing API. A pipeline of work units is naturally represented with a sequence of follows-from spans.

[t-8ch]

Unfortunately I do not control the execution inside the work units. Only of the scheduler. This is not an urgent issue anymore, as a workaround in the setup logic of the scheduler has been implemented. In general I still think functionality would be usable and hope it will end up on some wishlist for future development.

[yogeshVU]

In another use-case, I would like to start a span and stop a span and restart the span again without creating a new span id. The use-case is a set of tasks that. run in parallel and finish executing at a given step than pauses, and restarts executing operation again in the next step.

More info on the computation: https://en.wikipedia.org/wiki/Bulk_synchronous_parallel

Currently the way it shows in the jaeger ui is

However, it would be nice to just see the two spans which restart after it has finished executing in the previous run.