2009/7/28 Iustin Pop <[email protected]>: > On Tue, Jul 28, 2009 at 11:35:47AM +0200, Michael Hanselmann wrote: >> Another thing is which columns (or values) to return. In Ganeti we use >> a slightly different codepath as an optimization in listing nodes when >> the nodes need to be contacted. I don't know too much in this regard >> about LVM, but some values may be more expensive to get than others. >> Should the listing functions also take a list of columns? These column >> names would be type specific, but they can be stored in constants. > > I'm not sure if we have any ID-specific columns. Basically I was > thinking it's always id, free space, allocatable (yes/no), consistent > (yes/no).
> I would propose we start with all fields and worry later about > optimisations. Most storage types have more information attached to entities. Just as an example, “pvs” can also return used space. My proposed patch series for “gnt-node physical-volumes” lists it as well. On the other hand file storage doesn't have per-directory free space as it's a property of the underlying filesystem (may not matter if one uses only one directory). I think implementing different columns (and a few generic ones for name, allocatable and consistent) isn't very complex. >> Let me modify my proposal slightly: How about per-daemon namespaces >> for code specific to a daemon? “backend” could go to >> ganeti.noded.backend, “cmdlib”, “config” and “locking” to >> ganeti.masterd.* (didn't check those in all details, it may not work). >> Usually only a small part of the code is shared and could go into a >> generic module (ganeti.*). > > Sounds good. I'll ask again though: how is better than simply > documenting this split? It reduces the noise level in ganeti.* a bit and increases code modularization. Of course documentation is good, but it easily gets out of date (as opposed to realizing something isn't right when you start importing noded code into masterd). Regards, Michael
