Project

General

Profile

Actions

Feature #54

open
AS

Feature #33: Canofy Control Centre Backend Development

Feature #46: Canofy Control Centre Onboarding Process

# [CANOFY-108] Wait for SSM Agent Registration

Feature #54: # [CANOFY-108] Wait for SSM Agent Registration

Added by Akshath Shettigara about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
07/23/2026
Due date:
% Done:

0%

Estimated time:

Description

[CANOFY-108] Wait for SSM Agent Registration

Type: Story
Epic: New Client Onboarding — Automated AWS + Frappe Provisioning
Stage key: ssm_wait (pipeline stage 8 of 15)
Component: utils/ssm_client.py

User Story

As an operations engineer,
I want onboarding to wait until the new instance's SSM agent is fully
registered and online before attempting any remote commands,
so that the bootstrap stage doesn't fail on a race condition where the
instance is "running" but not yet reachable via SSM.

Description

Poll describe-instance-information for the target instance until
PingStatus == "Online", with a bounded timeout. This is a pure
synchronization stage — no resources created, no state mutated — but is
required because every subsequent stage depends on SSM working.

Configuration / Prerequisites

  • Depends on stage 1 (instance_id) and stage 6 (IAM role with
    AmazonSSMManagedInstanceCore attached — SSM registration cannot succeed
    without it).
  • A maximum wait duration must be configured (e.g. 5 minutes) — this stage
    must not hang the pipeline indefinitely.

Acceptance Criteria

  • Stage blocks (polling on an interval, not a single check) until the
    instance reports Online.
  • Stage fails clearly with a timeout error if the agent never comes
    online within the configured max wait — the error should point at
    likely causes (IAM role, network/security group, agent not installed
    on the AMI) to save debugging time.
  • Polling interval is reasonable (not hammering the API every second,
    not waiting so long between polls that a fast registration is missed
    for minutes).

Test Cases

ID Scenario Steps Expected Result
TC-1 Happy path Run stage right after a normal instance boot Stage completes once the agent registers (typically under 2 minutes on a standard Ubuntu AMI)
TC-2 Timeout Run against an instance whose IAM role lacks SSM permissions (agent can never register) Stage fails with a timeout error after the configured max wait, not an indefinite hang
TC-3 Already online Re-run this stage (retry scenario) against an instance whose agent is already registered Stage completes immediately, no unnecessary wait

No data to display

Actions

Also available in: PDF Atom