-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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] Change context inferrer to use functions and enums as hints #36869
[pkg/ottl] Change context inferrer to use functions and enums as hints #36869
Conversation
ya all the context implementations allowed these paths, but the grammar didn't actually allow you to use them in any statements I don't think. I don't think we need to support a path referencing the entire object higher in the otlp payload. I am ok with removing this capability from our context implementations and making statements like |
…r-fixes' into change-context-inferrer-and-minor-fixes
@evan-bradley since everything is internal and can be refactored later if needed im gonna merge now to keep things moving. |
open-telemetry#36869) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This PR is part of open-telemetry#29017, and a spin-off from open-telemetry#36820. It changes the existing context inferrer logic to also take into consideration the functions and enums used on the statements. (open-telemetry#36820 (comment)) New logic: - Find all `path`, function names(`editor`, `converter`), and `enumSymbol` on the statements - Pick the highest priority context (same existing logic) based on the `path.Context` values - If the chosen context does not support all used functions and enums, it goes through it's lower contexts (wide scope contexts that does support the chosen context as a path context) testing them and choosing the first one that supports them. - If no context that can handle the functions and enums is found, the inference fail and an empty value is returned. The parser collection was adapted to support the new context inferrer configuration requirements. **Other important changes:** Currently, it's possible to have paths to contexts root objects, for example: `set(attributes["body"], resource)`. Given `resource` has no dot separators on the path, the grammar extracts it into the `path.Fields` slice, letting the `path.Context` value empty. Why? This grammar behaviour is still necessary to keep backward compatibility with paths without context, otherwise it would start requiring contexts for all paths independently of the parser configuration. Previous PRs didn't take this edge case into consideration, and a few places needed to be changed to address it: - Context inferrer (`getContextCandidate`) - Parser `prependContextToStatementPaths` function. - Reusable OTTL contexts (`contexts/internal`) (not part of this PR, it will be fixed by open-telemetry#36820) When/If we reach the point to deprecate paths _without_ context, all those conditions can be removed, and the grammar changed to require and extract the `path` context properly. <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> #### Link to tracking issue open-telemetry#29017 <!--Describe what testing was performed and which tests were added.--> #### Testing Unit tests <!--Describe the documentation added.--> #### Documentation No changes <!--Please delete paragraphs that you did not use before submitting.-->
Description
This PR is part of #29017, and a spin-off from #36820. It changes the existing context inferrer logic to also take into consideration the functions and enums used on the statements. (#36820 (comment))
New logic:
path
, function names(editor
,converter
), andenumSymbol
on the statementspath.Context
valuesThe parser collection was adapted to support the new context inferrer configuration requirements.
Other important changes:
Currently, it's possible to have paths to contexts root objects, for example:
set(attributes["body"], resource)
. Givenresource
has no dot separators on the path, the grammar extracts it into thepath.Fields
slice, letting thepath.Context
value empty. Why? This grammar behaviour is still necessary to keep backward compatibility with paths without context, otherwise it would start requiring contexts for all paths independently of the parser configuration.Previous PRs didn't take this edge case into consideration, and a few places needed to be changed to address it:
getContextCandidate
)prependContextToStatementPaths
function.contexts/internal
) (not part of this PR, it will be fixed by [pkg/ottl] Change OTTL contexts to handle paths with context #36820)When/If we reach the point to deprecate paths without context, all those conditions can be removed, and the grammar changed to require and extract the
path
context properly.Link to tracking issue
#29017
Testing
Unit tests
Documentation
No changes