Dashboard › institutional-transition-lab › Distillation
e0b464f1-e5a3-431b-9245-0cce589c27e2["lore_tm_v1_W6ujz6un-5HV1mWrY3Vp9bYmPG81F-nXbs6IkkgJlAU","lore_tm_v1_T5qk0B4ihW0x6mSKz1_TCpvKVirV0pGBc7Z0-H1C2Mg","lore_tm_v1_7UMndNm0cT508eCtMhy5Hjk9460l4bZm5jkeeD22fqE","lore_tm_v1_Ns0mEVBigQ_vZeYa0zF3PKdZzZlQLEWYEFAJth3X7CI"]
Date: Sep 8, 2026
opentofu-github-pr-3473, titled RFC: databricks backend, proposes an OpenTofu Databricks state backend using Unity Catalog volumes for state storage and either Databricks Lakebase (recommended PostgreSQL-compatible locking) or Delta Lake tables (fallback locking); the stated goals are reduced IaC friction for data practitioners and unified governance over state files.opentofu-github-pr-3473 identifies 4 motivations: 1. lack of cloud-storage backends discourages IaC adoption; 2. duplicate access-control systems across cloud IAM and Unity Catalog RBAC/ABAC; 3. separate audit trails requiring manual correlation; 4. increased operational complexity when managing infrastructure and data.opentofu-github-pr-3473 identifies 4 use cases in order: 1. unified governance with one compliance audit trail; 2. Databricks-native infrastructure; 3. consistent multi-workspace state management; 4. enterprise compliance in regulated industries.host, catalog, schema, volume, and key as required settings; example values are https://workspace.cloud.databricks.com, terraform_state, production, infrastructure, and terraform.tfstate. Optional settings include lock_backend = "lakebase" (or "delta"), lock_timeout = "10m", and token = "${env:DATABRICKS_TOKEN}"; omitted authentication uses the Databricks SDK auth chain./Volumes/{catalog}/{schema}/{volume}/{key}, accessed through the Databricks Files API/SDK, using underlying cloud-storage versioning and cloud-provider encryption with optional client-side encryption.opentofu-github-pr-3473: 1. Lakebase — recommended, ACID transactions, sub-50-ms acquisition, but higher managed-instance compute cost; 2. Delta Lake — fallback using primary-key constraints, ACID guarantees, approximately 1-second stated latency, potentially requires a higher-cost SQL Warehouse, but delta-kernel-rs might provide very cheap access. The comparison table separately gives approximately 50ms for Lakebase and approximately 2 seconds for Delta Lake.~/.databrickscfg.opentofu-github-pr-3473: 1. run databricks catalogs create terraform_state, databricks schemas create production terraform_state, and databricks volumes create terraform_state production \ infrastructure MANAGED; 2. update backend configuration; 3. run tofu init -migrate-state.internal/backend/remote-state/databricks; Backend contains client *databricks.WorkspaceClient, catalog string, schema string, volume string, and lockBackend string, with methods StateMgr(workspace string) (statemgr.Full, error), Workspaces() ([]string, error), and DeleteWorkspace(name string, force bool) error.>80% coverage, integration tests against a real Unity Catalog instance, stress tests for concurrent operations and lock contention, and performance tests against latency targets. p95 targets are State GET < 3 seconds, State PUT < 5 seconds, Lakebase lock acquisition < 50ms, and Delta lock acquisition < 2 seconds.429 rate limiting, and no retry for authentication failures.opentofu-github-pr-3473: whether Lakebase/Postgres should be required or optional with Delta fallback; whether lock tables should be auto-created; and whether the backend should be a plugin or core backend. Future considerations are state caching, native Databricks monitoring, and Iceberg lock-table support.VARIANT column; 3. S3/Azure/GCS plus Unity Catalog metadata — proven reliability and lower cost, but does not unify governance.opentofu-github-pr-3473: S3 backend with DynamoDB or native S3 locking, Azure backend with Blob leases, GCS backend with consistency preconditions, and PostgreSQL backend with database-based state and locking; the RFC reports finding no existing Databricks backend in the Terraform/OpenTofu ecosystems.opentofu-github-pr-3473 metadata: 1 changed file, open and unmerged, not a draft; base SHA a961f737b7938f51a52202fdc6de5a2917b3c250, head SHA 3679fe6fa8e9cbcacbd5a0904f937a41151aa16a, and prospective merge commit SHA 799d04a68409e921b5402033488017b304c99797.opentofu-github-pr-3473 attested to reading CONTRIBUTING.md, not using an AI coding assistant, writing or attributing all code, and not consulting Terraform source.opentofu-github-pr-4018 describes the TSC-requested in-band warning during OpenTofu v1.13 before official support ends for 32-bit 386 and arm CPU architectures. The compromise marks only official release packages and emits the warning only during tofu init, avoiding repeated warnings during every tofu plan or tofu apply and avoiding irrelevant warnings in third-party builds.opentofu-github-pr-4018 makes official-build detection opt-in through BUILD_OPENTOFU_OFFICIAL: '1' in the official GitHub Actions release workflow, rather than .goreleaser.yml, because third-party distributors are considered less likely to reuse the project’s GitHub Actions workflow accidentally.opentofu-github-pr-4018 defines global officialBuild string; IsOfficialBuild() returns officialBuild != "" and is activated by linker argument -X 'github.com/opentofu/opentofu/version.officialBuild=1'. Test helper WithFakedOfficialBuild(official bool, f func()) temporarily sets officialBuild to "1" or "", restores the old value with defer, and must not be used in parallel tests because it mutates global state.opentofu-github-pr-4018 metadata: 7 changed files, merged at 2026-08-11T20:53:09Z; base SHA 34e03c9fc38eb1b290e7db57537e42506aca1c28, head SHA 38a52bc2038c180c9ca1859c8ff2e2fb24a6326f, and merge commit 82676082728b0dc5fb14552f2a663850d7422817.opentofu-github-pr-2953 moved governance material and references into the new opentofu/org repository: the full local charter was replaced by [opentofu/org/CHARTER.md](https://github.com/opentofu/org/blob/main/CHARTER.md), and the full local governance document was replaced by [opentofu/org/GOVERNANCE.md](https://github.com/opentofu/org/blob/main/GOVERNANCE.md).opentofu-github-pr-2953 specified TSC-member addition by nomination from an existing TSC member, demonstrated significant contribution, and a two-thirds supermajority; voluntary resignation without a vote; inactivity removal after 3 consecutive months by majority vote with at least 14 days’ notice; removal for cause by two-thirds excluding the affected member after an opportunity to respond; and affiliation-related rebalancing by consensus or vote.MAINTAINERS.md; and the TSC retains override authority but should exercise restraint.opentofu-github-pr-2953 metadata: 43 changed files, merged at 2025-06-25T17:50:10Z; base SHA 3c170157023ac1290c89567ce432c35aa185099a, head SHA 5f5705b8947cd62834733e6c20635d8d13a616dd, and merge commit 75bf1c2f65ad4baabd51a5e88873f805f5b2a1c7. All contribution, Go, and website/documentation checklist boxes shown in the body were unchecked.opentofu-github-pr-990 records the 2023-12-05 TSC meeting attended by Igor Savchenko (@DiscyDel, link spelled @DicsyDel), Marcin Wyszynski (@marcinwyszynski), Roger Simms (@allofthesepeople), and Roni Frantchi (@roni-frantchi); absent were Yevgeniy Brikman (@brikis98) and Omry Hary (@omry-hay).opentofu-github-pr-990: 1. quick unanimous approval to change the default registry namespace to opentofu; 2. registry UI/docs were not prioritized that quarter, with Roni voting yes and everyone else no, but the TSC invited RFCs for UI, third-party registry, or CLI-based approaches and would re-examine them; 3. client-side state encryption RFC #874 was unanimously accepted and elevated as a highly requested differentiating intermediate solution despite Marcin preferring the long-term goal of not storing secrets in state; 4. OpenTofu support in the VS Code Language Server issue #970 was unanimously not prioritized for core-team follow-up, though an RFC could be accepted; 5. gunzipbase64 PR #799 was unanimously accepted as the inverse of an existing function while acknowledging a longer-term preference for custom-function extension/reuse; 6. filesystem-state-backend performance PR #579 was unanimously accepted.opentofu-github-pr-990: Roni favored priority because the Homebrew-like registry lacked a convenient supported-package UI and sending users to HTF undermined OpenTofu branding; Igor opposed core-team focus and disclosed work on library.tf, envisioned as a non-associated Terraform/OpenTofu/other-IaC registry; Roger preferred UI/docs through the CLI; Marcin had no strong opinion and considered it non-priority.opentofu-github-pr-990 metadata: 1 changed file, merged at 2023-12-11T11:52:31Z; base SHA 5fc6ba240dbbe6ecc3643040150686f88e223583, head SHA 7db41d4cfbbd4c54cfd9db70c3d58282a0118bb3, and merge commit 6b864ef262d6b924d94a61a0e1e29ff27b834a02.opentofu-github-pr-2953: Luna A and Luna B both returned schema-valid abstain/reorganization codings with no power_changes, confidence 0.70 and 0.58, dates announced_on: 2025-06-24 and effective_on: 2025-06-25, citing the truncated 43-file patch and lack of proven rights change; Terra also returned schema-valid abstain, but with event_kind: null, announced_on: null, effective_on: null, body_patch_relation: unclear, and confidence 0.42.opentofu-github-pr-2959: all three models returned schema-valid abstain with event_kind: control_rights, no power_changes, and body_patch_relation: unclear because the implementing CODEOWNERS patch was absent. Luna A confidence was 0.72, Luna B 0.86, and Terra 0.45; all used announced_on: 2025-06-25 and left effective_on null.opentofu-github-pr-3473: Luna A and Luna B returned schema-valid control_event/product codings with no power_changes, announced_on: 2025-11-05, effective_on: null, body_patch_relation: consistent, and confidence 0.97 and 0.98; no Terra advisory was run.opentofu-github-pr-3559 disagreed: Luna A classified no_event with event_kind: null, no dates, body_patch_relation: unclear, confidence 0.70; Luna B classified a control_event/product, effective 2025-12-09, confidence 0.78; Terra classified a control_event/product, announced 2025-12-09 but not effective, body_patch_relation: body_only, confidence 0.68. All had no power_changes and noted that the support-policy patch terms were absent.opentofu-github-pr-4018: Luna A and B treated the merged official-build detection as a schema-valid control_event/product, announced 2026-04-09, effective 2026-08-11, with confidence 0.90 and 0.84; Luna A used body_patch_relation: patch_supersedes_body, while Luna B used consistent. Both noted that the supplied patch showed official-build detection but not warning-generation code.opentofu-github-pr-4018 instead classified proposal_only/control_rights, announced 2026-04-09, no effective date, body_patch_relation: consistent, confidence 0.84, with one proposed removal edge: actor OpenTofu project, right_kind: release, target 32-bit CPU architectures, scope official release packages, direction removed, status proposed; evidence cited “ending official support for 32-bit CPU architectures” and the statement that maintainers had not yet discussed it and might choose something different.opentofu-github-pr-727: Luna A and B both classified an effective_institutional_change/license, announced 2023-10-14, effective 2023-10-15, body_patch_relation: consistent, confidence 0.98, with an effective added license edge from OpenTofu to compare-release-versions.sh, grounded in the body and # SPDX-License-Identifier: MPL-2.0; Terra instead classified no_event, with no dates, no event kind or edges, confidence 0.99.opentofu-github-pr-823: all three classified a schema-valid control_event/strategy with no power_changes. Luna A used announcement date 2023-11-05, body_patch_relation: patch_only, confidence 0.94; Luna B used 2023-11-02, patch_only, confidence 0.95; Terra left the announcement date null, used consistent, confidence 0.90, and emphasized that the TSC strategy decisions did not establish an organizational-rights change.opentofu-github-pr-990: all three classified a schema-valid control_event with no power_changes, announced_on: 2023-12-10, effective_on: null, and body_patch_relation: consistent. Luna A used broad event_kind: strategy and confidence 0.94; Luna B and Terra focused on the default registry namespace with event_kind: product, confidence 0.88 and 0.91, noting that the summary documents a decision but does not show implementation.terraform-github-issue-22468: both Luna runs returned schema-valid no_event, body_patch_relation: not_applicable, no event kind, dates, affected scope, or power_changes; confidence was 0.96 and 0.98. No Terra advisory was run.terraform-github-issue-34139: Luna A classified control_event/product for Terraform Azure access-package-policy deployment with confidence 0.98; Luna B and Terra classified no_event with confidence 0.99. All used body_patch_relation: not_applicable, no dates, and no power_changes.