----- Original Message -----
From: "Saggi Mizrahi" smizrahi@redhat.com To: "Adam Litke" agl@us.ibm.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Dan Kenigsberg" danken@redhat.com, "Vinzenz Feenstra" vfeenstr@redhat.com, "Ayal Baron" abaron@redhat.com, "Federico Simoncelli" fsimonce@redhat.com Sent: Monday, February 18, 2013 8:50:30 PM Subject: Re: VDSM Repository Reorganization
----- Original Message -----
From: "Adam Litke" agl@us.ibm.com To: "Federico Simoncelli" fsimonce@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Dan Kenigsberg" danken@redhat.com, "Saggi Mizrahi" smizrahi@redhat.com, "Vinzenz Feenstra" vfeenstr@redhat.com, "Ayal Baron" abaron@redhat.com Sent: Tuesday, February 12, 2013 3: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?
Well they both should have the file but when installed both should have their own version of the file depending on the version installed of the client or the server. This is so that vdsm-cli doesn't depend on vdsm or vice-versa. You can't have them share the file since if one is installed with a version of the schema where the schema syntax changed the client\server will fail to parse the schema.
I'm not sure what's the purpose of having different versions of the client/server on the same machine. The software repository is one and it should provide both (as they're built from the same source). This is the standard way of delivering client/server applications in all the distributions. We can change that but we must have a good reason.
As for development, I think the least bad solution is to put it in contrib with symlinks that have relative paths.
|--daemon | |-- [...] | `-- vdsmapi-schema.json -> ../contrib/vdsmapi-schema.json |--client | |-- [...] | `-- vdsmapi-schema.json -> ../contrib/vdsmapi-schema.json |--contrib | |-- [...] | `-- vdsmapi-schema.json : .
Git knows how to handle symlinks and symlinks are relative to the location of the symlink.
+1.