Guides on Deevnet Terraform Provider

Install

Mon, 01 Jan 0001 00:00:00 +0000

Install the provider #

The provider is not in the public Terraform Registry. It goes into Terraform’s implicit local mirror, and terraform init finds it there:

~/.terraform.d/plugins/registry.terraform.io/deevnet/deevnet/<version>/<os>_<arch>/

The source address is deevnet/deevnet all the same, so a tenant’s required_providers block reads as it would for a registry provider.

At a Deevnet site #

On the tenant developer network, the site’s download server is the fastest route. It also installs the grafana provider, for dashboards as code.

What a Tenant Holds

Mon, 01 Jan 0001 00:00:00 +0000

What a tenant holds #

A tenant holds one credential: its Deevnet token. Nothing else about the substrate reaches the tenant: no hypervisor credential, no vault access.

Enrollment #

The first apply trades a single-use enrollment token for the tenant’s own token. The substrate admits a tenant name and issues the enrollment token, delivered encrypted into the tenant’s repository. The first terraform apply spends it and receives the tenant’s own token, which every later call uses ( ADR-0015).

Restore Instead of Recreate

Mon, 01 Jan 0001 00:00:00 +0000

Restore instead of recreate #

When the API no longer holds an object, the provider restores it from state instead of creating a new one. The usual advice for a remote object that is gone is to drop it from state and let the next plan create another. For the resources that carry secrets or addressing that would be a loss: a new tenant would mean new keys, and a new workload would mean a new address.