[Zope-dev] ZEO install/runtime issues

[Richard Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday, May 28, 2003, at 04:38 AM, Jeremy Hylton wrote:
> [Please followup to zodb-dev.]
>
> You made some changes to the mkzeoinst.py script in April.  I was busy
> then, and I've just had a chance to look at the changes now.  I'd like
> to discuss some of the changes, and I'm including a wider discussion
> list to make sure we include anyone else who is interested.
>
> A number of the changes are Zope specific.  (For example, you can't 
> even
> run mkzeoinst.py without having a directory named "Zope" hanging off of
> sys.path.)  ZEO and ZODB are intended for use separately from the rest
> of Zope, so we need to find a way to factor this out into a generic
> configuration and a Zope-specific configuration.

Go for it :)  [I'm in hard-core product development mode for a few 
months, so apart from critical Zope bugfixes along the way I'll not 
really be much use, sorry ... even Roundup is taking the back seat for 
a while ;)]

Perhaps Zope's mkzeoinstance should have all that Zope-specific stuff, 
and only hook into the mkzeoinst module for some of the generic 
functions. there may even be some more potential for sharing of code 
between mkzeoinstance and mkzopeinstance.


> The other question I have is about the organization of software into a
> Zope home and an instance home.  I'm not sure what the history of this
> arrangement is, but I recommend that people do not configure their ZEO
> servers to share software with their Zope app servers.  It can cause
> fairly severe problems!

I was completely unaware of this, and have always run ZEO servers with 
the full complement of Products. I have no immediate suggestion for a 
solution to this problem. The big issue is really how are (potentially 
"dumb", point-n-click) users to know that they need to install product 
X in their ZEO server but not product Y? Dieter's solution of some 
configuration variable controlling this sounds like a really good idea, 
if possible.


     Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE+1ZI4rGisBEHG6TARApA1AJ9V5Vy/FD8Dx7Nyp2lcXhTgDuAokwCeJqLJ
gbubTTKmtV/Heyush75rW44=
=qVyG
-----END PGP SIGNATURE-----