On Tue, Jul 28, 2009 at 11:35:47AM +0200, Michael Hanselmann wrote: > Hi Iustin > > As such, the listing can either auto-discover these (pvs, vgs, but not > > for files storage directories; for this I would leave in 2.1 a single > > file storage directory) or configure them in ganeti (like enable VG for > > ganeti use or not). > > Okay, so if the ID (or name) is None, we autodiscover all entities of > the storage type on the machine?
Sounds good. > 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. > > I'm not sure if this makes sense to do it like this instead of in > > the module docstring (@note: This is a node-daemon module) because > > in the future we'll also have the daemons on the master candidates > > and then it won't be a clear split (from ganeti.mc import foo?). > > 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? thanks! iustin
