thanks @matt-ffffff good to see this landing (especially as I was a proponent of the previous way - it sure seemed sensible at the time to reduce the inputs a consumer has to worry about 🙂). Lesson well learnt! I love that AVM is becoming this central standard where these sorts of problems can surface through shared use & adoption - much better to find this now, then when you've got these design patterns embedded and sprawling everywhere!
Thanks Matt glad to hear this is being looked at! I was running in to this exact limitation the last couple days with some of the avm's that use resource group data source for fallback location. E.g storage account module. Have to use a depends_on at the moment if I want to create a resource group inline and specify same resource group name with the avm module. 99% of the time I like to explicitly provide location and I imagine others do too so making it required I don't think is too much hassle and preferred over having to use depends_on.
Hy Matt, love your videos, learned a lot from them. I’m fairly new to coding in terraform but I’m interested in getting better. I’m curious, what is the extension you’re using to show in grey the required parameters of a resource, like at 07:29 ?
You had pointed out some of the changes that looked like would be coming in 1.8. It looks like that has been deferred to 1.9 and will require a "plan time" flag to defer those dependencies. I think this is actually a misbehavior of Terraform, though. Because, whenever a plan is happening, a refresh occurs to get the latest information of those resources from the provider. This should be enough information for Terraform to absolutely know that a dependency change hasn't occurred.
Hi! Yeah I saw the new stuff in relation to deferred actions. I was going to do a follow up on it 🙂 I think the specific circumstances here are that a computed value (one known only after apply) is passed into a data source. This means the data source read cannot happen at plan time and will be done during the apply. In this case we will get the issues reported in this video.
@@matt-ffffff Yep, I completely agree. You've highlighted some things I never hear anyone else talking about, so I love your depth in your videos. I teach as a HashiCorp Authorized Instructor and try to evangelizing solid solutions to these challenges. Keep making great content! Writing modules in a very simple way is extremely valuable for all of the reasons that you have mentioned. Try to keep your opinion within your module to a minimum so that it is more flexible for others to use it. One example I often cite as a tale of caution is the Palo Alto deployment in the Azure Marketplace (though I think it has since been addressed). It would create a virtual network for you... crazy... what if I have an existing virtual network that I want to deploy it to?
Great video, much better to pass location as a standard for all modules. For those without github codepilot, Microsoft copilot does a very good job of writing regex validation. Do you recommend trying to write regular expressions using terraform's customized regex or just standard regex for easier testing?
Hi Thanks for the comment! If I am crafting my own, I use an online regex tester to start. Then I'll use terraform console to validate. If I'm being super proper I will create a terraform test with the expect_failures option... developer.hashicorp.com/terraform/language/tests#expecting-failures
thanks @matt-ffffff good to see this landing (especially as I was a proponent of the previous way - it sure seemed sensible at the time to reduce the inputs a consumer has to worry about 🙂). Lesson well learnt! I love that AVM is becoming this central standard where these sorts of problems can surface through shared use & adoption - much better to find this now, then when you've got these design patterns embedded and sprawling everywhere!
Thanks Matt glad to hear this is being looked at! I was running in to this exact limitation the last couple days with some of the avm's that use resource group data source for fallback location. E.g storage account module. Have to use a depends_on at the moment if I want to create a resource group inline and specify same resource group name with the avm module. 99% of the time I like to explicitly provide location and I imagine others do too so making it required I don't think is too much hassle and preferred over having to use depends_on.
Thanks for the comment, yes I agree - we were trying to be too clever! Lesson learned 🙂
Hy Matt, love your videos, learned a lot from them.
I’m fairly new to coding in terraform but I’m interested in getting better.
I’m curious, what is the extension you’re using to show in grey the required parameters of a resource, like at 07:29 ?
Hey! Thanks and glad you find them useful..
I have the GitHub Copilot extension installed. This helps with the suggestions in grey
@@matt-ffffff thanks. Much appreciated
You had pointed out some of the changes that looked like would be coming in 1.8. It looks like that has been deferred to 1.9 and will require a "plan time" flag to defer those dependencies.
I think this is actually a misbehavior of Terraform, though. Because, whenever a plan is happening, a refresh occurs to get the latest information of those resources from the provider. This should be enough information for Terraform to absolutely know that a dependency change hasn't occurred.
Hi! Yeah I saw the new stuff in relation to deferred actions. I was going to do a follow up on it 🙂
I think the specific circumstances here are that a computed value (one known only after apply) is passed into a data source. This means the data source read cannot happen at plan time and will be done during the apply. In this case we will get the issues reported in this video.
@@matt-ffffff Yep, I completely agree. You've highlighted some things I never hear anyone else talking about, so I love your depth in your videos. I teach as a HashiCorp Authorized Instructor and try to evangelizing solid solutions to these challenges. Keep making great content!
Writing modules in a very simple way is extremely valuable for all of the reasons that you have mentioned. Try to keep your opinion within your module to a minimum so that it is more flexible for others to use it. One example I often cite as a tale of caution is the Palo Alto deployment in the Azure Marketplace (though I think it has since been addressed). It would create a virtual network for you... crazy... what if I have an existing virtual network that I want to deploy it to?
Great video, much better to pass location as a standard for all modules. For those without github codepilot, Microsoft copilot does a very good job of writing regex validation. Do you recommend trying to write regular expressions using terraform's customized regex or just standard regex for easier testing?
Hi Thanks for the comment!
If I am crafting my own, I use an online regex tester to start. Then I'll use terraform console to validate.
If I'm being super proper I will create a terraform test with the expect_failures option...
developer.hashicorp.com/terraform/language/tests#expecting-failures
Reminds me of the quote I saw on LinkedIn - Clear is better than clever.
Very insightful and well explained, thank you!