Can you please also make sure that topic subscriptions are maintained (re-subscribed) after the reconnect event?

(In reply to Martin Sivák from comment #5)
> Can you please also make sure that topic subscriptions are maintained
> (re-subscribed) after the reconnect event?

Setting NEEDINFO on Piotr.

It is how the engine client works and we intend to keep this behavior.

Will this make 4.1.6? We have BZ #1457471 and #1471617 depending on this

(In reply to Sandro Bonazzola from comment #8)
> Will this make 4.1.6? We have BZ #1457471 and #1471617 depending on this

We are trying our best to get this in, but due to difficult negotiation about those patches we will most probably be able to deliver them early next week.

This fix requires a lot of deep changes inside VDSM client infrastructure and it's still not ready even on master. So for now retargeting to 4.2, once finished on master we will decide to which 4.1.z will be backported

is this testable from user experience perspective?

I tested it using these steps:

1. change vdsm log level to DEBUG.
2. python script:

import logging
import sys
from vdsm import client

logging.basicConfig(stream=sys.stdout, level=logging.DEBUG)
cli = client.connect('localhost')
cli.Host.getCapabilities()
cli.close()

3. restarting vdsmd service after client connects and while running a command.


You should see log prints of the client timeout and attempts to reconnect and you should be able to run vdsm-client commands after reconnecting is successful.

ok, vdsm-4.20.3-178.gitee07ec4.el7.centos.x86_64

...
Traceback (most recent call last):
  File "/tmp/test.py", line 8, in <module>
    cli = client.connect('localhost')
  File "/usr/lib/python2.7/site-packages/vdsm/client.py", line 124, in connect
    raise ConnectionError(host, port, use_tls, timeout, e)
vdsm.client.ConnectionError: Connection to localhost:54321 with use_tls=True, timeout=60 failed: [Errno 111] Connection refused
DEBUG:root:START thread <Thread(Client localhost:54321, started daemon 140435456718592)> (func=<bound method Reactor.process_requests of <yajsonrpc.betterAsyncore.Reactor object at 0x7fb9babc6a50>>, args=(), kwargs={})
DEBUG:yajsonrpc.protocols.stomp.AsyncClient:Stomp connection established
DEBUG:jsonrpc.AsyncoreClient:Sending response
{u'systemProductName': u'RHEV Hypervisor', u'systemSerialNumber': u'4C4C4544-004D-4B10-8046-B4C04F313332', u'systemFamily': u'Red Hat Enterprise Linux', u'systemVersion': u'7.4-18.el7', u'systemUUID': u'C3EBA6D8-17EA-4942-80B7-CE66111D0B85', u'systemManufacturer': u'Red Hat'}

This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

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