----- Original Message -----
> From: "Saggi Mizrahi" <smizr...@redhat.com>
> To: "Adam Litke" <a...@us.ibm.com>
> Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>, "Dan 
> Kenigsberg" <dan...@redhat.com>, "Vinzenz
> Feenstra" <vfeen...@redhat.com>, "Ayal Baron" <aba...@redhat.com>, "Federico 
> Simoncelli" <fsimo...@redhat.com>
> Sent: Monday, February 18, 2013 8:50:30 PM
> Subject: Re: 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 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
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to