Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NnfDataMovementManager: Add UpdateStrategy to support parallel rolling updates #261

Merged
merged 1 commit into from
Feb 13, 2024
Merged

NnfDataMovementManager: Add UpdateStrategy to support parallel rolling updates #261

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions api/v1alpha1/nnf_datamovementmanager_types.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,7 @@
package v1alpha1

import (
appsv1 "k8s.io/api/apps/v1"
corev1 "k8s.io/api/core/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Expand Down Expand Up @@ -50,6 +51,10 @@ type NnfDataMovementManagerSpec struct {
// manages the per node data movement operations.
Template corev1.PodTemplateSpec `json:"template"`

// UpdateStrategy defines the UpdateStrategy that is used for the basis of the worker Daemon Set
// that manages the per node data movement operations.
UpdateStrategy appsv1.DaemonSetUpdateStrategy `json:"updateStrategy"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it need to be required? Can it be omitempty?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind, I see that sos has it covered always.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I originally had it as optional but then changed my mind to just make it a requirement. We basically never want it to use the default of 1 anyway, so I think expecting this field is the way to go.


// Host Path defines the directory location of shared mounts on an individual worker node.
HostPath string `json:"hostPath"`

Expand Down
1 change: 1 addition & 0 deletions api/v1alpha1/zz_generated.deepcopy.go
View file
Open in desktop

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

64 changes: 64 additions & 0 deletions config/crd/bases/nnf.cray.hpe.com_nnfdatamovementmanagers.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7626,11 +7626,75 @@ spec:
- containers
type: object
type: object
updateStrategy:
description: UpdateStrategy defines the UpdateStrategy that is used
for the basis of the worker Daemon Set that manages the per node
data movement operations.
properties:
rollingUpdate:
description: 'Rolling update config params. Present only if type
= "RollingUpdate". --- TODO: Update this to follow our convention
for oneOf, whatever we decide it to be. Same as Deployment `strategy.rollingUpdate`.
See https://github.com/kubernetes/kubernetes/issues/35345'
properties:
maxSurge:
anyOf:
- type: integer
- type: string
description: 'The maximum number of nodes with an existing
available DaemonSet pod that can have an updated DaemonSet
pod during during an update. Value can be an absolute number
(ex: 5) or a percentage of desired pods (ex: 10%). This
can not be 0 if MaxUnavailable is 0. Absolute number is
calculated from percentage by rounding up to a minimum of
1. Default value is 0. Example: when this is set to 30%,
at most 30% of the total number of nodes that should be
running the daemon pod (i.e. status.desiredNumberScheduled)
can have their a new pod created before the old pod is marked
as deleted. The update starts by launching new pods on 30%
of nodes. Once an updated pod is available (Ready for at
least minReadySeconds) the old DaemonSet pod on that node
is marked deleted. If the old pod becomes unavailable for
any reason (Ready transitions to false, is evicted, or is
drained) an updated pod is immediatedly created on that
node without considering surge limits. Allowing surge implies
the possibility that the resources consumed by the daemonset
on any given node can double if the readiness check fails,
and so resource intensive daemonsets should take into account
that they may cause evictions during disruption.'
x-kubernetes-int-or-string: true
maxUnavailable:
anyOf:
- type: integer
- type: string
description: 'The maximum number of DaemonSet pods that can
be unavailable during the update. Value can be an absolute
number (ex: 5) or a percentage of total number of DaemonSet
pods at the start of the update (ex: 10%). Absolute number
is calculated from percentage by rounding up. This cannot
be 0 if MaxSurge is 0 Default value is 1. Example: when
this is set to 30%, at most 30% of the total number of nodes
that should be running the daemon pod (i.e. status.desiredNumberScheduled)
can have their pods stopped for an update at any given time.
The update starts by stopping at most 30% of those DaemonSet
pods and then brings up new DaemonSet pods in their place.
Once the new pods are available, it then proceeds onto other
DaemonSet pods, thus ensuring that at least 70% of original
number of DaemonSet pods are available at all times during
the update.'
x-kubernetes-int-or-string: true
type: object
type:
description: Type of daemon set update. Can be "RollingUpdate"
or "OnDelete". Default is RollingUpdate.
type: string
type: object
required:
- hostPath
- mountPath
- selector
- template
- updateStrategy
type: object
status:
description: NnfDataMovementManagerStatus defines the observed state of
Expand Down
Loading