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

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

Do we need the nested cache_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 nested cache_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 nested cache_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 for autoscaling. 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 of cache_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 like expiration_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 nested cache_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 nested cache_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 for autoscaling. 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 of cache_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 like expiration_policy would make more sense? What do you think?

As discussed internally, 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
  }
}