USHIFT-1091 USHIFT-1095: Handle upgrade from 4.13#1957
USHIFT-1091 USHIFT-1095: Handle upgrade from 4.13#1957openshift-merge-robot merged 1 commit intoopenshift:mainfrom
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@pmtk: This pull request references USHIFT-1091 which is a valid jira issue. DetailsIn 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
Bot
added
the
do-not-merge/work-in-progress
openshift-ci
Bot
added
the
approved
pmtk
force-pushed
the
1091-from-4.13
branch
2 times, most recently
from
f934b37 to
0d1b04a
Compare
pmtk
changed the title
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
pmtk
changed the title
|
@pmtk: This pull request references USHIFT-1095 which is a valid jira issue. DetailsIn 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. |
pmtk
force-pushed
the
1091-from-4.13
branch
2 times, most recently
from
54e375e to
73cf1ef
Compare
|
/retest |
There was a problem hiding this comment.
It would be good to log before and after this call, since it's a distinct unit of work.
There was a problem hiding this comment.
It would be good to be consistent about either having each case be 1 if statement with combined conditions (like here) or to use nested if statements (like above). I don't have a strong preference for which approach is used, but if nested conditions make it easier to ensure we are testing all of the relevant cases maybe that's the thing to do?
There was a problem hiding this comment.
What I like about current version is clear distinction of cases where data does and does not exist (seems to me to be kind of a big deal that deserves special treatment).
Lines from 174 to the end of the function could be inside an else but that's not idiomatic...
TBH I'm most happy with the current version - it's explicit that if !dataExists exhausts all the cases when data doesn't exist, and the rest are cases when it does. Turning that into if !dataExists && !healthExists and if !dataExists && healthExists makes me spend some brain cycles to think if there are other, implicit cases with !dataExists
There was a problem hiding this comment.
Why not perform the pre-run process when moving from 4.13?
There was a problem hiding this comment.
I tried that in first version (333216d#diff-e78e17834c76663b756393d04ebe7aceb8ea4059d44b7d2ae3ee4e9999aead6eR65) but I didn't like the workaround to fit in that process (manually constructing "4.13" + "healthy" and generating backup name from deployId without boot id)
There was a problem hiding this comment.
I also expect that when we get to solving TODOs in this function, it might get renamed to resolve these special cases so all of this will be part of pre-run and what we have today will be "regular flow"
|
/lgtm That logic is easier to follow now, nice cleanup. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dhellmann, pmtk The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@pmtk: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
4 participants
No description provided.