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
"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."
> 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.
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
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!
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?
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.
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.
32 comments
[ 2.0 ms ] story [ 69.2 ms ] threadI laughed...
> 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.
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.
terraform apply ALWAYS charges you money!! Use caution because this action will put more on your plate not theoretically but *physically
But also a pizza probably costs a bit more than 15 minutes of whatever resource size you'd use for debugging tf configurations.
Good fun ordering pizza from your favorite tools!
Curious how you'd ammend this in the design?