On Mon, Mar 11, 2013 at 06:28:26AM -0700, Guido Trotter wrote: > On Mon, Mar 11, 2013 at 6:17 AM, Helga Velroyen <[email protected]> wrote: > > This patch updates the design doc "Design correct reporting of storage > > free space". The modifications were chosen to not conflict with any > > future changes of Ganeti regarding storage pools. > > > > Signed-off-by: Helga Velroyen <[email protected]> > > --- > > doc/design-storagespace.rst | 118 > > +++++++++++++++++++++++++++++++------------- > > 1 file changed, 83 insertions(+), 35 deletions(-) > > > > diff --git a/doc/design-storagespace.rst b/doc/design-storagespace.rst > > index 919479f..67603e8 100644 > > --- a/doc/design-storagespace.rst > > +++ b/doc/design-storagespace.rst > > @@ -20,21 +20,19 @@ interaction with different storage types. > > Configuration changes > > --------------------- > > > > -Each storage type will have a new "pools" parameter added (type list of > > -strings). This will be list of vgs for plain and drbd (note that we make > > -no distinction at this level between allowed vgs and metavgs), the list > > -of rados pools for rados, or the storage directory for file and > > -sharedfile. The parameters already present in the cluster config object > > -will be moved to the storage parameters. > > - > > -Since currently file and sharedfile only support a single directory this > > -list will be limited to one. In the future if we'll have support for > > -more directories, or for per-nodegroup directories this can be changed. > > - > > -Note that these are just "mechanisms" parameters that define which > > -storage pools the cluster can use. Further filtering about what's > > -allowed can go in the ipolicy, but these changes are not covered in this > > -design doc. > > +Add a new attribute "enabled_storage_methods" (type: list of strings) to > > the > > +cluster config which holds the types of storages, for example, "plain", > > "drbd", > > +or "ext". We consider the first one of the list as the default method. > > + > > +For file storage, we'll report the storage space on the file storage dir, > > +which is currently limited to one directory. In the future, if we'll have > > +support for more directories, or for per-nodegroup directories this can be > > +changed. > > + > > +Note that the abovementioned enabled_storage_methods are just "mechanisms" > > +parameters that define which storage methods the cluster can use. Further > > +filtering about what's allowed can go in the ipolicy, but these changes are > > +not covered in this design doc. > > > > Since the ipolicy currently has a list of enabled storage types, we'll > > use that to decide which storage type is the default, and to self-select > > @@ -47,17 +45,23 @@ RPC changes > > ----------- > > > > The noded RPC call that reports node storage space will be changed to > > -accept a list of <method>,<key> string tuples. For each of them it will > > -report the free amount of space found on storage <key> as known by the > > -requested method. Methods are for example ``lvm``, ``filesystem``, > > -``rados``, and the key would be a volume group name in the case of lvm, > > -a directory name for the filesystem and a rados pool name, for > > -rados_pool. > > +accept a list of <method>,<key> string tuples. For each of them, it will > > +report the free amount of storage space found on storage <key> as known > > +by the requested storage type method. For example methods are ``lvm``, > > +``filesystem``, or ``rados``, and the key would be a volume group name, in > > +the case of lvm, a directory name for the filesystem and a rados pool name > > +for rados storage. > > + > > +For now, we will implement only the storage reporting for non-shared > > storage, > > +that is ``filesystem`` and ``lvm``. For shared storage methods like > > ``rados`` > > +and ``ext`` we will not implement a free space calculation, because it does > > +not make sense to query each node for the free space of a commonly used > > +storage. > > > > Masterd will know (through a constant map) which storage type uses which > > method for storage calculation (i.e. ``plain`` and ``drbd`` use ``lvm``, > > -``file`` and ``sharedfile`` use ``filesystem``, etc) and query the one > > -needed (or all of the needed ones). > > +``file`` uses ``filesystem``, etc) and query the one needed (or all of the > > +needed ones). > > > > Note that for file and sharedfile the node knows which directories are > > allowed and won't allow any other directory to be queried for security > > @@ -73,18 +77,40 @@ 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. > > - > > -``gnt-node info`` will report information about all enabled storage > > -types, without querying them (just say which ones are supported > > -according to the cluster configuration). > > - > > -``gnt-node list-storage`` will change to report information about all > > -available storage pools in each storage type. An extra flag will be > > -added to filter by storage pool name (alternatively we can implement > > -this by allowing to query by a list of ``type:pool`` string tuples to > > -have a more comprehensive filter). > > - > > +other ones, if they're enabled. Examples: > > + > > +> gnt-node list > > +Node DTotal DFree MTotal MNode MFree Pinst Sinst > > +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 > > +Node DTotal (Lvm, myvg) DFree (Rados, myrados) > > +mynode1 3.6T - > > +mynode2 3.6T - > > + > > Could you add a note on how one is supposed to find about the > "myrados" and "myvg" parts, and perhaps we can also have just > dtotal/lvm that gives the "first/default" lvm. Also with storage > pools, won't we go directly dtotal/pool_name without specifying "lvm" > or "rados" in between? So perhaps we should "just" as an interim allow > two levels, or allow three levels in between but go towards having > two, in the future.
Wait a second. I'm thoroughly confused now. I thought the discussion was that in the current stage we don't allow custom names, but only one pool (key=type), and in the future key=type migrates to key=name (pointing to the definitions)?! iustin
