Skip to main content

Glossary

This glossary defines the key terms and concepts specific to the Infrastream v2 platform.

A​

apiVersion : The schema version for a manifest file. For all current Infrastream manifests, this value should be lowops.manifests.v1.

ApplicationSet : A manifest that groups multiple Application or ExternalApplication manifests into a single releaseable unit. All applications within an ApplicationSet are promoted through the ReleaseTrack stages together as a single atomic bundle. Owned by Product or Release Managers.

B​

BuildDefinition : A manifest that defines how to build a container image from source code. Specifies the project type (e.g., Go, Java, Node.js), containerization settings, and build parameters. The platform uses this to auto-generate CI workflows (GitHub Actions) for building, testing, and publishing the application.

C​

Conventional Commits : A standardized commit message format (e.g., feat:, fix:, docs:) used by the platform's automatic versioning system. The commit prefix determines the version bump type: feat → minor, fix → patch, feat! → major.

Core Project : A special, singleton Google Cloud project within an Infrastream organization that acts as the central hub for shared services. It hosts the core Infrastream Engine execution environment, the Spanner State Ledger, manages the Shared VPC network hub, and contains platform-level resources like central Artifact Registries. It is opaque to end-users to allow for rapid rehydration and disaster recovery.

D​

Declarative Configuration : The core philosophy of Infrastream, where users define the desired state of their infrastructure in Manifests (the "what"), rather than writing procedural scripts to achieve that state (the "how").

DeploymentConfig : A manifest that provides environment-specific runtime settings for an Application or ExternalApplication. Contains the version to deploy, environment variables, scaling parameters, and health check configuration. The metadata.name must match the parent application's name.

E​

Engine (The Engine) : The core, high-performance execution runtime that reads Manifests, resolves dependencies in memory, and translates them directly into Cloud Provider API calls. It replaces legacy tools like Terraform.

ExternalApplication : A manifest that defines an application whose container image is built and stored externally (outside the platform's CI system). Unlike Application, which references a BuildDefinition, an ExternalApplication references an ExternalRegistry for its image source.

H​

High Privilege Access Management (HPAM) : A core governance benefit of Infrastream. The platform replaces traditional, manual, and often opaque HPAM systems with a declarative, GitOps-based workflow. All requests for privileged access (e.g., adding a project administrator) are handled via version-controlled pull requests, which are subject to a formal, auditable approval process driven by CODEOWNERS rules.

J​

JIT Graph Resolution : Just-In-Time resolution. The process where the Engine parses all user Manifests, builds a directed acyclic graph (DAG) in memory using gonum/graph, and uses Promises to pass output variables (like an IP address or a generated ID) directly from one executing resource to another in a single pass.

M​

Manifest : A declarative YAML file that represents the desired state of a resource or a logical component within the Infrastream platform. Manifests are the primary interface for all platform users.

Manifest Driven Secure Execution (MDSE) : The official term for the Infrastream workflow. It describes the end-to-end process of users defining their desired state in Manifests, which then drives a secure and automated execution pipeline to realize that state in the cloud.

metadata Block : A top-level block in every manifest that defines the resource's identity and its location within the organizational hierarchy. It contains fields like name and the names of parent manifests (e.g., project, organization). The fields use kebab-case.

MetaGroup : A virtual logic node inside the execution graph. MetaGroups enforce strict execution boundaries (transparent gating) by ensuring that an entire group of resources (like an Organizational Unit) finishes provisioning before any of its children (like Projects) begin.

P​

PreRelease : A deployment track that validates individual application changes in isolation. Triggered automatically when a CI build publishes a new version. PreRelease deployments are per-application (not bundled) and deploy through the preReleaseStages defined in the ReleaseTrack.

Promises / Inputs : The strongly-typed concurrency mechanism used by the Engine to manage dependencies. When a downstream resource needs data from an upstream resource that hasn't been created yet, the Engine injects a Promise. The downstream resource waits for the Promise to resolve before executing.

R​

Release : A deployment track that promotes a complete, bundled set of applications through the releaseStages defined in the ReleaseTrack. Initiated manually by a Release Manager. All applications in the ApplicationSet are version-locked using immutable Release Candidate tags.

Release Candidate (RC) : An immutable container tag created in Artifact Registry when a Release is initiated. The RC tag points to a specific image digest, ensuring that every environment in the pipeline deploys the exact same binary. Format: <appSet>-<bundle>-rc.<N> (e.g., infrastream-cloud-2026.11-rc.0).

ReleaseTrack : A manifest that defines the complete multi-stage deployment and promotion strategy for an ApplicationSet. Specifies preReleaseStages, releaseStages, and optional hotfixStages, each listing the environments that code must pass through. Owned by the Platform/SRE team.

Runner : A Go struct that implements the plugin.Runnable interface. A Runner encapsulates the complete lifecycle (Plan, Create, Update, Delete) of a specific physical cloud resource and handles the direct API interactions with the cloud provider.

S​

Shared VPC : The networking model used by Infrastream. The Core Project hosts the central VPC network (the "hub"), and all other service projects (the "spokes") are granted access to dedicated subnets within this central VPC. This allows for centralized network control, security policy enforcement, and traffic auditing.

Spanner State Ledger : The Google Cloud Spanner database used by Infrastream to store infrastructure state. Unlike traditional flat state files (terraform.tfstate), the Spanner Ledger is an append-only, temporally-aware database that records every change with millisecond precision, enabling immediate rollbacks and preventing write-hotspotting at scale.

spec Block : A top-level block in a manifest that contains the user-configurable settings for the resource. The fields within this block use camelCase.

StorableNode : The core data contract for any element in the execution graph (Manifests, Runners, MetaGroups) that can be serialized and persisted to the Spanner State Ledger.

T​

Trunk-Based Development : A branching strategy where all development merges directly into main (the "trunk"), with long-lived release branches that snapshot a tag for post-release maintenance. Infrastream supports this as one of three branching strategies (GITHUB_FLOW, GIT_FLOW, TRUNK_BASED), sitting as a middle-ground between GitHub Flow and Git Flow.