mirror of
https://github.com/xcat2/xcat-core.git
synced 2026-09-05 04:27:55 +00:00
Daniel Hilst
6a9983abef
The pacing that keeps the install monitor alive is written inline in xcatd, and xcatd cannot be run in a unit test: it needs the database, SSL, the plugin tree and /var/run/xcat before it will start at all. So the test reached for the only thing left and matched regular expressions against the script's source -- that a respawn branch exists, that it mentions an interval, that it names a cap. Every one of those assertions passes against pacing that is subtly wrong, and none of them would notice the retry budget running out and never being refilled, which is the actual defect under review. Grepping the implementation also pins its shape, so the code cannot be rearranged without editing the test that is supposed to be guarding it. State the pacing instead as an interface a test can execute: xCAT::RespawnUtils, pure functions that take a state and a time and return the next state, with no clock, no globals and no I/O of their own. Passing the time in is what lets the schedule be checked over a virtual clock rather than in real seconds. Drive it for the delay backing off to a ceiling and holding there, for the never-give-up property (three hours into a continuous failure the daemon is still forking monitors), for the reset (a monitor that stayed up long enough to serve clears the backoff when it later dies), for the guards on a policy that could not back off, and for purity itself. Then drive it for real against a genuinely held TCP port: fail several times, release the port, and require that a respawned monitor binds it and stays up without the daemon being restarted. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>