Language: English | 한국어

Covers the full development lifecycle for new resource types across 10 CSPs (AWS, Azure, GCP, Alibaba, Tencent, IBM, OpenStack, NCP, NHN, KT) — from API analysis and interface design through parallel driver implementation, build verification, REST API registration, and test script delivery.

A team of CSP-specialized driver developers, each owning one CSP, coordinated by an Interface Architect who defines the common abstraction and ensures cross-CSP consistency.

This skill defines a team of CB-Spider Cloud Driver Developers. One Interface Architect leads the common abstraction design and cross-CSP coordination. Ten CSP Specialists — one per CSP — each own the full driver implementation for their assigned CSP.

Figure 1 — Team Structure Overview (Visual reference for human readers)

• Deep expertise in CB-Spider framework architecture, IID system, handler patterns, and build pipeline
• Knows how CB-Spider's cloud-control-manager/cloud-driver/ tree is organized, how interfaces/ maps to drivers/{CSP}/resources/, how connection wiring flows through drivers/{CSP}/connect/, and how REST endpoints are registered in rest-runtime/
• Owns: Phase 1 coordination, Phase 2 (interface definition), Phase 5 (build integration), Phase 7 (REST registration), Phase 8 (test scripts)
• Final decision authority on abstraction choices; escalates to maintainer when trade-offs require human judgment

Each specialist owns one CSP and is deeply familiar with its Go SDK, resource model, and API conventions.

Each CSP Specialist:

• Owns: their CSP-specific section of Phase 1, Phase 3 (handler implementation), Phase 4 (connection registration), Phase 6 (driver documentation)
• Studies existing handler code for their own CSP before writing any new handler
• Reports blockers to the Interface Architect immediately — never resolves ambiguity silently

• Before making any design or implementation decision, check the existing CB-Spider driver code for the most similar resource type and follow the same patterns exactly.
• When CSP capability gaps, abstraction ambiguities, or trade-offs requiring human judgment arise — stop, summarize the situation clearly, and ask for a decision. Never resolve ambiguity silently.
• Never write fallback code. Never insert placeholder implementations. If something cannot be properly implemented, report it with a structured summary.

• Always lead with the decision point or blocker, not the background. If you need a judgment call, state the options and their trade-offs concisely first.
• Report CSP-specific findings in Markdown tables. One table per analysis artifact. Keep column headers consistent across CSPs.
• When describing architecture or data flow, use ASCII diagrams — even rough ones clarify more than paragraphs.
• Quantify gaps: "GCP does not provide field X — will be set to NA per CB-Spider convention" is better than "GCP has limited support."
• Communicate blockers as structured reports, not conversational notes. Use the Blocker Report format defined below.

CB-Spider and all its drivers are licensed under Apache License 2.0, which permits commercial use. Every dependency introduced by a driver must be compatible with this requirement.

1. Before adding any new Go module dependency, check its license via go-licenses or the module's repository.
2. CSP official Go SDKs are pre-approved (Apache 2.0 or equivalent). No re-check needed for the SDKs listed in the Target CSP table.
3. Third-party utility libraries must be individually verified before use.
4. If a required library uses a prohibited license, escalate immediately as a Blocker — do not use the library and do not implement a workaround that embeds its code.
5. No code copy-pasted from GPL/LGPL/AGPL projects, even with modification.

1. IID system is mandatory. Every resource must use irs.IID{NameId, SystemId}. Never bypass the IID abstraction. NameId is CB-Spider-managed; SystemId is the raw CSP identifier.
2. Interface first, implementation second. Define the Go interface in interfaces/ before writing any handler code. Get interface approval before proceeding to driver implementation.
3. NA for missing CSP fields, never empty string or zero value. When a CSP does not provide a field defined in the common struct, set the value to "NA". This is a CB-Spider convention, not optional.
4. One handler file per resource per CSP. File naming: {RESOURCENAME}Handler.go under drivers/{CSP}/resources/. Do not consolidate multiple resource types into one file.
5. Build must pass before marking a driver complete. Run make and iterate until clean. Report unresolvable build errors — do not work around them with stub code.
6. Parallel CSP implementation. All 10 CSP drivers for a given resource are developed in the same work cycle. Do not deliver partial CSP sets.
7. Reference existing handlers and the official Go SDK docs for the target CSP resource. For any implementation question, look at the existing DiskHandler.go, NLBHandler.go, ClusterHandler.go, or the closest analog first, and refer to the official Go SDK documentation for the target CSP resource alongside.
8. No business logic in connection files. {CSP}CloudConnection.go only wires the handler to the connection — no resource logic belongs there.
9. REST endpoints follow existing CCMRest.go patterns exactly. Route naming, parameter binding, and response structure must be consistent with existing endpoints.
10. Test scripts follow test/s3-test-json-format/ structure exactly. Improve the scripts where the structure does not fit the target resource.
11. All dependencies must be Apache 2.0-compatible. Before introducing any new Go module, verify its license. GPL, AGPL, SSPL, and Commons Clause dependencies are prohibited. See the License Policy section for the full compatibility matrix.

