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

The OpenTF Manifesto

opentf.org

Post reply on HN
Print view View original

201–210 of 392 posts

Re: The OpenTF Manifesto

#201

Post by snom380 »

0xbadcafebee wrote: post #142

Actually, can we just kill Terraform? Please? Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at al…

I have a hard time thinking of how terraform as a piece of software can do to much more than it already does to fix things?

When terraform fails, it's typically because of a an API error or a configuration issue that is beyond its control?

Not handling state rollback is a design decision that, having dealt with the fun of CloudFormation, I'm pretty happy that they made.

Re: The OpenTF Manifesto

#202

Post by dbingham »

pa7ch wrote: post #186
AtNightWeCode wrote: post #179

Earlier quoted context omitted.

This is perhaps the most incorrect post you will ever find on HN. I am not a huge fan of Terraform. However, TF is made for infra not config. There are several tools out there to manage config like Salt, Ansible and so on.

Honest question, what do you consider config vs infra? What is infra if not configuring a system to run?

Infra is defining the servers that should be running. Config is writing configuration files to a running server.

Cloud blurs the line, since a lot of cloud offerings are managed where you're really doing both at once when you define the managed offering.

Re: The OpenTF Manifesto

#203

Post by cconstantine »

0xbadcafebee wrote: post #142

Actually, can we just kill Terraform? Please? Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at al…

I've been using terraform for 10-ish years, and this is very much not how I feel about it. Terraform absolutely makes life easier; I've managed infrastructure without it and it's a nightmare.

Yes, it can be awkward, and yes the S3 bucket resource change was pretty bad, but overall its operating model (resources that move between states) is extremely powerful. The vast majority of "terraform" issues I've had have actually been issues with how something in AWS works or an attempt to use it for something that doesn't map well to resources with state. If an engineer at AWS makes a bone-headed decision about how something works then there isn't much the terraform folks can do to correct it.

I've actually been pretty frustrated trying to talk about terraform with people who don't "get it". They complain about the statefile without understanding how powerful it is. They complain about how it isn't truly cross-platform because you can't use the same code to launch an app in aws and gcp. They complain about the lack of first-party (aws) support. They complain about how hard it is to use without having tried to manually do what it does. Maybe you do "get it", and have a different idea of what terraform should do. Could you give a specific example (besides the s3 resource change) where it fails?

It's a complicated tool because the problem it's trying to solve is complicated. Maybe another tool can replace it, and maybe someone should make that tool because of this license change, but terraform does the thing it intends to do pretty well.

Re: The OpenTF Manifesto

#204

Post by hdaz0017 »

brikis98 wrote: post #26
dbingham wrote: post #23

I appreciate the letter and trying to work with Hashicorp -- I used to have a ton of respect for Hashicorp. But honestly... at this point... ...just fork it into a foundation. Don't wait for Hashicorp's response. I get wanting to have the appearance of working with Hashicorp, but we've been shown again, and again, and again, and a-fucking-gain that private corporations cannot be trusted to maintain public goods. Only…

The truth is that a fork hurts everyone. Imagine a future CTO trying to pick the IaC tools for their company. They see Terraform as an option, but then learn there are multiple forks, licensing questions, and a big battle happening in the community. What do they do? They are now way more likely to pick a different tool that is genuinely open source. The same is true of every dev considering where to build their caree…

Hopefully it's not down to CTOs to be picking tools for their company but a process within DevOps/Engineering teams etc.

Does anyone else see this as the Nagios Effect all over again, there must be lots to learn from history?

Re: The OpenTF Manifesto

#205

Post by latchkey »

zapnuk wrote: post #200
latchkey wrote: post #151

Earlier quoted context omitted.

While I agree with you about TF having a lot of issues, the comment isn't helpful. What would you suggest otherwise? Kind of a moot point now that the license is fubar'd, but what could be improved to make it better? If you could have a do-over, what would that look like?

Right now there is pulumi as a alternative that supports different clouds. Otherwise AWS CDK or Azure Bicep come to mind. If i could to a do-over I'd want the solution to look and feel like AWS CDK but without the cloudformation in the background, and support for GCP and Azure. I've worked with CDK for 2 years now and being able to define your code in Typescript is quite handy and drastically reduces the effort it ta…

The mind boggles why Pulumi doesn't do ssh.

I have a whole bunch of bare metal sitting in data centers all over the world, how am I expected to manage it?

Ansible/Salt/Chef is obviously one type of solution, but like you said, being able to code things in TS is really nice.

One thing TF does well, is bare metal.

Re: The OpenTF Manifesto

#206

Post by smarx007 »

i_am_jl wrote: post #177
tootie wrote: post #150

Earlier quoted context omitted.

I'm not Hashicorp, but I mean look at Docker. They built the most valuable devops tool of the last generation and can barely muster a viable business. Why would Hashicorp give the slightest worry to losing thousands and thousands of non-paying customers? The upside is lots of money and the downside is loss of halo. Honestly, it's an unfortunate game of expectation setting. If I wrote an open letter decrying Salesforc…

Why would Hashicorp give the slightest worry to losing thousands and thousands of non-paying customers? Because it goes hand in hand with losing hundreds of unpaid developers, testers, bug-reporters and evangelists. If I wrote an open letter decrying Salesforce for not open sourcing their codebase, nobody would take me seriously. But we expect better from Hashicorp for some reason. Because the community contributed t…

