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

331–340 of 392 posts

Re: The OpenTF Manifesto

#331

Post by tux2bsd »

aftbit wrote: post #71
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.

My understanding was that some people in the community believed that GPLv3 was better, and one of Linus's criticisms was that it was essentially impossible to switch even if it were better. I also believe Linus was opposed to the switch, which would make it unlikely anyway, but even if he had approved, I still think it would be practically impossible.

[dead]

Re: The OpenTF Manifesto

#332

Post by zzbn00 »

marcinzm wrote: post #34

As I see it Hashicorp has failed to create a viable business model in an environment where there isn't unlimited perpetual VC money. Now they're at the stage of giving up and simply trying to shake down those who have managed to make better business models. It's usually not a good idea to be near a company flailing like this since who knows what their next rent seeking approach will be. A company with nothing to lose…

A company that loses money is a dangerous long-term partner, full stop.

Re: The OpenTF Manifesto

#333

Post by aequitas »

cyberax wrote: post #317
jen20 wrote: post #236

Earlier quoted context omitted.

Well, if that's something you _actually_ want, take a look at Pulumi, which does precisely what you ask.

Pulumi looks great. Why aren't they more popular?!? They still need the state (boo!), but otherwise they're great.

You can’t implement this kind of tooling with the features is provides without the state.

Re: The OpenTF Manifesto

#334

Post by oneplane »

Alupis wrote: post #284
oneplane wrote: post #263

Earlier quoted context omitted.

You generally only run Vault if your secrets don't/won't/can't reside on a public cloud service.

There's a lot more reasons to run Vault than those. Having a standardized way to "do secrets" for any team, any service, any app within the organization is very nice. Becoming cloud-agnostic for your secrets (connecting your local Vault with the cloud provider's vault) is another great benefit. Automatic secret rotation is also another great benefit. Secret versioning and auditing... etc. It's not just "can't have th…

> It's not just "can't have this secret in VCS or viewable via kubectl".

That is exactly what it is.

You seem to misunderstand (and thus downvote?) the statement I made. I'm not saying "haha vault bad", I'm answering "what other product" (from ghshephard) with the reality of today.

This has nothing to do with what Vault is or isn't, but just with the concept of storing secrets in a uniform way in clouds for use with cloud workloads what is being used right now.

Re: The OpenTF Manifesto

#335

Post by WhyNotHugo »

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.

> We're already exploring alternatives. Future client projects may not use Terraform at all.

I'd wait and see what happens with OpenTerraform. If the fork gains some good momentum, it would be the easier choice. Usually, you should be okay with using the latest FLOSS version for a few weeks/months until things settle anyway.

Re: The OpenTF Manifesto

#336

Post by jen20 »

jq-r wrote: post #328
jen20 wrote: post #237

Earlier quoted context omitted.

This is clearly a poor idea. Declarative infrastructure management is ultimately a dead end, because order of operations actually matters.

I'm not sure one follows from the other. You could have both: eg if resource Y depends on X, then you would just declare Y after X. Or you could do a "depends_on" directive like in TF. That certainly doesn't sound like a dead end to me.

That is the trivial part (and any tool even worth talking about already implements it).

The problem is things like “create this instance in parallel as a replacement for this one over here, then shut down the original, detach a volume from the original and attach it to the replacement then run command X on the replacement, stopping for manual intervention at any phase the running system reports it is running at reduced redundancy”.

This is not an atypical requirement for infrastructure as code beyond the basics, but none of the declarative tools come close to addressing it without a bucket load of external coordination.

Re: The OpenTF Manifesto

#337

Post by busterarm »

pcthrowaway wrote: post #238
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…

I was interested in Nomad in the past, but Kubernetes is open source, so it has that going for it

Sad but true.

Re: The OpenTF Manifesto

#338

Post by denvrede »

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…

The guys at Pulumi must be having a field day right now. It's exactly how you describe it for us. We're long overdue with an upgrade of our Terraform config from pre v1.0. We have to most likely re-write a big part of our HCL code, so why not try a competitor?

With Vault however that's another story, I've yet to find another secrets management system that has a tight integration with Kubernetes, AWS and supports providers for things like Postgresql to have ephemeral database credentials.

Re: The OpenTF Manifesto

#339

Post by jen20 »

candiddevmike wrote: post #114
empressplay wrote: post #103

Earlier quoted context omitted.

This is not testing? https://developer.hashicorp.com/terraform/cli/commands/plan

No, that's a rough guesstimate from Terrafrom on what actions it will be doing. Terratest allows you to write actual tests and mocks.

This one needs some clarification.

It’s actually not a guesstimate about what actions will be taken, it’s a guesstimate of the state that will result from those actions without any reference to ordering or “actions” as a cloud API would understand them - the plan is purely in terms of CRUD on Terraform provider resources and provisioners.

This may seem like a nit, but it fundamentally changes what Terraform is capable of doing in a single pass without external coordination.

Re: The OpenTF Manifesto

#340

Post by 0ct4via »

kragen wrote: post #315
anyoneamous wrote: post #265

Earlier quoted context omitted.

FWIW there are still people (dozens of us!) who don't feel the need to be artificially offended by a bit of hyperbole on an internet forum.

my objection is not that mass graves, piles of mangled bodies, your close friends unexpectedly disappearing into pink mist, and terrible stenches are too sacred to be used as a metaphor for something else my objection is that warfare involves people intentionally harming each other, and that doesn't seem to be what's going on here. it's not that war is a more extreme version of the situation; it's that it's direction…

Not sacred enough for you to invoke the Holocaust in a discussion about data protection legislation and the "right to be forgotten" within mere hours of this statement, however...

Such hypocrisy, attacking others for "rhetoric" that needs to be "dialled back a bit" when you're every bit as guilty of the exact. same. thing.

Post reply on HN