Anaconda/StorageRewrite

From FedoraProject

< Anaconda(Difference between revisions)
Jump to: navigation, search
(Add link to rough design diagram.)
(Add link to high-level storage flowchart.)
Line 50: Line 50:
 
== Design Documents ==
 
== Design Documents ==
 
Here is a quick mock-up of a [[:Image:Anaconda_storage.png|design diagram]].
 
Here is a quick mock-up of a [[:Image:Anaconda_storage.png|design diagram]].
 +
 +
Here is a first crack at visualizing the flow of storage-related portions of anaconda: [[:Image:storage_flow_highlevel.png|High-level storage flow]]
  
 
== TODO ==
 
== TODO ==

Revision as of 22:35, 14 November 2008

Contents

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
    • iscsiadm (iscsi-initiator-utils)
      • python bindings for equivalent of cmdline entry points
      • hansg
    • cryptsetup (cryptsetup-luks)
      • python bindings for libcryptsetup and wrapper module in python (or equivalent of cryptsetup entry points)
      • msivak
    • mdadm
      • python bindings for equivalent of cmdline entry points (or library, bindings, and wrapper module if feasible)
      • rvykydal
    • liblvm (lvm2?)
      • library is still in early development (is there a project page we could link to?)
      • 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

TODO

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