Bug 1827378 - Unable to load graphs in disconnected upgrade
Summary: Unable to load graphs in disconnected upgrade
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 4.3.z
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.5.0
Assignee: Latha S
QA Contact: liujia
Latha S
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-23 19:01 UTC by Jaspreet Kaur
Modified: 2024-01-06 04:29 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-22 13:04:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift openshift-docs pull 22252 0 None open modules/understanding-upgrade-channels: Recommend clearing channel 2021-02-15 15:23:34 UTC

Description Jaspreet Kaur 2020-04-23 19:01:03 UTC
Description of problem: when doing disconnected upgrade it fails to load cincinnati graph. we tried :

fter checking on this with Engineering. Can you run below command and check :

oc patch clusterversion version --type json -p '[{"op": "remove", "path": "/spec/upstream"}]'


But it doesnt help :


I0423 16:06:08.755260       1 cvo.go:371] Finished syncing cluster version "openshift-cluster-version/version" (185.748µs)
I0423 16:06:08.770516       1 availableupdates.go:155] Upstream server https://api.openshift.com/api/upgrades_info/v1/graph could not return available updates: Get https://api.openshift.com/api/upgrades_info/v1/graph?arch=amd64&channel=stable-4.2&id=ac2cf2a4-ec7b-4115-a266-08c09ca4219d&version=4.2.16: dial tcp: lookup api.openshift.com on 10.2.88.196:53: no such host


Version-Release number of the following components:
openshift 4.2.4 to 4.2.16

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual results: Unable to upgrade

Expected results: should be able to upgrade

Additional info:
Please attach logs from ansible-playbook with the -vvv flag

Comment 3 Stephen Cuppett 2020-04-23 19:28:43 UTC
Setting target release to current development version (4.5) for investigation. Where fixes (if any) are required/requested for prior versions, cloned BZs will be created when appropriate.

Comment 4 W. Trevor King 2020-04-25 03:48:58 UTC
So sadly, it seems that the CVO has been falling back to a default URI when the ClusterVersion upstream is empty since way back [1,2], and that this behavior is enshrined in the API [3].  I guess try clearing the channel.  Although the channel docs also talk about defaults [4] and the only channel defaulting in the CVO is when creating a ClusterVersion object after the in-cluster copy was (accidentally?) deleted [4].  So maybe we could talk folks into adjusting the CVO logic to return NoUpstream in the empty-upstream case...  Will see what the API folks think...

[1]: https://github.com/openshift/cluster-version-operator/blame/2c4931dc283c551938be1a00fee290de0b79d99c/pkg/cvo/availableupdates.go#L27-L31
[2]: https://github.com/openshift/cluster-version-operator/commit/ab4d84a021c38fea5e5973287e1f5580928907c1#diff-78f2af341fa49292dd6930f378018867R24
[3]: https://github.com/openshift/api/blame/0422dc17083e9e8df18d029f3f34322e96e9c326/config/v1/types_cluster_version.go#L56-L57
[4]: https://github.com/openshift/api/blame/0422dc17083e9e8df18d029f3f34322e96e9c326/config/v1/types_cluster_version.go#L62-L63

Comment 5 Lalatendu Mohanty 2020-04-27 14:49:57 UTC
This issue does not reduce the cluster functionality or availability. Can you confirm?

Comment 6 Lalatendu Mohanty 2020-04-27 14:59:47 UTC
Also as Trevor mentioned this is as per design. The upstream can not stay empty with the current design.

Comment 7 Lalatendu Mohanty 2020-04-27 16:37:19 UTC
Also the message is an info log. From the code "pkg/cvo/availableupdates.go:            klog.V(2).Infof("Upstream server %s could not return available updates: %v", upstream, err)"

Comment 14 Red Hat Bugzilla 2024-01-06 04:29:01 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


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