Gruntwork here. You can find our statement here: The Future of Terraform must be open—our plan and pledge to keep Terraform open source. https://blog.gruntwork.io/the-future-of-terraform-must-be-op... If you want to help us keep Terraform open source, please show your support at https://opentf.org/ !
Great to see your commitment but I'm also curious why you, unlike some other companies, have chosen not to support with any full time employees? It seems your business is largely based on Terraform and saying pretty much "we'll contribute code" doesn't signal too much commitment. I realize my comment might sound like an accusation but that's not my intention, I want to hear your reasoning about it!
The OpenTF Manifesto
381–390 of 392 posts
Re: The OpenTF Manifesto
#382Re: The OpenTF Manifesto
#383Earlier quoted context omitted.
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, ta…
Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).
Finally, how would you manage tags as an actual resource themselves in this model?
Re: The OpenTF Manifesto
#384Earlier quoted context omitted.
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 AP…
Yeah: latency. Everything else is identical, from the software perspective. Even the distributed aspect is identical: multiple copies of software running in one OS, or multiple machines running one copy of the software, are treated virtually identically.
> it's only in the world of modern virtualization and clouds that you can start to do that through APIs
I've worked in multiple companies, starting nearly 20 years ago, that had automated the process of provisioning and re-provisioning both hardware and software across tens of thousands of machines in multiple datacenters. Without virtualization, without the cloud. Know how we did it? Same way Terraform does it. Make an API, make a tool to call it, API backend does some magic, returns result, tool does something with result. Nothing has changed except the buzzwords (and the programming languages).
Configuration management is "a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life." [1] It is not Puppet or CFengine. It is an engineering practice that is nearly 70 years old. Terraform is an implementation of it, as are many other tools, and many things that aren't software at all.
> 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.
On the contrary, the categorizations are made up by people who don't understand the history and practice of the field and confuse designers and practitioners into thinking that what they're doing is correct because "that's just what things in this category do". It's throwing out systems thinking and replacing it with a cargo cult of buzzwords and generally useless concepts.
Every week I see somebody talking about "Infrastructure as Code" as if it's a real thing. It's not. IaC just means somebody put a shell script and config file in Git. Yet they treat it like it's both revolutionary and specific to this one corner of tech. Like we haven't been version-controlling or change-managing the provisioning of computing devices for decades. People who weren't aware of standardized practices for management of fleets of devices basically had to stumble upon it, and not having any other reference, decided to give it a new name and pretend it was novel, and in the process did not learn the lessons from past decades of similar practice.
This is not just an "old man yells at cloud" rant - the point is that tech people keep refusing to learn their history, and then poorly implementing something that could have been designed much better if they'd learned their history. It's like the history of medical practice, where some areas of the globe (cough western europe cough) were embarrassingly backward because they never reached out to learn about the history, research, and best practices outside their sphere. They just did what everyone else around them did. People suffered for decades as a result. We don't suffer quite as much now, but the advancement of technology does suffer as a result of the industry's stodgy refusal to improve on its cargo cult mentality. (Repeating whatever you read in a blog post on HN is what makes things like "Infrastructure as Code" seem like a real and novel idea to people; repeat an idea enough and people just believe it and repeat it too)
Another example: "declarative configuration". All configuration is declarative. Even imperative configuration is declarative. This tautology is debated in blog posts the same way you'd debate the use of types of butter in cooking. It's all just butter. Yeah, some comes without salt; just add some salt to your dish. Yeah, some comes with salt; just withhold some salt from your food. We don't need to go on long-winded writings about the use of different butters. But some people create entire software projects dedicated to one kind of butter, because they think it's super important to only use unsalted butter.
Re: The OpenTF Manifesto
#385Earlier quoted context omitted.
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 authori…
But if you have two programs what exchange secrets between multiple instances of each other, (one can do CRUD, the other only Read), you'd have much more interaction. Same as with a system creating secrets and a human reading it.
As for where it would make no sense at all: automated workload identities where you get time-limited temporary credentials that represent a role; most public clouds have some sort of link-local API, an injection method or mount method to provide ever-rotating secrets which gets picked up by the client SDK automatically. If you are using something like AWS, you'd be able to consume hundreds of services without ever persisting a secret anywhere.
This is also where my 'cloud' (and K8s) remarks are based on; when your workload and your resources speak the same authn/authz with a centrally coordinated policy system, there really isn't much value in adding something in the middle of that, and as such you don't see a lot of Vault and Vault-like implementations.
That said, as soon as you add something disconnected like local virtual machines, on-prem stuff etc. where authentication has historically been extremely bad and unless you brought a proper Kerberos setup you're screwed beyond mitigation. That's where Vault (when it came out) delivered a lot of value. It's probably also why we see AWS, IBM, GCP, Azure, in the same list with Vault and CyberArk. I'm surprised VMware doesn't have anything yet, but perhaps they recognise they lost this one already.
Re: The OpenTF Manifesto
#386Earlier quoted context omitted.
> 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, ta…
There may be no services at large that don’t support tagging (certainly was historically not the case though), but there a hundreds of resources that don’t. Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers). Finally, how would you manage tags as an actual resource themselve…
> Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).
You can fix your IAM. Cost allocation tags are treated specially.
> Finally, how would you manage tags as an actual resource themselves in this model?
Why would you do that?
Re: The OpenTF Manifesto
#387Earlier quoted context omitted.
Don't you think you should check yourself before attacking others? > "it's unclear to me which of the parties you intend to accuse of doing the moral equivalent of burning innocent people alive en masse, but either way, maybe you should think about walking back that rhetoric a bit" ... but only earlier today were you equating a data protection law with the Holocaust... seems you could do with a bit less projection an…
this is careless reasoning; rather than equating a so-called 'data protection law' with the holocaust, i said the justification others were using for that law was incorrect, because if it were correct, it would also justify the holocaust this is not an extremely advanced form of logic, but i understand that it is not within everyone's grasp the comment in question is https://news.ycombinator.com/item?id=37147305 octa…
Once again you jump to mansplaining and condescension, followed by failing to even get a username correct when it's literally on your screen.
Your repeated attempts to tell people what they think, what they do or do not know, and where they live, show that every observation of you being arrogant, condescending, and disingenuous, is patently correct.
Unsure if you need a shovel to get out of that hole you've put yourself in, but you're sure backpedaling quickly, yikes.
Re: The OpenTF Manifesto
#388Earlier quoted context omitted.
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!
Then a group of people who are users of idea and actually making money off it with value-adds step up to maintain it as a community project ensuring that it stays open for everyone -- yeah those guys are the assholes. Terraform would have went nowhere if it wasn't OSS and Terraform would be nothing without its outside contributions that make up far more than the code of Terraform core itself. There's a trail of bodies to prove it.
And you should love this, projects that are stewarded by its own users are incentivized to make it the best it can be instead of rejecting contributions because it competes with their cloud offering [1]
Re: The OpenTF Manifesto
#389Earlier 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…
Re: The OpenTF Manifesto
#390> When any company releases their tool as open source, the contract with the community is always the same... There is no contract. Try to enforce it. Even non-binding expectations differ widely among projects. > We believe that HashiCorp should earn a return by leveraging its unique position in the Terraform ecosystem to build a better product, not by outright preventing others from competing in the first place. Nobo…
There are social contracts