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.
Proposal: Apply a ceiling function to your pizza-counting algorithm and always leave the last slice in the freezer. Then simply throw out that slice when you want a new pizza!
"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 personal favorite bit:
> 8) As far as I know, there is no programmatic way to `destroy` an existing pizza. `terraform destroy` is implemented on the client side, by consuming the pizza.
10/10 infrastructure-as-code-based humor.
Dinner as code
I laughed at "it's pretty good. It's all right. Regular Dominos."
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?
The solution here creates Orders, not Pizzas. Therefore the lifecycle of the delivery is captured by Order itself.
Author here. I got nerdsniped at 2AM a few years back, never expected to see this on HN!
Do you have to run destroy first to order the same order again a second time?
I’d imagine taint would also do the trick.
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...
There's the AWS Marketplace, so, it's possible.
How do you imagine this? The underlying infra depends on the API, and the API requires a valid CC to order. Even if you know the CC data of your employer that is being used for AWS, and you decided to specify it in the configuration of Dominos Pizza TF provider, that would be no different from stealing someone else's money.
I wasn't really being serious...
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
oh, "any tf provider" support - i was going to say it at least supported some (esp when folks switched after the lic change); but nice indeed! i did not realize it was limited until now
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
Angry 4AM reverse engineering. Why does the spinach addon require "f: {}" ???
It's "unofficial" - https://news.ycombinator.com/item?id=23249545
Should be a makefile so you can type 'make pizza'
That's gotta be for a sandwich shop, so we can finally `sudo make sandwich`
Should be pretty easy to wrap it. Now I'm craving for a good Calzone...
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?
No, but Italian Pulumi is a topping option
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
Well, usually I think it charges your employer money.
But also a pizza probably costs a bit more than 15 minutes of whatever resource size you'd use for debugging tf configurations.
No, terraform apply will not always charge money. There are countless resources that do not cost any money.