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

chore(apple): Remove connlib_client_apple log filters because they have no effect #4182

Merged
merged 1 commit into from
Mar 18, 2024

Conversation

jamilbk
Copy link
Member

@jamilbk jamilbk commented Mar 17, 2024

Discovered that tracing doesn't respect the connlib_client_apple log filter, which makes it a bit confusing when logging debug in the Apple FFI module.

Removing to prevent further casualties.

Extracted out of #4133

Copy link

vercel bot commented Mar 17, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment
Name Status Preview Updated (UTC)
firezone ⬜️ Ignored (Inspect) Mar 17, 2024 2:02pm

@jamilbk jamilbk requested a review from conectado March 17, 2024 14:02
Copy link

Terraform Cloud Plan Output

Plan: 9 to add, 8 to change, 9 to destroy.

Terraform Cloud Plan

@jamilbk jamilbk changed the title chore(apple): connlib_client_apple log filters have no effect chore(apple): Remove connlib_client_apple log filters because they have no effect Mar 17, 2024
Copy link

Performance Test Results

TCP

Test Name Received/s Sent/s Retransmits
direct-tcp-client2server 230.4 MiB (-2%) 233.0 MiB (-1%) 519 (+92%)
direct-tcp-server2client 234.1 MiB (+1%) 235.5 MiB (+1%) 415 (+155%)
relayed-tcp-client2server 151.3 MiB (+2%) 151.9 MiB (+2%) 216 (+33%)
relayed-tcp-server2client 152.6 MiB (-2%) 153.0 MiB (-2%) 161 (+3%)

UDP

Test Name Total/s Jitter Lost
direct-udp-client2server 50.0 MiB (+0%) 0.29ms (+19%) 0.00% (NaN%)
direct-udp-server2client 50.0 MiB (-0%) 0.01ms (+22%) 0.00% (NaN%)
relayed-udp-client2server 50.0 MiB (-0%) 0.08ms (-50%) 0.00% (NaN%)
relayed-udp-server2client 50.0 MiB (+0%) 0.06ms (+11%) 0.00% (NaN%)

Copy link
Member

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

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

ACK modulo one comment.

We probably just don't have any logging code anymore in that gluecode crate. That is why they don't have any effect.

cc @conectado Should we use explicit log targets everywhere do that the crate name doesn't matter? Like, use connlib everywhere?

@@ -31,15 +31,14 @@ struct AdvancedSettings: Equatable {
authBaseURLString: "https://app.firez.one/",
apiURLString: "wss://api.firez.one/",
connlibLogFilterString:
"connlib_client_apple=debug,firezone_tunnel=trace,phoenix_channel=debug,connlib_shared=debug,connlib_client_shared=debug,info"
"firezone_tunnel=trace,phoenix_channel=debug,connlib_shared=debug,connlib_client_shared=debug,str0m=info,debug"
Copy link
Member

Choose a reason for hiding this comment

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

If you are setting an overall debug level, you could remove the others. I've found that too noise though because of the TLS stuff with the websocket.

I usually use overall info and narrow them down to debug / trace for others.

Copy link
Member Author

Choose a reason for hiding this comment

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

👍

Copy link
Member Author

@jamilbk jamilbk Mar 18, 2024

Choose a reason for hiding this comment

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

So the issue is that only the global filter applies to this glue module. Should we start at debug for dev builds and tune out the noisy ones with info on an adhoc basis?

That might be better than logging info globally in order to see things during development, because those might end up accidentally making their way to release.

Copy link
Member Author

Choose a reason for hiding this comment

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

Refs #3618

@jamilbk
Copy link
Member Author

jamilbk commented Mar 18, 2024

We probably just don't have any logging code anymore in that gluecode crate. That is why they don't have any effect.

The issue is that I added some in the other PR and it wasn't showing up which caused a few minutes of confusion.

The global info was taking effect however.

Maybe it's the crate type?

@thomaseizinger
Copy link
Member

We probably just don't have any logging code anymore in that gluecode crate. That is why they don't have any effect.

The issue is that I added some in the other PR and it wasn't showing up which caused a few minutes of confusion.

That is odd!

@jamilbk jamilbk added this pull request to the merge queue Mar 18, 2024
Merged via the queue into main with commit f5db34b Mar 18, 2024
137 checks passed
@jamilbk jamilbk deleted the fix/log-filter-apple branch March 18, 2024 19:34
github-merge-queue bot pushed a commit that referenced this pull request Mar 27, 2024
Tried to organize this PR into commits so that it's a bit easier to
review.

1. Involves simplifying the logic in Adapter.swift so that us mortals
can maintain it confidently:
- The `.stoppingTunnel`, `.stoppedTunnelTemporarily`, and
`.stoppingTunnelTemporarily` states have been removed.
- I also removed the `self.` prefix from local vars when it's not
necessary to use it, to be more consistent.
- `onTunnelReady` and `getSystemDefaultResolvers` has been removed, and
`onUpdateRoutes` wired up, along with cleanup necessary to support that.
2. Involves adding the `reconnect` and `set_dns` stubs in the FFI and
fixing the log filter so that we can log them (see #4182 )
3. Involves getting the path update handler working well on macOS using
`SystemConfiguration` to read DNS servers.
4. Involves getting the path update handler working well on iOS by
employing careful trickery to prevent path update cycles by detecting if
`path.gateways` has changed, and avoid setting new DNS if it hasn't.

Refs #4028 
Fixes #4297
Fixes #3565 
Fixes #3429 
Fixes #4175 
Fixes #4176 
Fixes #4309

---------

Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
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.

None yet

2 participants