121–130 of 191 posts
Earlier quoted context omitted.
The trend will continue. A company will be crazy to trust that IBM would give them fair-priced high quality support.
Do you appreciate the irony of that comment on a post about Oracle adopting OpenTofu?
Earlier quoted context omitted.
The trend will continue. A company will be crazy to trust that IBM would give them fair-priced high quality support.
Do you appreciate the irony of that comment on a post about Oracle adopting OpenTofu?
In this case Oracle is the user, not the vendor.
Slightly off-topic, but one of my greatest pet-peeves of working in devops is every few years a new "killer tech" comes out that some contingent of very-highly-opinionated (though not always very senior) people insists is life-and-death stakes and wants the whole company to move to (e.g. terraform). Too often it's a failure. Too often it has some upsides, but also is a LOT of work that is discovered over time. Too of…
It's great to see more companies adopting OpenTofu, and especially larger ones! As a side note, we've recently released OpenTofu 1.7 with end-to-end state encryption, enhanced provider-defined functions, and a bunch more[0]. If you've been holding out with the migration, now is the perfect moment to take another look, and join the many companies that have already migrated! [0]: https://github.com/opentofu/opentofu/re…
For example:
# current method
module "foo" {
count = var.enable_foo ? 1 : 0
}
# better?
module "bar" {
enabled = var.enable_bar
}
I'd also really like to be able to say in an output block, "this value doesn't have to exist, only display it if its parent module is enabled", again without the "count" attribute.
It's great to see more companies adopting OpenTofu, and especially larger ones! As a side note, we've recently released OpenTofu 1.7 with end-to-end state encryption, enhanced provider-defined functions, and a bunch more[0]. If you've been holding out with the migration, now is the perfect moment to take another look, and join the many companies that have already migrated! [0]: https://github.com/opentofu/opentofu/re…
Are there any incompatibilities cropping up between terraform and opentofu? I believe we're on terraform 1.7.5, I'm not sold on migrating yet but would like to keep the option open, especially if something like delaying an upgrade would help not have future backwards incompatible things to fix. I understand why people were upset about licensing changes but I was not one of them who were particularly bothered. Why sho…
OpenTofu is indeed a hard fork. When doing similar features (like provider-defined functions) we try to stay compatible where it makes sense, but there's often some differences (like our more extended capabilities of provider-defined functions[0]) and also new features in Terraform that we're not introducing - and vice versa.
You can check for known incompatibilities in our migration guides[1], based on your Terraform version. In practice, the longer you wait, the more the projects will diverge, so if you still want to "wait and see" I would suggest settling on your current Terraform version for now - otherwise, the migration will just be more work for you later.
Regarding the reasons for switching, I'd say features and community-first process. We're striving to be very community driven in what work we're prioritizing[2] and have received a lot of positive feedback over that from our users.
Some companies we've spoken to see adopting the open-source community-driven project as a way to reduce risk long-term. It's also a way to keep your options open if you're in the market for commercial Terraform/OpenTofu management systems.
[0]: https://github.com/opentofu/terraform-provider-go
It's great to see more companies adopting OpenTofu, and especially larger ones! As a side note, we've recently released OpenTofu 1.7 with end-to-end state encryption, enhanced provider-defined functions, and a bunch more[0]. If you've been holding out with the migration, now is the perfect moment to take another look, and join the many companies that have already migrated! [0]: https://github.com/opentofu/opentofu/re…
Are there any plans for a conditional way to enable/disable modules that doesn't use "count"? For example: # current method module "foo" { count = var.enable_foo ? 1 : 0 } # better? module "bar" { enabled = var.enable_bar } Preconditions and postconditions fail the apply run if their condition doesn't validate, so those can't be used. I'd also really like to be able to say in an output block, "this value doesn't have…
There's a bunch of nontrivial technical complexity though, because of how OpenTofu currently works.
Earlier quoted context omitted.
It's important to remember that a community is not a single minded entity. It's members can hold many contradicting beliefs, while each individual is ideologically consistent. This shouldn't be unexpected and it's not an excuse to be dismissive to an imagined hypocrite. Not saying there aren't hypocrites in this world, just that we shouldn't treat members of a community as some kind of superset of everything in that…
It's important to remember that a company is not a single minded entity. It's members can hold many contradicting beliefs, while each individual is ideologically consistent.
Believing every employee at Walmart thinks the same is silly and while someone is to blame for policy its important to not blame retail clerks for store policy, for example.
The article is somewhat confusing but it sounds like Oracle packages a cloud infrastructure management tool that’s based on Terraform. Presumably it’s built on 1.6, which was still MPL. Since they offer this product as a service, it directly falls under the restrictions HashiCorp put into place to prevent competition from repackagers and SaaS offerings of their products. So to move forward with upgrading the Terrafor…
Earlier quoted context omitted.
What really grinds my gears is how hard it is to refactor terraform code. Put something in a module, but want to move it elsewhere? Get ready for pain. I've been using terranix, which uses nix to generate a tf.json file, and oh my god is the experience night and day. I can make functions! I can refactor! And if it's a pure refactor, there is nothing to apply.
I know many people find it painful but isn't this fairly simple with "terraform state mv?" my process is roughly: comment out the resource in the module, run a plan -> get output like: "module.foo1.aws_resource.bar will be deleted" Then copy my resource in source to module.foo2.aws_resource.bar, the command becomes: terraform state mv module.foo1.aws_resource.bar module.foo2.aws_resource.bar I guess this might be har…