Project

General

Profile

Actions

Feature #49

open
AS

Feature #33: Canofy Control Centre Backend Development

Feature #46: Canofy Control Centre Onboarding Process

# [CANOFY-103] Allocate & Associate Elastic IP

Feature #49: # [CANOFY-103] Allocate & Associate Elastic IP

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-103] Allocate & Associate Elastic IP

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

User Story

As an operations engineer,
I want the client's server to have a stable public IP address,
so that DNS, SSL certificates, and client-facing URLs never break due to
an instance stop/start cycle changing the public IP.

Description

Allocate a new Elastic IP in the request's region and associate it with the
EC2 instance created in stage 1. The resulting public IP must be:

  • Stored on Onboarding Request.elastic_ip_address.
  • Available in the pipeline context (public_ip) for later stages that need
    it as an SSL/DNS fallback target (e.g. frappe_config's IP-override path
    when Certbot hasn't run yet).

Configuration / Prerequisites

  • Depends on stage 1 having produced a valid instance_id.
  • AWS account must have EIP allocation quota available in the target region.

Acceptance Criteria

  • A new Elastic IP is allocated (not a reused/stale one from a prior
    failed run).
  • The EIP is associated with the correct instance.
  • Onboarding Request.elastic_ip_address matches the allocated IP.
  • If EIP allocation fails (quota exhausted), the stage fails with a
    clear, specific error naming the quota problem, not a generic AWS
    exception dump.

Test Cases

ID Scenario Steps Expected Result
TC-1 Happy path Run stage against a running instance EIP allocated, associated; describe-addresses shows correct InstanceId
TC-2 Persisted on request Inspect Onboarding Request after stage elastic_ip_address field matches the real allocated address
TC-3 Survives instance stop/start Stop and start the instance (not terminate) Public IP is unchanged, still the allocated EIP
TC-4 Quota exhausted Simulate account at its EIP allocation limit Stage fails with a message identifying the quota limit, not a raw boto3 traceback
TC-5 Retry after partial failure Re-run this stage via retry_failed_stage after a downstream stage failure Does not allocate a second, orphaned EIP — reuses the one already associated with the instance

No data to display

Actions

Also available in: PDF Atom