From Fedora Project Wiki
(cryptsetuplib status)
No edit summary
 
(14 intermediate revisions by 6 users not shown)
Line 16: Line 16:
*** wrapper module in python if needed
*** wrapper module in python if needed
*** hansg, jgranados
*** hansg, jgranados
*** pyblock has the functionality we need for this.  I basically added two functions: getDmDeps and getDmTargets.
*** The idea with the new functions is to expose device mapper metadata.  No modification is intended.
*** Other functions that might be usefull is dmExists(), dmTargets()
** iscsiadm (iscsi-initiator-utils)
** iscsiadm (iscsi-initiator-utils)
*** python bindings for equivalent of cmdline entry points
*** Write a small library to expose iscsi-initiator-utils functionality in a sane manner: [http://people.atrpms.net/~hdegoede/html/libiscsi_8h.html API proposal]
*** python bindings for libiscsi
*** hansg
*** hansg
** cryptsetup (cryptsetup-luks)
** cryptsetup (cryptsetup-luks)
*** python bindings for libcryptsetup and wrapper module in python (or equivalent of cryptsetup entry points)
*** python bindings for libcryptsetup and wrapper module in python (or equivalent of cryptsetup entry points)
*** msivak
*** msivak
*** I have example of internal cryptsetup library usage from mbroz so I should be able to pythonize the basic entry points we use now. The cryptsetup API needs rewrite to enable more advanced stuff and extensibility (updating the keys, safe partition formatting, ...).
*** Basic python library for cryptsetup entrypoints is ready
*** temporary git repo is at http://msivak.fedorapeople.org/git/pycryptsetup.git/
*** gitweb lives at http://fedorapeople.org/gitweb?p=msivak/public_git/pycryptsetup.git;a=summary
*** The cryptsetup API needs rewrite to enable more advanced stuff and extensibility (updating the keys, safe partition formatting, ...) and to be thread-safe.
*** packaged as python-cryptsetup
*** testing basic key management functions
** mdadm
** mdadm
*** python bindings for equivalent of cmdline entry points (or library, bindings, and wrapper module if feasible)
*** python bindings for equivalent of cmdline entry points (or library, bindings, and wrapper module if feasible)
*** rvykydal
*** rvykydal
*** [http://rvykydal.fedorapeople.org/mdadm_notes.txt notes and status] after mail exchange with Doug Ledford
*** [http://rvykydal.fedorapeople.org/status2.txt status Jan 28] - DK abandoned; mdadm used (now testing and fixing); array stop issues and md/udev/mdadm communication
** liblvm (lvm2?)
** liblvm (lvm2?)
*** library is still in early development (is there a project page we could link to?)
*** library is still in early development. Here is the  [[LVM/liblvm|project page]].
*** python bindings for library, and a python wrapper module if needed
*** python bindings for library, and a python wrapper module if needed
*** twoerner, along with others from lvm team
*** twoerner, along with others from lvm team
Line 53: Line 64:


Here is a first crack at visualizing the flow of storage-related portions of anaconda: [[:Image:storage_flow_highlevel.png|High-level storage flow]]
Here is a first crack at visualizing the flow of storage-related portions of anaconda: [[:Image:storage_flow_highlevel.png|High-level storage flow]]
[[:Image:Device_scan.png|Diagram]] of block device scanning procedure.
Here's a UML [[:Image:Classes.png|class diagram]].
And here is a directory containing pydoc output for the mid-layer [http://dlehman.fedorapeople.org/storage/doc/ device classes].


== TODO ==
== TODO ==

Latest revision as of 11:03, 29 January 2009

Anaconda Storage Rewrite

This is the main page for information about anaconda's pending storage rewrite. The entire storage subsystem is being rewritten from scratch. This is long overdue.

Motivation

Anaconda's device management, filesystem management, and partitioning code are all intertwined in a confusing mess. This code is comprised largely of custom software. As new and complex storage paradigms arise this code gets more and more convoluted. It is time to redesign with an eye toward extensibility and maintainability, to the extent that this is possible in the long term. It is also a potential opportunity to integrate some pieces of the post-install system into the installation environment so that users experience consistent behavior.

Tasks

The following tasks have been identified:

  • create python bindings for critical utilities
    • pyparted
      • rewrite
      • dcantrell, clumens
    • libdevmapper (device-mapper)
      • python bindings for libdevmapper
      • wrapper module in python if needed
      • hansg, jgranados
      • pyblock has the functionality we need for this. I basically added two functions: getDmDeps and getDmTargets.
      • The idea with the new functions is to expose device mapper metadata. No modification is intended.
      • Other functions that might be usefull is dmExists(), dmTargets()
    • iscsiadm (iscsi-initiator-utils)
      • Write a small library to expose iscsi-initiator-utils functionality in a sane manner: API proposal
      • python bindings for libiscsi
      • hansg
    • cryptsetup (cryptsetup-luks)
    • mdadm
      • python bindings for equivalent of cmdline entry points (or library, bindings, and wrapper module if feasible)
      • rvykydal
      • notes and status after mail exchange with Doug Ledford
      • status Jan 28 - DK abandoned; mdadm used (now testing and fixing); array stop issues and md/udev/mdadm communication
    • liblvm (lvm2?)
      • library is still in early development. Here is the project page.
      • python bindings for library, and a python wrapper module if needed
      • twoerner, along with others from lvm team
  • design/develop anaconda storage subsystem
    • device discovery and/or management subsystem
      • dlehman
    • internal representations of devices, filesystems, &c
      • interfaces to external libraries, utilities described above
      • dlehman
    • integration layer
      • partitioning
        • dlehman
      • filesystem management
        • dcantrell, dlehman
      • kickstart
        • clumens, dlehman
      • transactional model to interface with the UI layer
        • clumens, dcantrell
    • user interface
      • an external UI designer, hopefully (mizmo?)
      • clumens, dcantrell

Design Documents

Here is a quick mock-up of a design diagram.

Here is a first crack at visualizing the flow of storage-related portions of anaconda: High-level storage flow

Diagram of block device scanning procedure.

Here's a UML class diagram.

And here is a directory containing pydoc output for the mid-layer device classes.

TODO

  • make a schedule
  • generate some (very rough) design documents