[PATCH] Enable environments to attempt to upgrade automatically

[Dave Gynn <dgynn@…>]

Enabling new plugins that require upgrade_environment to be run blocks the environment from being accessible. The attached patch allows the plugins to attempt the upgrade if a new auto_upgrade config option is true. Assuming all goes well, the environment is accessible without needing to run trac-admin from the command line. If the upgrade fails, the user is shown the normal Trac Error.

The auto_upgrade option is false by default and should only be enabled in setups where admins can ensure that upgrades will work when run from the server (such as file system permissions).

[rblank]

The patch will also automatically perform an upgrade after a Trac update, which I find quite dangerous. I don't know if it would be possible to limit automatic upgrades to plugins only.

As is, I'm -1 on this functionality. Please reopen if you have additional suggestions.

[Dave Gynn <dgynn@…>]

Let me explain the use case for this. We have >200 workspaces and TRAC_ADMINs from those workspaces can enable some optional plugins that are installed but disabled for their environment by default. If one of those plugins (such as TracPastePlugin) requires a database change then that workspace is not available for anyone until a sysadmin can run the trac-admin upgrade from the command line.

I agree that this patch is potentially dangerous which is why it would definitely be off by default. I could modify the patch to exclude cases were IEnvironmentSetupParticipant is from trac.*. But I would trust Trac upgrades just as much an other upgrade. And I would only recommend enabling this option in an environment with known, tested plugins available.

[rblank]

Replying to Dave Gynn <dgynn@…>:

We have >200 workspaces and TRAC_ADMINs from those workspaces can enable some optional plugins that are installed but disabled for their environment by default.

Oh. I tend to forget that some people actually are deploying Trac on such a massive scale. Now I understand your request much better. Unfortunately, I don't have much experience in this field.

Simon, would you mind commenting on this patch? IIRC, you are familiar with such deployments and the associated issues.

[osimons]

Yes, I got the same issues at my site. I considered some sort of auto-upgrade, but as mentioned above it really needs to be used with much caution as it may easily cause much problems - and certainly with the plugin-upload form available in admin that may cause and run upgrades way out of sysadmin control.

So, at the time I went a different route with this. Here is the essence of my strategy - with example for the two plugins I use that involve db changes (trachacks:FullBlogPlugin and trachacks:DiscussionPlugin):

• In a global trac.ini I enable just the part (component) in the plugin that deals with upgrades - meaning the schema og all environments will always be prepared for the plugin regardless of actual use.

  [components]
  tracfullblog.db.* = enabled
  tracdiscussion.init.* = enabled
  

• I've disabled the general Plugins admin page, and replaced it with a simple 'Features' admin page where project owners can enable/disable as they please (from my pre-selected list of available features of course). Behind the scenes, this just writes the remaining config settings to the environment - the parts of the plugin that actually deal with user-related things. Example of the remaining settings for the blog plugin that is per-project enabled/disabled:

  [components]
  ...
  tracfullblog.admin.* = enabled
  tracfullblog.core.* = enabled
  tracfullblog.macros.* = enabled
  tracfullblog.web_ui.* = enabled
  

As I see it, this is just as much about plugin design as it is about auto-upgrade - at least for the use-case you describe - and the possibility to keep just the 'upgrade component' always enabled. Trac and plugin handling for large-scale deployment with distributed administration is just something that is not a priority with Trac for the time being - and you basically have to be prepared to make your own management code to accomodate special needs.

I don't mind the ticket staying open as a place to discuss how best to handle this in the long term, but I'm not too keen on the auto-upgrade either. Perhaps the solution is a more flexible 'Plugins' admin page, with config settings to remove upload form and 'freeze' certain component selections that a project administrator cannot change via web? Perhaps that webadmin component can detect request for enabling of plugin implementing IEnvironmentSetupParticipant, and if a new plugin needs to upgrade then then the admin page/component performs it?

[rblank]

Thanks for your comments.

[Dave Gynn <dgynn@…>]

That's a great idea, osimons. I hadn't thought about configuring the upgrade components separately that way. I suppose it is better to have all DB schemas in sync in a multi-project setup even if many envs don't require the tables. We have also replaced the plugin admin panel with a more controlled "options" panel so the upgrade could be kicked off there. But I like the idea of having everything in sync much better.

We can keep the ticket closed. Thanks, guys.