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.

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

feat(upgrade): support parallel/faster upgrades for node daemonset #230

Merged
merged 1 commit into from
Nov 3, 2020

Conversation

pawanpraka1
Copy link
Contributor

@pawanpraka1 pawanpraka1 commented Oct 20, 2020

Signed-off-by: Pawan pawan@mayadata.io

Why is this PR required? What issue does it fix?:

For ZFSPV, all the node daemonset pods can go into the terminating state at
the same time since it does not need any minimum availability of those pods.

What this PR does?:

Changing maxUnavailable to 100% so that K8s can upgrade all the daemonset
pods parallelly. Also added labels to all the pods.

@pawanpraka1 pawanpraka1 added the enhancement Add new functionality to existing feature label Oct 20, 2020
@pawanpraka1 pawanpraka1 added this to the v1.0.2 milestone Oct 20, 2020
For ZFSPV, all the node daemonset pods can go into the terminating state at
the same time since it does not need any minimum availability of those pods.

Changing maxUnavailable to 100% so that K8s can upgrade all the daemonset
pods parallelly.

Signed-off-by: Pawan <pawan@mayadata.io>
@pawanpraka1 pawanpraka1 added this to In progress in ZFS Local PV Oct 20, 2020
@pawanpraka1 pawanpraka1 added this to RC1 - Due: Nov 5 2020 in 2.3 Release Tracker - Due Nov 15th. Oct 20, 2020
@pawanpraka1 pawanpraka1 moved this from RC1 - Due: Nov 5 2020 to Pre-commits and Designs - Due: Oct 31 2020 in 2.3 Release Tracker - Due Nov 15th. Oct 29, 2020
Copy link
Member

@prateekpandey14 prateekpandey14 left a comment

Choose a reason for hiding this comment

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

lgtm

@kmova
Copy link
Member

kmova commented Nov 2, 2020

@pawanpraka1 -- has upgrade from previously installed setup to this new operator.yaml with changes tested? In the past I had seen that when upgrade options are changed, we might have to delete some objects and then patch.

@kmova kmova added the pr/hold-review hold the review. label Nov 2, 2020
@pawanpraka1
Copy link
Contributor Author

@kmova, I have tested the upgrade on my Rancher setup, did not face any issue. Could you elaborate more about the issue, which object we need to delete and why?

@kmova kmova removed the pr/hold-review hold the review. label Nov 3, 2020
@kmova
Copy link
Member

kmova commented Nov 3, 2020

usually changing the default value of upgrade type, requires removing that json object from the deployment spec and recreating. Had faced this issue when changin from rollingUpgrade to recreate. In this case as it is not changing, it should be fine.

@kmova kmova merged commit 64bc7cb into openebs:master Nov 3, 2020
ZFS Local PV automation moved this from In progress to Done Nov 3, 2020
2.3 Release Tracker - Due Nov 15th. automation moved this from Pre-commits and Designs - Due: Oct 31 2020 to Done Nov 3, 2020
@pawanpraka1 pawanpraka1 deleted the yaml branch November 4, 2020 06:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Add new functionality to existing feature
Projects
ZFS Local PV
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

3 participants