Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1688993 - [network-operator] The version field does not continues to show the old version during an upgrade
Summary: [network-operator] The version field does not continues to show the old versi...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.1
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: ---
Assignee: Casey Callendrello
QA Contact: Anurag saxena
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-14 20:50 UTC by Anurag saxena
Modified: 2019-03-26 19:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-26 19:03:03 UTC
Target Upstream Version:


Attachments (Terms of Use)
Network operator logs (deleted)
2019-03-14 20:50 UTC, Anurag saxena
no flags Details

Description Anurag saxena 2019-03-14 20:50:40 UTC
Created attachment 1544201 [details]
Network operator logs

Description of problem: clusteroperator.config.openshift.io is not reporting the old VERSION during an upgrade process. Its reporting the new version when the upgrade is being processed

Version-Release number of selected component (if applicable): v4.0.0-0.182.0

How reproducible: Always

Steps to Reproduce:
1.Setup OCP cluster (Note the OCP version)
2.Upgrade cluster to an another payload
3.Make sure the cluster is being upgraded
4.Check the network operator VERSION is the old version as noted in step 1

Actual results:

The OCP version is 
$ oc get clusteroperators.config.openshift.io | grep "NAME\|network"
NAME                                  VERSION                             AVAILABLE   PROGRESSING   FAILING   SINCE
network                               4.0.0-0.nightly-2019-03-13-233958   True        False         False     15m


Following is captured when the upgrade is at 19% 
# oc get clusteroperators.config.openshift.io | grep "NAME\|network"
NAME                                  VERSION                             AVAILABLE   PROGRESSING   FAILING   SINCE
network                               4.0.0-0.ci-2019-03-14-150906        True        False         False     10m
# oc get clusterversion
NAME      VERSION                        AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.0.0-0.ci-2019-03-14-150906   True        True          19m     Working towards 4.0.0-0.ci-2019-03-14-150906: 19% complete


Expected results: During an upgrade, the VERSION field should continue to show the old version


Additional info: network operator logs are attached

Comment 1 Anurag saxena 2019-03-14 20:59:15 UTC
If we notice in "Following is captured when the upgrade is at 19%" under Actual results, my question is

Is it expected during the upgrade that the "oc get clusterversion" VERSION should report the version being upgraded? or i believe it should show the old version until the new version is upgraded successfully. If the latter case is true, that might be blocking this bug.

Comment 2 Casey Callendrello 2019-03-15 13:36:20 UTC
Upgrades are not atomic, so it is certainly possible that the network operator beats others out.

Comment 3 Casey Callendrello 2019-03-15 15:51:02 UTC
Yeah, checked with the team; this is NOTABUG.

Comment 4 Anurag saxena 2019-03-15 15:58:47 UTC
Today's experiment when cluster is up on 4.0.0-0.nightly-2019-03-15-043409 and oc adm upgrade is triggered for 4.0.0-0.nightly-2019-03-15-063749


When the upgrade was at 9%, >>>>>>>>>>> clusteroperator reports correct (old) network operator version

$ oc get clusteroperators.config.openshift.io | grep "NAME\|network"
NAME                                  VERSION                             AVAILABLE   PROGRESSING   FAILING   SINCE
network                               4.0.0-0.nightly-2019-03-15-043409   True        False         False     52m
$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.0.0-0.nightly-2019-03-15-063749   True        True          2m19s   Working towards 4.0.0-0.nightly-2019-03-15-063749: 9% complete


When the upgrade was at 22%, >>>>>>>>>>> clusteroperator reports new network operator version

$ oc get clusteroperators.config.openshift.io | grep "NAME\|network"
NAME                                  VERSION                             AVAILABLE   PROGRESSING   FAILING   SINCE
network                               4.0.0-0.nightly-2019-03-15-063749   True        False         False     58s
$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.0.0-0.nightly-2019-03-15-063749   True        True          6m9s    Working towards 4.0.0-0.nightly-2019-03-15-063749: 22% complete

Comment 5 Anurag saxena 2019-03-15 16:02:27 UTC
oops seems like the mid-air collision for my comment triggered the status to NEW/reopened, sorry for that
okay Casey, so seems like the expected behavior is that during the upgrade the new version should take in effect?

Comment 6 Casey Callendrello 2019-03-15 16:17:58 UTC
No worries.

Note that the STATUS for the ClusterVersion is "Working towards 4.0.0-0.nightly-2019-03-15-063749" - that will be updated when the *whole* cluster has reached the level. The network operator just got there before most others. So I think everything is working as designed.


Note You need to log in before you can comment on or make changes to this bug.