Skip to content

Remove dependency on arcctl-plugins  #196

@davidthor

Description

@davidthor

We had created arcctl plugins to divorce the main CLI from coupling to specific IaC providers, but 1) it doesn't quite go far enough since it requires datacenters to declare what type of plugin each module is, and 2) the implementation uses docker-in-docker which makes it hard to debug and acquire module execution logs in graceful ways.

The goal of this issue is to make modules more generic so that datacenters truly don't have to know anything about the modules in order to execute them.


From what I can tell from the first two plugin implementations, pulumi and opentofu, the main information we need about each module is 1) the runtime dependencies which are handled by the dockerfile, 2) the command that should be used to apply changes, and 3) the command that should be used to destroy the resources. In addition to these three bits of information, modules may also declare commands that can be used to import/export state, initialize the workspace, and preview changes.

To capture this information, we'll create a new file format, module.yml which will live with each module to declare these commands. The first version of this file format will include the following fields:

/**
 * Dockerfile to use to build the resource
 *
 * @default "Dockerfile"
 */
dockerfile?: string;

/**
 * Command that should be used to setup the module workspace
 *
 * @example "pulumi login --local && pulumi stack init --stack module"
 */
init?: string | string[];

/**
 * Command used to generate a preview of changes to apply
 *
 * @example "pulumi preview --stack module"
 */
plan?: string | string[];

/**
 * Command used to import state into the module. The statefile address is in the environment variable, $STATE_FILE.
 *
 * @example "pulumi stack import --stack module --file $STATE_FILE"
 */
import?: string | string[];

/**
 * Command used to export the module state. The statefile address is in the environment variable, $STATE_FILE.
 *
 * @example "pulumi stack export --stack module --file $STATE_FILE"
 */
export?: string | string[];

/**
 * The command to run to create or update the resources the module controls
 *
 * @example "pulumi up --stack module"
 */
apply!: string | string[];

/**
 * The command to run to destroy the module
 *
 * @example "pulumi destroy --stack module"
 */
destroy!: string | string[];

These fields (sans the dockerfile) will be turned into labels attached to the built image so that the metadata lives alongside the modules themselves. Whenever a datacenter wants to work with a module, it can look at the following labels to get the relevant commands to run:

label description
io.architect.module.apply Apply changes to the module
io.architect.module.destroy Destroy the module's resources
io.architect.module.init Initialize the local workspace
io.architect.module.import Import state
io.architect.module.export Export state
io.architect.module.plan Show a preview of changes to be applied

Metadata

Metadata

Assignees

Labels

tech-debtIssues relating to the cleanup of technical debt

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions