Can you give me the exact rpm version of ovirt-engine-backend, I can give you a replacement jar file to test
On Thu, Mar 23, 2017 at 3:56 AM, <[email protected]> wrote: > Hi Ravi, > > Could you please tell me what's the right way to apply this patch on an > already working oVirt instance? I already have applied some patches on *.py > files, but it seems the *.java files are not there. > > Thanks! > > > El 2017-03-22 16:06, Ravi Nori escribió: > >> Hi Nicolás, >> >> There has been some changes to how a session is refreshed after 4.0. >> So this is a BZ and is being tracked by BZ 1434605. >> >> Will post a patch to fix this. Thanks for reporting the issue. >> >> Ravi >> >> On Wed, Mar 22, 2017 at 9:10 AM, <[email protected]> wrote: >> >> Hi Juan, >>> >>> I confirm this was working with 4.0.6 (but the same SDK package). >>> The script is relatively new but I'm 100% sure it has been in >>> execution for several weeks, in contrast to current version where >>> after 5-6 iterations the exception starts showing up. >>> >>> I've voted for the bug and added myself as CC. >>> >>> Thank you. >>> >>> Regards, >>> >>> Nicolás >>> >>> El 2017-03-22 12:58, Juan Hernández escribió: >>> On 03/22/2017 01:50 PM, Juan Hernández wrote: >>> On 03/22/2017 01:10 PM, [email protected] wrote: >>> Hi, >>> >>> We've recently upgraded from oVirt 4.0.x to 4.1.0 and it seems that >>> the >>> behavior of a script we wrote in Python-SDK has changed slightly. >>> We >>> have a script that needs to be executed forever (daemon mode). This >>> daemon creates an ovirtsdk4.Connection object and uses the same >>> Connection object all the time. >>> >>> conn = sdk.Connection( >>> url=URI, >>> username=USERNAME, >>> password=PASSWORD, >>> ca_file=CAFILE >>> ) >>> >>> Between iterations we have ~5 minutes delays which we accomplish >>> with a >>> time.sleep(...) call. >>> >>> After some of these iterations (5 or 6), when trying to perform an >>> operation on the Connection object (in this case, listing all SDs): >>> >>> try: >>> sys_serv = conn.system_service() >>> sd_serv = sys_serv.storage_domains_service() >>> storages = sd_serv.list(search=sd_search_query) >>> except Error, e: >>> log('ERR: Error getting storage domains: %s' % (e)) >>> >>> We start getting exceptions (i.e., the sd_serv.list() call throwing >>> an >>> Error exception) with this message: >>> >>> ERR: Error getting storage domains: HTTP response code is >>> 401. >>> >>> I believe this has something to do with the Connection object >>> expiring >>> (even if it's not idle more than 5 minutes at any time). Is there a >>> way >>> to "refresh" the Connection object so it doesn't auto-logout >>> (assuming >>> this is the actual problem)? >>> >>> As I said, this started happening as of oVirt 4.1.0. >>> ovirt-engine-sdk-python version is 4.1.1. >>> >>> Any ideas? >>> >>> This sound like this bug, opened yesterday: >>> >>> SSO token used for the API expires when running only queries >>> https://bugzilla.redhat.com/1434605 [1] >>> >>> But I thought the same happened in 4.0. Can you confirm that you >>> don't >>> see this problem in 4.0? >>> >>> Open possible workaround is to force a refresh of the backend >>> session >>> sending an external event, like in this example: >>> >>> >>> https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/ >> examples/vm_backup.py#L112-L131 >> >>> [2] >>> >>> I also think that we need to modify the SDKs so that they detect >>> expired >>> SSO tokens and renew them automatically. I will open another bug >>> for that. >>> >> >> Here is the bug for adding automatic SSO token renew to the SDK, in >> case >> you want to follow/vote it: >> >> Implement automatic SSO token renew >> https://bugzilla.redhat.com/1434830 [3] >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/users [4] >> >> >> >> Links: >> ------ >> [1] https://bugzilla.redhat.com/1434605 >> [2] >> https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/ >> examples/vm_backup.py#L112-L131 >> [3] https://bugzilla.redhat.com/1434830 >> [4] http://lists.ovirt.org/mailman/listinfo/users >> >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
