Bug 1835869: Included check for v1alpha VolumeSnapshot CRD #55
Conversation
openshift-ci-robot
added
bugzilla/severity-high
|
@huffmanca: This pull request references Bugzilla bug 1835869, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
openshift-ci-robot
added
the
approved
|
@huffmanca: This pull request references Bugzilla bug 1835869, which is valid. 3 validation(s) were run on this bug
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/retest |
1 similar comment
|
/retest |
|
If the detected cluster state goes away, ie: they uninstall the v1alpha volumesnapshot CRD, is Upgradeable=False cleared? |
| @@ -145,6 +152,15 @@ func (r *ReconcileClusterStorage) Reconcile(request reconcile.Request) (reconcil | |||
| return reconcile.Result{}, err | |||
| } | |||
|
|
|||
| // Run validation checks | |||
| err = validation.CheckAlphaSnapshot(r.client) | |||
There was a problem hiding this comment.
How often is Reconcile called? In other words, how long does it take for Upgradeable=false to get away after user removes v1alpha1 CRD?
There was a problem hiding this comment.
This happens fairly quickly - we requeue the request when throwing an error, and on line 161 we return an error, so it continues trying. From testing it takes seconds to clear the flag after the CRD is removed.
The other way (flagging the cluster as Upgradeable=false) takes a bit longer, as we wait for a new Reconcile request to come in and proceed through this logic. From testing it can take up to 15 minutes.
There was a problem hiding this comment.
Performing additional tests show that the Reconcile request is retried fairly frequently. In most cases it's only a couple of seconds, as the request is immediately re-queued; however, it may take the full amount of time for a subsequent Reconcile request. So up to 15 minutes in worst case scenario.
|
@sdodson , Yes - once the CRD is removed Upgradeable is set back to |
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: huffmanca, jsafrane The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
@huffmanca: All pull requests linked via external trackers have merged: openshift/cluster-storage-operator#55. Bugzilla bug 1835869 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/cherrypick release-4.5 |
|
@huffmanca: new pull request created: #56 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This includes a check for the VolumeSnapshot CRD. If we detect v1alpha1 of the CRD, then we mark the Operator as Available, but Upgradeable=false.
Note that this needs to be included in 4.3; however, I think it would be useful to have some of these validations (since we're going to be checking for CSI Drivers) in current versions as well.