I'm in the process of attempting to migrate a fairly large scale internal XMLRPC system over to Zope. The current system is all custom. That provides for a lot of internal code that we really don't need to be managing. I'm looking for best practices and approaches to deploying Zope 3 instances and a backend ZEO server to share the data. I don't think I've seen it covered anywhere. I've seen it documented from the Zope 2 perspective (both old school and via buildout recipes). It seems this would be a fairly common configuration. Is this stuff covered anywhere? I've been hitting Google up for the last hour or so and I can't seem to find any documentation on deployment and update methodologies. Thanks!
--On 11. Juli 2008 10:57:17 -0400 Jeff McNeil <jeff@jmcneil.net> wrote:
I'm in the process of attempting to migrate a fairly large scale internal XMLRPC system over to Zope. The current system is all custom. That provides for a lot of internal code that we really don't need to be managing.
I'm looking for best practices and approaches to deploying Zope 3 instances and a backend ZEO server to share the data. I don't think I've seen it covered anywhere. I've seen it documented from the Zope 2 perspective (both old school and via buildout recipes). It seems this would be a fairly common configuration.
I don't see how this would be different in the Zope 3 world. Buildout is the way to go. Depart from that your question is pretty generic. -aj
That's not all that obvious to someone new to the Zope system. Most of the documentation I've found is geared towards the 2.x branch. As Zope 3 and Zope 2 are different animals, I wouldn't think that the deployment steps and recommendations would be all that similar. I really like what I've seen thus far, it's just been difficult at times as it feels like I'm fighting with documentation. So I'm assuming I'll just need to build up a Zeo server instance with zc.zodbrecipes and update my corresponding buildout.cfg for the Zope instances? If Buildout is the preferred deployment tool, then my redistributable is a sandbox tarball or an RPM containing the skeleton files needed to bootstrap a buildout run on the target hosts? Maybe I'll dump the whole process on a blog somewhere as I step through it. I do have another question. The project we're working on is plug-in based. Within the old system, eggs are loaded dynamically using setuptools pkg_resources and we define certain entry points for capability registration. Eggs are added to a directory and a config entry is made such that we can load the proper version of each plug-in. Is there an upfront way to reproduce that functionality without needing to update setup.py and rerun buildout every time we want to push a new plug-in or update an existing? I'd love to be able to just drop an egg on the file system and tell Zope "Here, go load that one now" via configuration alone. My apologies if some of this is obvious. As I said, I'm really just tackling Zope for the first time. Jeff On Fri, Jul 11, 2008 at 11:01 AM, Andreas Jung <lists@zopyx.com> wrote:
--On 11. Juli 2008 10:57:17 -0400 Jeff McNeil <jeff@jmcneil.net> wrote:
I'm in the process of attempting to migrate a fairly large scale internal XMLRPC system over to Zope. The current system is all custom. That provides for a lot of internal code that we really don't need to be managing.
I'm looking for best practices and approaches to deploying Zope 3 instances and a backend ZEO server to share the data. I don't think I've seen it covered anywhere. I've seen it documented from the Zope 2 perspective (both old school and via buildout recipes). It seems this would be a fairly common configuration.
I don't see how this would be different in the Zope 3 world. Buildout is the way to go. Depart from that your question is pretty generic.
-aj
Jeff McNeil wrote:
That's not all that obvious to someone new to the Zope system. Most of the documentation I've found is geared towards the 2.x branch. As Zope 3 and Zope 2 are different animals, I wouldn't think that the deployment steps and recommendations would be all that similar.
With buildout, they can be similar, at least superficially.
I really like what I've seen thus far, it's just been difficult at times as it feels like I'm fighting with documentation.
So I'm assuming I'll just need to build up a Zeo server instance with zc.zodbrecipes and update my corresponding buildout.cfg for the Zope instances?
Yep, you can do that.
If Buildout is the preferred deployment tool, then my redistributable is a sandbox tarball or an RPM containing the skeleton files needed to bootstrap a buildout run on the target hosts?
Yes.
Maybe I'll dump the whole process on a blog somewhere as I step through it.
That'd be cool!
I do have another question. The project we're working on is plug-in based. Within the old system, eggs are loaded dynamically using setuptools pkg_resources and we define certain entry points for capability registration. Eggs are added to a directory and a config entry is made such that we can load the proper version of each plug-in. Is there an upfront way to reproduce that functionality without needing to update setup.py and rerun buildout every time we want to push a new plug-in or update an existing?
Well, you could just do the exact same thing that you did in your old application, I suppose.
I'd love to be able to just drop an egg on the file system and tell Zope "Here, go load that one now" via configuration alone.
You could also write your own ZCML directive (+ a handler) that does that. Then you'd only ever have to change your application's site.zcml to load a new plugin.
My apologies if some of this is obvious. As I said, I'm really just tackling Zope for the first time.
Don't worry, your questions are valid. We haven't actually done a very good job of documenting things on the website.
On Sun, Jul 13, 2008 at 01:20:53PM -0400, Philipp von Weitershausen wrote:
Jeff McNeil wrote:
I'd love to be able to just drop an egg on the file system and tell Zope "Here, go load that one now" via configuration alone.
You could also write your own ZCML directive (+ a handler) that does that. Then you'd only ever have to change your application's site.zcml to load a new plugin.
There's also this: http://pypi.python.org/pypi/z3c.autoinclude -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Sun, Jul 13, 2008 at 01:20:53PM -0400, Philipp von Weitershausen wrote:
Jeff McNeil wrote:
I'd love to be able to just drop an egg on the file system and tell Zope "Here, go load that one now" via configuration alone. You could also write your own ZCML directive (+ a handler) that does that. Then you'd only ever have to change your application's site.zcml to load a new plugin.
There's also this: http://pypi.python.org/pypi/z3c.autoinclude
Yep, that only saves you the <include package="..." /> directive, though.
I think I'll add a new directive to register my application specific plugins. That way, I can rely on my own entry points and whatnot. That gives me a nice way to not have to rerun buildout (rather, not have to rely on the operations department to rerun buildout). I'm planning on running through and setting up an HA installation using zc.zodbrecipe as long as that's a "standard" way of doing it. I'll throw it up on my blog; if I get it wrong, someone can correct me. Thanks for all of the help. It would be nice to have standard and somewhat generic installation guides. Nothing too in-depth, just something to get us Zope newbies pointed in the right direction. Jeff On Sun, Jul 13, 2008 at 1:47 PM, Philipp von Weitershausen <philipp@weitershausen.de> wrote:
Paul Winkler wrote:
On Sun, Jul 13, 2008 at 01:20:53PM -0400, Philipp von Weitershausen wrote:
Jeff McNeil wrote:
I'd love to be able to just drop an egg on the file system and tell Zope "Here, go load that one now" via configuration alone.
You could also write your own ZCML directive (+ a handler) that does that. Then you'd only ever have to change your application's site.zcml to load a new plugin.
There's also this: http://pypi.python.org/pypi/z3c.autoinclude
Yep, that only saves you the
<include package="..." />
directive, though.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
participants (4)
-
Andreas Jung -
Jeff McNeil -
Paul Winkler -
Philipp von Weitershausen