Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oracle dumps Terraform for OpenTofu

thestack.technology

Post reply on HN
Print view View original

151–160 of 191 posts

Re: Oracle dumps Terraform for OpenTofu

#151

Post by [deleted] »

wcedmisten wrote: post #139
talldayo wrote: post #97

Earlier quoted context omitted.

That's not really a problem as long as the source license stays the same. If Amazon or Microsoft need a feature in the kernel, nobody tends to care as long as it's GPL. > Those companies are merely helping to “commoditize their complements” That's how they justify it internally, yeah. From an administrative standpoint it's pretty obvious that they all choose Linux because it's easier than retrofitting proprietary UNI…

I think you may have misinterpreted the parent comment. "Complement" as in a complementary good in economics terms. Not "complimentary", as in free. There's a good article on this by Joel Spolsky https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

[deleted]

Re: Oracle dumps Terraform for OpenTofu

#152

Post by x86a »

_w1tm wrote: post #143
x86a wrote: post #109

Earlier quoted context omitted.

I'm really excited to see the end-to-end state encryption. I've always thought it was bizarre that Hashicorp didn't prioritize this.

Could it be because it weakens the business case for using their SAAS?

Possibly, but we are paying enterprise customers (but not using HCP) and this still isn't possible. Seems like an obvious thing they could have at least offered to vault enterprise or TF enterprise customers years ago.

Re: Oracle dumps Terraform for OpenTofu

#153

Post by quesera »

JohnMakin wrote: post #150
quesera wrote: post #148

Earlier quoted context omitted.

I'm not being snotty. Terraform is not the best choice for every organization. Rather, Terraform does not add value within every organizational structure. Not adding value is failing. Having a negative ROI is failing. None of these infrastructure tools are perfect, and the ways in which they are imperfect mean that some are better or worse matches for an organization's needs. Therefore your initial statement is overs…

You're shifting goalposts now and still failed to answer my question. And since you seem to have cracked the long-known problem of measuring infrastructure/devops/etc. team performance (since apparently you have a way to measure the ROI on that) I'm assuming you're far above my expertise here and have it all figured out, and I'm in over my head and have clearly struck a nerve. Glad you figured out a problem that so m…

The answer is that they all suck. I've used them, and I've written them. They sucked 20 years ago, and they suck today.

But they suck differently, for different reasons, and they suck in different magnitudes in the hands of different teams, with different needs.

I have never met an org that was happy with their infrastructure tooling! But I have met some that were happier with some tools than with others.

It's horses for courses. Terraform is a contender for some use cases. Nothing more, nothing less.

Re: Oracle dumps Terraform for OpenTofu

#154

Post by fishnchips »

erik_seaberg wrote: post #144
fishnchips wrote: post #112

Earlier quoted context omitted.

> since it uses lock files on S3 versus a separate DyanamoDB + S3 combo This is disturbing because S3 does not give you guarantees required to implement real locking.

https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-rea... guarantees that a client's lockfile can always be seen by other clients immediately (which didn't used to be true). If every client backs off and retries after a race, is that enough?

I think not, actually. There would still be cases where a race is not detected. I can think of the following sequence: A checks - no lock, B checks - no lock, A writes - success, A reads - match, success, B writes - success, B reads - match, success. A and B both think they now hold the lock.

For locking to work properly you'd need to have a conditional write that would fail if some prerequisite was not met. GCP offers that operation, S3 AFAIK does not.

Re: Oracle dumps Terraform for OpenTofu

#155

Post by erik_seaberg »

fishnchips wrote: post #154
erik_seaberg wrote: post #144

Earlier quoted context omitted.

https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-rea... guarantees that a client's lockfile can always be seen by other clients immediately (which didn't used to be true). If every client backs off and retries after a race, is that enough?

I think not, actually. There would still be cases where a race is not detected. I can think of the following sequence: A checks - no lock, B checks - no lock, A writes - success, A reads - match, success, B writes - success, B reads - match, success. A and B both think they now hold the lock. For locking to work properly you'd need to have a conditional write that would fail if some prerequisite was not met. GCP offe…

