Project

General

Profile

Actions
Copy link

Feature #61

open
AS

Feature #33: Canofy Control Centre Backend Development

Feature #46: Canofy Control Centre Onboarding Process

# [CANOFY-115] Smoke Test & Create Control Centre Records

Feature #61: # [CANOFY-115] Smoke Test & Create Control Centre Records

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-115] Smoke Test & Create Control Centre Records

Type: Story
Epic: New Client Onboarding — Automated AWS + Frappe Provisioning
Stage key: smoke_test (pipeline stage 15 of 15, final)
Component: utils/onboarding_executor.py, utils/uptime_checker.py

User Story

As an operations engineer,
I want onboarding to verify the site is actually reachable before
declaring success, and only then register it in Control Centre,
so that a broken site never gets marked "Completed," and Control
Centre's inventory (AWS Server, Bench Instance, Client Site) always
reflects only real, working infrastructure.

Description

  1. Run an uptime check against the site (HTTPS if SSL configured, otherwise
    the IP-override fallback established in stage 12) — expect a 200
    response.
  2. Only on a successful check:
    • Create the AWS Server record (instance ID, region, type, etc.).
    • Create the Bench Instance record.
    • Create the Client Site record.
    • Link all three back onto Onboarding Request
      (aws_server_created, bench_created, site_created).
    • Set Onboarding Request.onboarding_status = "Completed",
      completed_at = now().
  3. On failure, the stage (and therefore the whole run) fails — no partial
    Control Centre records are created, so a failed onboarding never leaves
    a half-registered, confusing inventory entry.

Configuration / Prerequisites

  • Depends on every prior stage having succeeded (this is intentionally the
    last stage — it's the pipeline's final gate).

Acceptance Criteria

  • A non-200 (or unreachable) response fails the stage — Onboarding Request stays Failed, no Control Centre records created.
  • A successful check creates exactly one AWS Server, one Bench Instance, one Client Site — never duplicates on a retried run.
  • All cross-links (Onboarding Request ↔ the three new records) are
    set correctly.
  • onboarding_status only ever becomes Completed after this stage's
    uptime check passes — no earlier stage can set that status.

Test Cases

ID Scenario Steps Expected Result
TC-1 Happy path Run stage against a fully provisioned, reachable site Uptime check returns 200; AWS Server/Bench Instance/Client Site all created and linked; request marked Completed
TC-2 Site unreachable Simulate the site not responding (e.g. nginx down) Stage fails; onboarding_status stays Failed; no Control Centre records created
TC-3 No duplicate records on retry Retry this stage after a transient failure, where the site is now reachable Exactly one of each record created — not two, even though the stage ran twice
TC-4 IP-override fallback Run against a site with ssl_configured=False from stage 12 Uptime check correctly uses http://<elastic_ip> with the right Host header, not https://<site_name> (which would fail with no valid cert)
TC-5 Cross-link integrity After a successful run, inspect Onboarding Request aws_server_created, bench_created, site_created all point at the correct, real record names
Actions
Copy link

Also available in: PDF Atom