Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove dependency on arcctl-plugins #196

Open
davidthor opened this issue Dec 13, 2023 · 0 comments
Open

Remove dependency on arcctl-plugins #196

davidthor opened this issue Dec 13, 2023 · 0 comments
Assignees
Labels
tech-debt Issues relating to the cleanup of technical debt

Comments

@davidthor
Copy link
Member

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
@davidthor davidthor added the tech-debt Issues relating to the cleanup of technical debt label Dec 13, 2023
@davidthor davidthor self-assigned this Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tech-debt Issues relating to the cleanup of technical debt
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant