Bug 870376 - RFE: asynchronous storage jobs
Summary: RFE: asynchronous storage jobs
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: python-blivet
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Vojtech Trefny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-26 09:55 UTC by Jan Safranek
Modified: 2023-04-26 12:05 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jan Safranek 2012-10-26 09:55:41 UTC
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 10:14:09 UTC
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 10:17:35 UTC
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 20:25:09 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Fedora Admin user for bugzilla script actions 2023-04-26 00:29:37 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 5 Fedora Admin user for bugzilla script actions 2023-04-26 12:05:34 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.


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