Glossary

Definitions of terms used throughout the Odysseus documentation, organized by category.

Platform Concepts

Agent: A lightweight process that runs on each of your nodes. The agent communicates with the Odysseus control plane over an encrypted WireGuard tunnel, receives deployment instructions, manages containers via the local Docker API, and reports health and metrics back to the platform.
Athena: The AI-powered operations assistant built into the Odysseus dashboard. Athena uses Claude AI with Model Context Protocol (MCP) to connect to 61 orchestration tools, enabling natural language infrastructure management. See MCP.
Canary Deployment: A deployment strategy where a new version of your application receives a small percentage of traffic while the stable version handles the rest. Traffic weight is gradually increased as the canary passes health and performance checks. If the canary fails, traffic is routed back to the stable version automatically.
Control Plane: The centralized management layer of Odysseus, hosted and operated by Delta Telematics. The control plane handles scheduling, state coordination, secret management, metrics collection, and the dashboard. Users interact with the control plane through the dashboard.
Dashboard: The web-based user interface for managing your Odysseus deployments, nodes, secrets, and settings. Accessible at your tenant's Odysseus URL after authentication.
Deployment: A declared workload running on the Odysseus platform. A deployment specifies a container image, resource requirements, replica count, health checks, and configuration. The platform ensures the deployment's desired state is maintained across your nodes.
Enrollment Token: A time-limited, single-use or multi-use token used to register a new node with the Odysseus control plane. Generated from the dashboard. Once a node is enrolled, the token is no longer needed. See also Agent.
Health Check: A periodic probe that verifies a container is functioning correctly. Health checks can be HTTP requests, TCP connections, or command executions. Containers that fail health checks are restarted automatically, and unhealthy replicas are removed from load balancer rotation.
Incident: An automatically detected operational event that requires attention — such as a deployment entering a restart loop, a node going offline, or a critical CVE discovered in a running image. Incidents appear in the dashboard and can trigger notifications and auto-remediation actions.
Node: A server (physical or virtual) that runs the Odysseus agent and Docker. Nodes provide the compute resources where your containers run. Each node connects to the control plane via an encrypted WireGuard tunnel.
Orchestration: The automated management of container deployment, scaling, networking, and lifecycle across multiple nodes. Odysseus is a container orchestration platform — it decides where to place containers, how many replicas to run, and how to route traffic to them.
Reconciliation: The continuous process of comparing the actual state of your deployments against the desired state and taking corrective action. If a container crashes, a node goes offline, or replicas are missing, the reconciliation loop detects the drift and restores the desired state automatically.
Replica: A single running instance of a deployment's container. A deployment with replicas: 3 runs three identical containers, potentially distributed across multiple nodes for availability.
Rollback: Reverting a deployment to a previous version. Rollbacks can be triggered manually or automatically (e.g., when a canary deployment fails its health checks). The platform maintains deployment history to enable instant rollback to any previous version.
Scaling (Auto / Manual): Manual scaling: Changing the replica count of a deployment directly through the dashboard. Autoscaling: The platform automatically adjusts replica count based on metrics (CPU, memory, or custom metrics) and configured thresholds. See also Prometheus.
Tenant: An isolated organizational unit within Odysseus. Each tenant has its own users, roles, nodes, deployments, secrets, and configuration. Tenants are completely isolated from each other — a tenant cannot see or access another tenant's resources. See also Tenant Isolation.

Security & Access

Audit Log

A tamper-resistant record of all actions performed within a tenant — deployments, configuration changes, user logins, RBAC modifications, and secret access. Audit logs are available in the dashboard and can be exported for compliance purposes.

CVE

Common Vulnerabilities and Exposures. A standardized identifier for publicly known security vulnerabilities (e.g., CVE-2024-1234). Odysseus scans container images for known CVEs using Trivy and Grype. See also CVSS.

CVSS

Common Vulnerability Scoring System. A numerical score (0.0 to 10.0) that rates the severity of a CVE. Odysseus uses CVSS scores to classify vulnerabilities as Critical (9.0-10.0), High (7.0-8.9), Medium (4.0-6.9), or Low (0.1-3.9). Security policies can gate deployments based on CVSS severity.

JWT

JSON Web Token. A signed token used for authentication with the Odysseus platform. JWTs are issued when you log in and expire after a configurable period. The dashboard handles JWT lifecycle automatically.

mTLS

Mutual Transport Layer Security. A security protocol where both the client and server authenticate each other using certificates. Odysseus uses mTLS for agent-to-control-plane communication, ensuring that only authorized agents can connect to the platform.

RBAC

Role-Based Access Control. A permission model where users are assigned roles, and each role defines a set of allowed actions. Odysseus provides four built-in roles: Admin, Operator, Developer, and Read-only. See also Role.

Role

A named set of permissions assigned to a user within a tenant. Odysseus provides four roles:

Admin: Full access including user management, RBAC configuration, and tenant settings.
Operator: Manage nodes, deployments, scaling, scans, and configurations.
Developer: Create and update deployments, manage secrets, view logs and metrics.
Read-only: View all resources without making changes.

Row-Level Security

A data isolation mechanism that ensures database queries return only data belonging to the requesting tenant. Every data record is tagged with a tenant identifier, and all queries are automatically filtered. This prevents data leakage between tenants even at the storage layer.

Security Policy

A configurable rule set that governs security requirements for deployments within a tenant. Policies can enforce CVE severity thresholds (e.g., block deployments with Critical vulnerabilities), require image scanning before deployment, and mandate specific resource limits.

Tenant Isolation

The principle and set of mechanisms ensuring that tenants are completely separated. Isolation is enforced at every layer: network (WireGuard tunnels), compute (separate containers), storage (row-level security), secrets (Vault namespaces), and API (JWT tenant claims). No tenant can access, view, or affect another tenant's resources.

