Seems a bit convoluted.

Compare for example, event sourcing. In that case, you keep a log of all actions taken, and determine the current state by replacing that log.

Here, you have an action that you want to take (order a pizza). But you can't just do that directly, because it's too simple. So instead you tell yourself "I currently have 0 pizzas" (the initial empty state file) and "I want to have one pizza" (your configuration), and you ask it "how do I get there from here".

And then after that is where the real trouble starts. You eat your pizza. You now have resource drift. If you try to correct that drift (does this provider even implement that?), terraform will think it needs to order you another pizza, because it still thinks you want to have one pizza. If you don't fix the drift, then next time you want a pizza you'll have to tell it that actually you want two pizzas. Because what you actually want is an action, but you have to work backwards from the current state (or rather, what terraform thinks the current state is) and what state to tell it you want in order to make it calculate they action.

All of which is more or less the opposite of event sourcing. Instead of wanting a state and having to apply a sequence of events to get that state, you want an event and have to calculate a sequence of state diffs that will produce that event.

"This is not a joke provider. Or, it kind of is a joke, but even though it's a joke it will still order you a pizza. You are going to get a pizza. You should be careful with this provider, if you don't want a pizza."

I laughed...

My problem with this approach is that I feel like it's the wrong tool for the job. Am I declaring the state of my pizza? Ordering pizza is inherently an imperative task, and unless we are willing to track the lifecycle of the delivery or the pizza itself I feel like we need to explore alternative solutions. Can any solutions engineers weigh in?

Author here. I got nerdsniped at 2AM a few years back, never expected to see this on HN!

Would be much more usable if it could be billed to AWS. Then I'd wire it up so my employer would be paying for a pizza with every new deployment...

This doesn't make much sense as Terraform is for declarative infrastructure. It only make sense if you have an array of orders and keep adding orders and have an order resource with a for_each where you turn that array into an object with a unique key (maybe a hash of the date and line items). What happens if you delete an order from that list, though? Well, you will also have to delete it from the state then. Anyway, this is an abuse of Terraform. Best would be an CLI or TUI.

Reminds of "pizza party" CLI back in the day: https://entertainment.slashdot.org/story/04/05/07/138238/piz...

Good fun ordering pizza from your favorite tools!

I don't use Terraform/OpenTofu anymore. Thankfully you can enjoy this in Pulumi with their new TF provider support: https://www.pulumi.com/blog/any-terraform-provider

Today I learned that dominos has a public API for ordering pizza? Or is this some reverse engineered shenanigans? I'm not a Domino's fan, but I need to find this pizzapi

Should be a makefile so you can type 'make pizza'

This is excellent! Unnecessary thought though, I'm guessing it doesn't handle idempotency? I.e. if you run it twice, you'll get two pizzas?

Curious how you'd ammend this in the design?

Do they make a tofu pizza?

Notice that this provider is banned in Italy because of the low quality infrastructure generated

“but use caution, since this is going to charge you money”

terraform apply ALWAYS charges you money!! Use caution because this action will put more on your plate not theoretically but *physically