Swap direction of requests for propagating NAT state from Nexus
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- networking
Research direction
Start in dpd/src/rpw/mod.rs around line 102 and read the task that periodically fetches and ensures NAT state from Nexus. Remove the fetching and ensuring work covered by this issue, while checking how the latest valid NAT state generation is stored or referenced. Done means dpd no longer performs this pull-based NAT state propagation; propagation from Nexus is covered by a separate Omicron issue.
Written by the indexing model from the issue text.
Description
Today, dpd pulls NAT state from Nexus here:
That is a small loop which fetches the latest generation of NAT entries from Nexus periodically, and ensures they're all added to the ASIC tables. dpd then stores the latest valid NAT state generation number, which Nexus separately pulls and uses to clean up old NAT state in the database in its own background task.
We'd like to switch the sense of this propagation, pushing the state from Nexus to dpd rather than pulling it. The main reason for this is that it enables easier updates. dpd would no longer be a client of Nexus's internal API, so not "client-side versioned" in the terminology of RFD 567.
This issue covers removing this task for fetching and ensuring the NAT state. There will be a separate issue in Omicron for adding propagation from Nexus to dpd.
- Dominant language
- Rust
- Stars
- 21
- Forks
- 3
- Avg merge
- 8h 29m
- Merged PRs (30d)
- 2
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from oxidecomputer/dendrite
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
oxidecomputer/dendrite#380 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
oxidecomputer/dendrite#375 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
oxidecomputer/dendrite#369 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
oxidecomputer/dendrite#368 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
oxidecomputer/dendrite#359 · 1 comment ·
Maintainers usually reply within 1 day
All issues in oxidecomputer/dendrite
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
vercel-labs/agent-browser#2017 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
tursodatabase/turso#9405 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PolyMeilex/Neothesia#447 ·
Maintainers usually reply within 1 day
-
backend::vllm diffusion multimodal
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
trezor/trezor-firmware#7985 ·
Maintainers usually reply within 2 days