Plone on WSGI sprint report

Two laptops, two sprinters and two bottles of whiskey. What could possibly go wrong?

This is my attempt to document what I can only describe as the “Plone on Whisk-gi” sprint… As part of the Plone deployment sprint at the recent Plone Conference in Bristol, Reed O’Brien and I decided to try to get Plone 4 working on WSGI.

Why is this important? Hanno Schlichting (current Zope2 release manager) tells us on his blog post about the recent Zope 2.13 release:

Zope 2.13 comes with native WSGI support. First pioneered in the repoze.zope2 project, this capability finally found its way back into the core and obsoletes the externally managed project. With WSGI, Zope 2 can natively talk to a variety of web servers and isn’t restricted to its own ZServer anymore. It also opens up new possibilities for writing or reusing middleware in Zope 2 or factoring out capabilities into WSGI endware. It’s expected that this new deployment model will over time become the default and the old ZServer implementation will be deprecated. There’s no concrete timeline for this yet.

What is Hanno saying here? Basically, it means that Zope 2.13 (and subsequently Plone) can run on a server without the added complexity of a long-running process (ZServer). Just as PHP-based applications enjoy ease of deployment since Apache already has mod_php enabled, so too could Zope-based applications be easily deployed if mod_wsgi were enabled.

In thinking about how Plone and Zope can be more accessible to systems administrators and hosting companies, moving to a scenario in which Zope does not require a separate long-running process, and can be deployed essentially at the Apache layer is a step in the right direction.

As Hanno alludes to above, with the WSGI deployment model, Zope/Plone are able to tap into a whole ecosystem of 3rd party WSGI middleware tools. Repoze is an initiative to extract many of the core Zope technologies into reusable WSGI middleware components, that can be used in other Python web application frameworks. More WSGI components can be found on PyPi by searching for “wsgi”.

Also, by adopting a more typical deployment method, Zope will not seem so exotic to developers coming to Zope from other Python web frameworks. For example, the official Django documentation recommends deploying Django using mod_wsgi, so Django developers will likely already be familiar with this way of deploying Python web applications. Incidentally, if you’re doing Django development, check out twod.wsgi which makes WSGI a first-class citizen in Django applications.

How does Plone fit in this picture?

Plone, arguably being the most popular Zope2 application on the market, can stand to benefit from the WSGI deployment strategy. There have already been some efforts to do so with repoze.plone and repoze.zope2 (now deprecated with the release of Zope 2.13).

Calvin Hendrix Parker blogged about deploying Plone and Zine together with Deliverance using Repoze, and Wojciech Lichota blogged about his buildout for Plone 3 with Deliverance on WSGI. Nathan Van Gheem has also written a couple blog posts about his experiences running Plone 4 with a Zope2 WSGI and running Plone 4b4 with Zope 2.13.0a1.

Now that Plone 4 is officially out and Zope 2.13 has had a final release, the instructions for getting this working are considerably easier.

Here are the steps required to get Plone 4 running under WSGI using paster.

1. Create a buildout.cfg file with the following:

[buildout]
extends =
    http://dist.plone.org/release/4.0.1/versions.cfg
    http://download.zope.org/zopetoolkit/index/1.0/zopeapp-versions.cfg
    http://download.zope.org/Zope2/index/2.13.0/versions.cfg

parts =
    instance
    paster

versions = versions

eggs +=
    roman
    Products.ZSQLMethods

[versions]
Zope2=2.13.0
Products.ZSQLMethods = 2.13.3

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
eggs +=
    ${buildout:eggs}
    Plone
    Paste
    PasteScript
    PasteDeploy
    repoze.tm2
    repoze.retry

[paster]
recipe = repoze.recipe.egg
scripts = paster
eggs = ${instance:eggs}

2. Create a zope2.ini file:

[DEFAULT]
debug = True

[app:zope]
use = egg:Zope2#main
zope_conf = %(here)s/parts/instance/etc/zope.conf

[pipeline:main]
pipeline =
    egg:paste#evalerror
    egg:repoze.retry#retry
    egg:repoze.tm2#tm
    zope

[server:main]
use = egg:paste#http
host = localhost
port = 8080

3. Run the buildout and modify the zope.conf file:

Run the buildout which will generate the paster script in the bin dir and the zope.conf file in parts/instance/etc. You then need to comment out the <http-server> part in this file. If you don’t comment out these lines, then paster will complain that there is already a server running on port 8080.

#<http-server>
# valid keys are "address" and "force-connection-close"
#  address 8080#
#</http-server>

4. Start up paster using the zope2.ini file:

$ paster serve zope2.ini
Starting server in PID 4666.
serving on http://127.0.0.1:8080

You can now go to http://127.0.0.1:8080 to see your Plone site served up by Zope on WSGI!

In the next blog post, we will describe how to get this semi-working in a production environment using mod_wsgi. For a sneak preview you can check out this buildout that Reed put together at the sprint. Note that there are a few patches that must be applied to Zope2, and hopefully Tres Seaver is reading this and will respond to them. 😉

What’s the official word on WSGI support for Plone 4?

Plone 4.1 will ship with Zope 2.13, but as Hanno states in PLIP #10776:

While Zope 2.13 provides native WSGI functionality, it is outside of this PLIP to make use of this in any way. There’s a large number of open questions around WSGI and the changes it requires to instance creation and setup, which warrant their own PLIP. A good number of those will also have an impact on the Zope 2 codebase itself, which is going to be already past a beta release by the time this PLIP gets started and thus will have to wait for Zope 2.14. I expect to see more community experimentation being done with WSGI once the capability is there. We might see a PLIP for Plone 4.2 to see those experimentations being solidified into good practice, standards and documentation.

So in other words, it’s still on the bleeding edge to try to use it, and probably not advised for production use just yet. As Hanno mentions, it’s expected that there will be more experimentation around WSGI, and as a community, we can come up with some best practices and documentation for how to do it in a sane way. Please let me know if you have done any experimentation with WSGI already, or if you’re interested in getting involved in these efforts.