From Fedora Project Wiki
 
Line 34: Line 34:
 
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 
-->
 
-->
* Tracker bug: <will be assigned by the Wrangler>
+
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1264816 #1264816]
  
 
== Detailed Description ==
 
== Detailed Description ==

Latest revision as of 09:43, 21 September 2015

Anaconda Using LVM DBus API

Summary

A new DBus API for LVM is being created so let's make the installation process use it for setting up LVM storage.

Owner

Current status

Detailed Description

For quite a long time there has been a request for a better API for LVM than what the current CLI tools provide. After a quite long discussion between the interested groups it has been decided that a DBus API should be the best choice. The LVM team has thus been working on a prototype implementation of such DBus API, but we ended up in a circle between "there's not enough time spent on the LVM DBus API because nobody's using it and thus it's not high priority" and "nobody's using the LVM DBus API because there's not enough time spent on it". To break this circle and get from the deadlock, we would like to make the installation process use the LVM DBus API and thus pioneer its usage for others and make sure it is maintained, improved and considered a high-enough priority by the LVM team due to a real usage in an important component of the system/distribution. The reasons for why the installation process could be the first one to use the new API are the following facts:

  • anaconda+blivet are written in Python so the performance of the LVM DBus daemon prototype also written in Python shouldn't be an issue
  • anaconda+blivet only do basic operations with LVM in the installation process so we could start with this limitted scope
  • blivet uses libblockdev as its backend and libblockdev is modular having the LVM functionality as a plugin which can be replaced with a new plugin using the DBus API where possible while keeping the old/current plugin as a backup solution if it turns out the LVM DBus API is not production ready even for the installation use case. This results in a wonderful Contingency plan (see below).

Benefit to Fedora

A new long-time-wanted LVM API will be used in production in the best possible first real use case we have (see the above facts). Users should see no difference other than possibly less appearances of the "Generate more random data entropy" pop-up in the installation process due to less forks being performed. Also, with libblockdev supporting the LVM DBus API we could move a little bit closer to the goal of using a common low-level layer for doing storage operations as other projects could start using it instead of rewriting their own code to use the DBus API. Finally, having a working, supported, maintained and continuously improved LVM DBus API would be a great benefit for a number of projects working with storage ranging from monitoring tools to graphical applications for storage visualisation or configuration.


Scope

  • Proposal owners: implement the LVMDBus libblockdev plugin (vpodzime), make sure the LVM DBus daemon is packaged for Fedora and production ready for the installation use case (jbrassow)
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

We would need to test that installations involving LVM (existing or being created) run as well as before. The installer team's CI performs kickstart tests that should cover the major cases, the rest would need to be tested manually or by adding some more kickstart tests (to either installer team's CI or QA's tests). We could start with a custom testing compose using the LVM DBus API being created before we make the real change and make the official (testing) composes use it.


User Experience

There should be no noticeable difference for the users.

Dependencies

  • lvm2 or whichever component will contain the LVM DBus daemon
  • lorax: a simple change in the templates that would make sure the new libblockdev's LVMDBus plugin ends up in the installation images
  • LiveCD kickstarts: same as for lorax above

Contingency Plan

  • Contingency mechanism: revert the simple change in lorax+LiveCD kickstarts so that the new LVMDBus libblockdev plugin is not in the installation images
  • Contingency deadline: beta freeze
  • Blocks release: Yes (being incomplete, this feature would block the release unless reverted)


Documentation

N/A (not a System Wide Change)

Release Notes