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

251–260 of 392 posts

Re: The OpenTF Manifesto

#251

Post by skywhopper »

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…

HashiCorp has plenty of revenue and that revenue is growing fast. They are losing money, but that's to be expected during the high-growth phase of their lifecycle. If they are having trouble growing as fast as their investors want it to, changing their licensing is not the way to fix it. This change is unfortunate because it won't bring serious new revenue to the company but it is a major blow to the reputation they had built.

Re: The OpenTF Manifesto

#252

Post by yjftsjthsd-h »

jen20 wrote: post #28

How exactly do the companies involved plan to fund a fork? It would require at minimum 3-4 full time engineers, and no one is going to do that work for free. It’s also telling that this manifesto blithely suggests TF could become Apache 2, which is wholly untrue.

> It’s also telling that this manifesto blithely suggests TF could become Apache 2, which is wholly untrue.

Why is it untrue? If Hashicorp has the ability to relicense to BSL, what would prevent them relicensing to anything else?

Re: The OpenTF Manifesto

#253

Post by yjftsjthsd-h »

latchkey wrote: post #205
zapnuk wrote: post #200

Earlier quoted context omitted.

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.

> 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.

Re: The OpenTF Manifesto

#254

Post by fishnchips »

kragen wrote: post #245
fishnchips wrote: post #32

Earlier quoted context omitted.

Marcin here, co-founder of Spacelift. Even though I strongly believe the OpenTF fork could open up incredible possibilities for the community (I could go on and on about it), it is an equivalent of a civil war. It doesn't serve the community and our only interest is in the continued strength of the community that we continue to build for. Based on my immense respect for what's been built under Hashi's umbrella I'd ra…

it's not war hashicorp has decided they don't want to contribute to open source any more they're totally within their rights to do so, and it doesn't harm anybody; it's not the equivalent of going around blowing up buildings, raping women, and napalming children. at most we can wish they had continued doing the beneficial things they were previously doing maybe they'll change their minds, as you say, but that's no re…

I apologize if I appeared to downplay the horror of actual war. I'm lucky to never have experienced it first-hand.

I mainly wanted to focus on the "civil" than "war" aspect of the possible schism.

Re: The OpenTF Manifesto

#255

Post by verdverm »

AaronFriel wrote: post #241
verdverm wrote: post #108

Earlier quoted context omitted.

We just went back to TF after giving Pulumi a try. Prefer declarative syntax for infra and more abuse of Yaml ("fn::..." here) is not what I'm after. We are working on wrapping TF in CUE since you can CUE->JSON->TF https://github.com/hofstadter-io/cuelm Many more CUE experiments are going on in the devops space

Pulumi has a few languages other than YAML and Pulumi is declarative[1], and the programs you write are only as complex as you want them to be. This python program declares an S3 bucket and declares ten objects to exist in it. from pulumi_aws import s3 bucket = s3.Bucket('bucket') for i in range(10): s3.BucketObject( f'object-{i}', s3.BucketObjectArgs( bucket=bucket.id, key=str(i), ) ) Even so, Pulumi YAML has a "com…

I'm aware of the SDKs, but we don't want them because they are an imperative interface, no matter how you want to spin it as "declarative". I have access to all the imperative constructs in the underlying language and can create conditional execution without restriction.

Even if I use the Yaml compiler for CUE (which we did) I still have to write `fn::` strings as keys, which is ugly and not the direction our industry should go. Let's stop putting imperative constructs into string, let's use a better language for configuration, something purpose built, not an SDK in an imperative language. These "fn::" strings are just bringing imperative constructs back into what could have been an actual declarative interface. Note, Pulumi is not alone here, there are lots of people hacking Yaml because they don't know what else there is to do. CEL making it's way to k8s is another specific example.

This cannot be the state-of-art in ops, we can do much better, but I get that Pulumi is trying to reach a different set of users than devops and will end up with different choices and tradeoffs

(I maintain https://cuetorials.com and am very active in the CUE community)

Re: The OpenTF Manifesto

#256

Post by Atotalnoob »

hdaz0017 wrote: post #204
brikis98 wrote: post #26

Earlier quoted context omitted.

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?

What is the nagios effect?

Re: The OpenTF Manifesto

#257

Post by latchkey »

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

Earlier quoted context omitted.

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.

> 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?

Re: The OpenTF Manifesto

#258

Post by bloopernova »

new23d wrote: post #175

As an end-user, not competing with HashiCorp, this change doesn't worry me. According to their FAQ [1]: 10. What are the usage limitations for HashiCorp’s products under BSL? All non-production uses are permitted. All production uses are allowed other than hosting or embedding the software in an offering competitive with HashiCorp commercial products, hosted or self-managed. 24. Can I host the HashiCorp products as a…

It's more that hashicorp leadership has shown themselves to be untrustworthy custodians of an infrastructure tool.

Re: The OpenTF Manifesto

#259

Post by candiddevmike »

ghshephard wrote: post #239
hdaz0017 wrote: post #183

Earlier quoted context omitted.

There is a big difference though Terraform is the out and out winner in its market. All their other products are at best small x% share of a crowded market or dominated by another product.

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.

Re: The OpenTF Manifesto

#260

Post by oars »

mdaniel wrote: post #170
ddon wrote: post #109

Earlier quoted context omitted.

Impossible to read, behind a paywall... why people post stuff to Medium is a big mystery to me :) Here is how your post looks like: https://postimg.cc/Pvwdw8D3

Let me introduce you to my go-to for that bullshit: https://scribe.rip/@DiggerHQ/diggers-statement-on-the-hashic... courtesy of: https://news.ycombinator.com/item?id=28838053

Thanks for sharing Scribe which can help me read Medium articles with an alternative front end that bypasses the paywall.
Post reply on HN