refactor(dslx): allow running w/o measurexlite as the backend #1376
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want to use the DSL inside the oohelperd. We don't care about collecting observations in the oohelperd. So, the plan is that of abstracting the ConnPool, renaming it Runtime, and giving it the power to create abstract Traces. The oohelperd will use a MinimalRuntime (sketched out by this commit) that will not collect any observation. Measuring code, instead, will use a MeasurexRuntime that will collect observations. This commit is just the first step. We rename and introduce the MinimalRuntime. No significant functional changes so far.
This diff builds on the previous diff and uses an abstract trace inside of the dslx package. By using an abstract trace, we can choose between using: - a runtime that collects observations, based on measurexlite; and - a minimal runtime that does not collect observations. To make the trace abstract, we need to modify measurexlite's trace such that it can be used as an interface. In turn, this means we need to update the throttling package such that it uses an abstract trace definition. Strictly speaking, we could have avoided introducing this abstraction, but it seems better to also use an abstract trace there, as it allows for improving the decoupling with measurexlite.
Currently, we pass these fields to each DSL function. However, if we want to load the functions from JSON, which is something we have experimented with in the richer input context, we can't do this. These fields should instead belong to the runtime. A subsequent diff will modify the DSL functions to take them from the runtime.
This diff builds upon the previous diff to use the Runtime to get the logger, ID generator, and zero time. By doing this, we make most structures that DSL functions takes as input or emit in output serializable and deserializable.
bassosimone
commented
Oct 20, 2023
bassosimone
changed the title
|
Something seems to have changed in the OONI I will investigate at a later time, since it may just be a transient issue. |
Murphy-OrangeMud
pushed a commit
to Murphy-OrangeMud/probe-cli
that referenced
this pull request
Feb 13, 2024
) Summary of the changes: * rename `ConnPool` (`struct`) to `Runtime` (`interface`) and retain the same functionality; * introduce a "minimal" runtime that does not collect observations along with a measurexlite runtime; * use the "runtime" to carry the logger and other bits of information that it seems more rational to keep into the runtime rather than keeping inside each pipeline stage result (I also did this in the richer-input PoC); * make sure `measurexlite`'s `Trace` can be fully accessed through an interface. Closes ooni/probe#2580
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of the changes:
rename
ConnPool(struct) toRuntime(interface) and retain the same functionality;introduce a "minimal" runtime that does not collect observations along with a measurexlite runtime;
use the "runtime" to carry the logger and other bits of information that it seems more rational to keep into the runtime rather than keeping inside each pipeline stage result (I also did this in the richer-input PoC);
make sure
measurexlite'sTracecan be fully accessed through an interface.Closes ooni/probe#2580