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

hubble: Use netip.Addr instead of net.IP in getter functions #23143

Merged
merged 3 commits into from Mar 9, 2023

Conversation

lambdanis
Copy link
Contributor

@lambdanis lambdanis commented Jan 17, 2023

Hubble getters now take netip.Addr as an argument instead of net.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 take netip.Addr, as it's called by GetEndpointInfo getter.

All conversions net.IP -> netip.Addr are handled by pkg/ip, with a hidden unmapping of IPv6-mapped IPv4 addresses. Conversions happen in Hubble parsers, DNS proxy (it uses LookupSecIDByIP getter), and wherever endpointmanager.LookupIP is called.

@maintainer-s-little-helper maintainer-s-little-helper bot added the dont-merge/needs-release-note-label The author needs to describe the release impact of these changes. label Jan 17, 2023
@github-actions github-actions bot added the kind/community-contribution This was a contribution made by a community member. label Jan 17, 2023
@lambdanis lambdanis force-pushed the pr/hubble-netip branch 2 times, most recently from 7893839 to 97ea578 Compare January 18, 2023 11:27
@lambdanis lambdanis marked this pull request as ready for review January 18, 2023 12:16
@lambdanis lambdanis requested review from a team as code owners January 18, 2023 12:16
@lambdanis
Copy link
Contributor Author

cc @gandro @tklauser

@lambdanis
Copy link
Contributor Author

/test

Copy link
Member

@gandro gandro left a 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)
Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

@lambdanis lambdanis Jan 23, 2023

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

@tklauser tklauser added the release-note/misc This PR makes changes that have no direct user impact. label Jan 18, 2023
@maintainer-s-little-helper maintainer-s-little-helper bot removed the dont-merge/needs-release-note-label The author needs to describe the release impact of these changes. label Jan 18, 2023
@tklauser tklauser removed the kind/community-contribution This was a contribution made by a community member. label Jan 18, 2023
daemon/cmd/fqdn.go Outdated Show resolved Hide resolved
sourceIP := net.ParseIP(ip.Source)
destinationIP := net.ParseIP(ip.Destination)
sourceIP, _ := netip.ParseAddr(ip.Source)
destinationIP, _ := netip.ParseAddr(ip.Destination)
Copy link
Member

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.

Copy link
Contributor

@chancez chancez left a 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.

@lambdanis lambdanis requested review from chancez and removed request for jrajahalme and thorn3r January 18, 2023 22:07
@lambdanis
Copy link
Contributor Author

/test

@lambdanis lambdanis marked this pull request as draft January 18, 2023 22:59
@lambdanis
Copy link
Contributor Author

Need to update tests, converting to draft.

@gandro
Copy link
Member

gandro commented Jan 23, 2023

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.

Cilium is slowly converting it's codebase to use netip.Addr instead of net.IP, because it uses less memory and allocations.

While there are still some netip.Addr <-> net.IP conversions left in this PR, ultimately they will likely be removed once other parts of Cilium do the migration too.

#21445 has a bit more on the rationale

@lambdanis lambdanis marked this pull request as ready for review January 23, 2023 13:56
@lambdanis
Copy link
Contributor Author

lambdanis commented Jan 23, 2023

/test

Job 'Cilium-PR-K8s-1.16-kernel-4.9' failed:

Click to show.

Test Name

K8sKafkaPolicyTest Kafka Policy Tests KafkaPolicies

Failure Output

FAIL: Unable to restart unmanaged pods with 'kubectl -n kube-system delete pods coredns-8cfc78c54-jqmzl': Exitcode: 1 

If it is a flake and a GitHub issue doesn't already exist to track it, comment /mlh new-flake Cilium-PR-K8s-1.16-kernel-4.9 so I can create one.

@lambdanis
Copy link
Contributor Author

/test-1.16-4.9

@lambdanis
Copy link
Contributor Author

The CI failure in ingress conformance test:

Error: waiting for service (foo-exact) endpoints available: timed out waiting for the condition

doesn't seem to be related. Can someone rerun it maybe?

@christarazi christarazi added kind/enhancement This would improve or streamline existing functionality. area/daemon Impacts operation of the Cilium daemon. sig/hubble Impacts hubble server or relay labels Feb 2, 2023
@christarazi
Copy link
Member

@chancez ping.

Copy link
Contributor

@chancez chancez left a 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.

@lambdanis
Copy link
Contributor Author

/test

@aanm
Copy link
Member

aanm commented Mar 8, 2023

related to #24246

@aanm
Copy link
Member

aanm commented Mar 8, 2023

@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>
@lambdanis
Copy link
Contributor Author

/test

@maintainer-s-little-helper maintainer-s-little-helper bot added the ready-to-merge This PR has passed all tests and received consensus from code owners to merge. label Mar 9, 2023
@christarazi christarazi merged commit 75c9ce9 into cilium:master Mar 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/daemon Impacts operation of the Cilium daemon. kind/enhancement This would improve or streamline existing functionality. ready-to-merge This PR has passed all tests and received consensus from code owners to merge. release-note/misc This PR makes changes that have no direct user impact. sig/hubble Impacts hubble server or relay
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants