Looks good. I'd just like to revisit the schema:

prebuilds {  instances = 2  cache_invalidation {  invalidate_after_secs = 86400  }  }

Do we need the nestedcache_invalidation block? Is it because we expect other cache invalidation related fields to eventually be added? Could we get away with the following?

prebuilds {  instances = 2  invalidate_after_secs = 86400  }

Looks good. I'd just like to revisit the schema:

prebuilds {  instances = 2  cache_invalidation {  invalidate_after_secs = 86400  }  }

Do we need the nestedcache_invalidation block? Is it because we expect other cache invalidation related fields to eventually be added? Could we get away with the following?

prebuilds {  instances = 2  invalidate_after_secs = 86400  }

I also thought about that, the nestedcache_invalidation block was mainly to keep things flexible in case we want to add more expiration or invalidation-related settings down the road. For readability, I actually prefer this option, especially since if I understand correctly there’s another config coming forautoscaling. It makes sense to keep these configurations grouped per block and separated by concern. But I’m definitely open to suggestions! 🙂

One other concern I had was about the naming ofcache_invalidation. Since we’re not really dealing with traditional caching but more with managing prebuild lifecycle or resource expiration, the name might be a bit misleading. Maybe something likeexpiration_policy would make more sense? What do you think?

Looks good. I'd just like to revisit the schema:

prebuilds {  instances = 2  cache_invalidation {  invalidate_after_secs = 86400  }  }

Do we need the nestedcache_invalidation block? Is it because we expect other cache invalidation related fields to eventually be added? Could we get away with the following?

prebuilds {  instances = 2  invalidate_after_secs = 86400  }

I also thought about that, the nestedcache_invalidation block was mainly to keep things flexible in case we want to add more expiration or invalidation-related settings down the road. For readability, I actually prefer this option, especially since if I understand correctly there’s another config coming forautoscaling. It makes sense to keep these configurations grouped per block and separated by concern. But I’m definitely open to suggestions! 🙂

One other concern I had was about the naming ofcache_invalidation. Since we’re not really dealing with traditional caching but more with managing prebuild lifecycle or resource expiration, the name might be a bit misleading. Maybe something likeexpiration_policy would make more sense? What do you think?

As discussedinternally, and after getting the confirmation that we'll likely introduce more expiration-related parameters in the future, the terraform schema was updated to:

prebuilds = {  instances = 2  expiration_policy {    ttl = 86400  }}