[Web-SIG] WSGI deployment use case

[Ian Bicking]

I thought it would muck up the list of issues too much if I added too 
much commentary.  But then it's not that useful without it...

Ian Bicking wrote:
> Here's some types of applications:
> 
> * Things I (or someone in my company) codes.

I'm planning on making everything an egg.  I'm even thinking about how I 
can make my Javascript libraries eggs, though I'm not sure about that. 
We keep an internal index of these.

> * Full application someone else creates and I use.

I'm hoping these are eggable; if not we'll probably make them so, just 
so we can manage them.

> * Applications that are more like a service, that use inside an 
> application of mine.  These are end-point applications, like a REST 
> service or something.  An application like this probably appears to live 
> inside my application, through some form of delegation; unless it's a 
> service many applications share...?

This is more annoying.  Again, eggs.  But they get mounted somewhere, 
maybe based on configuration, maybe not.

If the application is nested, then my application will recursively use 
configuration to create these applications.

> * Middleware written by me for my internal use, maybe application-specific.

I'll probably apply these in my own factory functions.

> * Middleware written specifically for the framework I (or someone else) 
> uses.

Again, probably in a factory function.  Sometimes my own stuff will go 
above or below these.  Some pieces of the framework need to be aware of 
my special middleware (like a URL parser).

> * General-purpose middleware that could apply to anything.

This is stuff I want to configure globally; an open issue.

> Some kinds of deployments I want to do:
> 
> * Two clients with the same application, same version (like "latest 
> stable version").

I can potentially install these in a single process or in separate 
processes.  They each get a separate configuration.  Probably domain 
name based dispatching to the different configuration files.

> * Two clients with different versions; e.g., one client hasn't paid for 
> an upgrade (which might mean upgrading).

Definitely need two processes; otherwise no problem with Eggs -- that 
means I don't have to fiddle with PYTHONPATH, special package 
directories, etc.

> * A client with branched code, i.e., we've tweaked one instance of the 
> application just for them.

I don't know what to version such a branch as.  Maybe some version that 
goes before everything else, and use an explicit version requirement 
(==client_name_1.0)

> * Two installations of the same application, in the same process, with 
> different URLs and different configurations.  This might be something as 
> small as a formmail kind of script, or a large program.

Woops, same thing as before.  Anyway, I might use a pattern, like "/app" 
gets redirected in Apache to an application server that does further 
dispatching on URLs.  Or I might add specific rewriting and aliases to 
mount applications in their place.  These have to map to specific 
processes, maybe through some convention on port numbers, maybe 
filenames if I'm using something that talks over named sockets.

I guess potentially I could use an environmental variable to indicate 
which app I'm trying to point to (SetEnvIf style).  Or, rather, what 
configuration file I'm pointing to, since there's a many-to-one 
relationship between configuration files and applications.

> * Sometimes apps go into different processes, but often they can go into 
> the same process (especially if I start using Python WSGI for the kind 
> of seldom-used apps that I now use CGI for).

Deployment in these cases should be really light.  Definitely not a 
programming task.

> * I have to mount these applications at some location.  This should be 
> part of the deployment configuration; both path based and domain name based.
> 

... And then none of this configuration stuff is handled to my 
satisfaction...

> Here's some aspects of the configuration:
> 
> * Many applications have a lot of configuration.  Much of it is "just in 
> case" configuration that I'd never want to tweak.  Some of that 
> configuration may be derivative of things I do want to tweak, e.g., URL 
> layouts where I configure the base URL, but all the other URLs could be 
> derived from that.
> 
> * What appears to be an application from the outside might be composed 
> of many applications.  Maybe an app includes an external formmail app 
> for a "support" link.  That app requires configuration (like smtp server).
> 
> * I'd like to configure some things globally.  Like that smtp server. 
> Or an email address to send unexpected exceptions to.
> 
> * I might want to override configuration locally, like that email 
> address.  I might want to augment configuration, like just add an 
> address to the list, not reset the whole value.
> 
> * I'd like to install some middleware globally as well.  Like a session 
> handler, perhaps.  Or authentication.  Or an exception catcher -- I'd 
> like everyone to use my well-configured exception catcher.  So not only 
> am I adding middleware, I might be asking that middleware be excluded 
> (or should simply short-circuit itself).
> 
> * And of course, all my applications take configuration, separate from 
> middleware and frameworks.
> 
> * And usually there are non-WSGI pieces that need access to the exact 
> same configuration; scripts and cronjobs and whatnot.  Usually they just 
> need the application configuration, but nothing related to middleware or 
> the web.