Hi Iustin
2009/7/28 Iustin Pop <[email protected]>:
> Ah, I think my patch was misunderstood. The storage types/framework is
> intended to complement, not replace bdev.
>
> In other words:
> - for the storage that is related to a particular instance, bdev
> remains and works as today (e.g. a LV, a DRBD device, a file).
> - for the storage *groups* that are common to multiple instances, the
> storage units framework will unify the current disparate functions
> under this common framework
>
> So bdev remains as-is, and only things like:
> - bdev.LogicalVolume.ListPVs (which doesn't make sense under a logical
> volume)
> - utils.ListVolumeGroups
> - backend.FileStorageCreateDirectory
>
> will move under this framework.
>
>> Listing:
>> LVM PVs: Nothing
>> LVM VGs: Nothing
>> LVM LVs: VG name
>> File: Directory path
>> DRBD: Nothing (not sure)
>
> Per the above, LVs, DRBD do not belong to this framework.
Thanks for the clarification.
>> Should these parameters be passed in a dict? E.g. in pseudocode:
>>
>> class LvmLv:
>> def List(self, params):
>> try:
>> vgname = params["vgname"]
>> except KeyError:
>> raise Exception("Missing 'vgname' parameter")
>>
>> …
>>
>> Of course the real code would use constants, but do you see another
>> way to do it?
>
> I think that we should aim to keep the listing without custom
> parameters, but via a generic ID. For each storage type, we have this
> 'id' which is unique for storage units of that type:
> - the file storage directory
> - the volume group name
> - the PV physical device name
>
> 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?
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 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.*).
Regards,
Michael
