Currently the engine considers sessions expired when the user logs out or after 30 minutes of inactivity configurable with the UserSessionTimeOutInterval parameter. It doesn't matter if the session is in use or not, it will just be removed. A long running command can have the session it is using killed before it finishes. Also, queued tasks can have their session removed even before they start. This is particularly feasible with the REST API, as a user can start an asynchronous request (wiping a large disk) and then close the session. To fix this the backend needs to keep track of what commands are using a session, and avoid removing the session when there are still pending commands. In addition the backend needs to provide a mechanism that the REST API can use to indicate that an asynchronous task (submitted via ThreadPoolUtil.execute(...)) requires a session, so that this session won't be killed before the task starts the required commands.
Not strictly the same, but bug 1157751 is another manifestation of the lack of sync between the HTTP session and the backend session. My be considered a duplicate.
Based on your experience with SDK/REST-API in previous versions - is that a regression? Backend did not have a mechanism as you described before. Looks like something we need to involve Command Coordinator (CoCo) in as well.
No, it isn't a regression.
without knowing that I anticipated this but was told it cannot happen. the simplest solution for this case (async) is duplicate the current session into the async context, this session will live as long as the async context lives.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
verified in ovirt-engine-4.0.2.6-0.1.el7ev.noarch checked multiple times, all successful verification steps: 1. set UserSessionTimeOutInterval to 1 minute so I don't need 30 minute long tasks 2. create async task that lasts more than 1 minute (preallocated disk creation) 3. make sure async task runs more than a minute 4. check after task is complete for success