Bug 870376 - RFE: asynchronous storage jobs
RFE: asynchronous storage jobs
Status: NEW
Product: Fedora
Classification: Fedora
Component: python-blivet (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: blivet-maint-list@redhat.com
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-26 05:55 EDT by Jan Safranek
Modified: 2015-09-28 16:25 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Safranek 2012-10-26 05:55:41 EDT
Currently, the Anaconda storage module (Blivet) performs all actions synchronously, e.g. starts mkfs.ext3 and blocks the application until it is done.

Long duration jobs should be started in separate processes asynchronously and application should be notified when they end (e.g. via callback).

Sure, the application can fork itself, but forking whole Anaconda while one part starts mkfs.ext3 and the second part serves other application requests does not seem to be a good idea.
Comment 1 Jan Safranek 2013-02-23 05:14:09 EST
I've talked with dlehman and we agreed on this solution:
- application has one thread (T1) to read stuff from DeviceTree
- application puts actions to the device tree in T1, but does not execute them
  - more actions can wait for execution in (application managed?) queue
- application starts new thread (T2) and executes the queued actions
  - the actions are executed sequentially, one at a time 
  - it's up to the application to preserve order of the actions
  - (in future) the application may create multiple threads and do more actions in parallel, if they do not influence each other
- the devicetree shows the *target* state, all the devices look like they were already created/removed/changes
  - with appropriate properties that clearly distinguish that the device does not exist yet
  - (this is already implemented)
- if an queued action fails, application determines the consequences
  - in the first release, it just wipes the queue and re-reads devicetree

Possible pitfall:
 - application adds a new action to the device tree in T1
 - at the same time, T2 finishes an action and updates the device tree with it
 - (in future) async event comes at the same time that a device was changed/added/removed (there is separate bug for async event, just keep in mind it may be another source of race conditions)

Most of the functionality is probably already implemented in Blivet. This bug is about further investigation if everything is safe and/or how to make it safe in Blivet.
Comment 2 Jan Safranek 2013-02-23 05:17:35 EST
Asynchronous device actions are high priority for OpenLMI, we do not want to wait for mkfs on 1TB drive :) and block everything until it finishes.
Comment 3 Fedora Admin XMLRPC Client 2015-09-28 16:25:09 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Note You need to log in before you can comment on or make changes to this bug.