Skip to content

Plugin System and Extensions

The plugin system in dapcli enables the extension of the CLI by allowing users to build, upload, list, and delete custom plugins (wagons) that interact with the DAP orchestrator. The architecture separates the local build process, which ensures ABI compatibility via Docker, from the remote lifecycle management, which handles plugin registration and state polling via REST APIs. This section details the client interface for orchestrator communication, the Docker-driven build process for creating compatible wagon archives, and the CLI command handlers that orchestrate these operations.

The plugin client, located in src/dap/plugin/client.py, provides the REST surface for interacting with the orchestrator’s plugin endpoints. It exposes functions for uploading, listing, and deleting plugins, as well as polling for upload completion.

  • Upload: The upload_plugin function POSTs the raw wagon archive to /api/v3.1/plugins with Content-Type: application/octet-stream and a visibility query parameter. It returns the plugin record, which may initially have a pending or uploading state for large files 1.
  • Polling: The wait_plugin_uploaded function polls /api/v3.1/plugins/<id> until the state reaches uploaded or fails. It raises a DapError if the state becomes failed_uploading or invalid 2.
  • List/Delete: list_plugins retrieves plugins via GET /api/v3.1/plugins, while delete_plugin handles deletion via DELETE /api/v3.1/plugins/<id>, treating 404 responses as success for idempotency.

The client uses open_orchestrator_client to manage sessions and authentication, supporting both user sessions and admin bootstrap results 1.

diagram

The build_wagon function in src/dap/plugin/client.py ensures that plugins are built with an ABI compatible with the DAP mgmtworker. It achieves this by running the build process inside a manylinux Docker container.

  • Containerization: By default, it uses quay.io/pypa/manylinux2014_x86_64 with Python 3.11. This can be overridden via CLI flags or environment variables like DAP_PLUGIN_BUILD_IMAGE.
  • Build Steps: The function creates a temporary stage directory, copies the source (excluding VCS and cache directories), and runs a shell command inside the container. This command installs build dependencies (e.g., wagon, build, setuptools), optionally runs a fetch_govc.py script, and then invokes wagon create to generate the .wgn file 2.
  • Output: The resulting .wgn file and plugin.yaml are copied to the output directory. The function requires Docker (or Podman) to be available on the host PATH.
diagram

The CLI commands in src/dap/plugin/commands.py provide the user interface for plugin management. They resolve authentication, invoke the client functions, and handle user feedback.

  • Authentication: The _resolve_auth helper attempts to load a user session first, falling back to persisted admin credentials. If neither is available, it raises an error prompting the user to log in 3.
  • Upload Command: The dap plugin upload command accepts a wagon path, visibility, and TLS options. It calls upload_plugin and, unless --no-wait is specified, calls wait_plugin_uploaded to confirm the plugin is fully processed 4.
  • Build Command: The dap plugin build command takes a source directory, resolves build parameters (image, Python version, platform) from CLI args or environment variables, and calls build_wagon. It then prints the path to the built wagon, suggesting the subsequent upload command.
diagram