----- 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.
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.
We could also just select the daemon or the client folder and put the real
file there and a symlink in the other but I feel it's like choosing which
one of your children is the main user of a schema file.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center