I think that once you have more than X customers, you don't really need OSS testers and bug-reporters that much – your customers will be the first ones to file a ticket if anything is wrong. And as we saw with CentOS Stream, OSS users are not generally keen to be beta-testers.

Ditto for earnings: once your company is publicly traded or at least lands in a Gartner report, you don't need evangelists that badly anymore.

Free pull requests are always welcome, but I guess a calculation was made in this case.

Re: The OpenTF Manifesto

#207

Post by manvillej »

0xbadcafebee wrote: post #142

Actually, can we just kill Terraform? Please? Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at al…

its really funny because I needed to create a terraform like functionality & went in depth into looking at both building it into terraform (which ended up not working) and building a new tool.Its not THAT complex. there are a few gimmicks in HCL, like it being an actual language, that create some interesting features.

but it could just be a yml file. In essence, the requirements section says "here are the builders it needs & their versions" which identifies types of jobs. each entry is a job with a job type, a unique name, and some config info. Each builder is just a series of CRUD operations.

Like you said, it builds a directed acyclic graph, queues up the ready jobs, and executes them. updating the infrastructure's "state" with info from the completed jobs & adding new jobs when their dependencies are finished. the state files are just a dump of that structure as json.

Its not thathard. I think of myself of a junior level dev and I built something for me in my side time in a month with a full test suite and its 3/4 of the way there. CLI, builder dependency injection, type checking, relationship dependencies, it took me a few weekends

I think a senior engineer could build out an enterprise grade functional core product in a few weeks. building & maintaining the CRUD APIs is the real headache, but I think vendors would take care of that themselves if there was a popular enough OS solution.

Re: The OpenTF Manifesto

#208

Post by danenania »

MrBuddyCasino wrote: post #176
0xbadcafebee wrote: post #142

Actually, can we just kill Terraform? Please? Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at al…

I don’t know what it is about the ops sector that favors ugly tools, but apparently they don’t care, otherwise Pulumi would see more traction.

There’s a lot of inertia in ops tooling. Switching costs are very high for an existing project, and once you learn the quirks of one tool or another, it takes a lot to justify something else for a new project even if it’s better, since you know the new tool will have its quirks too.

The cost-benefit analysis of new stuff is also different for ops compared to pure development. You tend to care more about stability and predictability than productivity and elegant design. Problems in pure dev land cause bugs that mostly aren’t super urgent; problems with ops tools bring down whole systems and wake everyone up at 2am. For these reasons, ops is always going to have a more conservative mindset that shuns the shiny new thing to some extent.

Re: The OpenTF Manifesto

#209

Post by bayindirh »

smarx007 wrote: post #198
bayindirh wrote: post #136

Earlier quoted context omitted.

As a Free Software advocate and supporter, I'm thinking about the answer to this question: - MPL is a weak-copyleft license, which allows companies to grab and run Terraform codebase, provide it as-is (as Terraform), or as white-labeled Terraform compatible feature/layer. This is alright (because license allows this). - These people also contribute their own fixes upstream, which is great, and maintain their own patc…

MPL is a copyleft license, actually, just like EPL and EUPL. What it is not is a viral copyleft license. Anyone making changes to TF code and productionizing it is expected to contribute back but only the direct changes to TF itself, not the extensions around it. That's my reading of EPL/MPL/EUPL. Does that match your reading?

You're right. MPL is a weak-copyleft license. I mistyped it, I don't know why. Fixed my comment with a note, thanks.

However, it still allows your code to be bundled inside a bigger work. The bigger work can be in any license (maybe not GPL, need to check), but MPL stays MPL. This doesn't prevent white-labeling the codebase, though.

As far as I read the MPL, the contribution back part is not mandatory, but encouraged by not affecting the larger work. It keeps the MPL part open, but doesn't enforce a "send patches back" policy.

Re: The OpenTF Manifesto

#210

Post by busterarm »

bastardoperator wrote: post #190
busterarm wrote: post #169

Earlier quoted context omitted.

the OP was suggesting that it's just obvious to use Kubernetes instead of Nomad. I was saying that anyone who operates large scale Kubernetes knows that you will forever be dealing with tuning etcd and fighting to keep etcd alive. It's an underpinning service of Kubernetes. Roblox's outage was related to the intricacies of running consul and mistakes that they made. The point I was making was that I would rather, at…

Until you have 3 days of downtime and end up on a special build of consul that nobody else has while nearly decimating your companies stock price, reputation, and employee morale, the alternatives start looking better. The point I'm making is that it doesn't handle their scale today and that projects with larger communities, support, and usage exist today. No one said k8s was a silver bullet, it's just an alternative…

If you truly read and understood the Roblox post-mortem you would understand that the problems that they had with Consul were partly and unintentionally self-inflicted and partly due to BoltDB. The "special build" was just early access to Hashi's already-ongoing work to replace boltdb with bbolt, which has long-since shipped.

The hyperbole applied to the description of the harm done to Roblox here I'm just going to ignore. Roblox is still popular. The company still has the reputation of a rock-solid engineering department. Roblox's stock isn't doing much differently than the rest of technology companies on the market and the "damage" you mention is vastly overstated anyway. In fact, Roblox's stock literally had a huge rally after and PEAKED within two weeks after the outage.

Post reply on HN