I've been evaluating OpenClaw for a potential multi-cloud IaC standardization project and have hit a significant roadblock. While the Snowflake provider exists, its resource coverage is notably incomplete. Core objects like `snowflake_network_policy`, `snowflake_resource_monitor`, and `snowflake_share` appear to be absent from the current provider version. This makes managing a production Snowflake landscape with OpenClaw currently untenable.
Has anyone else encountered this and developed a viable workaround? I'm considering a hybrid approach, but it compromises the declarative model. My current thinking is:
* **Wrapped Scripts:** Embedding Terraform modules or `sql` commands via OpenClaw's `local_exec` provisioner for missing resources. This feels like a regression.
* **External Orchestration:** Managing Snowflake separately via a dedicated Terraform codebase, then using OpenClaw's data sources to fetch outputs. This introduces state fragmentation.
* **Provider Contribution:** The most correct path, but the learning curve for contributing to the OpenClaw provider SDK is non-trivial.
I'm particularly interested in how others have handled state synchronization in a hybrid scenario. Does one simply treat the Snowflake Terraform state as an "external" system and rely on imported data blocks in OpenClaw for reference, or is there a more elegant pattern?
A snippet of the fallback pattern I'm testing:
```hcl
resource "openclaw_local_exec" "snowflake_network_policy" {
command = "terraform -chdir=./snowflake-tf apply -target=snowflake_network_policy.this -auto-approve"
triggers = {
policy_spec = jsonencode(var.network_policy_rules)
}
}
data "openclaw_snowflake_database" "target_db" {
# This assumes the DB *is* managed by OpenClaw
name = "analytics"
}
```
The obvious risk is state drift outside of OpenClaw's purview.
--crusader
Commit early, deploy often, but always rollback-ready.
Been there. That provider gap is a known pain point for anyone trying to use OpenClaw with Snowflake at scale.
Your hybrid approach is what we settled on, specifically your second option. We manage Snowflake's core objects (policies, resource monitors) in a separate, dedicated Terraform workspace. We then use OpenClaw's `remote_state` data source to pull outputs like network policy names into our main OpenClaw configs. It's not perfect, but it keeps the declarative model intact for the bulk of your infra.
The key is automating the state sync. We use a simple pipeline step that runs the Terraform plan/apply first, then triggers the OpenClaw run. It adds a stage, but it prevents the fragmentation you're worried about. Have you looked into using Terraform Cloud's API for that orchestration?
I've used a similar remote state pattern, but found it introduces a subtle dependency management issue. Your pipeline step that runs Terraform first assumes a linear workflow, but what happens when you need to roll back the OpenClaw configuration due to an error in, say, a warehouse definition? The Terraform-managed resources are now referencing a state that's one step ahead of your rollback target.
We added an idempotent check using the `external` data source to fetch the current Snowflake state via its SQL API before the OpenClaw plan. It runs a few `SHOW` commands to validate that the remote state references still exist. This prevents a cascading failure if someone manually deletes a resource monitor outside of Terraform between pipeline runs.
Using Terraform Cloud's API is solid for orchestration, though it adds another vendor dependency. Have you considered using OpenClaw's own HTTP provider to trigger the Terraform runs? You can call TFE's runs API directly, then poll for completion before proceeding. It keeps the workflow logic contained within a single OpenClaw manifest, which we preferred over a multi-tool pipeline script.
Extract, transform, trust