Alright, I'll bite. I've been forced to use OCI for a client and, naturally, Terraform wasn't cutting it for their "unique" requirements. So we looked at OpenClaw. The promise was decent: open-source, multi-cloud, yada yada.
Turns out, the OCI provider support feels like someone built it on a dare. The documentation has that distinct smell of "written by someone who has never actually operated the thing." Getting a simple compute instance with a VCN up was an exercise in archaeology.
Here's the kind of nonsense you'll run into:
* The `oci_core_vcn` resource is straightforward, but good luck finding consistent examples for security list ingress/egress rules that actually work. The schema validation passes, the deployment fails with a cryptic Oracle error.
* Module structure? Forget about it. You're basically stitching together raw provider calls, and the learning curve is all cliffs.
* The state management is... fine. But if you're coming from Terraform, the lack of a mature ecosystem means you're writing everything from scratch. No `terraform-oci-modules` to save you here.
* Biggest gotcha: The authentication config. The required key format and the way OpenClaw reads the `config` file differs just enough from Terraform's OCI provider to waste an afternoon. You'll get "unauthorized" until you tweak the tenancy OCID format.
I eventually got a basic stack running, but it felt more like a proof-of-concept than a production tool. The testing story is basically "hope it works." If you're deep in OCI and hate Terraform Cloud's pricing, maybe it's worth the pain. For anyone else? Hard to recommend.
Anyone else been through this? Did you find a trick to make the network layers behave, or did you just go back to managing it all through the cursed console?
been there, migrated that
Oh, you got to the auth part. That one's a rite of passage. The PEM key format it needs is very specific, and the SDK config file path resolution is brittle. I've found you can't just point it to the standard `.oci` directory; you have to explicitly set the `key_file` path in the provider config, absolute, no tilde.
For the security list rules, the ingress/egress block syntax is indeed a trap. The examples often omit that you need to explicitly set `stateless = false` for stateful rules, which is what you almost always want. If you leave it out, it defaults to true and your connections won't track state. That's likely your cryptic error.
It gets smoother once you're past these initial walls, but yeah, you're building the plane while flying.
Integrate or die
Ugh, the PEM key. You're spot on about the absolute path. I wrote a quick wrapper script that generates the OpenClaw config snippet because of that. It just resolves the path and spits out the provider block.
```bash
#!/bin/bash
KEY_FILE=$(readlink -f ~/.oci/oci_api_key.pem)
cat << EOF
provider "oci" {
tenancy_ocid = var.tenancy_ocid
user_ocid = var.user_ocid
fingerprint = var.fingerprint
key_file = "$KEY_FILE"
region = var.region
}
EOF
```
Saved me a few headaches across different environments.
And yeah, the `stateless = false` thing is a classic. Feels like a bug in the provider's defaults, honestly. Who wants a stateless security list by default?