Vault

HashiCorp Vault. The secrets management system used by Odysseus to securely store, access, and rotate credentials. Secrets are encrypted at rest and injected into containers via tmpfs mounts at runtime. See the tmpfs entry for details on the injection mechanism.

WireGuard

A modern, high-performance VPN protocol used by Odysseus for encrypted communication between the control plane and agents. WireGuard tunnels are established automatically during node enrollment and carry all management traffic. See the VPN abbreviation.

Infrastructure

Consul: HashiCorp Consul. A distributed service discovery and key-value store used by the Odysseus control plane for node registry, deployment state coordination, and configuration distribution. Consul is managed by the platform and transparent to users.
Docker: The container runtime installed on each node. Docker is the only prerequisite on your infrastructure. The Odysseus agent uses the Docker API to pull images, create and manage containers, enforce resource limits, and collect metrics. Minimum version: 24.0.
Grype: An open-source container vulnerability scanner developed by Anchore. Odysseus uses Grype as one of two scanning backends (alongside Trivy) for CVE detection. Results from both scanners are merged for comprehensive coverage.
Prometheus: An open-source monitoring and metrics system. Odysseus uses Prometheus to collect time-series metrics from containers and nodes. These metrics power dashboard visualizations, autoscaling decisions, and alerting rules.
tmpfs: A temporary filesystem stored in memory (RAM) rather than on disk. Odysseus mounts secrets into containers via tmpfs, ensuring that sensitive data is never written to persistent storage on the node and disappears when the container stops.
Traefik: A modern reverse proxy and load balancer. Odysseus uses Traefik for ingress routing, automatic HTTPS certificate management (via Let's Encrypt), load balancing across replicas, and weighted traffic splitting for canary deployments.
Trivy: An open-source container vulnerability scanner developed by Aqua Security. Odysseus uses Trivy as one of two scanning backends (alongside Grype) for CVE detection. Results from both scanners are merged for comprehensive coverage.
Volume: Persistent storage attached to a container. Volumes survive container restarts and redeployments. In Odysseus, volumes are defined in deployment manifests and managed by Docker on the host node.
x-odysseus: A metadata prefix used in deployment manifests for Odysseus-specific configuration fields. Fields prefixed with x-odysseus are processed by the platform and ignored by standard Docker tooling, allowing manifests to be compatible with both.

SRE & Operations

Auto-Remediation: Automated corrective action taken by the platform in response to a detected incident. Examples include restarting a crashed container, rescheduling workloads away from an unhealthy node, and rolling back a failed canary deployment. Auto-remediation actions are logged in the audit log.
Incident Detection: The automated identification of operational problems based on metrics, health checks, and state changes. The platform continuously monitors for conditions such as restart loops, resource exhaustion, node failures, and failed deployments.
OOM Kill: Out of Memory Kill. When a container exceeds its memory limit, the Linux kernel terminates it to protect the host. OOM kills appear in container events and are a common cause of restart loops. The solution is to increase the memory limit or reduce the application's memory consumption.
Restart Loop: A condition where a container repeatedly crashes and is restarted, typically caused by a failing health check, missing dependency, or resource exhaustion. Odysseus detects restart loops and can take corrective action such as alerting, scaling, or rolling back.
SRE: Site Reliability Engineering. A discipline that applies software engineering practices to operations problems. Odysseus embeds SRE principles through automated monitoring, incident detection, self-healing reconciliation, and error budgets.
Self-Healing: The ability of the platform to automatically detect and recover from failures without human intervention. Self-healing includes container restart, workload rescheduling, node failover, and canary rollback. See also Reconciliation and Auto-Remediation.

Abbreviations

Abbreviation	Full Form	Description
API	Application Programming Interface	A set of defined methods for communication between software components.
CVE	Common Vulnerabilities and Exposures	A standardized catalog of publicly known security vulnerabilities. See CVE definition.
CVSS	Common Vulnerability Scoring System	A severity rating scale for CVEs, ranging from 0.0 to 10.0. See CVSS definition.
GDPR	General Data Protection Regulation	European Union data privacy regulation. Odysseus supports GDPR compliance through tenant isolation, audit logging, and data residency controls.
JWT	JSON Web Token	A signed authentication token used for API access. See JWT definition.
MCP	Model Context Protocol	A protocol that enables AI models to interact with external tools and data sources. Athena uses MCP to connect Claude AI to 61 Odysseus orchestration tools.
mTLS	Mutual Transport Layer Security	Two-way certificate authentication between client and server. See mTLS definition.
OOM	Out of Memory	A condition where a process exceeds available memory, triggering a kernel kill. See OOM Kill definition.
PIPEDA	Personal Information Protection and Electronic Documents Act	Canadian federal privacy law governing how private-sector organizations collect, use, and disclose personal information. Odysseus supports PIPEDA compliance through data isolation and audit controls.
RBAC	Role-Based Access Control	Permission model based on user roles. See RBAC definition.
SLA	Service Level Agreement	A formal commitment defining expected uptime, performance, and support response times. Odysseus SLAs are defined per pricing tier.
SOC 2	System and Organization Controls 2	An auditing framework for service organizations covering security, availability, processing integrity, confidentiality, and privacy. Odysseus's security architecture supports SOC 2 compliance requirements.
SRE	Site Reliability Engineering	An operations discipline focused on reliability through automation. See SRE definition.
TLS	Transport Layer Security	A cryptographic protocol for secure communication over networks. All Odysseus traffic (API, dashboard, agent communication) is encrypted with TLS.
VPN	Virtual Private Network	An encrypted network tunnel between two endpoints. Odysseus uses WireGuard VPN tunnels for secure control-plane-to-agent communication.