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

Bug 1828757

Summary:	staging-ovirt driver maintains open session
Product:	Red Hat OpenStack	Reporter:	Gianluca Cecchi <gianluca.cecchi>
Component:	openstack-ironic-staging-drivers	Assignee:	Steve Baker <sbaker>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	13.0 (Queens)	CC:	bfournie, dtantsur, pweeks, rpittau, sbaker, sbonazzo
Target Milestone:	beta	Keywords:	TestOnly, Triaged
Target Release:	16.1 (Train on RHEL 8.2)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-ironic-staging-drivers-0.12.1-0.20200526103911.b5a8aaf.el8ost	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-07-15 19:16:31 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gianluca Cecchi 2020-04-28 10:17:13 UTC

Description of problem:
The ovirt driver works correct but I see that doesn't contain the close.connection() directive

Version-Release number of selected component (if applicable):
verified on Queens: 0.9.2-0.20190420093856.546ceca.el7

and also in stable Stein:
openstack-ironic-staging-drivers-0.11.1-0.20191023075755.ab5bb1d.el7.noarch.rpm

How reproducible:
always

Steps to Reproduce:
1. configure staging-ovirt driver with dedicated ovirt user (ostackpm) on internal domain
2. deploy undercloud
3. register and introspect overcloud nodes

Actual results:
In case of 8 VMs representing Openstack Nodes (3 controllers, 2 compute and 3 ceph), every minute I have 8 new connections to ovirt, that are never closed. It is true that at UserSessionTimeOutInterval (that defaults to 30 minutes) they are automatically dropped, but it is inefficient to keep open the connection (240 connections in my case...)
They are seen in web admin gui portal through Administration --> Active User Sessions page


Expected results:
connection closed after the session completed through the connection.close() call


Additional info:

Comment 1 Steve Baker 2020-05-06 20:20:33 UTC

Indeed, the driver creates a new connection for every oVirt API call. I've proposed a fix upstream which closes the connection after each call.

Comment 2 Bob Fournier 2020-06-23 22:01:35 UTC

In compose RHOS-16.1-RHEL-8-20200610.n.0.

Comment 6 Gianluca Cecchi 2020-07-10 16:41:41 UTC

Hello, on my Queens install I tried substituting /usr/lib/python2.7/site-packages/ironic_staging_drivers/ovirt/ovirt.py with the one in https://review.opendev.org/#/c/728719/1 but it seems the problem is still there

My ovirt is 4.3.9 
On director
openstack baremetal node power off ostack-compute1

In Webadmin GUI, Administration --> User sessions I see two sessions opened and not closed for this event

Session DB Id | User Name | Authoriz. Provider | User Id | Source IP | Session Start Time | Session Last Active Time
374460 ostackpm internal-authz ac8c8130-5726-457f-9ab9-144ea8329df5 172.19.0.220 Jul 10, 2020, 6:28:57 PM Jul 10, 2020, 6:28:57 PM
374459 ostackpm internal-authz ac8c8130-5726-457f-9ab9-144ea8329df5 172.19.0.220 Jul 10, 2020, 6:28:56 PM Jul 10, 2020, 6:28:57 PM

Also with
openstack baremetal node power on ostack-compute1

two sessions opened and not closed and still there

Session DB Id | User Name | Authoriz. Provider | User Id | Source IP | Session Start Time | Session Last Active Time
374462 ostackpm internal-authz ac8c8130-5726-457f-9ab9-144ea8329df5 172.19.0.220 Jul 10, 2020, 6:32:51 PM Jul 10, 2020, 6:32:51 PM
374461 ostackpm internal-authz ac8c8130-5726-457f-9ab9-144ea8329df5 172.19.0.220 Jul 10, 2020, 6:32:51 PM Jul 10, 2020, 6:32:51 PM

The connection.close() seems to be called only in _getvm(driver_info) definition? Is it sufficient?

Comment 7 Lon Hohberger 2020-07-29 10:49:37 UTC

According to our records, this should be resolved by openstack-ironic-staging-drivers-0.12.1-0.20200526103911.b5a8aaf.el8ost.  This build is available now.

Comment 9 pweeks 2021-07-15 19:16:31 UTC

closed currentrelease as fix is available in the 16.1 zstream