Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pkg/ottl] Convert Statement to an interface #14869

Merged
merged 8 commits into from
Oct 12, 2022

Conversation

TylerHelmuth
Copy link
Member

Description:
Converts Statement to an interface with an Execute function. Users can now use this execute function to evaluate statements, instead of needing to handle Condition and Function themselves.

Testing:
Ran unit tests

pkg/ottl/parser.go Outdated Show resolved Hide resolved
pkg/ottl/parser.go Outdated Show resolved Hide resolved
processor/routingprocessor/logs.go Outdated Show resolved Hide resolved
Copy link
Member

@kentquirk kentquirk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

pkg/ottl/parser.go Outdated Show resolved Hide resolved
pkg/ottl/parser.go Outdated Show resolved Hide resolved
// Returns true if the function was run, returns false otherwise.
// If the statement contains no condition, the function will run and true will be returned.
// In addition, the functions return value is always returned.
func (s *Statement[K]) Execute(ctx K) (any, bool) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good (later) to change ParseStatements to return array of pointers.

@bogdandrutu bogdandrutu merged commit 064fd31 into open-telemetry:main Oct 12, 2022
@TylerHelmuth TylerHelmuth deleted the ottl-eval-interface branch October 12, 2022 22:30
// Returns true if the function was run, returns false otherwise.
// If the statement contains no condition, the function will run and true will be returned.
// In addition, the functions return value is always returned.
func (s *Statement[K]) Execute(ctx K) (any, bool) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be good to also pass context.Context. Also we should return an error.

Do we have use-cases for "returning if func was executed"?

Do we have use-cases for "func returning a value (any)"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be good to also pass context.Context

Would it be better to pass context.Context to execute or pass it to the parser and give every function access to it if they need it?

Also we should return an error.

Yes can add this in the future.

Do we have use-cases for "returning if func was executed"?

Tangentially. The routing processor makes decisions on if the condition returned true (true condition currently guarantees function execution)

Do we have use-cases for "func returning a value (any)"?

Based on my previous attempt to implement drop() I think the return value will be useful. It may also allow interesting situations with factory functions in the future.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to pass context.Context to execute or pass it to the parser and give every function access to it if they need it?

I am thinking about the context associated with the data not with the component that created the Parser.

our ConsumeTraces(ctx context.Context, td ptrace.Traces) so we should pass this context not the one passed in the component.Start(ctx context.Context, ...) which created the parser.

Should the context be passed to all the funcs - yes

Tangentially. The routing processor makes decisions on if the condition returned true (true condition currently guarantees function execution)

Not sure if then worth calling this API. Maybe we provide on this struct just a "CheckCond(...)" and "ExecFunc(...)" and they manually call if they need such granular control (which for example in transformprocessor is not needed)

Copy link
Member Author

@TylerHelmuth TylerHelmuth Oct 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if then worth calling this API.

They want to call the function though. The routing processor allows using expression to match but also update the telemetry when there is a match

processors:
  routing:
    default_exporters:
    - jaeger
    table:
      - expression: route() where resource.attributes["X-Tenant"] == "acme"
        exporters: [jaeger/acme]
      - expression: delete_key(resource.attributes, "X-Tenant") where IsMatch(resource.attributes["X-Tenant"], ".*corp") == true
        exporters: [jaeger/ecorp]

In that example the routing processor will match a rule and send to jaeger/ecorp and delete the X-Tenant key for that data.

So the they need to be able to call a function and also know if it was called.

shalper2 pushed a commit to shalper2/opentelemetry-collector-contrib that referenced this pull request Dec 6, 2022
* Convert Statement to an interface

* update documentation

* add changelog entry

* Add unit tests

* adjust routing processor if statements

* Reorder return values

* Switch from interface to struct
@plantfansam plantfansam mentioned this pull request Jul 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants