s/disk type/desired storage type/g
The example adds the extra information, as a StorageUnit would be
rendered:
["drbd8", "volumegroup", []], etc
On Fri, Dec 19, 2014 at 02:12:55PM +0100, Klaus Aehlig wrote:
>
> > +Proposed changes
> > +================
> > +
> > +Definitions
> > +-----------
> > +
> > +* All disks have exactly one *disk type*, which determines where and how
> > the
> > + disk can be stored. If the disk is transfered, the disk type remains
> > + unchanged.
>
> This is a bit misleading, as we usually use the term "disk type" to referr to
> the way the disk is built up, i.e., things like "drbd", "plain", and "file".
> However, already now we can specify which volume group a disk for an instance
> is to be taken from---and that is supposed to remain unchanged over instance
> moves. A typical use case for this already existing feature is to have two
> volume
> groups formed of different physical disks, e.g., solid-state disk and hard
> drives.
>
> So, is this notion supposed to be "disk type" in the sense we use it for
> disk templates (then the assumptions that all providers of that disk type
> are equal does not hold, already now) or is it supposed to be an abstract
> name space supposed to take also into account how storage for that type is
> provided (then I'd prefere a name not easily confusable with the notion
> of disk type we already have)?
>
>
> --
> Klaus Aehlig
> Google Germany GmbH, Dienerstr. 12, 80331 Muenchen
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschaeftsfuehrer: Graham Law, Christine Elizabeth Flores
--
Google Germany GmbH
Dienerstr. 12
80331 München
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
diff --git a/doc/design-multi-storage-htools.rst
b/doc/design-multi-storage-htools.rst
index 17cb8e3..627939b 100644
--- a/doc/design-multi-storage-htools.rst
+++ b/doc/design-multi-storage-htools.rst
@@ -37,16 +37,17 @@ Proposed changes
Definitions
-----------
-* All disks have exactly one *disk type*, which determines where and how the
- disk can be stored. If the disk is transfered, the disk type remains
- unchanged.
+* All disks have exactly one *desired storage unit*, which determines where and
+ how the disk can be stored. If the disk is transfered, the desired storage
+ unit remains unchanged. The desired storage unit includes specifics like the
+ volume group in the case of LVM based storage.
* A *storage unit* is a specific storage location on a specific node. Storage
- types have at least one disk type they can contain. A storage unit further
- has a name, a total capacity, and a free capacity.
-* For the purposes of this document a *disk* has a disk type and a size.
+ units have exactly one desired storage unit they can contain. A storage unit
+ further has a name, a total capacity, and a free capacity.
+* For the purposes of this document a *disk* has a desired storage unit and a
size.
* A *disk can be moved* to a node, if there is at least one storage unit on
- that node which can contain the disk type of the disk and if the free
- capacity is at least the size of the disk.
+ that node which can contain the desired storage unit of the disk and if the
+ free capacity is at least the size of the disk.
* An *instance can be moved* to a node, if all its disks can be moved there
one-by-one.
@@ -64,19 +65,19 @@ The LUXI protocol is extended to include:
{
"storage": [
- { "stype": "drbd8"
+ { "stype": ["drbd8", "xenvg", []]
, "free": 2000,
, "total": 4000
},
- { "stype": "file"
+ { "stype": ["file", "/path/to/storage1", []]
, "free": 5000,
, "total": 10000
},
- { "stype": "file"
+ { "stype": ["file", "/path/to/storage2", []]
, "free": 1000,
, "total": 20000
},
- { "stype": "lvm-vg"
+ { "stype": ["lvm-vg", "xenssdvg", []]
, "free": 1024,
, "total": 1024
}
@@ -123,15 +124,15 @@ In order to determine a storage location for an instance,
we collect analogous
metrics to the current total node free space metric -- namely the standard
deviation
statistic of the free space per storage unit.
-The full storage metric for a given disk type is a weighted sum of the standard
-deviation metric of the storage units. The weights of the storage units are
-proportional to the total of that storage unit and sum up to the weight of
-space in the old implementation (1.0).
+The full storage metric for a given desired storage unit is a weighted sum of
+the standard deviation metric of the storage units. The weights of the storage
+units are proportional to the total of that storage unit and sum up to the
+weight of space in the old implementation (1.0).
This is necessary to
#. Keep the metric compatible.
#. Avoid that the metric of a node with many storage units is dominated by
them.
-Note that the metric is independent of the disk type to be placed, but the
+Note that the metric is independent of the storage type to be placed, but the
other types don't change the ranking of the possible placements.
