[BMC] Initialize the admin_status according to Air or Liquid cooled devices

[judyjoseph]

Description

Initialize the admin_status according to Air or Liquid cooled devices

• Additional change in this PR
  Fine tune the power_on_boot_delay for liquid cooled devices -- so that the delay is computed against system uptime (CLOCK_BOOTTIME), so a bmcctld restart mid-boot does not re-arm a fresh timer

Motivation and Context

Update the CHASSIS_MODULE table in CONFIG_DB and STATE_DB on bmcctld startup based on whether it is air cooled or liquid cooled devices

In case of Air cooled devices we startup the Switch-Host immediately, no delay
In case of Liquid cooled devices, we check if there is a power_on_delay configured before powering on the switch-host

Ideally in production systems we will get the chassis_db config viz. admin_status/powr_on_delay/shutdown_timeout from NDM. The default setting is useful in manufacturing test scenarios to bring up the switch-host soon on powering on.

Air cooled 

$ sonic-db-cli CONFIG_DB hgetall "CHASSIS_MODULE|SWITCH-HOST"
{
    'admin_status': 'up',
    'power_on_delay': '0',
    'graceful_shutdown_timeout': '0'
}

$ sonic-db-cli STATE_DB hgetall "CHASSIS_MODULE_TABLE|SWITCH-HOST"
{
    'name': 'SWITCH-HOST',
    'desc': 'Switch Host Module',
    'serial': '<platform-reported>',
    'admin_status': 'up',
    'oper_status': 'ONLINE'
}

Liquid cooled

$ sonic-db-cli CONFIG_DB hgetall "CHASSIS_MODULE|SWITCH-HOST"
{
    'admin_status': 'down',
    'power_on_delay': '300',
    'graceful_shutdown_timeout': '0'
}

$ sonic-db-cli STATE_DB hgetall "CHASSIS_MODULE_TABLE|SWITCH-HOST"
{
    'name': 'SWITCH-HOST',
    'desc': 'Switch Host Module',
    'serial': '<platform-reported>',
    'admin_status': 'down',
    'oper_status': 'OFFLINE'
}

How Has This Been Tested?

Additional Information (Optional)

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[judyjoseph]

@nats-nokia @Pavan-Nokia f.y.i

[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).

[nats-nokia]

@nats-nokia @Pavan-Nokia f.y.i

Thank you Judy. We have tested the changes and default switch-host state is set as admin-up.
LGTM.

[yxieca]

Reviewed by AI agent on behalf of Ying. The change is correct and well-tested — the admin_status default is properly gated (_initial_power_on_sequence early-returns when admin_status != up, so a liquid-cooled box defaulting to down genuinely stays off, and that suppression is unit-tested), the CONFIG_DB seed is clobber-safe (operator overrides preserved), is_liquid_cooled() matches the existing usage, and the CLOCK_BOOTTIME-relative boot delay degrades conservatively. CI is green.

Approving. A couple of non-blocking items worth a follow-up (docs/PR-body consistency):

1. power_on_delay default — docstrings and the PR description say 0, but the code seeds/returns 300.

   • initialize_chassis_module docstring says it seeds default timings (power_on_delay=0, ...), but it seeds DEFAULT_POWER_ON_DELAY_SECS (now 300).
   • get_power_on_delay() docstring still says (default: 0) but returns 300.
   • The PR description's air-cooled example shows 'power_on_delay': '0', while the daemon actually writes '300' for air-cooled too (only admin_status differs by cooling type).
   • It's functionally inert on air-cooled (the sole reader, _initial_power_on_sequence, is only on the liquid-cooled path), so this is documentation/CONFIG_DB-accuracy rather than a behavior bug. Cleanest fix: seed the delay conditionally (air → 0, liquid → 300) so CONFIG_DB matches the documented per-cooling intent and the example — or just correct the two docstrings + the PR-body example.

2. PR housekeeping: the "How Has This Been Tested?" section is empty and there's no linked issue. Could you add the test evidence (especially for the liquid-cooled path — the air-cooled default-up case is already confirmed on hardware in the thread) and associate an issue if one exists?

Neither blocks merge.

[mssonicbld]

Cherry-pick PR to msft-202608: Azure/sonic-platform-daemons.msft#71