----- Original Message -----
From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
To: "Adam Litke" <agl(a)us.ibm.com>
Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org>,
"Dan Kenigsberg" <danken(a)redhat.com>, "Vinzenz
Feenstra" <vfeenstr(a)redhat.com>, "Ayal Baron"
<abaron(a)redhat.com>, "Federico Simoncelli" <fsimonce(a)redhat.com>
Sent: Monday, February 18, 2013 8:50:30 PM
Subject: Re: VDSM Repository Reorganization
----- Original Message -----
> From: "Adam Litke" <agl(a)us.ibm.com>
> To: "Federico Simoncelli" <fsimonce(a)redhat.com>
> Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org>,
> "Dan Kenigsberg" <danken(a)redhat.com>, "Saggi
> Mizrahi" <smizrahi(a)redhat.com>, "Vinzenz Feenstra"
> <vfeenstr(a)redhat.com>, "Ayal Baron" <abaron(a)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.
--
Federico