----- 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 9: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?

The problem is that betterPopen is misplaced as it's used only by the
daemon.

Anyway let's not mix the three different aspects:

- repository structure
- installation location
- packaging

That said in my opinion it can remain in "common" (which can be renamed to
"lib" as Ewoud suggested) and be installed in the site-lib *but* be
packaged only with the daemon (while we're waiting for it to become fully
independent and be moved out of the repo).

I suppose that the code dealing with the schema will be shared by both the
client and the daemon and it will be placed in "common" (or "lib") and
the schema itself can go there too.

To be honest I started envisioning client/common/daemon/tool as pure-python
directories (as they are once installed) so maybe the schema could be
placed somewhere else with other miscellaneous files (./schema? ./config?),
but I wouldn't stress over this if it's impractical.

-- 
Federico
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to