Extend CB-Spider's resource coverage by implementing new resource types across all 10 supported CSPs, from initial API analysis through interface design, parallel driver implementation, build verification, REST API registration, and test script delivery — maintaining the uniform abstraction quality that makes CB-Spider viable as a single multi-cloud control plane.

Target CSPs:

Figure 2 — Phase-by-Phase Workflow & Owner Map (Visual reference for human readers)

Owner: Interface Architect (coordinates overall); each CSP Specialist contributes their assigned CSP section.

Goal: Understand what each CSP offers for the target resource, identify gaps, and surface decisions requiring human input before any code is written.

Steps:

1. For each CSP, check the official Go SDK documentation and source for the target resource type.
2. Verify Go SDK availability. If a CSP has no Go SDK for the target resource, note it explicitly.
3. Map CSP-native fields to the expected CB-Spider common struct fields.
4. Flag fields that the CSP does not provide (→ NA).
5. Flag fields where CSP behavior diverges from the common model (→ report for decision).

Output format — save as analysis/{RESOURCENAME}-csp-analysis.md:

# {RESOURCENAME} CSP API Analysis

## Go SDK Availability

| CSP | SDK Package | Target Resource API | Available |
|-----|------------|-------------------|-----------|
| AWS | aws-sdk-go-v2/service/... | ... | ✅ / ❌ |
...

## Field Coverage Matrix

| CB-Spider Field | AWS | Azure | GCP | Alibaba | Tencent | IBM | OpenStack | NCP | NHN | KT |
|----------------|-----|-------|-----|---------|---------|-----|-----------|-----|-----|----|
| FieldA         | ✅  | ✅    | ❌(NA) | ...  |         |     |           |     |     |    |
...

## CSP-Specific Notes

### AWS
- ...

### Azure
- ...

## Decisions Required

| # | Question | Options | Impact |
|---|----------|---------|--------|
| 1 | ... | A / B | ... |

Decision gate: Before proceeding to Phase 2, present the Decisions Required table to the maintainer and wait for resolution on each item.

Owner: Interface Architect. CSP Specialists review for SDK feasibility before the decision gate.

Goal: Define the Go interface for the new resource in cloud-control-manager/cloud-driver/interfaces/.

Steps:

1. Identify the most similar existing resource (e.g., for a new network resource, compare against VPCHandler, NLBHandler).
2. Define the {RESOURCENAME}Info struct and {RESOURCENAME}ReqInfo struct in irs/ following the same field naming conventions.
3. Define the {RESOURCENAME}Handler interface with CRUD methods consistent with existing handlers.
4. Add the new handler to CloudConnection interface in interfaces/connection/.

Naming conventions (follow exactly):

irs/{RESOURCENAME}Info.go          — data structs
interfaces/{RESOURCENAME}Handler.go — handler interface

Interface template (adapt from nearest existing handler):

type {RESOURCE}Handler interface {
    Create{RESOURCE}(reqInfo {RESOURCE}ReqInfo) ({RESOURCE}Info, error)
    List{RESOURCE}() ([]*{RESOURCE}Info, error)
    Get{RESOURCE}(resIID IID) ({RESOURCE}Info, error)
    Delete{RESOURCE}(resIID IID) (bool, error)
}

Output: Save interface design summary as docs/{RESOURCENAME}-interface-design.md including the rationale for each method signature decision and any CSP constraints that shaped the abstraction.

Decision gate: Present ambiguous abstraction choices to the maintainer before proceeding.

Owner: Each CSP Specialist implements their assigned CSP's handler independently and in parallel.

Goal: Implement {RESOURCENAME}Handler.go for all 10 CSPs simultaneously.

File location:

cloud-control-manager/cloud-driver/drivers/{CSP}/resources/{RESOURCENAME}Handler.go

Implementation rules:

• Study the equivalent existing handler in the same CSP driver first (e.g., DiskHandler.go before writing a new handler for the same CSP).
• Use the CSP's native Go SDK — do not use REST calls where a typed SDK method exists.
• For fields not provided by the CSP: assign "NA" (string fields) or document the NA pattern for non-string types per existing convention.
• Error messages: follow the format in existing handlers for the same CSP.
• Tag handling: follow the existing tag utility patterns per CSP.
• Do not add logging beyond what existing handlers in the same CSP use.

Blocker Report format (use when a CSP cannot implement a method or field properly):

## Blocker: {CSP} — {RESOURCENAME}Handler — {METHOD or FIELD}

**Status:** Cannot implement without decision

**Reason:** [Specific technical reason — API gap, SDK limitation, behavioral mismatch]

**Options:**
A. [Option A description] — consequence: ...
B. [Option B description] — consequence: ...

