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
hubble: Use netip.Addr instead of net.IP in getter functions #23143
Conversation
7893839
to
97ea578
Compare
/test |
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.
Awesome, thanks a lot for fixing this!
sourceIP := net.ParseIP(ip.Source) | ||
destinationIP := net.ParseIP(ip.Destination) | ||
sourceIP, _ := netip.ParseAddr(ip.Source) | ||
destinationIP, _ := netip.ParseAddr(ip.Destination) |
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.
Last time I was looking at this, I was considering just rejecting flows with invalid IPs (i.e. return an error here, if ParseAddr
fails). #22949 indicates that flows with invalid addresses can occur, but it's not yet clear why.
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 agree and think we should check the , ok
value here and return an error.
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.
@gandro @tklauser You mean only here or in all decoders? I did that in all decoders, but then looked at failing tests and reverted the change.
Currently L7 parsers don't require log records to include SourceEndpoint
or DestinationEndpoint
at all. Are there possible cases when they'd be entirely empty?
For L3/4 parser it's also a behaviour change - at the moment it doesn't error if it receives e.g. an Ethernet packet, without IP layer. I don't know how intentional it is, do you think the parser should return an error in such case? If so, I'd leave this change for a separate PR.
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.
Ah, good point regarding L3/L4. I think we can observe packets that are Ethernet-only (e.g. ARP) so we probably should not reject flows that do not have any IP address.
For L7, we don't know. Issue #22949 seems to indicate that those flows seem to be able to occur in practice, but it's not yet clear what kind of flows those are.
So I guess we probably should keep the existing behavior (and ignore ok
) for now.
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.
Agree, let's keep the existing behavior (i.e. ignore , ok
) for now and follow up in a separate PR if needed.
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.
Reading this, it seems like we should explicitly add a comment to why we're ignoring , ok
, since multiple people were confused about it.
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, I added some comments
sourceIP := net.ParseIP(ip.Source) | ||
destinationIP := net.ParseIP(ip.Destination) | ||
sourceIP, _ := netip.ParseAddr(ip.Source) | ||
destinationIP, _ := netip.ParseAddr(ip.Destination) |
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 agree and think we should check the , ok
value here and return an error.
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.
Is there a motivation for this change, I can't quite tell from the PR description or commit messages? Might be useful to provide such details in the commit message.
97ea578
to
ea01003
Compare
/test |
Need to update tests, converting to draft. |
Cilium is slowly converting it's codebase to use While there are still some #21445 has a bit more on the rationale |
ea01003
to
77c03a4
Compare
/test Job 'Cilium-PR-K8s-1.16-kernel-4.9' failed: Click to show.Test Name
Failure Output
If it is a flake and a GitHub issue doesn't already exist to track it, comment |
/test-1.16-4.9 |
The CI failure in ingress conformance test:
doesn't seem to be related. Can someone rerun it maybe? |
@chancez ping. |
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.
Changes LGTM. I think since a few reviewers had questions about why we're ignoring errors, we should add some comments in the areas, so future readers will know why we've chosen to ignore them.
77c03a4
to
f27bc13
Compare
/test |
f27bc13
to
7395a75
Compare
related to #24246 |
@lambdanis ping? |
It's preparing to migrate Hubble getters (calling LookupIP) from net.IP to netip.Addr. Signed-off-by: Anna Kapuscinska <anna@isovalent.com>
Only renaming a variable, to avoid confusion with netip.Addr. It's preparing to migrate from net.IP to netip.Addr. Signed-off-by: Anna Kapuscinska <anna@isovalent.com>
Various parts of Cilium now use netip.Addr instead of net.IP or custom IP types internally, and other parts will likely be migrated soon. This patch updates Hubble getters to take netip.Addr as an argument instead of net.IP. That will reduce type conversions needed in Hubble. All getters handle invalid addresses. Signed-off-by: Anna Kapuscinska <anna@isovalent.com>
7395a75
to
e56cfc2
Compare
/test |
Hubble getters now take
netip.Addr
as an argument instead ofnet.IP
. All of them handle invalid addresses, and Hubble parsers just pass addresses without checking if they're valid.I also migrated
endpointmanager.LookupIP
to takenetip.Addr
, as it's called byGetEndpointInfo
getter.All conversions
net.IP
->netip.Addr
are handled bypkg/ip
, with a hidden unmapping of IPv6-mapped IPv4 addresses. Conversions happen in Hubble parsers, DNS proxy (it usesLookupSecIDByIP
getter), and whereverendpointmanager.LookupIP
is called.