On 02/13/2013 03:08 PM, Yaniv Bronheim wrote:
First lets illustrate the current repository structure:
- tests
- vdsm
- storage
- gluster
- betterPopen
... and more unused directories
- vdsm_api
- vdsm_cli
- vdsm_hooks
- vdsm_log
- vdsm_reg
- vdsm_tools
- vds_bootstrap
- contrib
As I understand your proposal, you added 'common' and 'deamon' and left the
rest the way it is.
So vdsm can be renamed to vdsm_core and can include sub folders for deamon and
common\lib python files.
It'll be something like:
- vdsm_core
- deamon
- vdsmd
.. - more deamon scripts
- lib - independent tools -> can also be part of vdsm_tools, as it doesn't
part of the vdsm_core
- utils.py
- betterPopen
- dmidecode
... - more unrelated utils that vdsm uses
- core
- vdsm
- API.py
- clientIF.py
- config.py defines.py constants.py ... should be part of vdsm_core
- libvirtconnection.py
... core files of vdsm
- storage
... as it now without files that can be and should be moved to lib folder
(e.g. threadPool, task, taskManager and inc..)
the rest we'll stay the same.
about the installation location it something else..
In my opinion this arrangement is nice to have, but not a must - we'll still
need to set PYTHONPATH when we run from different locations (what you called
making an hack), so as I see it, it just for comfort.. no? Maybe I missed
something..
(And tests can be split to subfolders for each part - core\tests lib\tests and
inc..)
----- Original Message -----
From: "Federico Simoncelli" <fsimo...@redhat.com>
To: "Adam Litke" <a...@us.ibm.com>
Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>
Sent: Wednesday, February 13, 2013 1:06:55 AM
Subject: Re: [vdsm] 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 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:
+1
- repository structure
Well that's what is supposed to be the topic.
- installation location
- packaging
Those are supposed to be off topic considerint $SUBJECT
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).
Where such things could be put in a folder 'extra' for now. (As an example)
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.
I would like to see also pure python directories.
A rough quick n dirty overview how I could imagine it to look like:
topdir/
build-aux/*
contrib/*
deployment/
bootstrap/
log/
reg/
doc/
vdsm
api
cli
hooks/*
m4/*
tests/*
scripts/
vdsm/*
storage/*
network/*
vdsm/
api/
json/
jsonrpc/
BindingJsonRpc.py
xml/
BindingXMLRPC.py
Bridge.py
vdsmapi-schema.json
process-schema.py
vdsmapi.py
cli/
vdsClient.py
VdsClientGluster.py
extra/
betterPopen/
shared/
vdsm/
SecureXMLRPCServer.py
config.py.in
constants.py.in
utils.py
vdscli.py.in*
utils.py
tool/
daemon/
storage/*
network/*
vdsmd/
vdsm
*
That said, I need to assert that I am not yet fully aware of all
connections between the files and I guess the maintainers will know best
about their respective parts of responsibility.
I'd like to add that it'd be probably a good idea to start having
network and storage split off the main daemon for maintenance reasons,
even if they interface each other.
I personally even could see a scenario where network and storage are
working as standalone daemons. However that's off topic for know I guess.
--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
