Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1856339

Summary:	[CNV&RHV] Add test for the OpenShift API to Provider Test connection
Product:	[oVirt] ovirt-engine	Reporter:	Lucia Jelinkova <ljelinko>
Component:	BLL.Infra	Assignee:	Artur Socha <asocha>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Pavol Brilla <pbrilla>
Severity:	low	Docs Contact:
Priority:	low
Version:	4.4.1	CC:	ahadas, asocha, bugs, masayag, mperina
Target Milestone:	ovirt-4.4.2	Flags:	pm-rhel: ovirt-4.4+
Target Release:	4.4.2.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	rhv-4.4.2-2 ovirt-engine-4.4.2.1	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-09-18 07:12:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Lucia Jelinkova 2020-07-13 12:38:08 UTC

When adding Kubevirt/Openshift virtualization provider, there is the Test button to test the connection. It tests if the KubeVirt API is accessible. If the KubeVirt is installed on plain Kubernetes, the call would succeed, but the adding of the provider would fail later on missing OpenShift API.

Would it make sense to add a test for OpenShift API? And maybe Prometheus URL?

Comment 1 Artur Socha 2020-07-13 13:44:46 UTC

+1 for testing OpenShift API. However, I suggest to keep it with lower priority than other issues. With proper documentation this issue should not confuse users. 

In case for Prometheus URL I don't think we should require it. My impression is that it is not crucial to work. Personally on my dev setup I do not have it configured.

Comment 2 Lucia Jelinkova 2020-07-15 08:37:39 UTC

I am still thinking that maybe we should enable using the plain KubeVirt on Kubernetes in the upstream and make use of the templates optional. The user would not be probably able to create new VMs but still could see and run the existing ones. 

This would make also the naming easier - we would use KubeVirt in upstream and OpenShift Virtualization in downstream instead of using both terms. The same goes for the icons. 

WDYT?

Comment 3 Moti Asayag 2020-07-15 11:55:51 UTC

(In reply to Lucia Jelinkova from comment #2)
> I am still thinking that maybe we should enable using the plain KubeVirt on
> Kubernetes in the upstream and make use of the templates optional. The user
> would not be probably able to create new VMs but still could see and run the
> existing ones. 
> 
> This would make also the naming easier - we would use KubeVirt in upstream
> and OpenShift Virtualization in downstream instead of using both terms. The
> same goes for the icons. 
> 
> WDYT?

For the upstream we should support kubevirt on top of OKD since kubernetes
doesn't support the Template resource which is required by the integration
for creating VMs.

Comment 5 Pavol Brilla 2020-08-26 17:16:10 UTC

Adding OCP with Virtualization added successfully.

Tried to add  CRC cluster to RHV-M and failed = Success.
( Pathing between CRC and RHVM machine was working )

Comment 6 Sandro Bonazzola 2020-09-18 07:12:57 UTC

This bugzilla is included in oVirt 4.4.2 release, published on September 17th 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.2 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.