You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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: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:
io.architect.module.apply
io.architect.module.destroy
io.architect.module.init
io.architect.module.import
io.architect.module.export
io.architect.module.plan
The text was updated successfully, but these errors were encountered: