Open
Description
As per #8, currently, the upgrade mechanism exposes low-level CRD concepts like in_place_rollout
, request_rollout
, and force_rollout
directly to end users. This might be unnecessarily complex for most use cases.
One way that we might be able to achieve this is to replace these fields with a simpler abstraction that focuses on user intent rather than implementation details. For example:
variable "instances" {
type = list(object({
# existing fields...
version = string
upgrade_strategy = optional(object({
minimize_downtime = optional(bool, true) # false = in-place, true = rolling update
force = optional(bool, false) # whether to force the upgrade
}))
}))
}
Example usage:
instances = [
{
name = "my-instance"
version = "v0.130.3"
upgrade_strategy = {
minimize_downtime = true # Use rolling updates
}
}
]
The module would handle the underlying CRD fields (request_rollout UUIDs, etc.) internally, abstracting these implementation details away from users.
Metadata
Metadata
Assignees
Labels
No labels