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

[feature-1435]: Disable Resiliency for Array Upgrades #1268

Merged
merged 2 commits into from
Oct 7, 2024

Conversation

atye
Copy link
Contributor

@atye atye commented Oct 2, 2024

Description

Add a section in Resiliency that it should be disabled for storage array upgrades.

GitHub Issues

List the GitHub issues impacted by this PR:

GitHub Issue #
dell/csm#1435

Checklist:

  • Have you run a grammar and spell checks against your submission?
  • Have you tested the changes locally?
  • Have you tested whether the hyperlinks are working properly?
  • Did you add the examples wherever applicable?
  • Have you added high-resolution images?

Copy link

github-actions bot commented Oct 2, 2024

Test Results

77 tests  ±0   77 ✅ ±0   3s ⏱️ ±0s
 3 suites ±0    0 💤 ±0 
 1 files   ±0    0 ❌ ±0 

Results for commit eba7f43. ± Comparison against base commit 308a9de.

♻️ This comment has been updated with latest results.

@@ -189,6 +189,9 @@ Similarly, the label selector for csi-powerscale, csi-unity, csi-powerstore and

3. As noted previously in the Limitations and Exclusions section, CSM for Resiliency has not yet been verified to work with ReadWriteMany or ReadOnlyMany volumes. Also, it has not been verified to work with pod controllers other than StatefulSet.

### Storage Array Upgrades
To avoid application pods getting stuck in a Pending state, CSM for Resiliency should be disabled for storage array upgrades; even if the storage array upgrade is advertised as non-distruptive. If the container orchestrator platform nodes lose connectivity with the array, which is more likely during an upgrade, then Resiliency will delete the application pods on the affected nodes and attempt to move them to a healthy node. If all of the nodes are affected, then the application pods will be stuck in a Pending state.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there another place where we could also reference this as a prerequisite? Chances are it will not be noticed in this page, it needs to be a reminder before any storage upgrade.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This section is now added to the Deployment documentation for Helm and Operator as Prerequisite.

@atye atye force-pushed the usr/atye/resiliency-array-upgrade branch from 22bbd4d to f960c3b Compare October 4, 2024 15:17
@atye atye requested a review from sharmilarama October 4, 2024 18:11
@atye atye force-pushed the usr/atye/resiliency-array-upgrade branch from f960c3b to 8e7c0bf Compare October 4, 2024 19:17
@atye atye force-pushed the usr/atye/resiliency-array-upgrade branch from 8e7c0bf to eba7f43 Compare October 7, 2024 13:00
@atye atye merged commit 77dd066 into main Oct 7, 2024
7 checks passed
@atye atye deleted the usr/atye/resiliency-array-upgrade branch October 7, 2024 13:42
coulof pushed a commit that referenced this pull request Oct 21, 2024
* storage array upgrades

* add prerequisites to helm and note array upgrades in deployment docs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants