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

281–290 of 392 posts

Re: The OpenTF Manifesto

#281

Post by VectorLock »

yonixwm wrote: post #132
mousetree wrote: post #128

As a regular end-user of Terraform, what difference does BSL vs MPL make to me? From reading this article it seems not very much? Perhaps I'm misreading this.

I think you will be affected by the bigger picture. Mongo did this move also but there they were mostly in control before and after. Here there is a huge community of plugins. If before AWS shared a provider without hesitating, now they will ask themselves why contribute to a closed and possibly competitor garden.

AWS has had a Terraform competitor for a long time; CloudFormation. I'm not sure how much they contribute to Terraform, some I think, but most of the AWS provider for Terraform to my knowledge is developed and owned by Hashicorp. If AWS just stopped contributing to Terraform development, I think it would have effectively zero difference.

Re: The OpenTF Manifesto

#282

Post by VectorLock »

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…

I don't think you can just "fork it." Hashicorp already owns all that code because they make contributors sign it away to them.

Re: The OpenTF Manifesto

#283

Post by bifrost »

anyoneamous wrote: post #265
fishnchips wrote: post #254

Earlier quoted context omitted.

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.

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.

I concurr.

Re: The OpenTF Manifesto

#284

Post by Alupis »

oneplane wrote: post #263
ghshephard wrote: post #239

Earlier quoted context omitted.

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.

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 this secret in VCS or viewable via kubectl".

Re: The OpenTF Manifesto

#285

Post by scrum-treats »

mardifoufs wrote: post #243
scrum-treats wrote: post #225

Earlier quoted context omitted.

Didn't Docker actually try it earlier this year, e.g., https://blog.alexellis.io/docker-is-deleting-open-source-ima... ?

That's just hosting though iirc. Docker hub is very important, but it's not really part of Docker the software. As in, you could deploy your own container registry with 0 licensing issues. They just didn't want to pay the bandwidth costs anymore, though I think they walked back on that for open source images.

Got it. Thanks for the clarity.

Re: The OpenTF Manifesto

#286

Post by kragen »

tedivm wrote: post #270
kragen wrote: post #264

Earlier quoted context omitted.

it's not a possible schism. hashicorp has clearly and unmistakably abandoned the open source community. conceivably they'll change their minds, but their communication doesn't have any ambiguity in it i have no idea what you could possibly mean by 'focus on the "civil"'. it's good that people are being civil to one another, isn't it? then why are you criticizing them?

You're missing the point- the OpenTF group wants to mend the schism if possible, by getting Hashicorp to change their licensing back. If they immediately fork then that's not likely to happen, so they're attempting this first. I don't think it will work, but I think it's good of them to try.

mending the schism would be great, but we probably can't do that by pretending it doesn't exist like https://news.ycombinator.com/item?id=37139929, or analogizing it to blowing thousands of children's extremities off, or analogizing acknowledging its existence to blowing thousands of children's extremities off

I'm still not sure which of the latter two was the intent of the comment I was responding to

Re: The OpenTF Manifesto

#288

Post by lmm »

enneff wrote: post #242
RcouF1uZ4gsC wrote: post #221

Earlier quoted context omitted.

> it is an equivalent of a civil war. Why. It is open source. A fork should be no big deal, and definitely not a “civil war”. I think the community should be quicker to fork open source projects that are not serving the needs of the community. The corporations are trying to have the benefits of open source without the responsibility. Forking is a normal, acceptable part of open source and we should normalize it.

What would it mean to “normalise” forking? The costs of maintaining a fork are significant, and if one group of programmers are being funded to work on the project then it can be very difficult to fork a project in any meaningful way without significant resources behind it. Also IIUC most of the parties in this conversation are corporations. They’re all trying to enjoy the benefits of open source development for a va…

> The costs of maintaining a fork are significant

Why? If we have tooling or workflows that assume forks don't happen, maybe we can fix those. Forking should be cheap, easy and frequent.

Re: The OpenTF Manifesto

#289

Post by cyberax »

rank0 wrote: post #246
cyberax wrote: post #76

Terraform core is kinda crappy. The language is awful, and the module infrastructure sucks. I would support (with my own money) a fork that would re-use the Terraform providers, and reimplement the language as something not so insane.

Any reason why you don’t like cloudFormation or the SDKs?

They are EVEN MORE crappy than TF.

Re: The OpenTF Manifesto

#290

Post by lmm »

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…

An imperative for loop is somehow declarative now? Lol.
Post reply on HN