server: consider delegating migration payload logging to individual components

[gjcolombo]

The migration destination runner logs the entire serialized device state payload it got from the source:

propolis/bin/propolis-server/src/lib/migrate/destination.rs

Lines 483 to 495 in 220a6f3

	let devices: Vec<Device> = match self.read_msg().await? {
	codec::Message::Serialized(encoded) => {
	ron::de::from_reader(encoded.as_bytes())
	.map_err(codec::ProtocolError::from)?
	}
	msg => {
	error!(self.log(), "device_state: unexpected message: {msg:?}");
	return Err(MigrateError::UnexpectedMessage);
	}
	};
	self.read_ok().await?;
	info!(self.log(), "Devices: {devices:#?}");

Depending on exactly what devices are attached and how they're configured, this message may include tens of kilobytes of serialized state, e.g. repeated messages about MSI-X interrupts that are allocated to a particular device but aren't currently in use.

It would be nice to have the migration logic log only top-level information about the component payloads it received--the component name, the kinds/versions of the payloads, and maybe the lengths of those payloads--and delegate the logging of the actual payloads to the components themselves. Then the components can deserialize the data and decide whether and how they'd like to log it.

Note that not all components have ready access to a slog::Logger when they're importing device state, so we'll need to do some plumbing to make sure they have access to one (either by adding a Logger to the relevant component structures or updating the MigrateSingle/MigrateMulti traits to supply one).

[pfmooney]

Note that not all components have ready access to a slog::Logger when they're importing device state, so we'll need to do some plumbing to make sure they have access to one (either by adding a Logger to the relevant component structures or updating the MigrateSingle/MigrateMulti traits to supply one).

The reason I've dragged MigrateCtx around in those traits is for exactly that sort of situation.

[gjcolombo]

The reason I've dragged MigrateCtx around in those traits is for exactly that sort of situation.

Oh yeah, good call--I've looked at that type half a dozen times this week and didn't put two and two together on using it for this. That'll work.