Skip to content
RunningLake
Company Console ↗ Request early access
Contents: Reference

BUILDING Parts of this page describe what is not built yet, and each says so.

Terraform

RunningLake is meant to be managed the same way from the console, the API, the rl command line and Terraform. The Terraform provider is not published yet.

What is true today

No Terraform provider is published yet. One is being built. Its first version reads which projects an API token can reach, and manages the Layer, Schema, Volume, View, Grant, Table and SpendCap documents of one environment, as a single change set that it never approves itself: on a direct environment the change is committed, except a Grant, or a change to what a view reads or says, which the control plane always holds for approval, and on one that follows review every change is proposed. A member approves a proposal in the control plane. A Table is shared by every environment of the project, so removing one, or destroying the resource that holds it, drops it in all of them: the provider refuses that unless allow_destroy is set to true. A SpendCap is the project’s one work cap: lowering it takes effect at the next sync, unless it would sit below the month’s work so far, which is held too, but raising it, relaxing it, changing its currency or period, or removing it is held by the control plane until an owner or admin confirms it in the console, which Terraform cannot do, so such an apply succeeds and says the change is held while the cap in force stays as it was. A restricted layer can be managed with the Grant that names who sees it, in the same configuration; a token must be covered by a Grant on every restricted layer it manages, because a token the Grants do not name cannot see the layer it made, and the provider refuses an apply that would write to it. What a managed document holds is kept in Terraform state, where anyone who can read the state can read it, so keep state in an encrypted backend. There is nothing to install: terraform init cannot fetch one, and its resources are not documented until it is published.

What exists is one path that the console, the API and rl share. A change to your configuration is planned, then submitted as one change set, reviewed when the environment asks for review, and applied from your repository. A provider would be one more client of that path, not a different one, and it would never approve anything itself.

The Terraform that exists today is the data plane module for AWS, which is applied in your own cloud account to build a plane. It is not published for download, its setup guide is not published yet, and it is not a way to manage RunningLake itself.

What to use instead

Keep your configuration as files in your repository and use rl. rl diff checks the files offline and sends nothing. rl plan shows what would change in an environment, as one change set. rl deploy plans and then submits it; on an environment that asks for review, it waits there for someone who may approve it. The command line reference has every flag and exit code.

What will be console-only

A few acts are decided to be console-only: they will be done in the console, by an owner or admin who has just confirmed it is them, because a token held by a pipeline must not be able to do them. Terraform will not do them until the provider has a safe way to. Each one below says where it stands.

  • Service principals, the identities a machine uses to start runs, can be made. Creating one, widening what it may do, enabling or deleting one, and minting or rotating its secrets are console-only: each needs an owner or admin who confirmed it is them within the last five minutes, which an API token never has. Disabling one, revoking a secret and narrowing what a principal may do work from the console and the API. A principal can be told which repository's CI jobs to trust, and a policy can be tested against decoded claims. Adding a trust policy is console-only too; deleting one, which revokes every token issued under it, works from the console and the API. A CI job exchanges its identity token for a short-lived token through the API alone, because the job has no sign-in to give; what that token may reach is decided by the trust policy a signed-in owner or admin added. Creating a webhook endpoint for a principal, and rotating its signing secret, are console-only too; disabling one, or stopping an older signing secret, works from the console and the API. A sender cannot call an endpoint yet.
  • Raising a model budget is console-only. So is setting a team organisation's first monthly cap, which is the act that lets model calls begin, so a CI job cannot raise its own spending limit. Lowering one, down to nothing, works from the console and the API, from a session or a token, so a model budget can always be cut off. Nothing makes a model call yet, so every budget reads zero spent.
  • Widening the organisation-wide limit on what AI may do is console-only. Narrowing it works from anywhere; a widening needs a console session whose person confirmed it is them within five minutes and a second owner or admin to approve it.
  • The business glossary, its terms and the domains that own them, are built. The control plane keeps them, not your repository, and Terraform does not write them.
  • Registering your own encryption key is built in the console and is not switched on yet. When it is, you will register it in the console, and neither rl nor Terraform will do it.
  • Delivering your audit log to a bucket in your own account is not switched on yet. When it is, you will turn it on in the console, and the provider will not manage it at first.

When one of these is built, this page changes to say who may do it and from where. Until then, do not plan around any of them.