Live data from Hacker News

The OpenTF Manifesto

opentf.org

351–360 of 392 posts

Re: The OpenTF Manifesto

#351
post #150

Earlier quoted context omitted.

I'm not Hashicorp, but I mean look at Docker. They built the most valuable devops tool of the last generation and can barely muster a viable business. Why would Hashicorp give the slightest worry to losing thousands and thousands of non-paying customers? The upside is lots of money and the downside is loss of halo. Honestly, it's an unfortunate game of expectation setting. If I wrote an open letter decrying Salesforc…

It is all about the change. HashiCorp model was open source, and now is not. Salesforce has never been open source. Would terraform have been as popular it if had never been open source? That we won't know, but we can guess.

Hello Juan!

Re: The OpenTF Manifesto

#352
opentf.org - the "tf" part

Isn't "Terraform" a copyrighted / owned word by Hashicorp? Is it somehow itself part of the MPL - the name itself?

Would then whatever opentf.org would become need a new "tf" name?

Just don't know the ins and outs on that.

Re: The OpenTF Manifesto

#353
post #284

Earlier quoted context omitted.

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…

I did not downvote you, no. Downvoting because we disagree isn't how that's supposed to work, even though some use it that way.

Regardless, the use of Vault is not exclusive to cloud environments.

All of the listed features of Vault have benefits within larger organizations even if they don't use the "cloud" and deploy monolithic applications.

Most frameworks have built in ways to fetch secrets/config from Vault, making it an easy standardized way to do things across all of your applications/teams.

It doesn't mean you need to use it, of course, but it has a lot of perks for many different situations.

Re: The OpenTF Manifesto

#354
post #275

Earlier quoted context omitted.

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

No, it's astronomically unlikely to be Vault at all.

It's far more likely to be Vault as a base, actually. The MPL would allow someone like Amazon to use Vault's source as a base, and so long as the core source wasn't modified Amazon would be under no obligation to make their modifications public.

The MPL is a lot more "business" friendly than the GPL.

The very fact that HashiCorp is changing their license and restricting use clearly indicates they see this threat as reality. Amazon/Microsoft/Google/Whoever using HashiCorp's work/effort but keeping all the money to themselves.

Re: The OpenTF Manifesto

#355
post #353

Earlier quoted context omitted.

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

I did not downvote you, no. Downvoting because we disagree isn't how that's supposed to work, even though some use it that way. Regardless, the use of Vault is not exclusive to cloud environments. All of the listed features of Vault have benefits within larger organizations even if they don't use the "cloud" and deploy monolithic applications. Most frameworks have built in ways to fetch secrets/config from Vault, mak…

I totally agree that Vault is more than a glorified password manager (because that's what most Clouds have in their implementation of a secrets store), but the thing is, everywhere I go, I don't see people use Vault, I see them use whatever AWS/Google/Azure happens to have (and often badly).

I'm not sure if that's even what ghshephard meant when he was curious for 'products', since technically all those cloud-integrated services aren't really stand-alone products for that matter.

In AWS for example, with or without EKS (and then something like External Secrets Operator in the EKS case), it's all just AWS Secrets Manager and sometimes Parameter Store. In a few cases people do manual encryption (using KMS), but in no case was HashiCorp Vault used.

Often, it's even worse: no secrets management at all. Stuff just gets pumped into environment variables (more often than not they get committed as .env files to Git), and there's just no drive to change that, even when a business policy is in place. Some even 'work around' this by storing secrets in password managers like 1Password and LastPass so they can check the compliance box without actually protecting the secrets (since they also live in plain text in VCS and at runtime in the environment).

In terms of 'products', I'd say Vault and the cloud ones don't really compare, but reality is depressing and secrets are often not as secret as the name implies. From a developer perspective, they might compare them because they desire the secrets to be injected into the environment either way, and as such the source doesn't matter much. I'm not sure if we should see that as a feature or a bug.

Re: The OpenTF Manifesto

#356

Earlier quoted context omitted.

The claim above isn't "imperative is impossible".

The claim above is that Pulumi uses an imperative interface and that it is quite easy to slip past the declarative guardrails, so in most cases Pulumi is imperative, not declarative. The fact that Pulumi makes this separation opaque can be discussed, as can the clear separation be shown an alternative with benefits The claim I keep seeing from Pulumi folks is that Pulumi is declarative, which is is not, as shown in m…

The claim above was that a for loop implied that the code couldn't be declarative.

> Please stop calling it such

I'm not claiming it is always declarative, I'm only claiming that a declarative example above can contain a for loop, and that laughing at that is the wrong response. That's it.

Re: The OpenTF Manifesto

#357
post #354

Earlier quoted context omitted.

No, it's astronomically unlikely to be Vault at all.

It's far more likely to be Vault as a base, actually. The MPL would allow someone like Amazon to use Vault's source as a base, and so long as the core source wasn't modified Amazon would be under no obligation to make their modifications public. The MPL is a lot more "business" friendly than the GPL. The very fact that HashiCorp is changing their license and restricting use clearly indicates they see this threat as r…

I don't know what you've heard but none of the cloud providers use HashiCorp Vault as the foundation for their secrets manager.

Re: The OpenTF Manifesto

#358

Earlier quoted context omitted.

The claim above is that Pulumi uses an imperative interface and that it is quite easy to slip past the declarative guardrails, so in most cases Pulumi is imperative, not declarative. The fact that Pulumi makes this separation opaque can be discussed, as can the clear separation be shown an alternative with benefits The claim I keep seeing from Pulumi folks is that Pulumi is declarative, which is is not, as shown in m…

The claim above was that a for loop implied that the code couldn't be declarative. > Please stop calling it such I'm not claiming it is always declarative, I'm only claiming that a declarative example above can contain a for loop, and that laughing at that is the wrong response. That's it.

> Please stop calling it such

That was more me yelling into the void or larger thread than at anything specific you said, sorry :]

Re: The OpenTF Manifesto

#359
post #354

Earlier quoted context omitted.

No, it's astronomically unlikely to be Vault at all.

It's far more likely to be Vault as a base, actually. The MPL would allow someone like Amazon to use Vault's source as a base, and so long as the core source wasn't modified Amazon would be under no obligation to make their modifications public. The MPL is a lot more "business" friendly than the GPL. The very fact that HashiCorp is changing their license and restricting use clearly indicates they see this threat as r…

Yes, they could, but no major cloud provider does. They're all bespoke. Read their white papers and it'll make more sense.

Re: The OpenTF Manifesto

#360
From Hasicorp’s perspective this license change is less about Terraform and mostly about Vault. Terraform Enterprise isn’t very successful. Their cloud offering for Terraform isn’t competitive with a basic GitHub actions workflow. They’ve learned this the hard way.

With Vault they’ve just recently launched their new cloud secrets service. Most of their revenue comes from Vault. Nearly all of their future revenue growth is vault. Any competitor could relatively easily provide the same service with vault FOSS today. Vault is feature complete. The only moat they have is their license.

Best for the ecosystem if both Vault and Terraform are maintained by a foundation. Not best for Hashicorp, but best for the industry for sure.

Post reply on HN