I'm no expert but from a quick glance at https://www.pulumi.com/docs/concepts/state/#using-a-self-man... it looks like this might work:

  client A lists s3://bucket/prefix/.pulumi/locks/, sees nothing

  client B lists s3://bucket/prefix/.pulumi/locks/, sees nothing

  client A creates s3://bucket/prefix/.pulumi/locks/unique1.json

  client A lists s3://bucket/prefix/.pulumi/locks/, only sees unique1.json, and proceeds

  client B creates s3://bucket/prefix/.pulumi/locks/unique2.json

  client B lists s3://bucket/prefix/.pulumi/locks/ and sees both unique1.json and unique2.json

  client B assumes it lost a race, deletes s3://bucket/prefix/.pulumi/locks/unique2.json, and retries
There's another mode where both clients pessimistically retry, but fuzzing a retry delay could eventually choose a winner randomly.

Re: Oracle dumps Terraform for OpenTofu

#156

Post by jamesrr39 »

8organicbits wrote: post #20

We're seeing an uptick in open source projects getting relicenced to non-open licenses. Some projects are successfully forked and the userbase shifts, other times not. One theory of mine is that we can measure the risk that a project will be relicensed by looking at things like diversity of contributors, trademark ownership, contributor agreements, and license terms. Low risk projects include the Linux kernel (GPL, D…

Regarding Kubernetes and the Apache license, Apache license 2.0 has to be one of the most business friendly licenses around? It's widely used and understood, no requirement to open source changes, automatic patent license for any patents the software uses included. If the corporate lawyer says no to that, what do they say yes to?

Re: Oracle dumps Terraform for OpenTofu

#157

Post by fishnchips »

erik_seaberg wrote: post #155
fishnchips wrote: post #154

Earlier quoted context omitted.

I think not, actually. There would still be cases where a race is not detected. I can think of the following sequence: A checks - no lock, B checks - no lock, A writes - success, A reads - match, success, B writes - success, B reads - match, success. A and B both think they now hold the lock. For locking to work properly you'd need to have a conditional write that would fail if some prerequisite was not met. GCP offe…

I'm no expert but from a quick glance at https://www.pulumi.com/docs/concepts/state/#using-a-self-man... it looks like this might work: client A lists s3://bucket/prefix/.pulumi/locks/, sees nothing client B lists s3://bucket/prefix/.pulumi/locks/, sees nothing client A creates s3://bucket/prefix/.pulumi/locks/unique1.json client A lists s3://bucket/prefix/.pulumi/locks/, only sees unique1.json, and proceeds client B…

In this case you have the opposite issue, with no-one actually guaranteed to get a lock even though nothing is holding one. Fuzzed retries may work in practice but theoretically speaking this is a flawed algorithm.

Re: Oracle dumps Terraform for OpenTofu

#158

Post by zug_zug »

scarface_74 wrote: post #93
zug_zug wrote: post #92

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…

Welcome to technology. Yes, I too wish I could make a living programming in 65C02 assembly on my Apple //e like I did in 1986. I also don’t see any reason I have to learn about S3 instead of storing all of my files on an on prem CDRW jukebox

No, it's not inevitable. There are many technologies that will outlast my whole career: java, sql, tcp/ip, linux, to name a few.

S3 will also certainly be around in 20 years.

Re: Oracle dumps Terraform for OpenTofu

#159

Post by zug_zug »

JohnMakin wrote: post #105
zug_zug wrote: post #92

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…

if moving to terraform fails for your org, you have much deeper issues that likely aren’t related to terraform

I didn't downvote, but I disagree. You put forth the question of when a company might rightly not use terraform and I think I can answer that.

I think of terraform as a form of insurance. It's "Oops manual change" insurance. In the event that somebody breaks something in the console and you need to undo it, it's exponentially faster-easier. However you have to pay premiums to get this insurance as well as a setup cost.

So is the insurance worth it? It depends on the org. But I've seen small places where it's a small team that communicates well and nobody screws around in the console with stuff they don't understand (and if they break it they can own it). So there absolutely are places where the amount of time terraform costs you (in learning, setup, and extra PR time, waiting for atlantis to finish, locks) is higher cost than the time saved when you need.

Re: Oracle dumps Terraform for OpenTofu

#160

Post by zug_zug »

playingalong wrote: post #123
zug_zug wrote: post #92

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…

Would you classify k8s in this bucket?

I'm still debating that. Certainly on the one hand it seems like there's already dozens of different incompatible variants/tools/setups/workflows to learn [most of which will be zombies in 5 years]. If I had to pick -- my gut instinct is kubernetes will be around for 5 more years but won't be common in 20 years.
Post reply on HN