[pmon] Port psud to Rust

[ganglyu]

Why I did it

The pmon daemons move to Rust while they keep reaching the hardware
through each vendor's Python platform API, over the facade that
sonic-platform-common generates (sonic-net/sonic-platform-common#768).
This PR ports psud.

Work item tracking

• Microsoft ADO (number only):

How I did it

• crates/psud is a port of sonic-psud/scripts/psud. It writes the same
  PSU_INFO, the PSU half of FAN_INFO, the PSU tray LEDs and, on a
  modular chassis, the power budget in CHASSIS_INFO as the Python daemon
  and logs the same messages. Where it departs from Python on purpose, a
  comment at that spot says so.
• It builds on crates/pmon-common and adds the binary package
  sonic-psud-rs to the workspace's source package.
• The Python psud is unchanged. A platform picks one of the two in
  pmon_daemon_control.json.

It is based on #915, which adds the Rust
workspace, crates/pmon-common and thermalctld; until #915 merges, this
PR also shows that commit. It does not depend on the other daemons,
which are ported in PRs of their own: syseepromd (#917), pcied (#918),
stormond (#919), chassisd (#920).

How to verify it

Build an image whose pmon runs the Rust daemons and run the sonic-mgmt
platform tests (tests/platform_tests) on it.

Which release branch to backport (provide reason below if selected)

• 202305
• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605
• 202608

Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO):
Failure type:

Tested branch

• master
• 202305
• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605
• 202608
• N/A

Test result

master: the sonic-mgmt platform tests pass with the Rust pmon daemons
running.

Description for the changelog

Add a Rust port of psud.

Link to config_db schema for YANG module changes

N/A

A picture of a cute animal (not mandatory but encouraged)

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[yxieca]

Reviewed this at 934a7c2e. One blocking item; the rest are non-blocking.

Scope note: this is based on #915, so I reviewed only the psud delta — crates/psud/src/*, the crate and workspace manifests, azure-pipelines.yml, debian/*, .gitignore. #915's content I reviewed separately.

Blocking — a transient read at start-up pins psu_num=0 for the life of the daemon.

publish_counts(&platform.get_psus().unwrap_or_default(), chassis_tbl.as_ref());

That's the only production call site, and it runs once before the loop — run() calls cycles.next, one_pass, updater.clear, chassis_tbl.del, and one_pass never republishes the counts. So when get_psus() fails at boot, publish_counts computes count(PowerEntityKind::Psu) over an empty slice, writes ("psu_num", "0"), and nothing ever corrects it.

The daemon already rejects this interpretation one function away. On the same get_psus() failure, one_pass does:

pmon_common::fail_once_warn!(read, "Failed to update PSU data - {e}");
// Not treated as "every PSU vanished": that would blank PSU_INFO
// on a transient i2c failure and red every tray LED.
return;

A failed read is explicitly not "no PSUs" in the loop, but is "zero PSUs" at start-up.

I checked the Python before raising this. psud defaults num_psus_chassis = 0 but guards only except NotImplementedError — a transient error isn't caught there, so it propagates, the daemon dies, supervisor restarts it, and the count gets republished correctly. unwrap_or_default() swallows every error class, so where Python fails loudly and self-corrects, this fails silently and permanently.

The consequence is the one your own doc names: "show platform psustatus iterates PSU 1..n, so a wrong number here hides a PSU that is otherwise being published correctly." And 0 is numeric, so the FRU MIB doesn't even fall back to None — consumers iterate 1..0 and see nothing while PSU_INFO fills in normally.

I'm aware the count API is deliberately absent from the facade — #768 omits all thirteen get_num_* variants with the reasoning that declaring both gives a platform two ways to disagree with itself, so deriving the count from get_psus() is right. But that's what makes this sharper rather than excusing it: in Python the count came from get_num_psus(), which is len(self._psu_list) and cannot fail transiently, while the port collapses it onto the hardware-touching enumeration. The count now inherits that call's failure modes, so a derived count must not be published from a failed read. On Err, leave the key untouched and retry on a later cycle (or exit with a load error) rather than writing a derived zero.

Non-blocking:

1. The same swallow disables the power budget permanently. let is_modular = platform.get_chassis_info(CHASSIS_COLS).map(|c| c.is_modular_chassis).unwrap_or(false); then let budget = is_modular.then(PowerBudget::default); — decided once, moved into the loop, never revisited. One failed read at start-up and a modular chassis silently runs without a budget or a master PSU LED for the rest of the run.

2. An unreachable arm. } else if first_run && !present { log::error!("{name} is not present."); } can't fire: PsuStatus::default() has presence: true, so on the only pass where first_run holds, set_presence(false) always returns presence_changed == true and the earlier branch wins — which already logs the same line.

3. PSU fan rows are frozen between presence transitions. if presence_changed || first_run { publish_psu_fans(...) } means speed, direction and timestamp stay at their first-pass values until a PSU is pulled. That reads against the module doc, which justifies writing these rows at psud's three seconds precisely so show platform psustatus and show platform fan don't disagree for up to a minute. Both existing tests only exercise the first pass and a presence change, so neither would catch a stale speed. If the gate is deliberate, the file's own rule ("Where it departs from Python on purpose, a comment at that spot says so") asks for a note.

4. Teardown leaks the fan rows. Updater::clear deletes the PSU_INFO and PHYSICAL_ENTITY_INFO keys but never the FAN_INFO keys this daemon wrote for PSU/PDB fans, so the rows from (3) outlive the daemon.

5. Two timestamp formatters in one pass, unexplained. refresh_one ends with ("timestamp", fmt::epoch_timestamp()) while publish_psu_fans ends with ("timestamp", fmt::timestamp()). Every other spelling divergence in this file carries a comment, so this reads as an oversight.

6. A doc block is attached to the wrong constant. The paragraph describing the FanInfo columns (and the is_under_speed/Mellanox rationale) sits immediately above const CHASSIS_COLS, so rustdoc renders PSU-fan prose on the chassis constant while FAN_COLS further down has no doc at all.

7. #[derive(Default)] on Updater yields first_run: false, which new() has to patch — an Updater::default() would skip every first-pass LED write. PowerBudget hand-writes Default for exactly this reason, with the comment explaining why.

8. Each cycle re-reads everything to use one field. one_pass does a full get_psus() and a full get_fans(FAN_COLS) for the LED refresh, but update_led_color consumes only row.status_led and fan.status_led. The doc notes Python's equivalent is get_status_led(), and the FAN_COLS projection exists precisely to avoid reads Mellanox logs at ERR.

9. .gitignore adds target/ under a comment saying "Not */target/" — an unanchored pattern matches at any depth; /target/ is the one that matches the comment.

10. azure-pipelines.yml leaks $CARGO_TARGET_DIR when the job fails — set -ex aborts before the trailing rm -rf, under a comment about the agent's disk being nearly full. A trap ... EXIT would honour the intent.

One question: psu_fans() filters on f.kind and f.parent_name, but FAN_COLS requests only DIRECTION, SPEED_PCT and STATUS_LED, and the parity test lists name/direction/speed/LED. Are kind and parent_name always-populated rather than projectable? If they're declinable, every PSU fan row would silently disappear.

---

AI-assisted review, reviewed by Ying Xie (@yxieca).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[ganglyu]

Thanks @yxieca. Addressed in 6e4fac7:

Blocking: the counts are published from the first PSU read that succeeds, and again only if they change. They are never published from a failed read. (For the record, Python's count is len(self._psu_list), which reads no hardware, so it never had this failure mode.)

1. Whether the chassis is modular is asked every pass, as in Python. The budget is built on first need and kept.
2. Removed.
3. Same gate as Python (if presence_changed or self.first_run in update_psu_data). thermalctld refreshes speed and direction every cycle.
4. Matches Python: psud's __del__ never touches FAN_INFO. thermalctld owns those rows; deleting them from psud would blank thermalctld's columns whenever only psud restarts.
5. Both formats are Python's: epoch float for PSU_INFO, %Y%m%d %H:%M:%S for FAN_INFO. Comments added.
   6, 7. Fixed.
6. A pass reads again only after it wrote an LED, and the fan read asks for the LED column only.
7. /target/ (in [pmon] Run thermalctld in Rust over the generated platform API #915).
8. The target dir is under Agent.TempDirectory, which the agent cleans after each job.

Q: kind and parent_name are Parent() fields. They have no column bit and are always populated.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).