On Mon, Jul 27, 2009 at 03:23:34PM +0200, Michael Hanselmann wrote: > > Hi Iustin
Hi Michael, > 2009/6/30 Iustin Pop <[email protected]>: > > diff --git a/doc/design-2.1.rst b/doc/design-2.1.rst > > index 607687c..af68087 100644 > > --- a/doc/design-2.1.rst > > +++ b/doc/design-2.1.rst > > +There will be a generic list of methods that each storage unit type > > +will provide, like: > > + > > +- list of storage units of this type > > +- check status of the storage unit > > I spent thought on this. Different storage types need different > parameters just to list them, not even thinking of more complex > operations such as creation or getting them ready for use (“Open” in > bdev). 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. > 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). > > > +Additionally, there will be specific methods for each method, for example: > > + > > +- enable/disable allocations on a specific PV > > +- file storage directory creation/deletion > > +- VG consistency fixing > > Should these additional methods exist outside the framework or just > throw NotImplementedError for the types where they don't apply? I think within the framework, with NotImplementedError. Well, better said 'errors.NotApplicable' instead of notimplemented. > > +This will allow a much better modeling and unification of the various > > +RPC calls related to backend storage pool in the future. Ganeti 2.1 is > > +intended to add the basics of the framework, and not necessarilly move > > +all the curent VG/FileBased operations to it. > > This is not directly related to this design proposal, but it fits in > here nonetheless: Most of the code currently resides in the ganeti.* > namespace. Some of it is used by both ganeti-noded and ganeti-masterd, > some just by ganeti-noded and some by ganeti-masterd. One has to > remember which modules are used where and I think it would make sense > to introduce an additional layer for new code, such as this storage > framework, which will only be used by ganeti-noded and could go to (this storage framework will be very much used by masterd) > ganeti.node.*. ganeti.master.* could be used for masterd specific > code. Generic things, such as utils, continue to live in ganeti.*. Of > course we wouldn't migrate everything for 2.1, but can do so gradually > over the next versions. A design doc update would have to be written. > What do you think of this? I agree that we have many submodules right now and that it becomes a confusing situation. However, except for a very few modules (backend, cmdlid) some of the modules are also used in both sides just for some special cases. E.g. hypervisor is imported in masterd for the static naming, even though it's real functionality is purely noded-side. In the end, only the imports will change (from ganei.master import cmdlib), so the change for the code is zero. So if you think this is useful, go ahead. 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?). thanks, iustin
