dpd: Want a better API for bulk NAT entry operations
メンテナーはふだん 2 日以内に返信
@nicolaskagami がすでに取り組んでいます。
2026年7月8日 から。
評価
この issue はまだ評価されていません。
説明
As a part of https://github.com/oxidecomputer/omicron/issues/10167, sled-agent running on each scrimlet wants to ensure the NAT entries for all Omicron services are correct on its switch zone's dpd. The information it has is a generation-numbered-guarded declarative set of "entries that should exist".
The existing dpd API makes it easy to ensure each of those entries does exist, but I don't think there's an easy way for sled-agent to remove stale Omicron service NAT entries that shouldn't exist. It doesn't know what entries might have existed in the past; only what should exist now.
I have a prototype branch that makes this work, but it's pretty gnarly: it reads all current NAT entries from dpd across a series of API calls:
- For each IP returned by looping over all pages of
nat_ipv4_addresses_list, fetch all NAT entries associated with that IP vianat_ipv4_list. - For each IP returned by looping over all pages of
nat_ipv6_addresses_list, fetch all NAT entries associated with that IP vianat_ipv6_list.
As a heuristic for "what entries exist that shouldn't", it filters all the returned NAT entries down to just those with a VNI matching the Omicron services VNI. Now it can diff locally and decide whether any entries exist that shouldn't, and delete those.
This issue is similar in spirit to #209. In this specific case we don't necessarily need a generation number on the dpd side for correctness, since there is only one client (the local sled-agent) and it already guards changes via a generation number of its own. But I could imagine wanting a similar kind of "bulk" API if we wanted to invert the Nexus <-> dpd NAT syncing path (which we do at some point - this is #83), and it would be easy for us to pass through the generation number we do have if needed.
I'm not sure exactly what shape this should be. The features I'd like are:
- Some way of identifying an entire set of related NAT entries. I'm using VNI to do this now - maybe that's fine / correct? Or there could be some metadata that described a group of "all Omicron service entries".
- Either:
- A single "ensure" API that takes a generation-guarded, identified-by-group set of NAT entries, and then
dpdinternally removes any stale entries that are in the same group but not in the new request, and adds/updates all entries that are in the new request. (I believe this is similar to the way BGP is configured inmgd- there's a singlebgp_apply()endpoint that takes the config that should exist, then internally does whatever it needs to do to make that happen.) - A bulk "get" API (presumably paginated) that returns all the current entries in a group. This would be more similar to the prototype branch I have, but the filter-down-to-a-group would happen on the
dpdside instead of the client needing to fetch all NAT entries. Given this, the client can do its own diffing and then use the existing add/remove APIs to make updates as needed.
- A single "ensure" API that takes a generation-guarded, identified-by-group set of NAT entries, and then
I think the first of those options is more generally useful - the second is only useful if there's a single client that can't race with others, since it opens an obvious TOCTOU between the "bulk get" and the "local diff then apply changes". But either would be a big improvement for the current project, and I assume (perhaps naively) that the second would be a smaller lift.
- 主要言語
- Rust
- スター
- 22
- フォーク
- 3
- 平均マージ
- 2日 23時間
- マージ済み PR（30日）
- 6
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
oxidecomputer/dendrite のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
oxidecomputer/dendrite#404 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
oxidecomputer/dendrite#402 ·
メンテナーはふだん 2 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
oxidecomputer/dendrite#384 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
oxidecomputer/dendrite#375 ·
メンテナーはふだん 2 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
oxidecomputer/dendrite#369 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
oxidecomputer/dendrite の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
good first issue gpu serve
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
biomejs/biome#12475 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
メンテナーはふだん 1 日以内に返信
-
documentation E-easy good first issue help wanted
難易度 1/5 1〜3時間 初心者へのやさしさ 91/100
メンテナーはふだん 1 日以内に返信