-
Notifications
You must be signed in to change notification settings - Fork 31
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
NETOBSERV-1298: include duplicate list in the exported record #217
NETOBSERV-1298: include duplicate list in the exported record #217
Conversation
@msherif1234: This pull request references NETOBSERV-1298 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.15.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #217 +/- ##
==========================================
+ Coverage 33.38% 33.62% +0.24%
==========================================
Files 39 39
Lines 3463 3494 +31
==========================================
+ Hits 1156 1175 +19
- Misses 2241 2251 +10
- Partials 66 68 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @msherif1234 , sounds good to me on the deduper side!
Then the protobuf will have to be updated accordingly
40e4dbd
to
0ea64c8
Compare
0ea64c8
to
338019f
Compare
New image: It will expire after two weeks. To deploy this build, run from the operator repo, assuming the operator is running: USER=netobserv VERSION=8f2f1bc make set-agent-image |
pkg/decode/decode_protobuf_test.go
Outdated
"FlowDirection": 1, | ||
"FlowDirections": []interface{}{1}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to discuss about what's the best model here to have, regarding the loki querying side too
At the moment I don't think our json maps have other value types than strings or numbers, so arrays would be something new here.
In the JIRA description I was suggesting a single field, such as "TraversedInterfaces" for both interface+direction, in the form of ["genev/0", "abc1234/1"], but this isn't perhaps a better solution and is still an array.
Another option could be coma-separated strings instead of arrays, which perhaps would be easier to manipulate in queries with regexp. And also regarding the column displays.
@jpinsonneau any thoughts / preference here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, to avoid ambiguity and redundancy, I think we could remove FlowDirection & Interface (singular) when the plural form is defined? (and vice-versa)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As soon as we will not need the deduplication mechanism on loki side anymore, we can get rid of FlowDirection
label and Interface
field indeed.
What would be the issue with JSON arrays for each of these then ?
If the JSON value is:
{
"FlowDirections": [0,1],
"Interfaces": ["eth0","br-ex"],
...
}
Regexes could be the following:
"Interfaces": \[.*"br-ex".*\]
to match only br-ex
interface.
"FlowDirections": \[.*0.*\]
to match only ingress.
I don't think we need to cover exact match here since there is no overlap between Interfaces names or FlowDirection numbers 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what the problem could be with arrays, I'm asking because I guess new implementation is needed with the configurable fields both for filtering and for column display, whereas I guess we already have this in place for strings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes there is a bit more to manage on query side but that's fine to me.
Internally we already bind arrays to column value function so I'm confident on the web side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok ... anyway we can still change that later if we find this isn't ideal on consuming side
/lgtm |
Signed-off-by: Mohamed Mahmoud <mmahmoud@redhat.com>
338019f
to
0f53015
Compare
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: msherif1234 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Description
create duplicate list which contains interface name and direction pairs so we can
avoid sending duplicate flows
Dependencies
n/a
Checklist
If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.