Revision a392a6b8 doc/design-2.1.rst
b/doc/design-2.1.rst | ||
---|---|---|
37 | 37 |
Core changes |
38 | 38 |
------------ |
39 | 39 |
|
40 |
Storage units modelling |
|
41 |
~~~~~~~~~~~~~~~~~~~~~~~ |
|
42 |
|
|
43 |
Currently, Ganeti has a good model of the block devices for instances |
|
44 |
(e.g. LVM logical volumes, files, DRBD devices, etc.) but none of the |
|
45 |
storage pools that are providing the space for these front-end |
|
46 |
devices. For example, there are hardcoded inter-node RPC calls for |
|
47 |
volume group listing, file storage creation/deletion, etc. |
|
48 |
|
|
49 |
The storage units framework will implement a generic handling for all |
|
50 |
kinds of storage backends: |
|
51 |
|
|
52 |
- LVM physical volumes |
|
53 |
- LVM volume groups |
|
54 |
- File-based storage directories |
|
55 |
- any other future storage method |
|
56 |
|
|
57 |
There will be a generic list of methods that each storage unit type |
|
58 |
will provide, like: |
|
59 |
|
|
60 |
- list of storage units of this type |
|
61 |
- check status of the storage unit |
|
62 |
|
|
63 |
Additionally, there will be specific methods for each method, for example: |
|
64 |
|
|
65 |
- enable/disable allocations on a specific PV |
|
66 |
- file storage directory creation/deletion |
|
67 |
- VG consistency fixing |
|
68 |
|
|
69 |
This will allow a much better modeling and unification of the various |
|
70 |
RPC calls related to backend storage pool in the future. Ganeti 2.1 is |
|
71 |
intended to add the basics of the framework, and not necessarilly move |
|
72 |
all the curent VG/FileBased operations to it. |
|
73 |
|
|
74 |
Note that while we model both LVM PVs and LVM VGs, the framework will |
|
75 |
**not** model any relationship between the different types. In other |
|
76 |
words, we don't model neither inheritances nor stacking, since this is |
|
77 |
too complex for our needs. While a ``vgreduce`` operation on a LVM VG |
|
78 |
could actually remove a PV from it, this will not be handled at the |
|
79 |
framework level, but at individual operation level. The goal is that |
|
80 |
this is a lightweight framework, for abstracting the different storage |
|
81 |
operation, and not for modelling the storage hierarchy. |
|
82 |
|
|
40 | 83 |
Feature changes |
41 | 84 |
--------------- |
42 | 85 |
|
Also available in: Unified diff