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

271–280 of 392 posts

Re: The OpenTF Manifesto

#271

Post by yjftsjthsd-h »

latchkey wrote: post #257
yjftsjthsd-h wrote: post #253

Earlier quoted context omitted.

> One thing TF does well, is bare metal. How? I've always viewed TF as good at anything except metal; the best I would know to do is remote-exec but at that point you might as well drop to raw shell.

What is raw shell in the world of automation?

I mean that the only way I can think to use terraform to provision bare metal is to remote-exec a shell script (ex. to `apt install foo`), at which point you might as well skip terraform and `ssh targethost apt install foo` or `scp ./my-install-commands.sh root@targethost: && ssh root@targethost sh my-install-commands.sh`

Re: The OpenTF Manifesto

#272

Post by LinXitoW »

mousetree wrote: post #128

As a regular end-user of Terraform, what difference does BSL vs MPL make to me? From reading this article it seems not very much? Perhaps I'm misreading this.

Someone correct me if I'm wrong, but if I use TF in a Petstore-as-a-Service to provision new machines for my users, does that not count as embedding TF? So if HashiCorp decides to do Petstore-as-a-Service tomorrow, no matter how shitty the offering, no matter how insincere, even if it's just a single intern working on it, I would have to, overnight, rip TF out of my entire offering, no?

Re: The OpenTF Manifesto

#273

Post by latchkey »

yjftsjthsd-h wrote: post #271
latchkey wrote: post #257

Earlier quoted context omitted.

What is raw shell in the world of automation?

I mean that the only way I can think to use terraform to provision bare metal is to remote-exec a shell script (ex. to `apt install foo`), at which point you might as well skip terraform and `ssh targethost apt install foo` or `scp ./my-install-commands.sh root@targethost: && ssh root@targethost sh my-install-commands.sh`

Sure. That's effectively what Ansible does as well. You could even just have TF call that and be done.

The point that I'm trying to make is that I see a disconnect between deployment and provisioning.

I want both in a single tool (ala: Pulumi), even with bare metal. Ideally, in a programming language like TS or golang that is easy to get up to speed with and wraps up the complexity of getting servers up and running (as well as maintaining them over time).

Re: The OpenTF Manifesto

#274

Post by 0xbadcafebee »

mdaniel wrote: post #262
snom380 wrote: post #201

Earlier quoted context omitted.

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.

> 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? Oh, that one's easy: have the "plan" phase actually consult the underlying provider in order to know the straight face errors that are going to fail 60% of the way through your "apply" phase. I thought about including an example, but I don't care to try and lobby unless the community fork take…

1000%. The state file causes way more problems than it solves. The tool makes no attempt to look for an existing resource, or import existing resources, or absorb or ignore changes; you have to manually intervene. Meanwhile production is broken because only half the apply succeeded, but you have no idea if it'll blow up until you apply. No idea if you've set the necessary lifecycle policy correctly for this resource; you'll need to destroy the resource or rename something and see what happens. It's ridiculous.

Re: The OpenTF Manifesto

#275

Post by Alupis »

candiddevmike wrote: post #259
ghshephard wrote: post #239

Earlier quoted context omitted.

Genuinely curious - other than Vault - what other product is there for secret management in the cloud infrastructure space. I get that CyberArk Conjur is big in the enterprise space, but I thought cloud users, even with k8s, mostly went with vault.

Most companies are probably using the secret manager provided by their cloud platform instead of Vault, especially after they tried to buy Vault.

Which is more than likely Vault + new carpets and paint.

Re: The OpenTF Manifesto

#276

Post by comex »

kmeisthax wrote: post #93
cies wrote: post #37

Earlier quoted context omitted.

I thought Linus and other believed GPLv2 was fine and the improvements of GPLv3 did not outweigh the potential problems introduced by it. It never came to a point where all authors were asked to agree, or sign away their ownership.

Torvalds considered the anti-TiVo clause to be changing the deal and he didn't want to do that, and there's no way in GPLv3 to opt-out of the clause[0]. This is less "locking down devices is a human right" and more him being angry that the FSF was trying to butt into his project's affairs. He's also similarly angry about "GNU/Linux" as it sounds an awful lot like Stallman just demanding everyone stick "GNU" onto the…

Are you arguing that the GPL check “effectively controls access to a work” or “effectively protects a right of a copyright owner [..] in a work or a portion thereof”? Either way, the bar of how “effective” a measure needs to be to count may be low, but probably not that low.

Re: The OpenTF Manifesto

#277

Post by bshacklett »

johnbellone wrote: post #192
bloopernova wrote: post #125

If any Hashicorp people are reading, can you please tell your middle and senior management that this decision has deeply soured my entire DevOps cohort on continuing to use Terraform in the future. We're already exploring alternatives. Future client projects may not use Terraform at all. Languages and frameworks must remain open or they will wither and die.

Just stop using their products. Stop giving them free advertisements. Stop integrating your software and services with them. It is harsh, but they’re a public company now, not Mitchell.

Far easier said than done.

Re: The OpenTF Manifesto

#278

Post by jen20 »

tedivm wrote: post #269
jen20 wrote: post #185

Earlier quoted context omitted.

It doesn’t have a testing tool built in. No one legitimately understands the phrase “terraform doesn’t have a test suite” to mean anything except “there are no tests”. A runner and a suite are quite different.

I can understand the miscommunication in the first post, but I clarified in a direct comment to you what I meant. I was even comparing it to Terratest, which is not used for testing terraform core. At this point you're just being belligerent for the sake of being belligerent.

I'm not arguing with you, your clarifying comment was fine. I'm arguing with the person who replied to you.

Re: The OpenTF Manifesto

#279

Post by 0xbadcafebee »

yevpats wrote: post #165
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 think it's not only the issue with terraform but also the underlying infrastructure. AWS should've never have imperative APIs in the first place. Or at least it's time for AWS V2 APIs

I agree. Cloud infrastructure should be versioned and immutable. If I have an S3 bucket and make 4 changes to it, there should be V0 (making the bucket) and V1-V3 (each subsequent change). I should be able to tell the bucket API to restore the bucket to V2. Terraform is a hack to fill that gap. The AWS bucket service itself should be doing it, not Terraform. Several classes of software that we all maintain ourselves would go away if cloud infra were versioned & immutable.

Re: The OpenTF Manifesto

#280

Post by pxc »

bayindirh wrote: post #136
bloopernova wrote: post #125

If any Hashicorp people are reading, can you please tell your middle and senior management that this decision has deeply soured my entire DevOps cohort on continuing to use Terraform in the future. We're already exploring alternatives. Future client projects may not use Terraform at all. Languages and frameworks must remain open or they will wither and die.

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…

> What should they do? I'd advocate AGPL, but xGPL licenses are avoided like a plague, because Free Software is not "closed forks" friendly, and companies hate to open everything like that.

They can offer it under more than one license if they want. I, for one, would be pretty happy if they offered it under both BuSL and AGPL.

  - business users who are afraid of copyleft could use Terraform under the terms of the BuSL
  - the F/OSS community could distribute it under the terms of the AGPL and freely build on it
  - competitors to Hashicorp would have a choice:
    + open their whole stack and compete in the market based on the quality of their services and support alone (admirable but very tough)
    + negotiate and pay HashiCorp to license Terraform under special, proprietary terms
Probably, many of the same companies who want to fork Terraform now would still want to. But I'd be satisfied and it would likely shift the conversation in a way beneficial to Hashicorp's reputation.
Post reply on HN