Swap direction of requests for propagating NAT state from Nexus
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- rust
- Ambito
- networking
Direzione di ricerca
Inizia in dpd/src/rpw/mod.rs intorno alla riga 102 e leggi il task che recupera periodicamente lo stato NAT da Nexus e ne garantisce la presenza. Rimuovi il lavoro di recupero e verifica coperto da questa issue, controllando al contempo come viene memorizzata o referenziata la generazione valida più recente dello stato NAT. Il lavoro è completato quando dpd non esegue più questa propagazione dello stato NAT basata su pull; la propagazione da Nexus è coperta da una issue separata di Omicron.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Rust
- Stelle
- 21
- Fork
- 3
- Merge medio
- 8h 29m
- PR unite (30g)
- 2
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di oxidecomputer/dendrite
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
oxidecomputer/dendrite#380 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
oxidecomputer/dendrite#375 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
oxidecomputer/dendrite#369 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
oxidecomputer/dendrite#368 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
oxidecomputer/dendrite#359 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di oxidecomputer/dendrite
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
vercel-labs/agent-browser#2017 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
tursodatabase/turso#9405 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
PolyMeilex/Neothesia#447 ·
I maintainer di solito rispondono entro 1 giorno
-
backend::vllm diffusion multimodal
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
trezor/trezor-firmware#7985 ·
I maintainer di solito rispondono entro 2 giorni