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

371–380 of 392 posts

Re: The OpenTF Manifesto

#371

Post by jen20 »

cyberax wrote: post #369
aequitas wrote: post #333

Earlier quoted context omitted.

You can’t implement this kind of tooling with the features is provides without the state.

You can, for most of the cases. You just need a way to tag resources as belonging to the tool. This can be done via prefixed (or suffixed) names, tags, etc.

That… is state, just stored elsewhere. It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.

Terraform having state wasn’t some easy button decision, it was absolutely required and carefully considered.

Re: The OpenTF Manifesto

#372

Post by i4k »

theowawayhs wrote: post #43

Once a prolific commentator, Mitchell Hashimoto has gone quiet here for over 50 days now. His GitHub activity seem to indicate he is now focused on the Zig programming language.

yes, I really hope he says something about it.

Re: The OpenTF Manifesto

#373

Post by eraser215 »

Spivak wrote: post #163
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…

I don't get this one, you pick OpenTerraform and get on with your life. It's the same with picking OpenSearch over Elastic. I can use the proprietary version that locks me into a single profit-seeking vendor and doesn't have community backing or the one run by a foundation made up of companies that use and are heavily invested in Terraform.

How dare a vendor come up with an idea, pay people to execute on that idea, and the gasp try to make money from it? Outrageous!

Re: The OpenTF Manifesto

#374

Post by sevagh »

jen20 wrote: post #236
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.

Well, if that's something you _actually_ want, take a look at Pulumi, which does precisely what you ask.

What's preventing Pulumi from making a license change in the future?

Re: The OpenTF Manifesto

#375

Post by sevagh »

cconstantine wrote: post #203
0xbadcafebee wrote: post #142

Actually, can we just kill Terraform? Please? Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at al…

I've been using terraform for 10-ish years, and this is very much not how I feel about it. Terraform absolutely makes life easier; I've managed infrastructure without it and it's a nightmare. Yes, it can be awkward, and yes the S3 bucket resource change was pretty bad, but overall its operating model (resources that move between states) is extremely powerful. The vast majority of "terraform" issues I've had have actu…

I'm no Terraform expert but it's been in my resume and toolbox since ~2016.

Up until these changes, I would always pick Terraform for managing AWS. I have my gripes with it but it has been the best choice (as the saying goes, anybody that uses a tool long enough should have complaints about its limitations).

Now, however, I'm finally thinking of going with the CDK to insulate myself from more seismic shifts in the "OSS ecosystem" of devops tools.

Re: The OpenTF Manifesto

#377

Post by cyberax »

jen20 wrote: post #371
cyberax wrote: post #369

Earlier quoted context omitted.

You can, for most of the cases. You just need a way to tag resources as belonging to the tool. This can be done via prefixed (or suffixed) names, tags, etc.

That… is state, just stored elsewhere. It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits. Terraform having state wasn’t some easy button decision, it was absolutely required and carefully considered.

> That… is state, just stored elsewhere.

The state is stored in the resources themselves, to be precise.

> It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.

As someone who worked on tagging inside AWS, I don't believe that there are any major AWS services left that don't support tagging. These days, tagging-on-creation also guarantees that you won't have untagged resources if your provider happens to die between "CreateResource" and the "TagResource" operations.

You can also sometimes use prefixed names to signal that a resource belongs to the infrastructure-as-code.

API limits for "describe" calls are also pretty lax. And you need to use them anyway to check if the current state of the world matches with the saved state.

State will be needed for some integrations that don't support tagging/naming (Okta, I'm looking at YOU!), but at least for AWS it's not needed.

Re: The OpenTF Manifesto

#378

Post by dbingham »

throwawaaarrgh wrote: post #248
dbingham wrote: post #202

Earlier quoted context omitted.

Infra is defining the servers that should be running. Config is writing configuration files to a running server. Cloud blurs the line, since a lot of cloud offerings are managed where you're really doing both at once when you define the managed offering.

Let's not continue this cargo cult mumbo jumbo. Terraform is literally a program that looks at a declarative configuration file, looks at a state file, queries some APIs, and then submits some API calls. That is all it does. There is no "infrastructure", or "config", or "cloud". It's literally just calling HTTPS APIs, the same way it would call a system call or a library function. Call function, pass input, receive o…

Yes and no. Yes, all terraform does is wrap APIs and you could easily write a Terraform provider for just about anything.

But there is a very real difference between "Deploying a server" and "Modifying configuration files on that server". The former used to require actual physical actions in a data center and it's only in the world of modern virtualization and clouds that it has become possible to do it through an API. Where as the latter used to require secure access to an individual physical machine, often over SSH after someone had done the physical work of setting it up. Again, it's only in the world of modern virtualization and clouds that you can start to do that through APIs.

It is only modern clouds that has blurred the lines between these two by abstracting away the difference between the physical server and the software running on it behind APIs.

Conceptually, it can still useful to think of "infrastructure orchestration" and "configuration management" as different things and different categories. Like I said, in many cases cloud offerings significantly reduce the utility of those categorizations - because they often abstract both steps behind a unified API where you are launching virtual infrastructure (still largely using the same conceptions that were used when it was physical) and defining its configuration at the same time through the same interface.

None of this is marketing speak. It's just definitions and categorizations. Sometimes useful, sometimes not. And all of it is orthogonal to what terraform does do or should do. Whether or not terraform is "infrastructure orchestration", "configuration management" or both is neither here nor there for the definition of those terms and considerations of their utility.

Re: The OpenTF Manifesto

#379

Post by nikolay »

jen20 wrote: post #234
nikolay wrote: post #219

Earlier quoted context omitted.

It should worry you - it hurts the ecosystem. Terraform is just a tool. The providers, modules, not supported by HashiCorp, is what makes Terraform useful. Ige the ecosystem dies, Terraform becomes useless.

The ecosystem outside of providers is far less important than people like to claim. Open source modules are almost all poorly scoped, often just wrapping a single resource completely unnecessarily - simultaneously over- and under-abstracted. It's also a huge security risk to pull them in.

That's really not the case. Most of the provider I use are third-party - Datadog, Cloudflare, GitHub, PostreSQL, RabbitMQ, MySQL, and tons more. Regarding the module - you should choose them the way use you any other third-party library. I use reputable modules for many things that save me tons of work.

Re: The OpenTF Manifesto

#380

Post by ghshephard »

oneplane wrote: post #355
Alupis wrote: post #353

Earlier quoted context omitted.

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

We use vault as a framework that associates authentication with secret engines via a policy framework. The Secret Engines could be AWS, PostGres Database, PKI, SSH Certificate Signer, Key value stores, etc... and the Authentication Framework might be LDAP, OKTA, or plain tokens. The Policy framework is pretty dynamic and has many thousands of possible policies mapping various authenticated entities to various authority (read, list, write, etc...) to various secret engines. Combine that with the syntactic niceties of template-rendering integration with the chosen secret-store, and maybe some clever stuff around single-use token wrapping - and I think of all of those features as belonging to a single product.

I'm relatively new to this field - and see tons of Vault at colleagues companies, and have friends who run/support Conjur (Enterprise more than cloud). Those are the only two secret-management framework/products I'd hear of - so was interesting in knowing what else had mindshare.

Post reply on HN