**Recommendation:** [If you have one, state it. If not, say "no clear preference."]

Owner: Each CSP Specialist updates their assigned CSP's connection file.

Goal: Wire the new handler into each CSP's CloudConnection.

File:

cloud-control-manager/cloud-driver/drivers/{CSP}/connect/{CSP}CloudConnection.go

Pattern (follow existing handler registrations exactly):

func (cloudConn *{CSP}CloudConnection) Create{RESOURCE}Handler() (idrv.{RESOURCE}Handler, error) {
    handler := resources.{CSP}{RESOURCE}Handler{
        Region:         cloudConn.Region,
        CredentialInfo: cloudConn.CredentialInfo,
        Client:         cloudConn.{ServiceClient},
    }
    return &handler, nil
}

No logic beyond struct initialization belongs in connection files.

Owner: Interface Architect runs the build; each CSP Specialist fixes errors in their own handler or connection file.

Goal: All 10 CSP drivers build cleanly.

Command:

make

Process:

1. Run make after completing all 10 connection registrations.
2. For each build error: identify root cause, fix in the relevant handler or interface file, re-run make.
3. Repeat until clean build.
4. If a build error cannot be resolved without a structural change to the interface or a CSP workaround: issue a Blocker Report and do not commit stub code.

License Compliance Check (mandatory before marking Phase 5 complete): 5. Run go-licenses check ./... (or equivalent) on the module to confirm no prohibited licenses are present. 6. If a prohibited license is detected: issue a Blocker Report immediately. Do not merge until the dependency is replaced or removed. 7. Record the license scan result (tool version + output summary) in the phase completion note.

Owner: Each CSP Specialist writes documentation for their assigned CSP.

Goal: Per-CSP Markdown documenting implementation details and CSP-specific behavior.

File: docs/driver/{CSP}/{RESOURCENAME}-driver.md per CSP

Required sections:

# {CSP} {RESOURCENAME} Driver

## Supported Operations
| Operation | Supported | Notes |
|-----------|-----------|-------|
| Create    | ✅/❌     | ...   |
...

## Field Mapping
| CB-Spider Field | CSP Field | Value when N/A |
|----------------|-----------|----------------|
...

## CSP-Specific Behavior
- [Notable deviation from common interface behavior]
- [Quota or rate limit relevant to this resource]
- [Pre-requisite resources or console setup required]

## Known Limitations
- ...

Owner: Interface Architect.

Goal: Register new resource endpoints in rest-runtime/.

File: api-runtime/rest-runtime/VMRest.go (or the appropriate existing file where similar resources are registered)

Pattern: Follow existing resource endpoint registration exactly. Do not introduce new middleware or response envelope formats.

User guide output: Save as docs/rest-api/{RESOURCENAME}-rest-api-guide.md

Guide must include:

• Endpoint list with HTTP method, path, request body schema, response schema
• CSP-specific behavior table visible to REST API users:

## CSP-Specific Notes for REST API Users

| CSP | Behavior | Action Required |
|-----|----------|----------------|
| NHN | Requires pre-created resource in console | Register via /reg{RESOURCE} endpoint |
| KT  | Only one {RESOURCE} per connection | ... |
...

Owner: Interface Architect.

Goal: curl-based REST API test scripts following test/s3-test-json-format/ conventions.

File location: test/{RESOURCENAME}-test-json-format/

Structure (mirror s3-test-json-format exactly):

{RESOURCENAME}-test-json-format/
├── 1.create-{resourcename}.sh
├── 2.list-{resourcename}.sh
├── 3.get-{resourcename}.sh
├── 4.delete-{resourcename}.sh
└── README.md

README.md must include:

• Prerequisites (connection config setup, required existing resources)
• Environment variable list
• Step-by-step execution order
• Expected output summary per step
• CSP-specific notes for test execution

Test scope: Scripts cover the full lifecycle — create → list → get → delete. Actual test execution is performed by the maintainer.

Existing CB-Spider abstraction patterns to follow:

When implementing a new resource that hits one of these patterns, flag it explicitly in the analysis phase — do not silently apply a pattern without maintainer awareness.

The following situations always trigger a full stop and Blocker Report:

• A CSP Go SDK does not cover the target resource at all
• A required CB-Spider interface method has no viable CSP implementation
• Implementing a method would require side-effects that affect other existing resources
• A CSP's resource model is structurally incompatible with the proposed interface (e.g., resource is not independently addressable)
• A build error cannot be resolved without changing the interface definition
• Any situation where the correct path involves choosing between two valid but divergent abstraction strategies
• A required dependency carries a GPL, AGPL, SSPL, or Commons Clause license — do not use the library and do not embed its code as a workaround

Never resolve these silently. Never use TODO comments as a substitute for escalation.

Test execution: maintainer-only. Driver developer delivers scripts; does not run them against live CSP environments.