bfd: actually insert peers into persistent db - #884
Conversation
BFD peers were not being inserted into the sled db, which means they weren't recoverable on daemon restart/crash. This moves all of the BFD API handlers' core logic into methods of BfdContext, and makes BfdContext.daemon private. With BfdContext being the sole owner of its inner state, all locking invariants can be upheld without requiring any participation from its callers. API operations now lock the daemon slightly earlier, ensuring updates to both the DB and the runtime state happen during the critical section of the mutex. This prevents concurrent API Add/Del requests from partially trampling over each other by enforcing serialization. Peer add requests now implement a rollback function upon runtime errors. e.g. 1) Add peer to DB (success) 2) Add peer to daemon (failure) 3) Rollback DB entry Rollback failures return a 500 error. before: ``` treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 8e0f (empty) (no description) › ./target/debug/mgadm bfd add-peer 100.64.0.0 0.0.0.0 1000 3 single-hop treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 8e0f (empty) (no description) › ./target/debug/mgadm bfd get-peers Peer Listen Required Rx Detection Threshold Mode Status 100.64.0.0 0.0.0.0 1000 3 SingleHop Down treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 8e0f (empty) (no description) › pkill mgd pkill: signalling pid 33096: Operation not permitted treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 8e0f (empty) (no description) ✕ › sudo !! treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 8e0f (empty) (no description) ✕ › sudo pkill mgd treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 8e0f (empty) (no description) › pkill mgd pkill: signalling pid 35931: Operation not permitted treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 8e0f (empty) (no description) ✕ › ./target/debug/mgadm bfd get-peers Peer Listen Required Rx Detection Threshold Mode Status treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 8e0f (empty) (no description) › ``` after: ``` treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 1651 bfd: actually insert peers into persistent db ±1 +15 -9 › ./target/debug/mgadm bfd get-peers Peer Listen Required Rx Detection Threshold Mode Status treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 1651 bfd: actually insert peers into persistent db ±1 +15 -9 › ./target/debug/mgadm bfd add-peer 100.64.0.0 0.0.0.0 1000 3 single-hop treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 1651 bfd: actually insert peers into persistent db ±1 +15 -9 › pgrep mgd 42931 treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 1651 bfd: actually insert peers into persistent db ±1 +15 -9 › sudo pkill mgd treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 1651 bfd: actually insert peers into persistent db ±1 +15 -9 › pgrep mgd 43407 treyaspelund@Tallon-IV …/oxidecomputer/maghemite/bfd-db xsml 1651 bfd: actually insert peers into persistent db ±1 +15 -9 › ./target/debug/mgadm bfd get-peers Peer Listen Required Rx Detection Threshold Mode Status 100.64.0.0 0.0.0.0 1000 3 SingleHop Down ``` Signed-off-by: Trey Aspelund <trey@oxidecomputer.com>
Signed-off-by: Trey Aspelund <trey@oxidecomputer.com>
rcgoodfellow
left a comment
rcgoodfellow
left a comment
There was a problem hiding this comment.
Thanks @taspelund. Comments follow, but first a higher level thought.
Now that BFD is being managed by a reconciler in Omicron, and early networking is also a reconciler, do we even need a persistence layer for BFD at all? Or even for mgd as a whole at all?
| }) | ||
| /// Restore persisted BFD peers to the running daemon. | ||
| /// | ||
| /// This reads the peer configs from the DB itself so callers cannot start |
There was a problem hiding this comment.
I'm not really following this comment. I get why we want to be able to restore peers from the db. But I don't see how ensuring callers cannot start an unpersisted peer directly follows from that. I would think ensuring persistence is a property of the functions that create peers, not the db restoration function.
| db: rdb::Db, | ||
| rq: BfdPeerConfig, | ||
| ) -> Result<(), HttpError> { | ||
| let mut daemon = lock!(self.daemon); |
There was a problem hiding this comment.
The PR description says this lock is moved up to have the db write and the act of adding the peer to the daemon be in the same critical region. Should we just move the db update into daemon.add_peer so that would be naturally enforced since the daemon needs to be locked to make that call? When I look at this code without the PR description context, my immediate thought is that the daemon lock is being held too long and that line 111 should be lock!(self.daemon).add_peer(... instead of the lock up top. It's easy to see that optimization being made later on and unwinding the intent here.
The db could call could be transformed into more of an ensure than an add within daemon.add_peer to make the db part idempotent.
| peer: IpAddr, | ||
| ) -> Result<(), HttpError> { | ||
| let handle = { | ||
| let mut daemon = lock!(self.daemon); |
There was a problem hiding this comment.
Same comment as above on the eager lock here. Consider moving the db operations into daemon.remove_peer instead.
| daemon.remove_peer(peer) | ||
| }; | ||
|
|
||
| if let Some(handle) = handle { |
There was a problem hiding this comment.
What is the drawback of doing this while holding the lock? Potentially waiting forever on the listen task to abort?
| format!("bfd peer {ip_addr} already exists"), | ||
| ) | ||
| } | ||
| bfd::AddPeerError::Bind { .. } |
There was a problem hiding this comment.
A bind error may not always be an internal error, we could have been handed a futile bind address through the API?
| let tree = self.persistent.open_tree(BFD_NEIGHBOR)?; | ||
| let key = cfg.peer.to_string(); | ||
| let value = serde_json::to_string(&cfg)?; | ||
| match tree.contains_key(key.as_str()) { |
There was a problem hiding this comment.
Related to the comment above about moving db operations into Damon::add_peer. If we do that we may want this to be more of an idempotent/ensure type of call rather than returning an error when the entry already exists.
2 participants
BFD peers were not being inserted into the sled db, which means they
weren't recoverable on daemon restart/crash.
This moves all of the BFD API handlers' core logic into methods of
BfdContext, and makes BfdContext.daemon private. With BfdContext being
the sole owner of its inner state, all locking invariants can be upheld
without requiring any participation from its callers.
API operations now lock the daemon slightly earlier, ensuring updates to
both the DB and the runtime state happen during the critical section of
the mutex. This prevents concurrent API Add/Del requests from partially
trampling over each other by enforcing serialization.
Peer add requests now implement a rollback function upon runtime errors.
e.g.
Rollback failures return a 500 error.
before:
after:
Signed-off-by: Trey Aspelund trey@oxidecomputer.com