bin/upgrade command: json api connects to asyncworker zope process

[fredvd]

I've been using bin/upgrade recook for a very long time, a few months ago it suddenly stopped working for one of our sites with an 'internal server error' reported by the client (and also on the zope zeoclient).

I didn't connect the dots until I spotted the port the client tried to connect to: we had added a background asyncworker zeoclient to this project: the bin/upgrade script uses a simple

ftw.upgrade/ftw/upgrade/command/jsonapi.py

Line 215 in 6bae4e2

return sorted(buildout_path.glob('parts/*/etc/zope.conf'))

To get to the zope.conf and asyncworker comes before 'instance' or 'zeoclient'. The asyncworker doesn't have a full zope config and somehow fails in creating the authentication temp file on the server:

ERROR Zope.SiteErrorLog 1521720075.840.120536098429 http://localhost:9208/plone/upgrades-api/recook_resources
Traceback (innermost last):
  Module ZPublisher.Publish, line 138, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 48, in call_object
  Module ftw.upgrade.jsonapi.utils, line 121, in json_wrapper
  Module ftw.upgrade.jsonapi.utils, line 92, in action_wrapper
  Module ftw.upgrade.jsonapi.utils, line 200, in perform_tempfile_authentication
  Module ftw.upgrade.jsonapi.utils, line 212, in validate_tempfile_authentication_header_value
OSError: [Errno 2] No such file or directory

Some solutions I can think of:

• filter on 'sync' or 'async' hardcoded in the zope.conf filepath glob as these are most of the time associated with background zope processes
• add a command line option that allows you to select the instance names: "--client-partname zeoclient"

Drawback of a command line option is that you'd have to use it everytime or modify creation of the bin/upgrade script to add that parameter as a default. I always forget how to properly insert extra python code in scripts using zc.recipe.egg.... ;-)

[jone]

Ah that makes sense and is indeed annoying. I didn't run into that yet but I see the problem. Filtering or giving hints would absolutely make sense.

The hardcoded filter has the problem that it is not configurable. If someone has another client which is not called "async" it won't filter correctly and we'd have to exclude another string in a new release.
The command line option isn't that convenient, as you already stated.

Other ideas:

• We could look for an .upgrade.cfg in the root of the repository, where we could configure whiteliste and / or a blacklist of instance names.
• We could look for something in the zope.conf, indicating that the instance should be ignored or used. This can be added with zope-conf-additional via buildout.

I'd probably go with the config file as this is simple, convenient and flexible. It could also be used for other settings if we need that in the future.

[mauritsvanrees]

Ugly workaround: try parts/zeoclient/etc/zope.conf first, then instance, then the rest.

A better and easier possibility may be: read an environment variable ZOPECONF or FTW_ZOPECONF and use that in ftw.upgrade to get the zope.conf path. If the variable points to a non-existing file, fall back to the current method.

For users of ftw.upgrade, on the command line this would be passed with a simple export FTW_ZOPECONF=something. In a buildout config, you could do it like this:

[upgrade]
recipe = zc.recipe.egg:scripts
eggs = ftw.upgrade[colors]
initialization =
    import os
    os.environ['FTW_ZOPECONF'] = '${zeoclient:location}/etc/zope.conf'