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

IBM completes acquisition of HashiCorp

newsroom.ibm.com

Post reply on HN
Print view View original

351–360 of 407 posts

Re: IBM completes acquisition of HashiCorp

#351

Post by JohnMakin »

linuxftw wrote: post #303
goodoldneon wrote: post #101

Earlier quoted context omitted.

IIRC, the lifecycle hook only prevents destruction of the resource if it needs to be replaced (e.g. change an immutable field). If you outright delete the resource declaration in code then it’s destroyed. I may be misremembering though

I find this statement to be technically correct, but practically untrue. Having worked in large terraform deployments using TFE, it's very easy for a resource to get deleted by mistake. Terraform's provider model is fundamentally broken. You cannot spin up a k8s server and then subsequently use the k8s modules to configure the server in the same workspace. You need a different workspace to import the outputs. The net…

This sounds like an operational issue and/or a lack of expertise with terraform. I use terraform (self hosted, I guess you’d call it?) and manage not only kubernetes clusters but helm deployments with it just fine and without the issues you are describing. Honestly, this is just my honest feedback, I see things and complaints a lot like this in consulting, where they expect terraform to magically solve their terrible infrastructure and automation decisions. It can’t, but it absolutely provides you the tooling to avoid what I think you are describing.

It’s fair to complain that terraform requires weird areas of expertise that aren’t that intuitive and take a little bit of a learning curve, but it’s not really fair to complain that it should prevent bad practices and inexperience from causing the issues they typically do.

Re: IBM completes acquisition of HashiCorp

#352

Post by brudgers »

danw1979 wrote: post #236
brudgers wrote: post #48

Earlier quoted context omitted.

Who's the target audience for this pricing that can afford this? The kind of customers it is good to have. Because filtering out price sensitive customers is a sound business strategy. As a rule of thumb, solve any problem your customer might have. Except not having money.

We are not talking about price sensitive customers though. Hashicorp shut out all customers who wanted a fixed price agreement with RUM.

Fixed price customers can be good customers.

A good customer makes it easier to stay in business.

For fixed price customers that means paying a premium over time and materials.

If a customer pays more under time and materials pricing, they were not a good customer because they were making it harder to stay in business.

Re: IBM completes acquisition of HashiCorp

#353

Post by tiberious726 »

cyberpunk wrote: post #266
throwaway2037 wrote: post #197

Earlier quoted context omitted.

If RHEL is becoming irrelevant, what distro will replace it for enterprise users?

We don’t run anything on bare metal anymore it’s all containers (90k employee very large enterprise). Of course I can’t speak for all the teams, but all new projects are going out on kubernetes and we don’t care about rhel at all, typically it’s alpine it Debian base images

So Red Hat Openshift.

Re: IBM completes acquisition of HashiCorp

#355

Post by dpe82 »

jl6 wrote: post #248
avhception wrote: post #238

Earlier quoted context omitted.

I second the TUI argument here. Back in ... maybe 2005 or what, in our ~60 people family business, I had the pleasure to watch an accountant use our bespoke payroll system. That was a DOS-based app, running on an old Pentium 1 system. She was absolutely flying through the TUI. F2, type some numbers, Enter, F5 and so on and so on, at an absolutely blistering speed. Data entry took single-digit seconds. When that was c…

Not just accountants. I remember watching fully “non-technical” insurance admin / customer service people play the green screen keyboard like they were concert pianists. People can cope with a lot when they have to.

I worked at Best Buy as a high school teenager just before they switched the green screens to some GUI monstrosity. Everyone in the store had to learn how to use the green screens (sales people, cashiers, techs, stockers - everyone) and after a few weeks / months you would get CRAZY fast.

A few years later in college I worked there again and by that point they'd transitioned to a much slower GUI that basically just wrapped the underlying green screen system. The learning curve was slightly better, but it wasn't nearly as fast.

Purpose-built mainframe-based TUIs were amazing. We lost a lot in pursuit of colored pixels.

Re: IBM completes acquisition of HashiCorp

#357

Post by cyberpunk »

cmsj wrote: post #288
cyberpunk wrote: post #266

Earlier quoted context omitted.

We don’t run anything on bare metal anymore it’s all containers (90k employee very large enterprise). Of course I can’t speak for all the teams, but all new projects are going out on kubernetes and we don’t care about rhel at all, typically it’s alpine it Debian base images

You have a hardware implementation of Docker?

When I say "we don't run anything on" I mean our involvement in the infra begins after those layers; sure, maybe someone at google cloud is doing rhel stuff but we don't care. Push button receive kubeconfig.

Re: IBM completes acquisition of HashiCorp

#358

Post by nightpool »

OJFord wrote: post #172
nightpool wrote: post #158

Earlier quoted context omitted.

This works great for toy examples and fails the moment you have 1 (one) module

It doesn't fail, but you're right you can't reach inside submodules with terraform console; I wish you could.

It "fails" in that I cannot use it to debug my code or print out outputs like the . In general, Terraform's debuggability story is very poor, and the DX tools (like the VS Code plugin) are lacking

Re: IBM completes acquisition of HashiCorp

#359

Post by trallnag »

JohnMakin wrote: post #351
linuxftw wrote: post #303

Earlier quoted context omitted.

I find this statement to be technically correct, but practically untrue. Having worked in large terraform deployments using TFE, it's very easy for a resource to get deleted by mistake. Terraform's provider model is fundamentally broken. You cannot spin up a k8s server and then subsequently use the k8s modules to configure the server in the same workspace. You need a different workspace to import the outputs. The net…

This sounds like an operational issue and/or a lack of expertise with terraform. I use terraform (self hosted, I guess you’d call it?) and manage not only kubernetes clusters but helm deployments with it just fine and without the issues you are describing. Honestly, this is just my honest feedback, I see things and complaints a lot like this in consulting, where they expect terraform to magically solve their terrible…

Terraform explicitly recommends in the Kubernetes provider documentation that the the cluster creation itself and everything else related to Kubernetes should live in different states.

https://registry.terraform.io/providers/hashicorp/kubernetes...

> The most reliable way to configure the Kubernetes provider is to ensure that the cluster itself and the Kubernetes provider resources can be managed with separate apply operations. Data-sources can be used to convey values between the two stages as needed.

Re: IBM completes acquisition of HashiCorp

#360

Post by adastra22 »

bayindirh wrote: post #311
ghaff wrote: post #308

Earlier quoted context omitted.

Red Hat bringing CentOS in-house (well before IBM entered the picture) was IMO one of the first in a string of expedient decisions that were... unfortunate. When I was at Red Hat I loudly argued against some of the ways things were handled but I also understand why various actions were taken when they were. I'd also argue that CentOS classic was mostly bug for bug compatible but probably close enough for most. It sha…

That closeness allowed CentOS to be a drop-in replacement for RHEL for thousands of installations and exotic hardware combinations. Unfortunately, we don't have this capability anymore. Rocky bears most of that load now.

Despite being a debian/ubuntu guy, I usually used CentOS for production deployments because it would be easy and seamless to upgrade to RHEL when I hit the big leagues.

Not anymore. I just use the latest ubuntu LTS and call it a day.

IBM/RedHat was soo predictably short sighted on this.

Post reply on HN