Saved Connections and Inventory

In enterprise usage, saved connections become the operational backbone of rauto.

They are not just convenience shortcuts. They are the source of truth for:

reusable target definitions
inventory grouping
variable inheritance
orchestration targeting
long-term execution history

Why saved connections matter

Ad-hoc flags are fine at the beginning:

rauto exec "show version" \
  --host 192.168.1.1 \
  --username admin \
  --password secret \
  --device-profile cisco

But enterprise workflows quickly need:

shorter and safer command lines
reusable target naming
stable inventory selection for jobs and orchestration
consistent device profile assignment
auditable history bound to known targets

That is where saved connections become essential.

Core connection lifecycle

Add or update a saved connection

rauto connection add lab1 \
  --host 192.168.1.1 \
  --username admin \
  --ssh-port 22 \
  --ssh-security balanced \
  --device-profile cisco

Reuse a saved connection

rauto exec "show version" --connection lab1

Inspect and delete

rauto connection list
rauto connection show lab1
rauto connection delete lab1

Save effective connection after success

rauto connection test \
  --connection lab1 \
  --save-connection lab1_backup

Password handling rules

The current behavior is deliberately conservative.

--save-connection does not save passwords by default
add --save-password if you want password fields persisted
connection add saves password fields only when they are explicitly provided
saved passwords are encrypted in rauto.db
the master key is stored in the local system keyring

Operational implication:

database backups move most runtime state
encrypted passwords may still require re-save or key migration when moved to another machine or account

Bulk import

Bulk import is one of the most important enterprise onboarding features.

rauto connection import ./devices.csv
rauto connection import ./devices.xlsx

Supported file types:

.csv
.xlsx
.xls
.xlsm
.xlsb

Recommended headers

name,host,username,password,port,enable_password,ssh_security,linux_shell_flavor,device_profile,template_dir
core-sw-01,192.168.1.1,admin,secret,22,,balanced,,cisco,
linux-jump-01,192.168.1.10,root,secret,22,,secure,posix,linux,

Import behavior

From the README and current docs:

import uses upsert semantics by connection name
if name is omitted, it can be derived from host
if password fields are omitted for an existing target, stored encrypted passwords are preserved
Web UI also exposes a starter CSV download flow

Repository sample files:

templates/examples/connection-import-template-en.csv
templates/examples/connection-import-template-zh.csv

History model

Saved connections are also the anchor for execution history.

Current CLI support:

rauto history list lab1 --limit 20
rauto history show lab1 <history-id>
rauto history delete lab1 <history-id>

This matters in enterprise environments because history becomes easier to interpret when bound to a stable saved target instead of transient ad-hoc flags.

Inventory model

There is no separate persistent inventory target record layer anymore.

Instead:

saved connections are the inventory target source of truth
inventory CLI focuses on group management and merged vars preview

This is a subtle but important design decision.

It means the target identity model stays unified:

one saved connection entry
reused by CLI execution
reused by Web UI
reused by groups
reused by orchestration

Group management

Current group operations:

rauto inventory group list
rauto inventory group show access --json
rauto inventory group upsert access --file ./group-access.json
rauto inventory group delete access

Group JSON shape

{
  "name": "access",
  "description": "Campus access switches",
  "hosts": ["edge-sw-01", "edge-sw-02"],
  "vars": {
    "role": "access"
  }
}

Variable merge resolution

One of the most useful enterprise features is merged variable preview.

rauto inventory resolve-vars \
  --host edge-sw-01 \
  --group access \
  --vars-json '{"ticket":"CHG-42"}' \
  --json

Current merge order:

group vars
saved connection vars
runtime vars

Use this command before workflow or orchestration rollout when you need to verify exactly which effective variable set a target will receive.

Labels, groups, and enterprise inventory usage

The README describes saved connections as the source of truth for fields including:

enabled
labels
groups
vars

This makes saved connections suitable for:

environment segmentation
region / site grouping
role-based grouping
staged orchestration targeting
approval-friendly naming and reporting

Enterprise operating model

Recommended maturity path

Stage 1: ad-hoc execution

Use direct flags while learning.

Stage 2: saved connection normalization

Standardize names, device profiles, and SSH security settings.

Stage 3: group-based inventory

Define groups such as:

core
access
edge
linux-app
linux-jump

Stage 4: orchestration and workflow reuse

Build rollout logic on top of saved connections and groups rather than inline host fields.

Naming recommendations

Use stable names that work well in task history and orchestration plans.

Examples:

core-sh-01
access-bj-07
fw-hq-01
linux-jump-01