----- Original Message -----
> From: "Federico Simoncelli" <fsimo...@redhat.com>
> To: "Saggi Mizrahi" <smizr...@redhat.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>, "Adam 
> Litke" <a...@us.ibm.com>
> Sent: Tuesday, February 19, 2013 11:27:59 AM
> Subject: Re: VDSM Repository Reorganization
> 
> ----- 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.
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
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to