Skip to content

Install and Use a Content Archive

A content archive (.drpca) delivers automation and its payload — tasks, workflows, and the files they need — as one installable unit. This tutorial gets an archive onto a running endpoint two ways (from a file and from the catalog), confirms it is installed and serving, and runs its content on a machine.

The example uses the raid-tools archive from the developer tutorial. For the concepts — how an archive mounts and serves — see Content Archives.

Prerequisites

  • A running DRP endpoint, with drpcli configured to reach it.
  • One of: the raid-tools.drpca file (from the developer tutorial), or access to a catalog that publishes it.
  • A machine managed by the endpoint, if you want to run the content (the final step).

Install from a file

If you were handed a .drpca — for example the one built in the developer tutorial — upload it directly:

Bash
drpcli content_archives upload raid-tools.drpca

The upload is atomic: the endpoint stages the archive, loads its content and mounts its payload together, and commits — or rolls back cleanly if anything fails.

Tip

Where the DRP portal exposes content-archive upload, it performs the same atomic operation as the CLI.

Install from the catalog

More often you install a published archive from a catalog. Browse what is available, then install by name:

Bash
drpcli catalog items                          # list available items
drpcli catalog item install raid-tools        # install the latest version
drpcli catalog item install raid-tools --version v1.0.0   # pin a version

For a content archive, the catalog install downloads the .drpca and uploads it to the endpoint for you — the same atomic operation as the file path above. To see what an item needs first:

Bash
drpcli catalog item prereqs raid-tools        # prerequisites, in install order

Manage an in-progress upload

An archive upload is a staged transaction: the endpoint stages the archive, then commits it. If an upload is interrupted or gets stuck, inspect or clear the pending transaction:

Bash
drpcli content_archives upload-status          # shows the token and staged items, or "No uploads in progress"
drpcli content_archives upload-cancel          # discard a stuck or partial upload

upload-cancel throws away anything staged but not yet committed, leaving the endpoint unchanged — use it before retrying a failed upload from scratch.

Confirm it is installed and serving

Check the archive is present:

Bash
drpcli content_archives list                  # raid-tools appears, with its version

list is the everyday view — installed archives and their versions. For a lower-level look at the raw <sha256>.drpca files on disk (the storage view used by replication and backup), use drpcli content_archives sources; you rarely need it.

Then confirm the payload is being served — straight from the mounted archive, not a copy on disk (HTTP on port 8091, HTTPS on 8090):

Bash
curl -sS -o /dev/null -w '%{http_code}\n' \
  http://<endpoint>:8091/files/raid-tools/storcli

A 200 means the endpoint is serving the tool out of the archive. To see everything the archive carries, inspect it:

Bash
drpcli catalog item download raid-tools to raid-tools.drpca   # if you don't have the file
drpcli content_archives inspect raid-tools.drpca

Run its content on a machine

Installing the archive also loaded its content — the tasks, stages, and workflow that use the tooling. Putting it to work is an ordinary workflow assignment.

Find the workflow the archive provides, and a machine to run it on:

Bash
drpcli workflows list                          # a content archive's workflow would appear here
drpcli machines list                           # pick a target machine (note its Name or UUID)

Assign the workflow to the machine. A production raid archive would provide a workflow such as raid-configure; substitute the one your archive actually lists. A machine is referenced by its UUID or by Name:<name>:

Bash
drpcli machines workflow Name:rack1-node5 raid-configure

Setting the workflow makes DRP re-evaluate the machine's tasks and begin running them. Those tasks fetch the RAID tooling directly from the served archive — nothing is downloaded or exploded on the machine's behalf.

Watch it run:

Bash
drpcli machines currentlog Name:rack1-node5    # the current job's log — no UUID lookup needed

Note

The raid-tools stand-in from the developer tutorial ships only files/ payload — no workflow — so raid-configure will not appear in workflows list and this assign step is illustrative. The point is the mechanics: install, serve, assign, and watch are exactly the commands you use for a production archive that does carry a workflow. Swap in that archive's real workflow name and the steps are identical.

Update to a new version

When a new version is published, install it the same way. An endpoint runs one version of a named archive at a time, so the new one replaces the old:

Bash
drpcli catalog item install raid-tools --version v1.1.0

Installing from a file instead? Use --remove to retire an archive as part of the same atomic upload — useful when a new archive supersedes a differently-named one:

Bash
drpcli content_archives upload new-tools.drpca --remove old-tools

For managed fleets, which version each endpoint runs is governed by its version sets — check your architecture team's version-set policy rather than installing by hand.

Remove an archive

To uninstall a single archive, use destroy with its name (as shown by list):

Bash
drpcli content_archives destroy raid-tools

On success it prints Deleted content archive raid-tools. If the name isn't installed it errors and exits non-zero, so a typo fails loudly instead of quietly doing nothing:

Bash
drpcli content_archives destroy raid-tool     # typo
# Error: content archive "raid-tool" is not installed

destroy removes one archive by name. To retire an archive as part of installing another — in a single atomic transaction — use upload --remove instead (see Update to a new version).

Troubleshooting

A payload URL returns 404. The archive is not installed, or the path is wrong. Confirm with drpcli content_archives list, and remember payload under files/ is served at /files/....

The workflow is not available to assign. The archive did not install, or it does not provide that workflow. Confirm with drpcli content_archives list and drpcli workflows list, and check what the archive carries with drpcli content_archives inspect.

Install fails or rolls back. The upload is atomic, so a validation failure leaves the endpoint unchanged. Read the error, and run drpcli catalog item prereqs <name> to check for missing prerequisites.

References