----- Original Message -----
From: "Federico Simoncelli" <fsimonce(a)redhat.com>
To: "Saggi Mizrahi" <smizrahi(a)redhat.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>, "Adam Litke" <agl(a)us.ibm.com>
Sent: Tuesday, February 19, 2013 11:27:59 AM
Subject: Re: VDSM Repository Reorganization
----- 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.
There isn't really a reason. But, as I said, you don't want them
to
depend on each other or have the schema in it's own rpm.
This means that you have to distribute them separately.
I also want to allow to update the client on a host without updating
the server. This is because you may want to have a script that works
across the cluster but not update all the hosts.
Now, even though you will use only old methods, the schema itself
might become unparsable by old implementations.
> 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