Is this a new feature, an enhancement, or a change to existing functionality?
New Feature
How would you describe the priority of this feature request
Medium
Please provide a clear description of problem this feature solves
MAT uses two flat u64 delay values (host_reboot_delay, dpu_reboot_delay) shared across all lifecycle operations and all platforms. The FSM has no concept of per-operation timing — every timer event uses the same undifferentiated delay. This makes it impossible to simulate the distinct timing windows that real hardware exhibits for power-on, power-off, reboot, and reset, and means any future per-operation or per-platform differentiation requires invasive changes to the FSM.
Feature Description
As a developer testing NVIDIA Infra Controller, I want lifecycle timings to be represented as a typed struct (LifecycleTimings) covering all relevant operations (power-on BMC ready, OS ready, graceful power-off, force power-off, reboot, reset, BMC reset), wired into MachineStateMachine at construction time, so that individual operations can be given distinct durations without modifying FSM logic.
Describe your ideal solution
Replace the two flat config values with the full LifecycleTimings struct. Wire into MachineStateMachine so it gets a resolved_timings: LifecycleTimings at construction. Hardcode a single placeholder profile (all durations = current flat values) to keep everything working. Includes unit tests for struct construction and timer event mapping.
Describe any alternatives you have considered
No response
Additional context
No response
Code of Conduct
Is this a new feature, an enhancement, or a change to existing functionality?
New Feature
How would you describe the priority of this feature request
Medium
Please provide a clear description of problem this feature solves
MAT uses two flat u64 delay values (host_reboot_delay, dpu_reboot_delay) shared across all lifecycle operations and all platforms. The FSM has no concept of per-operation timing — every timer event uses the same undifferentiated delay. This makes it impossible to simulate the distinct timing windows that real hardware exhibits for power-on, power-off, reboot, and reset, and means any future per-operation or per-platform differentiation requires invasive changes to the FSM.
Feature Description
As a developer testing NVIDIA Infra Controller, I want lifecycle timings to be represented as a typed struct (LifecycleTimings) covering all relevant operations (power-on BMC ready, OS ready, graceful power-off, force power-off, reboot, reset, BMC reset), wired into MachineStateMachine at construction time, so that individual operations can be given distinct durations without modifying FSM logic.
Describe your ideal solution
Replace the two flat config values with the full LifecycleTimings struct. Wire into MachineStateMachine so it gets a resolved_timings: LifecycleTimings at construction. Hardcode a single placeholder profile (all durations = current flat values) to keep everything working. Includes unit tests for struct construction and timer event mapping.
Describe any alternatives you have considered
No response
Additional context
No response
Code of Conduct