Skip to content

Commit

Permalink
Add spec for rollout strategy to API
Browse files Browse the repository at this point in the history
This commit puts a placeholder field in Module for representing the
"rollout strategy", without an implementation.

Signed-off-by: Michael Bridgen <[email protected]>
  • Loading branch information
squaremo committed Apr 7, 2021
1 parent 46f6c7c commit 283ed8c
Show file tree
Hide file tree
Showing 4 changed files with 65 additions and 0 deletions.
27 changes: 27 additions & 0 deletions control/api/v1alpha1/module_types.go
Original file line number Diff line number Diff line change
Expand Up @@ -20,11 +20,38 @@ type ModuleSpec struct {
// +optional
Selector *metav1.LabelSelector `json:"selector,omitempty"`

// Rollout gives the strategy for updating the module
// +optional
// +kubebuilder:default={"strategy": "all-at-once"}
Rollout *RolloutSpec `json:"rollout,omitempty"`

// Sync gives the configuration to sync on assigned clusters.
// +required
Sync asmv1.Sync `json:"sync"`
}

// RolloutSpec defines how the module rolls out changes when it is
// updated itself.
type RolloutSpec struct {
// Strategy names the rollout strategy to use when updating
// assigned clusters.
// +required
// +kubebuilder:validation:Enum=all-at-once;gradual
Strategy RolloutStrategyName `json:"strategy"`
}

type RolloutStrategyName string

const (
// RolloutReplace names the strategy in which all module uses are
// replaced with the new definition.
RolloutReplace RolloutStrategyName = "all-at-once"
// RolloutGradual names the strategy in which module uses are
// updated gradually, making sure there are a limited number of
// clusters updating at any point.
RolloutGradual RolloutStrategyName = "gradual"
)

// ModuleStatus defines the observed state of Module
type ModuleStatus struct {
// ObservedSync gives the spec of the Sync as most recently acted
Expand Down
20 changes: 20 additions & 0 deletions control/api/v1alpha1/zz_generated.deepcopy.go

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

15 changes: 15 additions & 0 deletions control/config/crd/bases/fleet.squaremo.dev_modules.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,21 @@ spec:
spec:
description: ModuleSpec defines the desired state of Module
properties:
rollout:
default:
strategy: all-at-once
description: Rollout gives the strategy for updating the module
properties:
strategy:
description: Strategy names the rollout strategy to use when updating
assigned clusters.
enum:
- all-at-once
- gradual
type: string
required:
- strategy
type: object
selector:
description: Selector gives the criteria for assigning this module
to an cluster. If missing, no clusters are selected. If present
Expand Down
3 changes: 3 additions & 0 deletions docs/design/modules.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,3 +22,6 @@ simplest is to update one cluster at a time, and wait until it is ready before u
The trickier questions come when you consider what to do if the assigned clusters are still in a
rollout when you begin another, i.e., there is already at least one cluster in updating
state. Naively, you might simply wait until there are no clusters in updating state.

What about if new clusters are assigned? There is nothing to do but give them the new configuration,
but does this count against the budget for clusters in updating state?

0 comments on commit 283ed8c

Please sign in to comment.