Documentation and Examples

This section provides an index of user-facing documentation, usage guides, and example blueprints that demonstrate common workflows and plugin capabilities. The dapcli repository is a headless CLI for the Dell Automation Platform orchestrator that drives the REST API directly so blueprints, deployments, and secrets can be managed from a script ¹. It is provided for testing and evaluation only, on an “AS IS” basis, with no warranty and no support.

Configuration and Authentication

The setup requires two commands: one to point dap-cli at a cluster and another to log in. The first command writes a ~/.config/dap-cli/config.json pointing at your portal (no secrets in the file). The second command prompts for an admin username + password, completes the OIDC handshake programmatically (no browser launched), and persists the resulting session cookies to ~/.config/dap-cli/session-<cluster>.json at mode 0600.

The portal session is short-lived (1-2 hours typical). When a command returns “session expired”, re-run dap auth login. For non-interactive auth (CI / headless), you can persist a customer-org admin API client once and let dap-cli mint Bearer tokens from it. The credentials persist to ~/.config/dap-cli/api-client.json at mode 0600. On rare DAP 2.0.0.1 installs where the portal’s OIDC callback is broken upstream, dap auth bootstrap-service-account provisions the admin client via the iam-mgmt-svc database directly.

Blueprint Workflows

A minimal blueprint that runs a one-task Ansible playbook inside the orchestrator’s mgmtworker pod and captures a fact into the deployment’s runtime properties is provided as a hello-world example. The smallest unit that proves the engine works involves uploading the blueprint, deploying it, and checking logs. The first run cold-provisions an ansible-core venv inside mgmtworker (8-15 minutes). Subsequent runs reuse the venv (30-90 seconds). The deployment’s runtime_properties will carry a dap_hello_greeting fact.

Secret Management

For a non-trivial example that uses the DAP Secret store (so the BMC password never lands in the deployment record as plaintext), you can push the BMC password into the encrypted DAP Secret store. By default dap secret put prompts for the value with input hidden (like sudo or ssh-add); the plaintext never appears on argv, in shell history, or in any environment variable. For scripted runs, you can pipe via stdin or point at a file.

The deployment record contains only bmc_password_secret_key: dap_bmc_password – never the password value. The blueprint resolves it via { get_secret: ... } at execution time, server-side.

Repository Structure and Hygiene

The repo’s hard rules (line limits, banned tokens, hermetic test discipline, no AI-speak in docstrings) live in tests/test_repo_hygiene.py as machine-checkable assertions. Failing a rule fails CI. There is no separate human-readable conventions doc. The layout includes src/dap/ for the CLI code, examples/ for blueprints, tests/ for hermetic tests, and docs/ for long-form operator docs and known upstream issues.