tfmodules/dbaas/README.md

dbaas module

Provisions a managed database and generates the consumer access credentials. One submodule per cloud provider, selected by the provisioner from the cloud provider of the provisioning request:

• ovh: an OVHcloud Managed PostgreSQL cluster (ovh_cloud_project_database) with one initial database and one application user, public by default, optionally attached to an existing vRack private network

Contract

Variable	Description
deployment_id	Unique deployment identifier, used in resource names
cloud_account	Cloud account (environment) name, second segment of the Vault credentials path, filled by the provisioner from the cloudAccount header via the {CLOUD_ACCOUNT} placeholder
requester_unique_id	Requester unique id, third segment of the Vault credentials path, filled by the provisioner from the requesterUniqueId header via the {REQUESTER_UNIQUE_ID} placeholder
username	Database user name, defaults to simpl_app_user, last segment of the Vault credentials path
name_prefix	Prefix for resource names, defaults to simpl
region	OVH macro region for the database nodes (for example SBG, GRA, DE), not the datacenter suffixed region used for instances
project_id	Optional override of the OVH project; by default the provider resolves it from the OVH_CLOUD_PROJECT_SERVICE variable of the runner environment, which the provisioner derives from the OVH_PROJECT_ID key of the cloud account configuration
engine_version, plan, flavor	PostgreSQL version and sizing of the managed offer
database_name	Name of the initial application database, defaults to simpl_app_db
private_network_id, private_subnet_id	Optional vRack attachment, both null for a public deployment
allowed_ips	CIDR blocks allowed to reach a public deployment

Cloud credentials are never module inputs, they reach the provider from the runner environment.

Credentials, following the existing Vault contract: the OVHcloud managed database password is always generated server side (it cannot be set to an arbitrary value), read from the computed attribute of the user resource and written by the module to Vault: secret/{provider}/{cloud_account}/{requester_unique_id}/{username} with the keys username, password, host, port, database and a ready to use connection uri. No secret material is ever part of an output or of the user body. There is no admin sibling entry: day 2 credential renewal follows the same Terraform rotation flow as the other catalog modules, making OVHcloud regenerate the password and republishing the Vault entry in the same apply (the rotation marker input is added by the credential renewal ticket). The Vault provider configuration is generated by the provisioner next to the deployment script, and it authenticates through the Vault Kubernetes auth method with the service account of the Terraform runner, against a Vault role configured at installation time.

Outputs:

Output	Description
database_endpoint	Service endpoint (hostname) of the PostgreSQL instance
database_port	Port of the PostgreSQL instance
database_name	Name of the initial database
database_username	Database user name
database_cluster_id	Id of the managed database cluster
database_user_id	Id of the database user
credentials_ref	Vault path of the consumer credentials entry

Usage

The provisioner rewrites the {DBAAS_SOURCE} placeholder to this module's location for the cloud provider of the request (each catalog module has a placeholder derived from its directory name), so a deployment script only declares:

module "dbaas" {
  source              = "{DBAAS_SOURCE}"
  deployment_id       = "{UUID}"
  region              = "<region>"
  cloud_account       = "{CLOUD_ACCOUNT}"
  requester_unique_id = "{REQUESTER_UNIQUE_ID}"

  plan   = "essential"
  flavor = "db1-4"
}

output "database_endpoint" {
  value = module.dbaas.database_endpoint
}

output "credentials_ref" {
  value = module.dbaas.credentials_ref
}

The root file must re-export the module outputs it wants published to the deployment outputs.