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

111–120 of 392 posts

Re: The OpenTF Manifesto

#111

Post by busterarm »

bastardoperator wrote: post #82

Ask Roblox employees how they feel about Hashicorp products. Terraform is probably the most solid product they have seconded by vault, but after hearing the consul and nomad horror stories, I don't think I could take their products seriously ever, not when kubernetes is setting right there.

> not when kubernetes is setting right there.

Enjoy spending the rest of your life trying to get etcd to cooperate. If you think operating Kubernetes at scale is a cakewalk, you don't have the scale problems you think you do.

I'll take consul over etcd ten million times out of ten.

Re: The OpenTF Manifesto

#112

Post by busterarm »

fishpen0 wrote: post #104
busterarm wrote: post #52

Earlier quoted context omitted.

Hashicorp isn't going to budge here. The same argument that you've made about Terraform being the underpinnings and needing to be open-sourced can be applied to their other important products like Vault, Consul and Nomad as well. The ecosystem of those three is plainly a direct competitor to Kubernetes which is open-source. There's really no move for them to make here. It's unfortunate.

Tons of organizations run vault and consul as part of their k8s ecosystem so they don't directly compete. The vault CSI driver might be the single most installed CSI driver across all the orgs I've worked for

You're completely missing it.

If you are running Nomad as your orchestrator, because of the tight integrations you are almost certainly running vault for secrets and consul for service discovery/service mesh. The ecosystem of the three is the competitor to K8s.

s/ someone who runs both ecosystems at scale.

Re: The OpenTF Manifesto

#113

Post by jupp0r »

iojs comes to mind. This is the beauty of open source in action.

Long living forks and fragmentation sucks, but now HashiCorp has to react to this and provide compelling benefits if they don't want to loose the whole project alltogether.

Re: The OpenTF Manifesto

#114

Post by candiddevmike »

empressplay wrote: post #103
tedivm wrote: post #49

Earlier quoted context omitted.

Sorry, this may be a miscommunication. Terraform itself has a test suite, yeah, but it doesn't have a testing framework that users of the language can use to test their own code. To make a python metaphor, if cpython had a testing suite but pytest didn't exist then people wouldn't be able to test their own python code. That's kind of the situation with Terraform right now- you can't test your code using just the Terr…

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.

Re: The OpenTF Manifesto

#116

Post by lawnchair »

bcantrill wrote: post #89

We at Oxide were honored to be asked to add our name to OpenTF Manifesto. Our statement: At Oxide, our vision has been that on-premises infrastructure is deserving of a system consisting of both hardware and software, at once integrated and open. Ensuring Terraform users can easily deploy to Oxide has been essential for realizing this vision: we want customers of an Oxide rack to be able to use the tools that they kn…

Thanks Bryan!

Re: The OpenTF Manifesto

#118

Post by lamontcg »

miah_ wrote: post #99
lamontcg wrote: post #60

Earlier quoted context omitted.

Smells like the end of Chef. Management doesn't understand how much it takes to maintain the open source project and is just pouring resources into sales and marketing and products that they can charge for, and don't see how that erodes goodwill and the technological foundation of the company.

I also saw that parallel with Chef. I think its the story of all VC funded software that attempts to be "Open Source". For them, Open Source means "You can read the source code, and potentially fix a bug", for us, it means community, transparency, and fixing bugs beyond those your paying customer has. I looked at github /chef/chef and github /inspec/inspec and its the same as it was shortly after I left. The only cha…

There was a whole lot of community window dressing going on. I still wonder if they weren't trying to ship maintenance of the open source code off onto the community thinking that if all that worked appeared (or thinking that it was actually going on--believing their own bullshit about how involved the community was) that they could just leach that work.

There's probably some manager at Hashi right now trying to argue that they should offload TF maintenance entirely onto the community and they should pivot to hosting services and consulting and making money off of all that free work.

Re: The OpenTF Manifesto

#119

Post by justincormack »

rwmj wrote: post #105
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.

We changed the license[1] of a project which had 10 contributors, and we got every single one of them to do an Acked-by (by email) which took some weeks. That was on the advice of our lawyers. Can't imagine the impossible hassle of doing the same for something like Linux. [1] https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...

It has been done for some fairly large projects, eg openssl managed to swith to Apache for 3.0. It is a lot of work.

Re: The OpenTF Manifesto

#120

Post by twunde »

busterarm wrote: post #112
fishpen0 wrote: post #104

Earlier quoted context omitted.

Tons of organizations run vault and consul as part of their k8s ecosystem so they don't directly compete. The vault CSI driver might be the single most installed CSI driver across all the orgs I've worked for

You're completely missing it. If you are running Nomad as your orchestrator, because of the tight integrations you are almost certainly running vault for secrets and consul for service discovery/service mesh. The ecosystem of the three is the competitor to K8s. s/ someone who runs both ecosystems at scale.

While the Nomad stack is a direct competitor to k8s, Consul and Vault are both heavily used alongside k8s. In fact, Consul had features that were only for k8s the last time I checked
Post reply on HN