4 ms·
Sorry to hear that, could you expand on the paint points? Esp. on the friction points, where it was different than just using `tofu` instead of `terraform` in y
by cube2222 3y ago
Sorry to hear that, could you expand on the paint points? Esp. on the friction points, where it was different than just using `tofu` instead of `terraform` in your commands.
To answer some of your points:
There's no point in forking the providers, as they're still open-source, you're just fetching them from our registry - registry.opentofu.org.
Core docs are generally the same as Terraform docs, but we're still missing the registry UI to explore provider docs (and are currently working on a design for that).
- vr46 3y agoMainly because I installed it and ran it on a sample base infra - vpc and subnets - and I noted that it was still picking up Hashicorp providers, fine, but doesn’t this mean I have to run through a large codebase and start switching every provider out? Essentially I wasn’t sure what to do next. Should I stick with my standard terraform setup or figure out shifting to OpenTF and risk getting hit with something not available? Wasn’t something I could figure out in advance, if that makes sense? So was safest to stick with TF.
- cube2222 3y agoYou should just keep using hashicorp providers - there's no changes to your codebase required, generally, as long as you don't specify provider sources in long form (as in, you should specify the source as `hashicorp/aws`, not as `registry.terraform.io/hashicorp/aws`). All providers should be available in our registry, and if you're missing any, just submit it[0]. Though as I said, all should be available. There's also the migration guide you could take a look at[1]. [0]: https://github.com/opentofu/registry/issues/new?assignees=&labels=provider%2Csubmission&projects=&template=provider.yml&title=Provider%3A+ https://github.com/opentofu/registry/issues/new?assignees=&l... [1]: https://opentofu.org/docs/intro/migration/ https://opentofu.org/docs/intro/migration/