Hi everyone,
It would be nice to come to an agreement any time soon. I would like to
apply all the change as soon as possible.
I would not like to see this go into the depth of a dead hole.
Thanks.
On 02/13/2013 03:54 PM, Vinzenz Feenstra wrote:
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" <fsimonce(a)redhat.com>
> To: "Adam Litke" <agl(a)us.ibm.com>
> Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org>
> Sent: Wednesday, February 13, 2013 1:06:55 AM
> Subject: Re: [vdsm] 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 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