Hi! >> Ganeti reporting
> >> ---------------- > >> > >> -``gnt-node list`` will by default report information just about the > >> -default storage type. It will be possible to add fields to ask about > >> -other ones, if they're enabled. Examples: > >> +`gnt-node list`` can be queried for the different storage methods, if > they > >> +are enabled. By default, it will just report information about the > default > >> +storage method. Examples: > >> > >> > gnt-node list > >> Node DTotal DFree MTotal MNode MFree Pinst Sinst > >> @@ -85,18 +85,23 @@ mynode1 3.6T 3.6T 64.0G 1023M > >> 62.2G 1 0 > >> mynode2 3.6T 3.6T 64.0G 1023M 62.0G 2 1 > >> mynode3 3.6T 3.6T 64.0G 1023M 62.3G 0 2 > >> > >> -> gnt-node list -o dtotal/lvm/myvg,dfree/rados/myrados > >> +> gnt-node list -o dtotal/lvm,dfree/rados > >> Node DTotal (Lvm, myvg) DFree (Rados, myrados) > >> mynode1 3.6T - > >> mynode2 3.6T - > >> > >> -We want to ensure that this design is forward-compatible with respect > to > >> -the introduction of storage pools. When storage pools are introduced, > we > >> -will name the default drbd storage pool 'drbd'. It will be possible to > >> -rename it. By default, ``gnt-node`` will report on the default storage, > >> -but it will be possible to ask about any of them. With the > implementation > >> -of storage pools, there will be new functionality to ask about what > storage > >> -pools are available and of what type. > >> +Note that for drbd, we only report the space of the vg and only if it > was > >> not > >> +renamed to something different than the default volume group name. With > >> this > >> +design, there is also no possibility to ask about the meta volume > group. We > >> +restrict the design here to make the transition to storage pools easier > >> (as it > >> +is an interim state only). It is the administrator's responsibility to > >> ensure > >> +that there is enough space for the meta volume group. > >> + > >> +When storage pools are implemented, we switch from referencing the > storage > >> +method to referencing the storage pool name. For that, of course, the > pool > >> +names need to be unique over all storage methods. The default drbd > storage > >> pool > >> +will be called 'drbd' and it will be possible to rename it. There will > be > >> new > >> +functionality to ask about what storage pools are available and of what > >> type. > > > > Since there's no actual "drbd" storage, just LVM under drbd, the concept > > of "drbd storage pool" doesn't make much sense. > > > > I don't know if this is just an accidental oversight or if it points to > > a bigger problem behind the storage pools design (it's not a 1:1 mapping > > between storage type and storage pool type). > > > > I believe this is an oversight, as we agreed that the "pool" for drbd > would be the one called (by default) "lvm". > drbd as you say is just a storage type that uses an lvm-based storage > pool (or two, with a different meta device). :) > Oh, sorry, that was indeed an oversight. I rewrote the paragraph to make it consistent with the design: When storage pools are implemented, we switch from referencing the storage method to referencing the storage pool name. For that, of course, the pool names need to be unique over all storage methods. For drbd, we will use the default 'lvm' storage pool and possibly a second lvm-based storage pool for the metavg. It will be possible to rename storage pools (thus also the default lvm storage pool). There will be new functionality to ask about what storage pools are available and of what type. Is that okay? Cheers, Helga
