[Please followup to zodb-dev.]
Richard,
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.
One other requirement for ZEO is that it work with Zope 2.6. I expect there will be a ZODB 3.2 release long before there is a Zope 2.7 release. So we can't depend on any Zope 2.7 features in mkzeoinst.py.
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!
The problem with sharing software is that the ZEO server can load arbitrary modules when it attempts to perform conflict resolution. If there is a conflict for an instance of class A.B.C, then ZEO will load A.B.C and see if it has an _p_resolveConflict() method. If the modules A or B have any side-effects at import time, then those side-effects will occur in the ZEO server. I've seen this method lookup cause all of CMF to get imported and try to initialize itself. This ended up brining down the ZEO server.
A safer way to run a ZEO server is to have an isolated copy of the software that only contains software for objects that need to perform conflict resolution. In practice, many sites only need conflict resolution for BTrees. So none of the other Zope or product code needs to be accessible to the ZEO server.
Do you have any ideas about how to support the features you need given the requirements I've suggested here? Do those requirements make sense?
Jeremy
Jeremy Hylton wrote at 2003-5-27 14:38 -0400:
... The problem with sharing software is that the ZEO server can load arbitrary modules when it attempts to perform conflict resolution. If there is a conflict for an instance of class A.B.C, then ZEO will load A.B.C and see if it has an _p_resolveConflict() method. If the modules A or B have any side-effects at import time, then those side-effects will occur in the ZEO server. I've seen this method lookup cause all of CMF to get imported and try to initialize itself. This ended up brining down the ZEO server.
That sounds bad...
Products may well have classes which require conflict resolution (see e.g. "QueueCatalog"). It would be very tedious to let ZEO see only the classes, keep them importable for ZEO but remove everything else.
Can we find a better solution, maybe, some kind of configuration which lists are classes which may have conflict resolution?
Dieter
-----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
-
Dieter Maurer -
Jeremy Hylton -
Richard Jones