Re: [vdsm] VDSM Repository Reorganization
First lets illustrate the current repository structure: - tests - vdsm - storage - gluster - betterPopen ... and more unused directories - vdsm_api - vdsm_cli - vdsm_hooks - vdsm_log - vdsm_reg - vdsm_tools - vds_bootstrap - contrib As I understand your proposal, you added 'common' and 'deamon' and left the rest the way it is. So vdsm can be renamed to vdsm_core and can include sub folders for deamon and common\lib python files. It'll be something like: - vdsm_core - deamon - vdsmd .. - more deamon scripts - lib - independent tools - can also be part of vdsm_tools, as it doesn't part of the vdsm_core - utils.py - betterPopen - dmidecode ... - more unrelated utils that vdsm uses - core - vdsm - API.py - clientIF.py - config.py defines.py constants.py ... should be part of vdsm_core - libvirtconnection.py ... core files of vdsm - storage ... as it now without files that can be and should be moved to lib folder (e.g. threadPool, task, taskManager and inc..) the rest we'll stay the same. about the installation location it something else.. In my opinion this arrangement is nice to have, but not a must - we'll still need to set PYTHONPATH when we run from different locations (what you called making an hack), so as I see it, it just for comfort.. no? Maybe I missed something.. (And tests can be split to subfolders for each part - core\tests lib\tests and inc..) - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Adam Litke a...@us.ibm.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, February 13, 2013 1:06:55 AM Subject: Re: [vdsm] VDSM Repository Reorganization - Original Message - From: Adam Litke a...@us.ibm.com To: Federico Simoncelli fsimo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Dan Kenigsberg dan...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Vinzenz Feenstra vfeen...@redhat.com, Ayal Baron aba...@redhat.com Sent: Tuesday, February 12, 2013 9:08:09 PM Subject: Re: VDSM Repository Reorganization On Mon, Feb 11, 2013 at 12:17:39PM -0500, Federico Simoncelli wrote: It is some time now that we are discussing an eventual repository reorganization for vdsm. In fact I'm sure that we all experienced at least once the discomfort of having several modules scattered around the tree. The main goal of the reorganization would be to place the modules in their proper location so that they can be used (imported) without any special change (or hack) even when the code is executed inside the development repository (e.g. tests). Recently there has been an initial proposal about moving some of these modules: http://gerrit.ovirt.org/#/c/11858/ That spawned an interesting discussion that must involve the entire community; in fact before starting any work we should try to converge on a decision for the final repository structure in order to minimize the discomfort for the contributors that will be forced to rebase their pending gerrit patches. Even if the full reorganization won't happen in a short time I think we should plan the entire structure now and then eventually move only few relevant modules to their final location. To start the discussion I'm attaching here a sketch of the vdsm repository structure that I envision: . |-- client | |-- [...] | `-- vdsClient.py |-- common | |-- [...] | |-- betterPopen | | `-- [...] | `-- vdsm | |-- [...] | `-- config.py |-- contrib | |-- [...] | |-- nfs-check.py | `-- sos |-- daemon | |-- [...] | |-- supervdsm.py | `-- vdsmd `-- tool |-- [...] `-- vdsm-tool The schema file vdsmapi-schema.json (as well as the python module to parse it) are needed by the server and clients. Initially I'd think it should be installed in 'common', but a client does not need things like betterPopen. Any recommendation on where the schema/API definition should live? The problem is that betterPopen is misplaced as it's used only by the daemon. Anyway let's not mix the three different aspects: - repository structure - installation location - packaging That said in my opinion it can remain in common (which can be renamed to lib as Ewoud suggested) and be installed in the site-lib *but* be packaged only with the daemon (while we're waiting for it to become fully independent and be moved out of the repo). I suppose that the code dealing with the schema will be shared by both the client and the daemon and it will be placed in common (or lib) and the schema itself can go there too. To be honest I started envisioning client/common/daemon/tool as pure-python directories (as they are once installed) so maybe the schema could be placed somewhere else with other miscellaneous files (./schema? ./config?), but I wouldn't stress over this
Re: [vdsm] VDSM Repository Reorganization
On 02/13/2013 03:08 PM, Yaniv Bronheim wrote: First lets illustrate the current repository structure: - tests - vdsm - storage - gluster - betterPopen ... and more unused directories - vdsm_api - vdsm_cli - vdsm_hooks - vdsm_log - vdsm_reg - vdsm_tools - vds_bootstrap - contrib As I understand your proposal, you added 'common' and 'deamon' and left the rest the way it is. So vdsm can be renamed to vdsm_core and can include sub folders for deamon and common\lib python files. It'll be something like: - vdsm_core - deamon - vdsmd .. - more deamon scripts - lib - independent tools - can also be part of vdsm_tools, as it doesn't part of the vdsm_core - utils.py - betterPopen - dmidecode ... - more unrelated utils that vdsm uses - core - vdsm - API.py - clientIF.py - config.py defines.py constants.py ... should be part of vdsm_core - libvirtconnection.py ... core files of vdsm - storage ... as it now without files that can be and should be moved to lib folder (e.g. threadPool, task, taskManager and inc..) the rest we'll stay the same. about the installation location it something else.. In my opinion this arrangement is nice to have, but not a must - we'll still need to set PYTHONPATH when we run from different locations (what you called making an hack), so as I see it, it just for comfort.. no? Maybe I missed something.. (And tests can be split to subfolders for each part - core\tests lib\tests and inc..) - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Adam Litke a...@us.ibm.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, February 13, 2013 1:06:55 AM Subject: Re: [vdsm] VDSM Repository Reorganization - Original Message - From: Adam Litke a...@us.ibm.com To: Federico Simoncelli fsimo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Dan Kenigsberg dan...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Vinzenz Feenstra vfeen...@redhat.com, Ayal Baron aba...@redhat.com Sent: Tuesday, February 12, 2013 9:08:09 PM Subject: Re: VDSM Repository Reorganization On Mon, Feb 11, 2013 at 12:17:39PM -0500, Federico Simoncelli wrote: It is some time now that we are discussing an eventual repository reorganization for vdsm. In fact I'm sure that we all experienced at least once the discomfort of having several modules scattered around the tree. The main goal of the reorganization would be to place the modules in their proper location so that they can be used (imported) without any special change (or hack) even when the code is executed inside the development repository (e.g. tests). Recently there has been an initial proposal about moving some of these modules: http://gerrit.ovirt.org/#/c/11858/ That spawned an interesting discussion that must involve the entire community; in fact before starting any work we should try to converge on a decision for the final repository structure in order to minimize the discomfort for the contributors that will be forced to rebase their pending gerrit patches. Even if the full reorganization won't happen in a short time I think we should plan the entire structure now and then eventually move only few relevant modules to their final location. To start the discussion I'm attaching here a sketch of the vdsm repository structure that I envision: . |-- client | |-- [...] | `-- vdsClient.py |-- common | |-- [...] | |-- betterPopen | | `-- [...] | `-- vdsm | |-- [...] | `-- config.py |-- contrib | |-- [...] | |-- nfs-check.py | `-- sos |-- daemon | |-- [...] | |-- supervdsm.py | `-- vdsmd `-- tool |-- [...] `-- vdsm-tool The schema file vdsmapi-schema.json (as well as the python module to parse it) are needed by the server and clients. Initially I'd think it should be installed in 'common', but a client does not need things like betterPopen. Any recommendation on where the schema/API definition should live? The problem is that betterPopen is misplaced as it's used only by the daemon. Anyway let's not mix the three different aspects: +1 - repository structure Well that's what is supposed to be the topic. - installation location - packaging Those are supposed to be off topic considerint $SUBJECT That said in my opinion it can remain in common (which can be renamed to lib as Ewoud suggested) and be installed in the site-lib *but* be packaged only with the daemon (while we're waiting for it to become fully independent and be moved out of the repo). Where such things could be put in a folder 'extra' for now. (As an example) I suppose that the code dealing with the schema will be shared by both the client and the daemon and it will be placed in common (or lib) and the schema itself can go there too. To be honest I started envisioning client/common/daemon/tool as pure-python directories (as they are once
[vdsm] vdsm: patches last updated more than 30 days
below folks have the largest number of patches last updated more than 30 days ago, please refresh/abandon/ask for reviews/etc. preferred_email | count +-- fsimo...@redhat.com | 34 smizr...@redhat.com | 23 ewars...@redhat.com | 12 wu...@linux.vnet.ibm.com| 12 wu...@linux.vnet.ibm.com | 11 lvro...@linux.vnet.ibm.com | 8 shao...@linux.vnet.ibm.com | 6 li...@linux.vnet.ibm.com| 6 ybron...@redhat.com | 6 zhshz...@linux.vnet.ibm.com | 6 Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
