dorgu persona

Create ApplicationPersonas from running Deployments, and inspect them

​

Overview

The dorgu persona command group manages ApplicationPersona custom resources. An ApplicationPersona is a Kubernetes CRD that captures the operational identity of your application as a declarative, version-controlled resource. It records resource requirements, scaling behavior, health characteristics, and deployment preferences.

Dorgu only watches workloads that have a persona. You create them from the Deployments already running on your cluster with persona import, then inspect them with persona list and persona status.

CLI v0.13.0 removed persona generate and persona apply, which built a persona from local source. persona import reads the live Deployment instead and needs no source tree. See the CLI migration guide.

​

persona import

Requires CLI v0.9.0 or newer.

​

Synopsis

dorgu persona import -n <namespace> [--all | --name <deployment>] [flags]

Read the live Deployments in a namespace and synthesize an ApplicationPersona for each from what is already in the spec: resources, probes, replicas, ports, image, and ownership labels.

This is how you onboard apps. It needs no local source, no Dockerfile, and no relabelling of your workloads. Dorgu only watches workloads that have a persona, so until one exists a broken app raises no incident and gets no proposed fix.

It prints the YAML by default so you can read it before anything reaches the cluster. --apply creates the personas; -o writes them to a file.

​

Flags

Flag	Type	Default	Description
-n, --namespace	string	required	Namespace to import from
--all	bool	false	Import every Deployment in the namespace
--name	string	none	Import a single Deployment by name
--dry-run	bool	true (implied)	Print the personas without applying. This is the default; the flag is there to be explicit.
-o, --output	string	none	Write the personas to a file instead of stdout
--apply	bool	false	Apply the personas to the cluster
--kubeconfig	string	kubectl’s own resolution: $KUBECONFIG, then ~/.kube/config	Path to kubeconfig file

Exactly one of --all or --name is required, and they are mutually exclusive. --apply and --dry-run are mutually exclusive.

​

Examples

# Read the personas for every Deployment in a namespace
dorgu persona import -n apps --all

# Save them to a file to review, edit, and commit
dorgu persona import -n apps --all > personas.yaml
dorgu persona import -n apps --all -o personas.yaml

# One Deployment only
dorgu persona import -n apps --name checkout-api

# Create them on the cluster
dorgu persona import -n apps --all --apply

> personas.yaml is safe. Only the rendered YAML goes to stdout; every diagnostic, warning, and summary line goes to stderr. Redirecting stdout gives you a clean multi-document manifest you can commit to Git, and you still see the warnings on your terminal.

​

What gets inferred, and why it matters

Import reads the Deployment and invents as little as possible. Anything it does invent, it says out loud on stderr.

The warning to read is the one about resource limits. The remediation proposer skips any persona with no resources.limits, because without a current value it has nothing to compute a bounded change from. A persona that cannot heal is worse than no persona, so where a container declares no limits, import derives them:

• Limits are derived from the container’s requests at 2x where requests exist.
• Where there is neither a request nor a limit, Dorgu’s own defaults are used (500m CPU, 512Mi memory).

Either way you get a line naming the container and the number:

⚠ container "report-worker" sets no memory limit; the persona uses 96Mi (2x its memory request of 48Mi)
⚠ Resource limits were inferred for: report-worker. Remediation resizes from the persona, so check these before you rely on them.

Remediation resizes from the persona, not from the workload, so review these before you rely on them.

Other things import reports rather than guesses at silently:

Situation	What you see
No HTTP liveness or readiness probe	The health block is left out of the persona, and the Deployment is named. Exec and TCP probes have no path to record.
Another Deployment’s label outranks this one’s name	The conflict is named, with the label to set so the persona resolves to the workload you meant.
No Deployments in the namespace	Nothing is written, and it says so rather than emitting an empty file.
ApplicationPersona CRD not installed	Reported as a fact about the operator, with the helm install command for the operator as the hint.

​

How the persona is named

metadata.name is the Deployment’s name. spec.name is chosen so the operator’s discovery chain resolves it back to that same Deployment and no other: candidates are tried in chain order (app.kubernetes.io/name label, app label, then the Deployment name) and each is kept only if it resolves uniquely across the whole namespace.

Where no candidate works, because another Deployment carries a label that outranks this one’s name match, the CLI says so rather than pointing Dorgu at the wrong workload:

⚠ the persona for Deployment web will resolve to web-green instead: web-green carries a label
  that outranks the name match. Set app.kubernetes.io/name=web on web before importing

​

After importing

dorgu persona list -n apps

Phase Active means the operator resolved the persona to its Deployment. Phase Pending means it did not: check the Ready condition for NoDeployment or AmbiguousDeployment and see troubleshooting.

The full walkthrough, from install through breaking an imported app and healing it, is the brownfield quickstart.

​

persona list

​

Synopsis

dorgu persona list [flags]

List the ApplicationPersona resources on the cluster with their phase, health, and age. Defaults to every namespace.

​

Flags

Flag	Type	Default	Description
-n, --namespace	string	all namespaces	Namespace to list
--kubeconfig	string	kubectl’s own resolution: $KUBECONFIG, then ~/.kube/config	Path to kubeconfig file
--json	bool	false	Output the raw resource list as JSON (inherited global flag)

​

Example output

  NAME                           NAMESPACE        PHASE          HEALTH       AGE
  ────────────────────────────────────────────────────────────────────────────────
  api                            apps             Active         Healthy      4m
  report-worker                  apps             Active         Degraded     4m
  web                            apps             Pending        Unknown      4m

Column	Description
NAME	The persona’s metadata.name
NAMESPACE	Namespace of the persona
PHASE	Pending, Active, Degraded, or Unknown. Pending on a persona whose Deployment exists usually means resolution failed.
HEALTH	.status.health.status, or - when the operator has not reported one yet
AGE	Time since the persona was created

​

Examples

# Every persona on the cluster
dorgu persona list

# One namespace
dorgu persona list -n commerce

# JSON for scripting
dorgu persona list --json

With no personas, the command says so and points at dorgu persona import. If the CRD is missing entirely, it reports that the operator is not installed rather than reporting an empty list.

​

persona status

​

Synopsis

dorgu persona status <name> [flags]

Check the reconciliation status of an ApplicationPersona by name. Requires exactly one argument: the persona name.

​

Flags

Flag	Type	Default	Description
-n, --namespace	string	default	Kubernetes namespace to query
--kubeconfig	string	kubectl’s own resolution: $KUBECONFIG, then ~/.kube/config	Path to kubeconfig file

​

Examples

# Check status of a persona in the default namespace
dorgu persona status my-app

# Check status in a specific namespace
dorgu persona status order-service -n production

​

Status fields

The persona status command reports the following fields from the ApplicationPersona resource:

Field	Values	Description
.status.phase	Pending, Active, Degraded, Unknown	Current reconciliation phase
.status.validation.passed	true / false	Whether the persona passed validation
.status.validation.issues	list of strings	Validation issues found by the operator
.status.health.status	string	Overall health status of the application
.status.health.replicas	integer	Number of running replicas observed

Requires the Dorgu Operator installed on the cluster with the ApplicationPersona CRD registered. See the Operator installation guide for setup instructions.