Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
docs(connlib): add more inline docs to connlib's state #5105
docs(connlib): add more inline docs to connlib's state #5105
Changes from 2 commits
9563d7a
4cd35e5
8fcb752
3f0ca62
027be05
f1ee306
39ee471
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 did
cargo doc --no-deps --open -p firezone-tunnel
and this link didn't show up?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 guess because snownet is not in the workspace
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.
You need to build the docs for the entire
rust/
directory. Then the links work.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 that connecting to the Resource or to the Gateway? It's the Gateway that resolves DNS, and the Resource doesn't do anything except accepting incoming connections after we've resolved it, right?
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 think this is for the special case where the configured upstream DNS server is a resource itself.
@conectado Can probably answer this.
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.
These are for any DNS query that hasn't been answered by the gateway yet, we use this to create a response later on.
we don't really connect to a resource ever, but we have the gateway grant access to a resource, at that point it's resolved.
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 I forgot to address this one. Will send another PR once it is merged.
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.
What does this do? Do we redo DNS resolving even while connected to a Resource? Or is this the DNS TTL?
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.
Good question, let me dig into this.
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.
It is the former. I clarified this in a comment.
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.
the only reason we don't use the TTL here is because we don't have it, we would need to use something like hickory on the gateway too to obtain it.
with the DNS refactor we are doing now this will go away anyways and refreshing will look really different with a whole new set of problems 😛
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.
🤔 And the Portal connection via WebSocket / phoenix channel is not part of that pure state machine, right? It's also part of the Tunnel?
So for my goal of exercising the platform-specific I/O code of the Clients, even in Windows where a Portal can't be run, I could make a mock Tunnel implementation that uses the pure state machine but has fake I/O, similar to your prop tests, and then has a simulated portal?
Or is the WebSocket managed even higher, in
ClientTunnel
andGatewayTunnel
wrappers?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 think it should be part of the
Tunnel
. There is no reason why theEventloop
s for gateways and client couldn't be inTunnel
(those manage the portal connection). Doing that is tracked in #3837.But even once that is done, the connection to the portal is a side-effect and thus would likely be contained in
Io
or live at least next to it.ClientState
andGatewayState
are already pure state machines so you can already run them on Windows without a portal or TUN device.Our proptests mock everything. IO, portal, TUN device. Our (linux) integration tests don't mock anything, they use a real portal, real TUN device and real sockets.
I don't think it makes much sense to mock only parts of this. If we want to test sockets and TUN device on Windows, and thus perform real network communication, we already have an abstraction layer that can cross OS boundaries: the network. I'd try to somehow connect to a real portal and real gateway from a Windows-VM. Like, can we run a Linux container in a Windows VM on GitHub actions and connect to that?
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.
Actually, maybe we could. Github docs say the Windows runners have Docker installed.
But I haven't tried it because I don't want to spend all day fighting the CI again. Maybe if it was done in a side project so every run doesn't take 6 CPU-hours 🤔 And then integrated if it succeeds
It's just that, that's one more thing that has to be downloaded, installed, set up, another few gigabytes of junk to update. Testing everything end-to-end is great but I'd also just like to test the Windows to Windows Client integration sometimes.
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.
Yeah that is definitely worthwhile testing. I've found this: actions/runner-images#2216 (comment)
Seems like we need a self-hosted Windows runner for that.
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.
Crud, yeah that was why I didn't try it before. Github doesn't do nested virtualization and Docker / WSL2 needs that to run Linux on Windows.