OCM-5627 | ci: upgrade scenario test cases

[amalykhi]

https://polarion.engineering.redhat.com/polarion/#/project/OSE/workitem?id=OCP-63153

Test results:
https://polarion.engineering.redhat.com/polarion/#/project/OSE/workitem?id=OCP-63152

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci-robot]

@amalykhi: This pull request references OCM-5627 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.16.0" version, but no target version was set.

In response to this:

https://polarion.engineering.redhat.com/polarion/#/project/OSE/workitem?id=OCP-63153

https://polarion.engineering.redhat.com/polarion/#/project/OSE/workitem?id=OCP-63825

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@amalykhi: No Jira issue is referenced in the title of this pull request.
To reference a jira issue, add 'XYZ-NNN:' to the title of this pull request and request another refresh with /jira refresh.

In response to this:

https://polarion.engineering.redhat.com/polarion/#/project/OSE/workitem?id=OCP-63153

https://polarion.engineering.redhat.com/polarion/#/project/OSE/workitem?id=OCP-63825

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 openshift-eng/jira-lifecycle-plugin repository.

[nirarg]

/retest

[shellymiron]

/lgtm
can you show a run for it?

[amalykhi]

@amalykhi @shellymiron @xueli181114 Some additional common comments. You may have some discussion and conclusion before, I just confirm with you here.

• Is there any definitions for the cluster profile using for upgrade cases? If no, do we want to use an advanced clusters to make sure the upgrading testing runing on a more customized clusters or use a basic cluster on a bisic cluster? It is more like basic clusters in the PR.
• We hardcode the major_version as 4.14. What will we do when 4.14.z->4.15.z path is available？
• I understand the 'update cluster' means uprading cluster within z stream while 'upgrade cluster' means upgrading cluster within Y stream here. Do we want the test title like this, upgrade cluster within Y/Z stream more explicit for me.

And @amalykhi Is there any other cases for the validations about upgrade clusters? Like empty upgrade version, invalid upgrade version, etc. If no, please add the checkpoint in these two cases.

There is no definition of upgrade case profile AFAIK, Does it exist for OCM/rosa CLI?
Once 4.15 is released we are going to upgrade this in the repo - Release will require changes in the openshift/release.
For example, there are 4.15 versions exist in candidate channel, but I would like to verify latest GAed version

Regarding the label name, both looks fine for me, just wanted to separate the test cases between Y and Z stream upgrades.
@xueli181114 @shellymiron WDYT?

[amalykhi]

/unhold

[shellymiron]

/lgtm

[shellymiron]

/lgtm

[yuwang-RH]

/lgmt

[shellymiron]

/approve

[xueli181114]

/approve

[nirarg]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nirarg, shellymiron, xueli181114

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:

• OWNERS [nirarg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment